What is three-way matching in accounts payable?
Three-way matching is an accounts payable control that verifies an invoice against two independent records before any payment is released. It compares the purchase order (what was ordered and approved), the goods receipt (what was physically received), and the supplier invoice (what is being billed).
When quantity, unit price, and line description agree across all three within tolerance, the invoice is approved. When they do not, it is placed on hold and worked as an exception.
The control works because the three documents come from three different sources. Purchasing raises the PO, the receiving team logs the goods receipt, and the vendor issues the invoice.
No single person controls all three. That is a basic separation of duties, and it makes a fake or inflated invoice far harder to pay.
The three documents in a three-way match
Purchase order (PO). Created by the buyer and sent to the vendor. It is the authorization: the agreed items, quantities, unit prices, and terms.
Goods receipt, also called the receiving report or delivery note. Logged by the warehouse when the shipment arrives. It is the proof of what was actually delivered, and in what quantity and condition.
Supplier invoice. The vendor's request for payment. Its line items and pricing must reflect what was ordered and received.
Three-way matching example
The clearest way to understand the control is to walk one invoice through it.
Purchase order: 100 units of Part A at $10 each, total $1,000.
Goods receipt: 100 units received and logged.
Supplier invoice: 100 units at $10 each, total $1,000.
All three agree on item, quantity, and price. The invoice passes and is scheduled for payment with no human review.
Now change one field. If the invoice bills 100 units at $11, there is a $100 price variance, and the invoice is held until someone approves the higher price or the vendor sends a corrected invoice.
If the goods receipt shows only 90 units received but the invoice bills 100, there is a quantity variance, and the invoice is held until the last 10 units arrive or the invoice is adjusted.
That held invoice is what accounts payable calls an exception. Exceptions are where almost all of the time and cost in matching actually go.
2-way vs 3-way vs 4-way matching: what is the difference?
Three-way matching is the standard for physical goods, but it is not the only option. The right level depends on what you are buying and how much risk it carries.
Match type | Documents compared | Best for | The trade-off |
|---|---|---|---|
Two-way | PO + invoice | Services and low-risk spend with no physical delivery | Faster, less overhead, but no proof the goods arrived |
Three-way | PO + goods receipt + invoice | Physical goods and most purchase orders | The standard control; needs a goods receipt logged |
Four-way | PO + goods receipt + inspection or quality check + invoice | Regulated, high-spec or high-value goods | Strongest assurance, but slowest; needs an inspection step |
Most teams do not apply one level to everything. They use three-way matching for physical goods and higher-value POs, two-way matching for low-risk services and recurring spend, and four-way matching for regulated or high-specification items that need an inspection sign-off.
Why is three-way matching important?
It prevents overpayment. It catches invoices that bill for more units, higher prices, or extra charges than were ordered or received.
It detects fraud. It blocks fictitious invoices, ghost shipments, and fake billings, because a fake invoice has no matching PO and no goods receipt behind it.
It reduces errors. It catches honest mismatches in quantity, price, or product before the payment goes out, not after.
It builds accountability. Each document comes from a different source, which reduces the risk of collusion and gives you clean evidence for the audit.
The three-way matching process, step by step
Here is the full sequence, from purchase order to payment.
A purchase order is raised and approved, then sent to the vendor.
The goods arrive and the receiving team logs a goods receipt against that PO.
The supplier invoice arrives and is captured, by hand or with OCR, and coded to the PO.
The system compares the invoice line by line against the PO and the goods receipt on quantity, price, and description.
If every line is within tolerance, the invoice is posted and scheduled for payment with no human touch. This is straight-through processing.
If any line is outside tolerance, the invoice is blocked and routed to the right owner as an exception, then paid once the variance is resolved.
Common three-way matching errors (and why matches fail)
In practice, the invoices that stall are rarely fraudulent. They are ordinary invoices that trip a real-world edge case. The most common causes:
Quantity variance. A partial delivery, an over-shipment, or a goods receipt not yet posted, so the received quantity does not equal the billed quantity.
Price variance. The vendor billed a different unit price than the PO, often because a price change was never updated on the purchase order.
Unit-of-measure mismatch. The PO is in cases and the invoice is in individual units, or the reverse, so the quantities look wrong even when the delivery was correct.
Missing goods receipt. The invoice arrives before the warehouse logs the receipt, so there is nothing to match against yet.
Extra lines not on the PO. Freight, tax, surcharges, or handling fees that were never ordered and have no PO line to match.
Wrong or missing PO reference. The invoice cites the wrong purchase order, or none at all, so the match cannot even start.
Duplicate invoice. The same invoice submitted twice, which matching should catch before it is paid again.
Three-way match tolerances and how to handle exceptions
No two documents ever agree to the last cent, so matching runs on tolerances: the small variances you accept without a review. Set them well and clean invoices flow through untouched. Set them badly and you either leak overpayments or drown in holds.
Set tolerance limits. Agree an acceptable variance for minor differences, for example under 2 percent or a small fixed amount, so a few cents of rounding does not trigger a review.
Isolate quantity variance. If the invoiced quantity is higher than the goods receipt, hold the invoice until the warehouse logs the rest, rather than paying for goods you have not received.
Resolve price variance at source. If the price exceeds the PO, ask the vendor or buyer for a revised invoice or a credit memo instead of quietly paying the difference.
Route the right alert. Send unexpected upcharges to the buyer or department head who can approve or reject them, not to the AP clerk who cannot.
Track vendor patterns. Log recurring mismatches to spot unreliable suppliers or outdated price sheets, then fix the root cause instead of reworking the same exception every month.
One first-hand note from running multi-country accounts payable: the cost that surprises finance teams is never the per-invoice matching rate. It is the exception rate, the share of invoices that do not match first time and have to be chased and cleared by a person. That is the number worth measuring, and the number worth automating.
Challenges and limitations of three-way matching
Three-way matching is a strong control, but it has real costs worth planning for.
It is time-consuming when manual. Comparing three documents line by line slows invoice processing and does not scale as volume climbs.
Exceptions delay payments. Frequent mismatches need investigation, which holds up payments and creates vendor friction if they are not cleared quickly.
Automation takes upfront effort. AP automation software and managed services cost money and setup time, though they usually pay back through fewer errors, less rework, and captured early-payment discounts.
Three-way matching in SAP, Oracle, and NetSuite
The concept is identical across ERPs, but the mechanics and the words differ, which matters when you configure it or troubleshoot a blocked invoice.
SAP
In SAP, invoice verification happens in MIRO, and the goods receipt and invoice both clear through the GR/IR (goods-receipt / invoice-receipt) account. SAP uses tolerance keys to decide what passes:
Key BR handles an invoice receipt that arrives before the goods receipt.
Key BW handles the reverse, a goods receipt before the invoice.
Key DW blocks a line when there is no goods receipt at all.
An invoice outside tolerance is blocked and sits in MRBR until someone releases it. Tolerances are configured under SPRO, then Materials Management, Logistics Invoice Verification, Invoice Block, Set Tolerance Limits.
Oracle
Oracle Fusion and EBS apply matching rules and tolerances at the invoice level, placing holds automatically when a line falls outside them. The invoice cannot be paid until the hold is reviewed and released, the same block-and-release pattern as SAP under different names.
NetSuite
NetSuite matches the vendor bill against the purchase order and the item receipt, using tolerance thresholds you set for quantity and price. Bills within tolerance post automatically, and those outside it are flagged for review.
The common failure across all three is not the software. It is tolerance settings that are too tight, so the team is buried in holds, or too loose, so overpayments slip through. Getting that right matters more than any single feature.
When to use three-way vs two-way matching
Requiring three-way matching on every invoice slows down spend that carries almost no risk. Match the control to the purchase.
Use three-way matching for physical goods, inventory, and higher-value purchase orders, where confirming what was actually received is the whole point.
Use two-way matching for low-risk services and recurring spend with no delivery to receive, such as subscriptions, utilities, or professional fees.
Volume and geography change the calculus too. A team processing a few hundred invoices a month can hold exceptions by hand. One processing thousands cannot.
International vendors also add freight, duty, and tax lines that were never on the PO, so your matching rules and tolerances have to account for them, or every cross-border invoice becomes an exception.
How to automate three-way matching
Manual matching does not scale. Modern AP automation removes the data entry and comparison work through a few standard mechanics:
OCR data extraction reads the invoice and pulls out the header and line-item details.
Automated data routing pushes that data into your ERP, such as SAP or Oracle.
Algorithmic verification cross-references the line items across the PO, the receipt, and the invoice.
Straight-through processing pays the clean matches without human eyes.
Exception flagging isolates the failing matches and routes them to an AP specialist.
There are three broad ways to put those mechanics to work, and most teams move up this ladder over time.
ERP-native matching with OCR. Your ERP captures the invoice, reads the line items, and auto-matches the clean ones for straight-through processing. A sensible starting point for a single-ERP environment with clean data.
AP automation software. Tools such as BILL, Tipalti, Medius, and AvidXchange add capture, tolerance rules, exception queues, and approval workflows on top of the ERP. They match well, but the exceptions still land in a human queue.
Agentic managed AP. AI agents that do not just match the invoice but also work the exception: they chase the missing goods receipt, read the credit memo, check the price against the contract, and propose the fix, with your team on oversight. Mindsprint SprintAP runs this way across multiple ERPs, for teams where exception volume, not matching itself, is the bottleneck.
The test for any of these is simple. It should shrink the share of invoices that need a human, and shorten the time to clear the ones that still do.
Conclusion
Three-way matching is not complicated in theory. It is the discipline of paying only for what you ordered and received, checked across three documents that come from three different sources.
In practice, the whole game is the exceptions. The clean invoices look after themselves. The cost, the delay, and the vendor friction all sit in the invoices that do not match first time, which is why tolerances and exception handling matter more than the match itself.
So the path is straightforward. Match the control to the risk, three-way for physical goods and two-way for low-risk services. Tune your tolerances so clean invoices flow through and only real variances stop. Then automate, starting with OCR and straight-through processing, and moving to agents that resolve exceptions once volume, not matching, becomes the bottleneck.
Get those three right and three-way matching stops being a bottleneck. It becomes what it is meant to be: a quiet control that pays the right invoices and holds the rest.
