Back to Blog
Published:
Last Updated:
Fresh Content
Legal AI in the ERPChapter 8

How do negotiated terms reach a purchase agreement in Dynamics 365?

7 min read
1,602 words
high priority
Ali Ahmed

Ali Ahmed

AI Solutions Engineer, Cognilium AI

TL;DR

Five terms cross over and the rest stay in the document. An agreement attaches only at purchase-order creation, and a changed price breaks the link silently.

Less than most people assume, and the limits are published rather than discovered. The interesting answer is not what the API permits — it is what the agreement's own rules make safe.

An agent that writes carelessly here does not throw an error. It quietly detaches a commitment.

What is actually writable?

The terms that cross from an agreement into a transaction are a short list, and Microsoft names them:

"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. That is the operative surface.

And the agreement outranks the rest of the pricing system while doing it: "The prices and discounts of the purchase agreement override the prices and discounts that are specified in any trade agreements that exist."

So a write here is not a data update — it is a change to what every future order will charge. That is the reason to be conservative about it, and the reason the CLM-versus-ERP split matters more than it looks.

When can any of this be applied?

At creation. Once only. Microsoft is unambiguous:

"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 repair path. An order raised without its agreement attached cannot be corrected into compliance — it has to be recreated.

For an agent, this collapses a design question into a single rule: the moment of order creation is the only moment that matters. Any workflow that plans to enrich orders afterwards is building on something the platform does not offer.

What breaks without telling anyone?

Editing a price. This is the most important paragraph on the page:

"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."

No exception is raised. The order is valid. The commitment simply stops being fulfilled by that line.

This is the single strongest argument for an agent that proposes rather than writes. A silent price correction — the most obvious thing such a system might do — is precisely the action that detaches the line from the agreement it was meant to honour.

The related policies bound the damage: Max is enforced means "the total quantity or amount for all order lines can't exceed" the commitment, while minimum and maximum release amounts only mean "you receive a message" — a notification, not a block.

What actually preserves the record?

Confirmation, and it is optional in a way that matters:

"When you confirm a purchase agreement, the current version of the purchase agreement is stored in a history table… If you don't confirm a purchase agreement, you can still use it to create POs. However, the history information for the purchase agreement isn't stored."

An unconfirmed agreement works and remembers nothing. Orders flow, prices apply, and there is no stored version to point at when someone asks what the terms were in March.

For anything that changes an agreement — human or agent — confirmation is the step that makes the change auditable. Microsoft also notes all versions can be previewed or printed, and revisions shared with the vendor for approval.

What about the fields nobody mentions?

Two more are worth knowing, because they change who is accountable rather than what is charged.

The matching policy sits on the agreement header. Microsoft documents that "Documents that reference the purchase agreement will use the line matching policy that's defined on the purchase agreement header", unless overridden further down.

So a term negotiated into the agreement governs how invoices are matched later — a downstream consequence most contract reviews never consider.

Financial dimensions behave asymmetrically. Changing them on the header or a line "doesn't affect any released orders, but it will be reflected on any new orders." Old orders keep the old coding; new ones get the new. For an agent that means a dimension change is never retrospective, and any analysis that assumes otherwise will not reconcile.

So what should an agent do instead?

Propose, with the evidence attached. Let a person commit. This is our position, and the sections above are why:

  • Write nothing to a price. It is the one field whose edit silently breaks the commitment link. An agent should surface the discrepancy and name the agreement it came from.
  • Attach at creation or not at all. There is no later. If the agreement cannot be resolved when the order is raised, that is a blocking question, not a background task.
  • Make confirmation part of the change, not an afterthought. An unconfirmed change is invisible to whoever inherits the relationship.
  • Cite the clause and the rule. A proposal that says "the contract says thirty days, the agreement header says sixty" is actionable. One that says "payment terms may be inconsistent" is not.

On Business Central the same discipline applies to a smaller surface — a blanket order and a vendor card rather than a purchase agreement: how the check works there, and what each tier actually holds.

