TL;DR
Four things, all documented by Microsoft. A changed price breaks the commitment link, an agreement cannot attach after the order exists, and a field is cleared.
Four things, and Microsoft documents every one of them. Changing a price on an order line breaks the link to the commitment. A purchase agreement cannot be attached after the order exists. Amendments to an agreement never reach orders already released. And in one documented case a field is cleared rather than replaced, by design.
None of this is a defect in your CLM. It is how the ERP works, and it is knowable before you integrate.
Why does nobody publish this?
Because of who would have to write it.
A CLM vendor cannot publish the failure modes of its own integration without arguing against its own sale. Microsoft documents the ERP behaviour thoroughly, but has no reason to write the article that maps it onto a third-party product. The result is a gap that is structural rather than accidental, and it sits exactly where a buyer needs an answer.
What follows is the ERP side, quoted from Microsoft's own documentation. Your CLM may handle some of it well. The point is that you can check, before you sign, rather than after the first quarter-end.
What happens when a price changes on the order line?
The commitment link breaks. Microsoft states it directly in the purchase 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 the second half again, because it is the part that costs money. The order still exists. The goods still arrive. The invoice still posts. What stops is the order's contribution to fulfilling the commitment.
So a negotiated volume commitment can be quietly under-fulfilled by orders that were placed against it, priced differently, and silently detached. Nothing fails. A rebate or tier you had earned simply does not arrive, and the fulfilment figure that would have shown it is wrong.
What to check in your integration: whether anything in the chain — the CLM, a middleware step, a person correcting a price — writes to the unit price on a released order line. If it does, ask what happens to the commitment.
Can a CLM attach an agreement to an order after the fact?
No. This is the hardest limit in the set, and it is stated plainly:
"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."
That single sentence rules out an entire integration pattern. If your design is "let procurement raise the order, then have the CLM match it to the right agreement and link them", it cannot work. The window is at creation, and it does not reopen.
Microsoft does allow the search to happen automatically in some indirect cases: the documentation notes you can control whether Supply Chain Management "automatically searches for applicable purchase agreements" when firming planned orders or creating orders from sales orders. That is the seam worth designing around, and it is a very different build from post-hoc matching.
What to check: whether your CLM expects to link agreements to existing orders. If it does, that capability will not survive contact with this ERP.
Do amendments reach orders that already exist?
Not for financial dimensions, and the documentation is explicit about the split:
"If you change the dimensions in the agreement header or on the agreement line, the change doesn't affect any released orders, but it will be reflected on any new orders."
This is the amendment problem in one line. A renegotiated agreement updates the agreement. Orders already released against the old terms keep the old terms. That is reasonable ERP behaviour — you would not want a retroactive rewrite of posted documents — but it means the answer to "is this order on current terms?" is genuinely ambiguous, and no integration resolves that ambiguity by itself.
A CLM that pushes an amendment into Dynamics has updated the agreement. It has not updated the orders. Whether that matters depends on what was amended and what is still open, and that is a judgement a person has to make with both facts in front of them.
Which fields are silently dropped?
At least one, and it is documented as intentional.
When you apply a purchase agreement to a PO, you are prompted to transfer the currency and delivery address. Microsoft describes what happens when the agreement has no saved header defaults:
"If the agreement doesn't yet have a saved set of header defaults, there's no address for the transfer to apply, so it clears the delivery address on the PO instead of replacing it. This behavior is by design."
Cleared, not left alone. An address that was correct on the order is removed because the agreement had nothing to put there. Microsoft even publishes the workaround: open the agreement, update at least one header field, save it so the defaults are created, then reapply.
That is the shape to look for across any integration. The failure is not an error message. It is a field that is now empty, on a document that still posts.
What about Business Central?
Different structure, same lesson. Business Central's subscription contracts hold real fields for the things a contract decides — the vendor contract documentation names Cancellation possible until and Term until among the fields carried on a subscription line.
The fields exist. Whether they agree with the signed document is a separate question, and nothing in the ERP raises it. A CLM can populate them. Only something reading both the agreement and the record can tell you they have drifted apart.
What should you actually do with this?
Four questions, before the integration is scoped rather than after.
- Does anything write to price on a released order line? If yes, the commitment link is at risk.
- Does the design assume agreements can be attached after order creation? If yes, redesign now.
- What is the plan for amendments against already-released orders? "The CLM holds the current version" is not a plan; it is a description of the problem.
- Which fields does the write-back touch, and what is the behaviour when the source value is empty? Ask specifically about clearing versus leaving alone.
None of these require a vendor to answer honestly. They are all checkable against Microsoft's own documentation, which is the point.
Sources
- Purchase agreements — Supply Chain Management, Microsoft Learn · ms.date 2026-09-08
- Vendor subscription contracts — Business Central, Microsoft Learn · ms.date 2026-05-04
Sources and fact-check
| # | Claim | Tier | Source | Verdict |
|---|---|---|---|---|
| 1 | Changing the price on an order line breaks the link to the commitment, and the line then does not contribute to fulfilment | T1 verbatim | Purchase agreements, Microsoft Learn | PASS — quoted from the Policies section |
| 2 | A purchase agreement can be selected only at PO creation, not after | T1 verbatim | Purchase agreements, Microsoft Learn | PASS — quoted |
| 3 | Dimension changes do not affect released orders but do affect new ones | T1 verbatim | Purchase agreements, Microsoft Learn | PASS — quoted |
| 4 | Applying an agreement with no saved header defaults clears the delivery address, by design | T1 verbatim | Purchase agreements, Microsoft Learn | PASS — quoted, including "This behavior is by design" |
| 5 | Supply Chain Management can automatically search for applicable agreements when firming planned orders | T1 verbatim | Purchase agreements, Microsoft Learn | PASS — quoted |
| 6 | Business Central subscription lines carry Cancellation possible until and Term until | T1 verbatim | Vendor subscription contracts, Microsoft Learn | PASS — both named in the merge criteria |
| 7 | These failures are silent rather than raising an error | T2 ours | Inference from the documented behaviour | PASS — no error condition is described for any of the four |
| 8 | A CLM vendor has no incentive to publish its own integration failure modes | T2 ours | Our reading of the market | PASS — stated as our view, not as fact about any named vendor |
More on this: AI for legal operations on Dynamics 365 and SAP.
