Three-way matching cannot catch a purchase order that was…

Three-way matching cannot catch a purchase order that was priced wrong

Dynamics 365 checks the invoice against the purchase order. It checks the receipt against the purchase order. It never checks the purchase order against the contract that was supposed to price it.

So a buyer types £4.38 where the agreement says £4.10, and every control downstream passes — because they are all measuring against the £4.38.

For the CFO or controller who signed off a three-way matching policy and assumed it covered price. Finance & Operations. 7 minute read.

The reference price is the purchase order

From Accounts payable invoice matching overview (ms.date 2025-05-15 — Microsoft marks this page evergreen on a 1,095-day update cycle, so the age is deliberate rather than neglect):

"Accounts payable invoice matching is the process of matching vendor invoice, purchase order, and product receipt information."

Three documents. The invoice, the PO, the receipt. The agreement is not one of them.

And the benchmark is explicit: "The expected invoice totals are calculated based on the prices, charges, and sales tax information from the purchase order and the quantities from the invoice."

The PO is not one input among several. It is the definition of expected.

What the four matching types actually compare

All four, quoted from the same page:

Invoice totals matching — "Match the total amounts on the invoice to the total amounts on the purchase order"
Two-way matching — "Match the price information on the invoice to the price information on the purchase order"
Three-way matching — "Match the price information on the invoice to the price information on the purchase order. Also match the quantity information on the invoice to the quantity information on the product receipts"
Charges matching — "Match the charges information (amounts) on the invoice to the charges information (amounts) on the purchase order"

Four controls. Four appearances of the phrase "on the purchase order", and no appearance of the word agreement.

The tolerance machinery is genuinely good, which is what makes this easy to miss. Microsoft's own example runs a PO for 1,000 batteries at 1.00 each against an invoice at 1.10. Microsoft continues: "Your legal entity policy allows a 5 percent net unit price tolerance for this category of item. A price of 1.05 would be acceptable, but 1.10 is not." Tolerances configure down to item, item group, vendor, vendor group, item-and-vendor, or legal entity, on the Price tolerances page.

That precision is aimed entirely at one question: did the vendor invoice what we ordered? It is silent on the prior question: did we order what we agreed?

The override that erases its own evidence

Now the part worth taking to your procurement lead. From Purchase agreements (ms.date 2025-07-21), the three policies that govern the link between a commitment and its PO lines:

Max is enforced — "The total quantity or amount for all order lines can't exceed the quantity or amount that is specified on the related commitment"
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"
Minimum / Maximum release amount — "you receive a message if you make any change to an order line that causes the order line to differ from the related commitment"

Read the middle row twice. It is named like an enforcement and it is not one.

Changing the price does not fail. It detaches. The line keeps the new price, loses its connection to the agreement, and stops counting toward fulfillment. The agreement that proves the price was wrong is the exact thing the wrong price disconnects.

That is why this leak is quiet. There is no discrepancy icon, no held invoice, no blocked posting — the evidence removed itself, and the only visible symptom is a fulfillment figure that looks like under-buying.

You cannot re-attach it afterwards

Two more sentences from the same page close the door.

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

So a PO raised without its agreement can never be corrected into one. And where an agreement does apply, it wins: "The prices and discounts of the purchase agreement override the prices and discounts that are specified in any trade agreements that exist."

Precedence is settled. Attachment is a one-time event at creation. Between those two facts sits every PO somebody raised in a hurry.

The arithmetic, and both numbers are already in your system

Take a four-plant Tier 1 automotive supplier running three legal entities. One bracket, one vendor, one purchase agreement: 240,000 units at £4.10, an 18-month commitment.

POs raised on the agreement — Units: 186,000 · Price: £4.10 · Agreement link: linked
POs raised during a shortage, re-keyed — Units: 54,000 · Price: £4.38 · Agreement link: broken
Fulfillment shows — Units: 186,000 of 240,000 · Agreement link: a 54,000 shortfall

The shortfall is not under-buying. It bought all 240,000 — 54,000 of them at £0.28 over the agreed price. 54,000 × £0.28 = £15,120, on one part, from one vendor, in one entity.

Every invoice in that second row matched its PO perfectly. Three-way matching did its job.

And the fulfillment shortfall is the pointer: it is the ERP telling you, in the only language it has, that lines which should have counted did not. Microsoft even gives you the drill-down — the Related information action on an agreement line reaches the PO and invoice lines that contribute to the fulfillment calculation. The ones that stopped contributing are the question.

What we would reject

We would not build a second matching engine. Invoice matching is correct, well-configured and already trusted by your finance team. Adding a parallel control that disagrees with it creates an argument, not a saving.

We would not let a model change a price. A price is a commercial commitment to a supplier. The audit proposes; a buyer decides; the ERP records. Anything else is an incident with your name on it.

And we would not touch your procurement configuration. Agreement classifications, matching policies and tolerance bands are your implementation partner's ground and they should stay there.

How we build it, and the query for Monday

Pricing & Discount Optimizer decides the margin-optimal price and discount and writes it back into the agreements and price lists Dynamics already executes, behind an approval step. This audit is its mirror on the buy side: it finds every line where the agreed price existed and was not used.

A working demo exists; we build these on request. We have no delivered pricing engagements, so that is a capability statement rather than a report on somebody's business.

Monday, one query, no software. For each effective purchase agreement, list PO lines to the same vendor and item, in the agreement's validity window, that carry no agreement link. Then price the difference. That set is the leak, and it is already sitting in your system waiting to be counted.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Worked example. Modelled from public documentation and typical operations.

Want to know what the gap between your agreements and your purchase orders is worth? Book a 15-minute call — we'll walk the decision and the model with you, on your data if you bring it. No deck.

Three-way matching cannot catch a purchase order that was priced wrong