Three-way match in accounts payable: 2-way, 3-way and 4-way matching, tolerances, exceptions and e-invoices

Short answer: A three-way match compares every supplier invoice with the purchase order and the goods receipt before it is paid: prices against the order, quantities against what was actually received. Differences within tolerance pass; larger ones hold or block the invoice until someone resolves them. A 2-way match leaves out the receipt, a 4-way match adds inspection. SAP, Dynamics 365, Business Central and NetSuite all match natively, each with its own tolerance logic. E-invoices speed matching up because order references arrive as data, but receipts still have to be posted and the evidence archived.

Three-way matching has become more important with e-invoicing, not less. When invoices arrive as XML through Peppol or a national platform, the slow part is no longer reading the invoice but deciding whether to pay it. In our guide from e-invoice to archive, matching is stage 4 of seven; this guide covers it in depth: match levels, tolerances in the major ERPs, exceptions, e-invoice references and the evidence to archive. ERP behaviour is taken from SAP, Microsoft and Oracle documentation as checked on 3 and 4 October 2026; check the details for your release.

What is a three-way match?

A three-way match is a control in accounts payable that pays a supplier invoice only when it agrees, within tolerance, with the purchase order and the goods receipt. Each of the three documents proves something different, and each usually comes from a different person.

Document	What it proves	Who creates it	Where it usually lives
Purchase order	What was agreed: item, quantity, price, terms	Purchasing or the requester, after approval	ERP
Goods receipt (product receipt, item receipt, receiving report)	What actually arrived, when, and in what quantity	Warehouse, receiving or the requester for services	ERP
Supplier invoice	What the supplier asks you to pay	Supplier	Inbox, e-invoicing network, DMS or AP tool, then ERP

The control works because no single person controls all three. The buyer cannot confirm a delivery that never happened, and the warehouse cannot change the agreed price. That is what internal control frameworks describe in general terms: COSO’s 2013 framework lists verifications and reconciliations among typical control activities and expects segregation of duties to be built into them (COSO, Executive Summary).

Public procurement writes the same logic into law. The US Federal Acquisition Regulation requires invoice payments, except interim payments on cost-reimbursement contracts for services, to be supported by a receiving report or other government documentation authorising payment (FAR 32.905(c)), and states the principle in its first paragraph:

“Payment will be based on receipt of a proper invoice and satisfactory contract performance.”

Federal Acquisition Regulation, FAR 32.905(a)

The terms vary: Microsoft says product receipt, NetSuite item receipt, SAP goods receipt. In SAP the classic transactions are Enter Incoming Invoice (MIRO) and Park Incoming Invoice (MIR7) (SAP Help); in S/4HANA the Fiori app Manage Supplier Invoices does the same job (SAP Help, F0859).

1. OrderAn approved purchase order with item, quantity, unit of measure and price.
2. ReceiveThe warehouse posts a goods receipt, or the requester confirms a service.
3. Capture the invoiceFrom the e-invoice XML or, for paper and PDF, by recognition: supplier, order number, lines.
4. Match each linePrice against the order line, quantity against the received-but-not-invoiced quantity, both within tolerance.
5. Pass or holdWithin tolerance: post and pay. Outside: hold or block for payment and route to the owner of the difference.
6. Archive the evidenceInvoice original, order and receipt references, match result, tolerance and any variance approval.

2-way vs 3-way vs 4-way matching: what is the difference?

The match level says how many documents an invoice must agree with before it is paid: two (invoice and order), three (plus receipt) or four (plus inspection). Oracle’s procurement documentation states the three levels most compactly: two-way requires purchase order and invoice quantities to match within tolerance, three-way adds the receipt, and four-way adds the accepted quantities from inspection (Oracle Fusion Cloud Procurement 26C).

Level	Compares	Protects against	Typical use
Invoice totals	Invoice totals against order totals	Gross overbilling	Low-risk, high-volume spend where line detail adds little
2-way	Invoice prices (and often quantities) against the purchase order	Prices or quantities above what was agreed	Services, subscriptions, framework contracts without a physical receipt
3-way	Invoice against order for price, against goods receipt for quantity	Paying for goods that never arrived or arrived short	Stock items, materials, capital goods
4-way	As 3-way, plus the quantity accepted after inspection	Paying for goods that arrived but failed inspection	Regulated or quality-critical goods inspected before acceptance

