What three-way matching checks
Three-way matching is the control most accounts payable teams run before paying a supplier invoice. It compares three documents: the purchase order, the goods receipt (or receiving report, confirming what actually arrived), and the invoice itself. The system checks that all three agree on quantity, unit price, and total amount before the invoice clears for payment.
The logic is simple. The PO says what was authorized. The receipt says what was actually delivered. The invoice says what the supplier wants paid. If all three line up, the company pays for something it ordered, received, and was billed correctly for. If they don't, someone has to find out why before money moves.
A simpler version, two-way matching, compares only the PO and the invoice, skipping the receipt check. It is faster but leaves a gap: nothing confirms the goods showed up in the quantity billed. Two-way matching is common for services and low-risk purchases where a receiving step doesn't exist. Three-way matching is the standard for physical goods and higher-value purchase orders, where the receipt is the one document a supplier can't fabricate.
Why it exists
The control predates any software. It is the accounting-department answer to a basic risk: paying for goods that were never ordered, never delivered, or billed at the wrong price. Before automation, someone manually pulled the paper PO, the paper receiving slip, and the paper invoice and checked them by hand.
That manual version worked, but slowly, and it didn't scale. Every invoice needed a person to retrieve three documents and reconcile them line by line. As purchase volume grew, so did the backlog of unmatched invoices sitting in a queue waiting for someone's attention.
How automated matching differs
Modern AP automation software runs the same three-document comparison, but does it before a human looks at the invoice. The system pulls the PO and receipt data already in the ERP, extracts the invoice's line items using optical character recognition or a similar parsing layer, and checks them against each other automatically. Invoices that match within a set tolerance, commonly a small percentage or dollar variance on price and quantity, clear without anyone touching them. Invoices that fall outside that tolerance get routed to a person as an exception.
That tolerance setting is where most of the design work sits. Set it too tight and routine rounding differences or freight charges kick nearly everything into manual review. Set it too loose and the control stops catching real discrepancies. Vendors differ mainly in how well they handle matching at the line level rather than the invoice total, since a mismatch can be buried in one line of a fifty-line invoice while the total still looks close.
Where it still breaks
The exception rate is the honest measure of whether any of this is working. According to Ardent Partners' 2025 accounts payable benchmarking survey of AP and finance executives, invoice exception rates average 14% across the market, with top-performing teams closer to 9% and organizations without automation running closer to 22% (Ardent Partners, 2025). The same research put touchless invoice processing, invoices that clear with no human involvement, at an average of 32.6%, with best-in-class teams reaching 49.2% (Ardent Partners, 2025).
Those numbers point to where automation still stalls. Most exceptions are not extraction failures, they are structural mismatches: a PO that was never fully received in the system, a goods receipt logged against the wrong line item, a tax or freight charge the PO never accounted for, or a duplicate invoice that slips past a basic check. None of those are OCR problems. They are data problems upstream of the invoice, in how the PO was written or the receipt was recorded, and no amount of better invoice parsing fixes them.
Non-PO invoices make this worse. A three-way match has nothing to compare against when no purchase order exists in the first place, which is common for maverick or off-contract spend. Those invoices skip the automated check entirely and land directly in a manual coding queue, which is part of why non-PO invoice exception rates run higher than PO-backed ones.
What to check before buying automated matching
Ask a vendor to show line-level matching on a messy real invoice, not a demo invoice with clean one-to-one line correspondence. Ask what happens when a receipt is logged in the wrong unit of measure, or split across two deliveries against one PO line. Ask for the actual touchless rate their existing customers hit, not the theoretical ceiling, and ask how that number is measured. And check whether the tool has any answer for non-PO spend, since a matching engine that only works when a clean PO already exists solves the easier half of the invoice-to-pay problem.
Sources: Ardent Partners · Apexanalytix · Ascend Software · Stampli · Ramp