TL;DR
Two-way compares invoice price to purchase order price. Three-way adds the receipt quantity. Under two-way the product receipt is not tested at all.
Two-way compares the invoice price to the purchase order price. Three-way adds the product receipt quantity. The consequence is the part worth knowing: under a two-way policy the receipt is not part of the test at all, so a difference between what arrived and what was billed is not caught here.
What is the difference, in Microsoft's own words?
One sentence covers both:
"Two-way matching compares the unit price of the invoice to the unit price of the purchase order. Three-way matching additionally compares the invoice quantity to the matched product receipt quantity."
And the policy options spell it out again, more precisely:
| Policy | Microsoft's description |
|---|---|
| Not required | "There's no verification of individual invoice line prices to purchase order price or invoice quantities to packing slip quantities required." |
| Two-Way Match | "The verification of invoice lines is required but only the purchase order and the supplier's invoice documents are involved in the verification. The product receipt isn't factored into the matching validations." |
| Three-Way Match | "The invoice net unit price is compared to the purchase order's net unit price and the matching product receipt quantity is compared to the invoice quantity." |
That middle row is the one people get wrong. It is easy to assume two-way means "a lighter version of the same check". It does not — it means the receipt is excluded. If you are billed for ten and received six, two-way matching has no opinion, because it never looks at what was received.
What else can be matched besides price and quantity?
Four types exist, and Microsoft names them:
| Type | What it compares |
|---|---|
| Line level matching | "The most common type of matching is line matching." Two-way or three-way, as above |
| Invoice totals matching | "Match the total amounts on the invoice to the total amounts on the purchase order." Six totals: "Subtotal, Total discount, Charges, Sales taxes, Round off, and Invoice amount" |
| Charges matching | "Match the charges information (amounts) on the invoice to the charges information (amounts) on the purchase order" |
| Price totals for line item matching | "useful for companies that typically receive multiple invoices for a single purchase order line" |
The fourth one is quietly important if your vendors bill in instalments. Microsoft explains why: "If you typically receive only one invoice per purchase order line, this type of matching isn't necessary." It acts as a ceiling, described as "a not-to-exceed net amount validation", comparing each line against the net amount of the corresponding purchase order line — where the net amount is "(Unit price Line quantity) + Line charges - Line discounts."*
So "we do three-way matching" does not mean every check is on. Line matching and totals matching are separate switches.
Where is the policy actually set?
At the legal entity, and then overridable downwards.
The default lives on Accounts payable > Setup > Accounts payable parameters, on the Invoice validation tab, in the Line matching policy field — and Microsoft describes it as "a value used as the default policy for the legal entity that you are working with."
Then it can be narrowed: "To allow a different level of matching to be applied for an item, vendor, vendor and item combination, or purchase order line, select a value in the Allow matching policy override field." The overrides themselves live on the Matching policy page.
### Why this matters before you blame the data The policy that applied to a given line may not be the company default. A vendor-level or item-level override can be in force, which means two lines on the same invoice can be tested differently. Check the override before concluding the matching is broken.
One more switch decides when matching runs at all: the Automatically update invoice header match status field, where Microsoft's guidance is "The recommended setting is Yes, unless you're experiencing data entry performance concerns" — and if it is set to No, "The data entry clerk needs to manually update the invoice's match status."
What about tolerances?
The default is zero, which surprises people.
"The legal entity default price tolerance is set to zero percent for two-way and three-way matching."
Zero tolerance means any price difference is a discrepancy. Tolerances are then configured per legal entity, item and vendor on the Item price tolerance page, and Microsoft notes that "When vendor invoices are compared with the information on purchase orders, the applicable price tolerance percentage is searched for" — so the most specific tolerance wins.
Discrepancies do not necessarily block posting. The Post invoice with discrepancies setting decides: at Allow with warning, Microsoft says "visual indication displays when a discrepancy for invoice matching exceeds the tolerance. However, you can post the invoice."
And there is a workflow interaction worth knowing: "To use workflows together with invoice matching validation, make sure that the Post invoice with discrepancies field is set to Allow with warning to avoid having to approve multiple times."
Which should you actually run?
Three-way, unless you have a specific reason not to — and the reason is usually the receipt discipline, not the matching.
The honest trade-off: three-way matching is only as good as the product receipts behind it. If receipts are posted late, in bulk, or not at all, three-way matching converts a goods problem into an invoice backlog. Two-way hides that problem rather than solving it, which is why the choice is really a question about the warehouse, not about accounts payable.
If receipts are unreliable, fixing the receipt step pays better than relaxing the policy — and that is where the receipts actually get stuck.
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/
Agentic ERP. We build turnkey AI optimization apps for Dynamics 365 — sidecar applications that run in your own Azure tenancy and solve the calculations a standard ERP is not built to compute. Built on Azure OpenAI, Microsoft Fabric and Copilot Studio. We build these on request, against your data and your environment.
More on the boundary between what Copilot does and what you build: Agentic ERP on Dynamics 365.
If invoices are parking with discrepancies and nobody can say which policy applied, the overrides are usually the answer. Bring one parked invoice to a 15-minute call.
Sources
- Set up Accounts payable invoice matching validation · fetched and read in full 2026-10-21
- Record vendor invoice and match against received quantity · fetched and read 2026-10-21
Sources and fact-check
| # | § | Claim | Tier | Primary source | Verdict |
|---|---|---|---|---|---|
| 1 | 1 | "Two-way matching compares the unit price of the invoice to the unit price of the purchase order. Three-way matching additionally compares the invoice quantity to the matched product receipt quantity" | T1 — verbatim | matching-validation | PASS |
| 2 | 1 | All three policy options quoted — Not required, Two-Way Match, Three-Way Match | T1 — verbatim ×3, option names character-exact including Microsoft's capitalisation | Same page | PASS |
| 3 | 1 | "The product receipt isn't factored into the matching validations" | T1 — verbatim | Same page | PASS — the article's spine |
| 4 | 2 | The four matching types, each quoted | T1 — verbatim ×4 | Same page | PASS |
| 5 | 2 | The six totals, quoted as a list | T1 — verbatim | Same page | PASS |
| 6 | 2 | "a not-to-exceed net amount validation" and the net-amount formula | T1 — verbatim, formula reproduced exactly as published | Same page | PASS |
| 7 | 3 | The path Accounts payable > Setup > Accounts payable parameters, Invoice validation tab, Line matching policy field | T1 — verbatim. Not invented navigation; Microsoft publishes the path and the field names | Same page | PASS |
| 8 | 3 | "To allow a different level of matching to be applied for an item, vendor, vendor and item combination, or purchase order line, select a value in the Allow matching policy override field" | T1 — verbatim | Same page | PASS |
| 9 | 3 | Two lines on one invoice can be tested differently | T2 — ours, a direct consequence of claim 8 | — | PASS |
| 10 | 3 | Automatically update invoice header match status, with Microsoft's recommendation and the No consequence | T1 — verbatim ×2 | Same page | PASS |
| 11 | 4 | "The legal entity default price tolerance is set to zero percent for two-way and three-way matching" | T1 — verbatim | Same page | PASS |
| 12 | 4 | "the applicable price tolerance percentage is searched for", and that the most specific wins | T1 for the quotation; T2 for "most specific wins", which is our reading of the search order | Same page | PASS |
| 13 | 4 | Allow with warning — "visual indication displays… However, you can post the invoice" | T1 — verbatim | Same page | PASS |
| 14 | 4 | The workflow interaction and Microsoft's advice to use Allow with warning | T1 — verbatim | Same page | PASS |
| 15 | 5 | Three-way is only as good as the receipt discipline behind it; two-way hides the problem | T2 — ours, a recommendation. Argued, not asserted, and it names the trade-off rather than claiming a result | — | PASS |
Tier summary: 12 × T1 (all verbatim), 3 × T2 — 0 × T4.
🔴 Percentages appear and they are Microsoft's, not ours. "Zero percent" is Microsoft's published default. No percentage in this article describes our performance, a saving, or a measured outcome — the distinction PUBLISHING-CONTRACT.md §1 turns on. Zero digits appear in either lifted block.
🔴 No pricing. No rate, currency or cost figure anywhere.
No unbounded absence claimed. The strongest negative — "the product receipt isn't factored into the matching validations" — is Microsoft's own sentence about its own product, quoted with its policy name attached.
No figures of ours. No volume, no accuracy, no customer, no result.
Share this article
Procure-to-Pay Agent Operations
Topic Cluster