Two details matter in practice. First, the level is not fixed per company. Dynamics 365 Finance sets a matching policy for the legal entity and lets you override it per vendor, item, item and vendor combination or order line; Microsoft’s example uses two-way as the default and three-way for an asset item and for vendors with delivery problems (Microsoft Learn, matching policies). It also offers invoice totals matching and charges matching as separate checks (Microsoft Learn, invoice matching).

Second, a three-way match can refer to the order or to the delivery. In SAP’s goods-receipt-based invoice verification, the invoice refers to individual deliveries, identified by delivery note or goods receipt document, which SAP recommends when an order arrives in many partial deliveries; the goods receipt must be posted before the invoice is entered (SAP Help). The ERP integration guide has a short overview; this guide goes into the mechanics.

1. Is there a purchase order?Yes: at least a 2-way match.No: a non-PO approval by the budget owner; no match is possible.
2. Is something delivered or confirmed as performed?Yes: 3-way. For services, the requester's confirmation can serve as the receipt.No: 2-way, for example for subscriptions and fixed fees.
3. Are goods inspected before acceptance?Yes: 4-way, if your ERP records accepted quantities.No: stay with 3-way; a fourth document only adds waiting time.
4. Does one order arrive in many partial deliveries?Yes: match per delivery (goods-receipt-based).No: match against the order line and its receipts.

How do tolerances, price variances and quantity variances work?

A tolerance is the difference between invoice and order or receipt that you accept without review; a variance outside it becomes an exception. Every ERP distinguishes at least two kinds of variance: a price variance (invoice price against order price) and a quantity variance (invoiced quantity against received and not yet invoiced quantity). Tolerances can be a percentage, an absolute amount or both.

SAP S/4HANA shows how fine-grained this can get. Tolerance limits are set per tolerance key and per company code, and the system checks each invoice item against the order or the goods receipt (SAP Help, tolerance limits):

SAP tolerance key	What it checks
PP – price variance	Deviation of each invoice item from invoiced quantity × order price, against absolute and percentage limits
DQ – quantity variance	Net order price × (quantity invoiced − (quantity delivered − quantity already invoiced)), against absolute limits; percentage limits possible
DW – quantity variance when GR quantity is zero	Invoices for order items whose goods receipt has not been posted yet
BD – form small differences automatically	Small invoice balances, posted to an expense or income account for small differences
ST – date variance	Amount × days between scheduled delivery date and invoice entry date
AN / AP, VP	Item amounts without or with order reference; effect on the moving average price

Two rules follow from SAP’s documentation. If an upper limit is exceeded, except for BD and VP, the invoice is posted but blocked for payment and must be released separately; if the BD limit is exceeded, it cannot be posted at all. And if DW is not maintained for a company code, SAP blocks every invoice whose goods receipt has not been posted yet.

Because DQ multiplies the quantity difference by the order price, the same quantity variance weighs more on expensive items than on cheap ones, which is usually what a controller wants.

A worked example. The figures are an illustration, not a benchmark. A purchase order covers 500 units at EUR 12.00. The warehouse posts a goods receipt for 480 units. The supplier invoices 500 units at EUR 12.30.

• Price variance: EUR 0.30 per unit, or 2.5%. With a 2% price tolerance the line fails; with 3% it passes.
• Quantity variance: 20 units more than received. Under SAP’s DQ logic: EUR 12.00 × (500 − (480 − 0)) = EUR 240, compared with the absolute limit for the company code.
• Combined effect: the invoice asks EUR 6,150.00 for goods worth EUR 5,760.00 at order price as received. Even if each variance were tolerated, the difference is EUR 390.

Two traps hide in tolerances. First, variances can offset each other: SAP warns that if you post without checking the invoice items, variances in individual items can cancel each other out (SAP Help); line-level matching prevents this. Second, partial invoices add up. Dynamics 365 Finance compares price totals across all pending and posted invoices for an order line, so several small overcharges within tolerance are caught on the last invoice (Microsoft Learn).

NetSuite names both kinds of limit: a tolerance limit is a percentage, a difference limit an absolute quantity. Its 3 Way Match Vendor Bill Approval Workflow has six such fields, against the purchase order and the item receipt, on the vendor or subsidiary record; blank fields are not checked (NetSuite). Configuration needs care: with a quantity difference limit of 4, an order for 100 units, 98 received and a bill for 98 is still routed for approval if the separate “bill quantity less than order quantity” exception stays on (NetSuite, best practices).

