TL;DR
Both, and the split is not arbitrary. CLM holds the document and its history; the ERP holds the terms that price a purchase order. Microsoft documents it.
Both — and the split is not a matter of taste. The contract lifecycle system holds the document, its versions and its approvals. The ERP holds the handful of terms that actually price a purchase order.
Review the document where it lives. Enforce the terms where they act. Microsoft documents precisely which terms cross that line, and precisely what breaks the connection once they have.
What does each system actually hold?
A purchase agreement in Dynamics 365 is not a copy of the contract. It is the commercial commitment extracted from it:
"A purchase agreement is a contract that commits an organization to buy a specified quantity or amount by using multiple purchase orders over time. In exchange for this commitment, the buyer receives special prices and discounts."
And it outranks everything else in pricing: "The prices and discounts of the purchase agreement override the prices and discounts that are specified in any trade agreements that exist."
That is the distinction in one sentence. The signed PDF is the evidence. The agreement record is the authority — it is what the system consults when a buyer raises an order.
Microsoft defines four commitment types, and they are worth knowing because they decide what can be enforced at all:
| Commitment type | What is committed |
|---|---|
| Product quantity commitment | "a specific quantity of a product" |
| Product value commitment | "a specific currency amount of a product" |
| Product category value commitment | "a specific currency amount in a procurement category" |
| Value commitment | "a specific currency amount of any product or products in any procurement category" |
Which negotiated terms actually cross over?
A specific, short list — and this is the sentence to take to a vendor demo:
"When you create a PO, you can apply a purchase agreement to it. 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. If the PO contains one or more lines for products or categories that are covered by the agreement, the prices and discounts from the purchase agreement are used for those lines."
Payment terms, delivery terms, delivery address, prices, discounts. Those are the negotiated positions that become operative. Everything else in the contract — indemnity, liability caps, governing law, termination — stays in the document and never reaches the transaction.
That asymmetry is the whole design problem. The clauses your legal team argues hardest over are mostly not the clauses the ERP will enforce. A review system that only reads the document tells you about the first group. Nothing checks whether the second group arrived intact.
What silently breaks the connection?
Editing the price. Microsoft states it plainly under the agreement policies:
"Price and discount is fixed – The price on an order line and the price on the related commitment must be the same. If the price is changed on the order line, the link to the commitment is broken. If the link is broken, the order line doesn't contribute to the fulfillment of the commitment."
Read that twice. A buyer edits a price on one order line — plausibly for a good reason — and that line stops counting toward the commitment you negotiated. No error. The order proceeds. The agreement simply stops being fulfilled by that line, and the volume you promised in exchange for the discount quietly does not accumulate.
The neighbouring policies are worth configuring in the same sitting: Max is enforced, where "the total quantity or amount for all order lines can't exceed" the commitment, and the minimum and maximum release amounts, which "you receive a message" about rather than being blocked by.
This is the failure a contract review product will never show you, because it happens weeks later, in a different module, to a document the review never touched.
When can the agreement be applied at all?
Only at creation, and this constraint is unforgiving:
"You can select a purchase agreement only when you're creating a PO. You can't select a purchase agreement after the PO has been created."
There is no retrofit. An order raised without the agreement attached cannot be corrected into compliance later — it has to be recreated. For a team running high order volumes against negotiated agreements, that single sentence is worth more than most feature comparisons.
There is one useful counterweight. Confirming an agreement stores a version: "the current version of the purchase agreement is stored in a history table", and "You can preview or print all versions of the agreement" to share revisions with the vendor. Version history exists on the ERP side too — it is not a CLM-only capability.
So where should review actually live?
Review in the document. Verify in the record. Do not confuse the two. That split is ours, and it follows from the sections above:
- The document is where clauses are argued — indemnity, liability, termination, data protection. This is what Paralegent AI reads, clause by clause, against your own playbook.
- The record is where five terms become money — payment terms, delivery terms, delivery address, prices, discounts. Whether those arrived intact is a different question, and almost nobody asks it.
- The gap between them is where value leaks. A term negotiated in week one, typed into an agreement in week three, and detached by a price edit in week nine is not a legal failure. It is an operational one, and it is invisible to both systems.
This is where an AI optimization app for Microsoft Dynamics 365 belongs — beside the ERP rather than inside it. Paralegent AI reads the document against your playbook; the record stays the ERP's. We build these on request, which means the split above is a design conversation, not a licence you buy.
The build worth doing is the one that closes that gap — review the document, then check the record against what the review concluded. That is not a CLM feature and it is not an ERP feature. It sits between them, which is exactly where a companion app belongs.
Before choosing between CLM and the ERP at all, it is worth seeing every route on the table.
On the SMB tier that gap has a specific shape, because the record is a vendor card and a purchase line: what AI contract review looks like in Business Central.
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.
If the gap between the reviewed contract and the operative agreement is the part that worries you, bring one supplier agreement to a 15-minute call and we will trace it end to end.
Sources
Sources and fact-check
| # | § | Claim | Tier | Source | Verdict |
|---|---|---|---|---|---|
| 1 | 1 | The purchase-agreement definition, quoted whole | T1 — verbatim | purchase-agreements (ms.date 2026-09-08), fetched 2026-09-10, opening section | PASS — load-bearing |
| 2 | 1 | Agreement prices override trade-agreement prices | T1 — verbatim | Same section | PASS — load-bearing |
| 3 | 1 | The four commitment types, each quoted | T1 — verbatim ×4 | Same page, Commitment types | PASS |
| 4 | 2 | The terms copied to the PO header, quoted whole | T1 — verbatim | Same page, Applying purchase agreements in the ordering process | PASS — load-bearing |
| 5 | 2 | Indemnity, liability, governing law and termination do not reach the transaction | T2 — ours, bounded: read as the complement of the quoted list on this page. Not stated as a claim about everything Microsoft documents | Reading of claim 4 | PASS |
| 6 | 3 | The Price and discount is fixed policy, quoted whole including the broken-link consequence | T1 — verbatim | Same page, Policies for purchase agreements | PASS — load-bearing |
| 7 | 3 | No error is raised | T2 — ours, bounded: Microsoft describes the link breaking and the line not contributing, and documents no error. Stated as behaviour, not as "Microsoft says no error" | Same policy | PASS |
| 8 | 3 | Max is enforced, and release amounts produce a message | T1 — verbatim | Same section | PASS |
| 9 | 4 | An agreement can be selected only at PO creation | T1 — verbatim | Same page, same section | PASS — load-bearing |
| 10 | 4 | Confirmation stores a version in a history table; all versions can be printed | T1 — verbatim | Same page, Confirmations and version history | PASS |
| 11 | 5 | Review the document, verify the record; the gap is where value leaks | T2 — ours, and §5 says so | Internal definition | PASS |
Tier summary: 9 × T1 (all verbatim), 3 × T2 — 0 × T4.
Absence claims: two, both bounded in the body and in rows 5 and 7. Neither is stated as a claim about what Microsoft has not published anywhere — each is bounded to the page fetched on 2026-09-10 and framed as the complement of a quoted positive.
Disclosure: no client named or implied, no measured outcome, no deployment claim. Paralegent AI is described by what it reads, and the CTA is a private call.
