TL;DR
One place for the document, one for the terms that act. A repository holding files solves finding; it does not solve knowing, and those are different problems.
One place for the document, and one for the terms that act on it. Those are two systems, not one, and trying to make a single repository do both is why consolidation projects stall.
*A repository solves finding. It does not solve knowing.*
Why do contracts end up in six places?
Because each of the six was a rational decision at the time:
| Where | Why it happened |
|---|---|
| It arrived as an attachment and got answered | |
| A shared drive | Somebody needed a copy the whole team could open |
| The e-signature system | It executed there, so the signed original is there |
| Procurement's own folder | They own the supplier relationship |
| Someone's laptop | They were negotiating it and it never moved |
| The ERP | The terms that price orders had to be entered somewhere |
Nobody chose fragmentation. Six sensible local decisions produced it, which is why telling people to "just use the repository" does not work — each copy exists because it solved something.
The last row is the one that gets missed, and it is different in kind from the other five. The others are copies of a document. That one is the contract operating.
What are people actually complaining about?
Two different problems wearing one sentence:
- "I cannot find it." A finding problem. Solved by one place, consistent naming, and search.
- "I do not know what we agreed." A knowing problem. Not solved by storage at all — you can have every contract in one folder and still not know your aggregate liability exposure or which renewals land next quarter.
Most repository projects solve the first and are sold as solving the second. The second needs the contract turned into data — obligations as records rather than paragraphs.
Diagnose which one you have before buying anything. If your team can find contracts and still cannot answer questions about them, a repository will change nothing.
What does a repository have to hold to be useful?
Four things. Files alone is a folder, not a repository:
- The executed document, immutable, with its version history and what it superseded.
- Metadata that is queryable — counterparty, dates, value, owner, renewal terms. Typed fields, not a filename convention.
- Provenance for every extracted field — a pointer back to the clause it came from, so a disputed number can be traced in one click.
- One place that is authoritative, with the other five explicitly labelled as copies.
The fourth is a policy decision, not a technical one, and it is the one that actually stops the scatter. A repository without a stated authority just becomes the seventh place.
Where do the terms that act actually live?
In the ERP, whether the repository project acknowledges it or not.
Microsoft's purchase agreement is not a stored copy — it is the operative commitment. Its terms are pushed into transactions:
"Information from the terms for the agreement, such as the payment terms, delivery terms, and delivery address, is then copied to the header of the PO… the prices and discounts from the purchase agreement are used for those lines."
And its prices outrank the rest of the pricing system: "The prices and discounts of the purchase agreement override the prices and discounts that are specified in any trade agreements that exist."
So the ERP is not one of the six scattered places. It is the second authoritative system — and the honest architecture names both: the document lives in the repository, the terms live in the record.
The failure that costs money is the drift between them, and it is silent. Under the agreement policies, "If the price is changed on the order line, the link to the commitment is broken." No error. The document in your tidy repository still says what you negotiated; the record has quietly stopped honouring it.
How do you actually consolidate?
Order of operations matters more than the software choice, and this is ours:
- Declare the authority first. One system is the source of truth for documents. Everything else is a copy, labelled. This is a memo, not a migration.
- Inventory before you move. You cannot consolidate what you have not listed. The inventory is also the moment you discover which agreements are missing entirely.
- Extract on the way in, not later. A document that arrives without typed metadata arrives as a file, and files accumulate.
- Reconcile against the ERP. For anything with money attached, check that the record says what the document says. This is where the value is, and it is the step nobody schedules.
Steps 1 and 2 need no software. If a project starts at step 3 with a purchase order, it is solving finding and calling it knowing.
About Cognilium Cognilium builds AI optimization apps for Microsoft Dynamics 365 — companion apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Dynamics is your system of record. Cognilium is your system of intelligence. https://cognilium.ai · https://www.linkedin.com/company/37180269/
Legal AI Ops. We transform legal workflows with agentic AI, copilots, agentic workflows and decision intelligence — built into core workflows rather than beside them, to raise productivity and cut operational overhead. Contract Review Copilot is the contract-review app in that family. It ships as Paralegent AI, in production today. How we build Legal AI Ops — custom AI capabilities on top of legal work, against your playbook and your Dynamics 365.
Bring your six places to a 15-minute call and we will tell you which of them is actually authoritative, and which one is quietly disagreeing with your ERP.
Sources
Sources and fact-check
| # | § | Claim | Tier | Source | Verdict |
|---|---|---|---|---|---|
| 1 | 1 | The six places, each a rational local decision | T2 — ours, an observation, unquantified. No client, no count | Internal definition | PASS |
| 2 | 2 | Finding and knowing are different problems | T2 — ours, the article's central argument | Internal definition | PASS |
| 3 | 2 | Most repository projects solve finding and are sold as solving knowing | T2 — ours, bounded. Our reading, no vendor named, no figure | Internal definition | PASS |
| 4 | 3 | The four requirements of a usable repository | T2 — ours | Internal definition; profile §11 | PASS |
| 5 | 4 | The copied-terms passage | T1 — verbatim | purchase-agreements (ms.date 2026-09-08), fetched 2026-09-10 | PASS — load-bearing |
| 6 | 4 | Agreement prices override trade agreements | T1 — verbatim | Same page, opening | PASS — load-bearing |
| 7 | 4 | The price edit breaks the commitment link | T1 — verbatim | Same page, Policies | PASS — load-bearing |
| 8 | 4 | No error is raised | T2 — ours, bounded: Microsoft documents the break and documents no error | Same policy | PASS |
| 9 | 5 | The four-step consolidation order | T2 — ours | Internal definition | PASS |
Tier summary: 3 × T1 (all verbatim), 6 × T2 — 0 × T4.
Absence claim: one, row 8, bounded to the fetched page and stated as observed behaviour.
Disclosure: no client, no count, no measured outcome. §5 states that two of four steps need no software, and §2 tells a class of reader not to buy.