How to set tolerances without copying someone else’s numbers:

1. Combine percentage and amount. A percentage alone lets large orders through with large absolute differences; an amount alone blocks small orders for trivial ones.
2. Set them per category. Commodity prices and freight justify different tolerances from fixed-price contracts.
3. Use a lower limit too. Invoices far below the order price often point to a wrong item or a missing line.
4. Document every change. Auditors will ask which limits applied when an invoice was paid.

What happens to invoices that do not match? The exceptions workflow

An invoice that fails the match is not rejected automatically; it is held or blocked for payment until the difference is explained, corrected or approved. How that looks depends on the ERP:

ERP	What happens on a mismatch	How it is resolved
SAP S/4HANA	Invoice is posted and blocked for payment if a tolerance is exceeded; if a responsible person is found, an approval process starts	Release manually or automatically in Release Blocked Invoices (MRBR), or through the flexible workflow; release needs authorisation (SAP Help)
Dynamics 365 Finance	Match variance icons on the invoice; it can be saved until resolved	If approval is required, someone sets “Approve posting with matching discrepancies” before posting
Business Central	Deterministic warnings on the invoice draft, such as “Exceeds quantity received” or “Price difference”	Draft can be finalised with most warnings, but receipts must cover the full invoice quantity before posting (Microsoft Learn)
NetSuite	3 Way Match workflow sets the bill to Pending Approval and routes it to the supervisor	Supervisor approves or rejects; bills without discrepancies are approved automatically (NetSuite)

SAP’s release transaction also selects invoices that were blocked at random, a stochastic block, so that a sample of correctly matched invoices still gets a human look (SAP Help, Choosing Blocked Invoices). Business Central’s Payables Agent can propose order matches, but according to Microsoft it never posts the invoice, and its warnings come from rule-based validations, not from an AI confidence score.

Most exceptions fall into a handful of types, and each has a natural owner:

Exception	Typical cause	Owner	Usual resolution
No goods receipt yet	Delivery not booked, or service not confirmed	Warehouse or requester	Post the receipt; the block lifts on re-check
Quantity above receipt	Short delivery, split shipment, invoice ahead of delivery	Warehouse	Wait for the rest, or ask for a credit note
Price above order	Price increase, surcharge, wrong price list	Buyer	Correct the order if agreed; otherwise credit note
Unmatched line or charge	Freight, packaging, fees not on the order	Buyer or AP	Add the charge to the order or reject the line
No or wrong order reference	Supplier did not quote it, or quoted a sales order number	AP	Look up by supplier and item; tell the supplier
Unit of measure or item mismatch	Box versus piece, supplier item number unknown	Master data	Item reference or conversion, then re-match

Four rules keep the exceptions queue under control:

1. Reason codes, not free text, so you can report on causes and fix them upstream.
2. The owner of the difference resolves it. Accounts payable routes; the buyer decides on price, the warehouse on quantity.
3. Whoever approves a variance did not create the order. That segregation of duties is what makes the match a control.
4. Deadlines are becoming legal, not only commercial. Once Spain’s B2B mandate applies, the buyer must tell the supplier whether it has commercially accepted or rejected each e-invoice, and when it has paid it in full, within four calendar days of that status arising, not counting Saturdays, Sundays and national holidays (Article 10(3) of Royal Decree 238/2026). Full payment must also be reported to the tax agency’s public solution within four such days of the payment date, and rejections must be reported there as well (Article 12). The decree applies 12 months (volume of operations above EUR 8 million) or 24 months (everyone else) after a Ministry of Finance order on the public solution enters into force; that order had not been published by 3 October 2026, see our Spain profile. An exceptions queue that takes weeks will not fit that window.

How do structured e-invoices change three-way matching?

With an EN 16931 e-invoice, the data that matching needs arrives as fields instead of being read from a picture: supplier identifier, order reference, line quantities, units of measure, net prices and item identifiers. That removes recognition errors. It does not remove the need for a posted goods receipt, nor for suppliers to fill in the references.

What the European standard and Peppol BIS Billing 3.0 carry for matching (Peppol BIS Billing 3.0, UBL syntax):