That is the boundary Paralegent AI is built to respect — our contract-review app in Cognilium's family of AI optimization apps for Microsoft Dynamics 365, built on request against your own agreements. We build these; we do not sell you a licence and leave — it reads the document, reports what the record ought to say, and leaves the commitment to a person.

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 one supplier agreement and the purchase agreement it produced to a 15-minute call, and we will show you where they disagree.

Sources

Sources and fact-check
#§ClaimTierSourceVerdict
11The copied-terms passage, quoted wholeT1 — verbatimpurchase-agreements (ms.date 2026-09-08), fetched 2026-09-10, Applying purchase agreements in the ordering processPASS — load-bearing
21Agreement prices override trade agreementsT1 — verbatimSame page, opening sectionPASS
32Selection is possible only at PO creationT1 — verbatimSame page, same sectionPASS — load-bearing
43The Price and discount is fixed policy, quoted wholeT1 — verbatimSame page, Policies for purchase agreementsPASS — load-bearing
53No exception is raisedT2 — ours, bounded: Microsoft documents the link breaking and the line not contributing, and documents no error. Stated as behaviour, not attributed to MicrosoftSame policyPASS
63Max is enforced; release amounts produce a message rather than a blockT1 — verbatimSame sectionPASS
74Confirmation stores a version; without it no history is storedT1 — verbatimSame page, Confirmations and version historyPASS — load-bearing
7b4aLine matching policy is defined on the agreement header and governs referencing documentsT1 — verbatimSame page, Matching policy on purchase agreementsPASS
7c4aFinancial-dimension changes do not affect released orders but apply to new onesT1 — verbatimSame page, Financial dimensions on purchase agreementsPASS
85An agent should propose rather than write, and never touch priceT2 — ours, and §5 says so. Follows from claims 4 and 7Internal definitionPASS
95Paralegent AI reports rather than commitsT2 — capability, no outcome claimedParalegant_TECHNICAL_PROFILE.md §11PASS

Tier summary: 8 × T1 (all verbatim), 3 × T2 — 0 × T4.

Absence claim: one, row 5, bounded to the fetched page and phrased as observed behaviour rather than as a claim about Microsoft's complete documentation.

Disclosure: no client, no count, no measured outcome. The product is described by what it refrains from doing, which is the honest framing here.

Share this article

Ali Ahmed

Ali Ahmed

AI Solutions Engineer, Cognilium AI

Ali Ahmed is an AI Solutions Engineer at Cognilium AI.

Applied AI AgentsAgentic SystemsRetrieval-Augmented Generation (RAG)LLM Product Engineering
Next in this series
What is obligation extraction, and where should the obligations live?
Chapter 9 · 6 min
In short

Key takeaways

  • Only five things cross from agreement to order — payment terms, delivery terms, delivery address, prices and discounts — and those prices override trade agreements.
  • An agreement attaches at purchase-order creation and never afterwards. There is no repair path.
  • Changing a price on an order line breaks the commitment link silently, and that line stops counting toward fulfilment.
  • An unconfirmed agreement works but stores no version history, so there is nothing to point at later.
  • An agent should propose with evidence, not write. The most obvious unattended fix is the one that detaches the commitment.
What goes wrong

Common mistakes to avoid

  • Letting an agent correct a price. That single action breaks the link the contract was negotiated to create.
  • Planning to attach agreements to orders after the fact. The platform does not allow it.
  • Skipping confirmation because the agreement already works. It works and it remembers nothing.
  • Flagging an inconsistency without naming the rule. A finding that cannot cite its source cannot be acted on.

Frequently Asked Questions

Find answers to common questions about the topics covered in this article.

Still have questions?

Get in touch with our team for personalized assistance.

Contact Us

Still have a question this did not answer?

The person who wrote this article answers these. Describe your setup and what you are stuck on — you will get a straight answer, including where we think the approach is wrong.