What Is Three-Way Matching?

Three-way matching is the control most accounts-payable teams lean on to stop paying for goods that never arrived, and it does that job well. The purchase order says what was ordered, the goods receipt records what the warehouse signed for, and the invoice states what the vendor wants paid; when the three agree on item and quantity, the invoice clears the receipt gate. The trap is assuming a passed match also certifies the price. It does not. A three-way match confirms fulfilment — the order was received in the quantity billed — but says nothing about whether the unit price equals the one you negotiated. Price correctness lives in a separate tolerance check, with its own settings and its own messages. Conflating the two is why wrong prices sail through on correctly received goods.

Definition

Three-way matching compares three sources before an invoice is approved for payment: the purchase order (what was agreed), the goods receipt (what was received), and the invoice (what is being billed). The invoice is released only when all three line up on item and quantity. Drop the receipt leg and you have two-way matching — purchase order against invoice alone — which is faster but trusts the vendor’s word that the goods arrived.

SAP calls this GR-based invoice verification: the invoice is checked against the quantity actually posted at goods receipt, not merely against the order. Microsoft Dynamics 365 Finance exposes it as one of six named matching features — Invoice totals matching, Two-way matching, Three-way matching, Charges matching, Net unit price matching, and Price totals matching — and reports the outcome per line as a Passed or Failed status. On a two-way-matched line, the Product receipt quantity match column is simply left blank, because there is no receipt to read.

Why three-way matching misses a wrong price

A three-way match is a quantity control. It asks whether the quantity billed was ordered and received — and stops there. Nothing in the three documents it reads tells it what price you negotiated, so a vendor can bill a perfectly received quantity at the wrong unit price and the match will still pass. Price correctness is checked separately, by a tolerance comparison, and whether that check even blocks the invoice is a configuration choice.

In SAP, that separate check is an invoice price variance: the system compares the computed invoice price against the net order price under a dedicated tolerance key, PP, and issues Price too high (tolerance limit of & & exceeded) (M8 082, an absolute limit) or Price too high (tolerance limit of & % exceeded) (M8 083, a percentage limit). The quantity messages — such as Quantity invoiced greater than goods receipt quantity (& &) (M8 081) — are a different family entirely. SAP’s four blocking reasons keep them apart: Quantity, Price, Quality, and Date.

The subtlest failure is when the price looks wrong but is right: a correct unit price divided by a wrong order price quantity computes a variance and blocks the invoice as a price problem when the real fault is units — the case the guide the error says price, the cause is units walks through, and the reason SAP price-variance tolerances seem not to work when you simply widen them.

Before and after: a quantity match vs. a real price check

How to check price when three-way matching cannot

1. Run the three-way match for what it is good at. Confirm the purchase order, goods receipt, and invoice agree on item and quantity. A clean quantity match is necessary — it is not proof the price is right.

2. Add the price gate the match does not give you. Compare each billed unit price against the price you actually agreed — the contract, or the price-list version in force on the order date. A price-list diff surfaces the agreed-versus-billed gap that the quantity match never reads.

3. Check the units beneath the price. A right price divided by the wrong order price quantity computes as a price variance, so confirm the unit the vendor priced in matches the unit you ordered and received. A unit and dimension converter confirms the conversion factor before you treat it as a pricing dispute.

4. Set the price check to block, not just warn. In SAP, tighten tolerance key PP and confirm the message type for M8 082 / M8 083 blocks the invoice for payment rather than only warning. In Dynamics 365, configure the price-total tolerance instead of leaving the legal-entity default.

5. Fix the source record, not the single invoice. Write the corrected contract price or conversion factor back to the item or agreement so the next invoice inherits it, instead of releasing block after block by hand.

Related

FAQ

What is the difference between two-way and three-way matching? +

Two-way matching compares the purchase order with the supplier invoice — item, quantity, and amount — and nothing else. Three-way matching adds the goods receipt, so the invoice is paid only for the quantity the warehouse recorded as received, which is what catches short shipments and quantities billed but never delivered. In Dynamics 365 Finance a two-way-matched line leaves the Product receipt quantity match column blank, because there is no receipt to read.

Does a passed three-way match mean the price is correct? +

No. A three-way match confirms the quantity billed was ordered and received; it never reads the price you negotiated, so a correctly received quantity can still be billed at the wrong unit price and pass. Price correctness is a separate tolerance check with its own settings — in SAP, tolerance key PP and the price-variance messages M8 082 and M8 083. If that check only warns, or its limits are wide, a wrong price clears a clean quantity match.

What does three-way matching actually verify? +

That the order was fulfilled as billed: the item and quantity on the invoice agree with the quantity ordered and the quantity recorded at goods receipt. It is a fulfilment and quantity control. It does not verify price agreement, contract compliance, or that the units underneath the price are consistent — those are separate checks, if they run at all.

How does SAP perform three-way matching? +

SAP uses GR-based invoice verification: the invoice is checked against the quantity posted at goods receipt, not only against the purchase order. A quantity mismatch raises a message such as M8 081, “Quantity invoiced greater than goods receipt quantity”, whose type is configurable as an error or a warning. Price is handled by a different family of tolerance keys and messages, and SAP keeps the two apart through four blocking reasons: Quantity, Price, Quality, and Date.

Do Dynamics 365 and Business Central support three-way matching? +

Dynamics 365 Finance does, as one of six named matching features; three-way matching is enabled through the line matching policy and each line reports Passed or Failed. Business Central is different: it enforces that you can never invoice more than you have received, but has no native matching-policy or price-tolerance framework, so partners add that through extensions. Do not assume a built-in three-way-match tolerance setting exists in Business Central.

How does Claro help with three-way matching? +

Claro does not replace your ERP’s matching engine — it fixes the data the engine matches against. It resolves every supplier line to one canonical product record with known units, conversion factors, and the agreed price from the list in force, so the quantity match and the separate price check both run against trusted figures. Instead of chasing a price block that is really a unit error, or finding a wrong price months later in an audit, the discrepancy surfaces on the invoice — the job of invoice reconciliation against trusted catalog data.

REVIEW-NOTES

• M8 081 short text — SE91 spot-check needed (brief accuracy rule 6). This piece quotes M8 081 verbatim: in the “Why” table as Quantity invoiced greater than goods receipt quantity (& &) and, without the (& &) placeholder, in FAQ Q4. Two sources word this short text differently; confirm the exact SE91 text (message class M8, number 081) before publication and align both quotations.
• No other accuracy flags. Every artefact traces to the brief appendix: two-/three-way matching and GR-based invoice verification; SAP tolerance key PP with M8 082 (& &, absolute) / M8 083 (& %, percentage), ampersand placeholders preserved and message type noted as configurable; the four SAP blocking reasons (Quantity, Price, Quality, Date); Dynamics 365’s six named matching features, Passed/Failed statuses, and the blank Product receipt quantity match column on a two-way line; Business Central’s “never invoice more than received” rule and its lack of a native matching-policy/price-tolerance framework. No ERP error string was invented — Dynamics 365 is described only via Passed/Failed statuses and match icons, and Business Central’s message text is not quoted because Microsoft does not publish it.
• Intra-cluster links are to existing pages only. Inline links point to invoice-price-variance, tolerance-key, unit-of-measure, error-says-price-cause-is-units, sap-price-variance-tolerance-not-working, price-list-diff, and unit-dimension-converter, all present. Siblings not yet shipped (e.g. blocked-invoice, price-list-version) were deliberately not linked; add them in the final cross-link commit once they exist.