• Purchase order reference (BT-13) at document level. Peppol rule PEPPOL-EN16931-R003 requires a buyer reference (BT-10) or a purchase order reference, so an invoice can legitimately arrive without an order number. For Germany, Peppol rule DE-R-015 requires the buyer reference (BT-10) whenever supplier and customer are both located in Germany, so such an invoice can pass validation with a buyer reference but no order number. For VAT purposes the German Ministry of Finance treats a missing BT-10 as irrelevant (BMF letter of 15 October 2025, paragraph 35a); for matching, the order number is what counts.
• Referenced purchase order line reference (BT-132) on the invoice line. Peppol BIS says that if the order is referenced at header level, the line can state the order line number. This is what makes line-level matching reliable.
• Despatch advice reference (BT-16) and receiving advice reference (BT-15), each at most once and only at document level (Peppol rules UBL-SR-03 and UBL-SR-02). Peppol BIS adds that a UBL invoice should not include despatch or receipt line references on its lines. An invoice covering several deliveries cannot point to each delivery note per line; the buyer’s ERP has to find the receipts through the order lines.
• Item identifiers and units: the seller’s (BT-155), buyer’s (BT-156) and standard item identifier (BT-157, for example a GTIN, which must carry a scheme identifier), plus the invoiced quantity’s unit of measure code (BT-130), which every line must have. Box versus piece is a matching exception, not a pricing one.

Italy’s FatturaPA goes further: it has blocks for the purchase order (DatiOrdineAcquisto), the receipt (DatiRicezione) and the transport document (DatiDDT), each of which can point to specific invoice lines (Agenzia delle Entrate, specifiche tecniche 1.9.1). Whether suppliers fill them in is another matter; ask for it during onboarding. The Italy profile covers the SdI channel.

The ERPs use these fields literally. Business Central takes the first 20 characters of the extracted order number and looks for an exact match with an internal order number, not a fuzzy one, and offers only order lines with the same vendor and unit of measure (Microsoft Learn, invoice drafts). By default it matches only lines with the same amount; the field “E-Document Matching Difference %” adds a tolerance (Microsoft Learn, e-documents). An order number with an extra prefix is therefore an exception, even on a perfect XML file.

Matching a PDF or scanned invoice

• Order number read by recognition, sometimes from the wrong field
• Line items often captured as totals only
• Units and item numbers guessed from text
• Mismatches caused by reading errors mix with real ones
• The image is the evidence; data is derived from it

Matching an EN 16931 e-invoice

• Order reference and order line reference as fields
• Every line with quantity, unit code and net price
• Seller, buyer and standard item identifiers
• Remaining exceptions are real business differences
• The XML is the original and the source of the match

In practice: ask suppliers to quote your order number and order line, map their item numbers to yours once, and post receipts before invoices arrive. Those three measures decide your match rate more than the matching software does. Our Peppol guide explains how invoices reach you over the network, and the readiness check shows from when each of your entities has to receive e-invoices.

Who does the matching: the ERP, an AP tool or the DMS?

Matching needs current order and receipt data, so it runs either in the ERP or in a system that reads that data from the ERP. Three set-ups are common:

1. The ERP matches. The DMS or e-invoicing service delivers the invoice data, the ERP matches and blocks, the DMS archives the original.
2. An AP tool or DMS invoice module matches, the ERP posts. The tool reads order and receipt data through a connector, matches, runs the approval and hands over a parked or posted invoice; useful when several ERPs or entities need one process.
3. Split. The tool checks header data and duplicates, the ERP matches lines. Workable if both agree who owns the exception.

What our checked data sheets show, as of 4 October 2026: of 53 vendors with a checked data sheet, 23 record an inbound invoice process as a standard function and 15 as an add-on module or separate product. Only some of them record matching against orders explicitly. Seven data sheets record matching against both the order and the goods receipt or delivery note: Basware (orders, goods receipts and contracts), Doxis (order and delivery note), Candis (order and goods receipt, through its SAP Business One interface only), Esker (order and goods receipt), Medius (orders at line level and goods receipts), Siav (order and delivery note, with automatic posting in SAP) and Yooz (order and goods receipt at line level). Laserfiche names matching invoices with purchase orders as a solution example for finance. xSuite works inside SAP, checks invoices against SAP master data and names AI agents for matching and exceptions; OpenText offers Vendor Invoice Management for SAP environments only.

For most general DMS invoice modules, such as ELO’s ELO Invoice or d.velop’s invoice product, the data sheets record checking and approval but nothing specific on order or receipt matching. That does not mean the function is missing, only that the public sources we checked do not say. Ask, with your ERP named, and see it in a demo.

Questions that separate real matching from a marketing claim:

• Does the match run per line, against the received-but-not-invoiced quantity, or only on totals?
• Are tolerances configurable per vendor, item group and entity, as percentage and amount?
• Is order and receipt data read live from the ERP, and does an ERP block reason come back to the tool?
• Is the match result, with the tolerance applied, stored with the archived invoice?

The DMS finder filters vendors by inbound invoice module, ERP and e-invoice formats, with a source for every value.

How do you keep the match evidence audit-proof?

The match evidence is everything that explains why an invoice was paid: the invoice original, the order and receipt it was matched with, the result, the tolerance that applied and any variance approval. Auditors test this chain by sampling paid invoices.

1. Invoice originalThe XML as received, or the scan for paper invoices, with transmission evidence; locked against change
2. ReferencesPurchase order number and version, order lines, goods receipt or delivery note numbers and dates
3. Match result per linePrice and quantity variance, pass or fail, and the tolerance setting in force at the time
4. Exception handlingBlock or hold reason, who released or approved it, when, with which comment; credit notes requested
5. Posting linkERP document number and payment reference, so the archive and the books point to each other

Three points deserve attention:

• ERP data has its own lifecycle. Orders and receipts are archived or deleted in the ERP on their own schedules. Keep the references and result with the archived invoice, or make sure the ERP archive covers the same period.
• Not every document has the same period. In Germany, invoices and other booking vouchers are kept for eight years under § 147(3) AO, books, records and annual accounts for ten. Credit institutions, insurers and investment firms still keep booking vouchers for ten years (Art. 97 § 19a(3) EGAO). For a received delivery note that is not a booking voucher, the retention period ends when the invoice is received; for a delivery note you send, when the invoice is sent. That rule has applied since 2017 to every delivery note whose period had not yet expired. Neither period ends while the document still matters for a tax assessment that is open. The shortcut does not cover delivery notes that serve as booking vouchers themselves; those follow the eight years, so ask your tax adviser how yours are classified. Periods for eight EU countries are in our guide to e-invoice archiving requirements.
• Tolerances are part of the procedure. Raising a tolerance from 2% to 5% changes which invoices were paid without review. Record such changes with date and approver in your procedural documentation.

Which KPIs show whether three-way matching works?

Matching KPIs measure how many invoices pass without a person, why the others do not, and how long they wait. We quote no industry benchmarks, because published figures rarely say how they were measured; use these definitions to measure your own baseline.

• First-pass match rate: invoices with an order that pass all checks without manual intervention, divided by all invoices with an order, per month and per supplier.
• Exception rate by reason: held or blocked invoices per reason code divided by all matched invoices.
• Time in exception: median days from block to release, per reason and owner.
• Blocked for payment: number and value of blocked invoices at month end, and how many are past due.
• Discounts missed: early-payment discounts lost on invoices blocked during the discount period.
• Unmatched receipts and invoices: in SAP the open items on the GR/IR clearing account; in NetSuite, quantity, price and exchange-rate differences can post to the Accrued Purchases account and are cleared through vendor bill variances (NetSuite).
• Non-PO share: invoices without a purchase order, which cannot be matched and need their own approval path.

Checklist: three-way match in an e-invoicing process

• Match level set per purchase category: totals, 2-way, 3-way or 4-way
• Tolerances per category as percentage and amount, with a lower limit, documented
• Receipts and service confirmations posted before invoices arrive
• Suppliers quote order number and order line on every invoice
• Supplier item numbers and units of measure mapped once
• One system owns matching and blocking
• Exceptions routed by reason code, with deadlines that fit national rejection windows
• Variances approved by someone other than the order's creator
• Invoice, references, match result, tolerance and approvals archived together
• First-pass match rate and exception reasons reported monthly

Where to start

Start with the data you already have: report last quarter’s blocked or held invoices by reason. Causes such as missing receipts or missing order numbers are fixed outside accounts payable. Then check whether your e-invoices carry order and order line references, and ask the suppliers that do not send them. Only then compare software. If you are choosing a system for capture, approval and archiving, the DMS finder shows which vendors evidence an inbound invoice module for your ERP, and the readiness check tells you from when each of your entities must receive structured invoices.

This guide is general information, not legal, tax or audit advice. ERP functions are described from the vendors’ documentation as checked on 3 and 4 October 2026; vendor values come from our checked data sheets. Involve your auditor or tax adviser before changing tolerances, retention rules or approval rights.