Three-Way Match

Three-Way Match is an accounts payable control that compares the purchase order, invoice, and receipt before payment approval. The three documents are the purchase order, the supplier invoice and the goods receipt, and the control blocks payment until all three agree within tolerance.

Category: Accounts Payable Automation SoftwareBest Accounts Payable Automation Software

Your auditor pulled a sample of 30 AP invoices from last year. Six of them couldn't be matched to both a purchase order and a goods receipt. Three were payments for goods that, according to the warehouse system, hadn't been received at the time of payment. Two of those three turned out to be billing errors, and one was a payment that shouldn't have happened at all. Three-way match is the control that should have caught all six. Three-way matching is the process of comparing three documents before an invoice is approved for payment: the purchase order that authorized the purchase, the goods receipt (or receiving report) that confirms what was actually delivered, and the vendor invoice requesting payment. All three must agree, within defined tolerances, on what was ordered, what was received, and what is being billed. When they do, the invoice can be approved without manual intervention. When they don't, the invoice goes into an exception workflow and needs human review before payment is released. It is the foundational AP control for purchase-based spending. It stops payment for goods not received, catches billing errors before payment, creates a documented audit trail for every payable, and makes procurement, operations, and finance agree before money leaves the organization.

How three-way matching works

Each document in a three-way match confirms a different part of the transaction. The purchase order is a contract between your company and the vendor: it specifies what was ordered, at what price, in what quantity, and on what payment terms. Once a PO is approved and issued, it is an authorized commitment to spend. The goods receipt, sometimes called a receiving report or delivery confirmation, documents what actually arrived. The receiving team creates it when goods are physically accepted into inventory or a service delivery is acknowledged, and it records the quantity received and the date of receipt. It is the operational check. The vendor invoice is the billing request: what the vendor says you owe for what they say they delivered. The match compares PO quantity, invoice quantity, and received quantity, and PO unit price against invoice unit price. A clean match means all three documents agree within tolerance, and the invoice can be approved for payment. A mismatch triggers an exception. That might be a quantity discrepancy (the vendor billed for 100 units but only 80 were received), a price discrepancy (the invoice unit price is higher than the PO price), or a missing document (there's an invoice and a PO but no goods receipt recorded yet). Each exception type has its own resolution path, and resolving exceptions is where AP teams spend most of their match-related time.

Match tolerances, partial receipts

Three-way match in practice is rarely perfect. Tolerances define how much variation between the three documents is acceptable before an exception is triggered. A typical tolerance might be plus or minus 2 to 5% on amount, or a flat $25 to $50 per line, to absorb rounding differences, currency movements, or minor quantity variations within acceptable delivery terms. Tolerances set too tight create excessive exception volume, with AP spending hours reviewing $2 variances that aren't real problems. Tolerances set too wide defeat the control: a 10% tolerance on a $100K invoice lets a $10K billing error through without review. Partial receipts are a specific complication. When a vendor ships 60 units against a PO for 100, the invoice may still arrive for the full 100. The match fails because received quantity doesn't equal invoice quantity, but this may be expected rather than an error. AP systems need to handle partial receipt matching: approve payment for the received portion, hold payment for the undelivered portion, and track the open PO balance for future receipt and payment. The alternative, holding the entire invoice until all 100 units arrive, causes payment delays and vendor friction wherever partial delivery against a PO is normal. Service invoices raise a different problem because there's no physical goods receipt to confirm delivery. Three-way match for services uses a service receipt (sometimes called an acceptance form or completion sign-off) as the third document, which requires a service delivery confirmation process that many organizations haven't formalized.

How platforms handle it

Demos of AP automation platforms almost always show the clean case: a PO, a goods receipt, an invoice that matches on every field, and an auto-approval. That tells you the feature exists. The more useful test is a partial receipt: a PO for 100 units, a goods receipt for 60, and an invoice for 100. Walk through what happens. Does the system hold the entire invoice? Can it split the invoice, approving payment for 60 units and holding the rest? Does it match to the partial receipt amount automatically, or does it need manual exception handling? The second test is a price discrepancy within tolerance: a PO unit price of $45.00 and an invoice unit price of $45.85 on a line of 200 units. That's a $170 variance, within a 2% tolerance but meaningful at scale. Does the platform auto-approve on tolerance, flag for review, or require approval? How the system handles these edge cases tells you more about the real AP workload than any clean-match demo. Also ask where PO and goods receipt data comes from: does the AP platform pull it from a connected procurement system and ERP, or does someone have to key it in to complete the match? Manual data entry for matching wipes out much of the efficiency benefit.

Questions to ask

What are the current match tolerance thresholds, and are they calibrated to control effectiveness or just to minimize exception volume?
How does the system handle partial receipts: does it split invoices, hold entire invoices, or require manual handling?
Where does PO data come from: directly from the procurement system, or manual entry into the AP tool?
What is the exception approval workflow when a match fails? Who reviews, who approves, and what documentation is required?
How are service invoices handled where a physical goods receipt doesn't exist?
Is there a reporting view that shows match exception rates by vendor, category, and reason for pattern analysis?

Common mistakes

Three-way match is only as effective as the tolerances you set and the exception workflow you enforce. The most common failure is setting tolerances wide enough that meaningful billing errors pass without review. A 5% tolerance on a $500K construction invoice means $25K of overbilling can auto-approve. Set tolerances on what the company can accept as an unexplained variance, not on what keeps the exception queue manageable. The second failure is having a three-way match requirement with no clear, documented way to resolve exceptions. When AP staff can't get a hold or dispute resolved because there's no defined process for contacting the vendor, getting a corrected invoice, or escalating to procurement, invoices sit in the exception queue past their due dates, which leads to late payment penalties and damaged vendor relationships. The exception resolution process matters as much as the matching logic. Then there is the most common audit finding: three-way match is configured, but a significant share of invoices is approved outside it through manual overrides, bypass routes, or non-PO invoice types that don't need a PO at all. If the control doesn't cover a meaningful portion of spend, it provides less protection than it appears to.

Comparing AP automation

AP tools separate on what happens to the exceptions: the invoices that do not match a PO, arrive without one, or need a second approver. Once three-way match is settled as a requirement, read the Accounts Payable Automation Software category guide for how the market splits, then weigh the Stampli profile against the Tipalti profile on that requirement rather than on the feature list. Our Tipalti pricing breakdown records what the vendor publishes and what is quote-based. The BILL against Stampli comparison sets two of them side by side on the same criteria. Before you book demos, put your own numbers through the AP automation savings calculator so the business case is written down before a vendor writes it for you.

Three-Way Match questions

How is three-way match different from purchase order matching?

Purchase order matching, sometimes called two-way match, compares only the invoice to the purchase order, checking that the billed amount and items agree with what was ordered. Three-way match adds a third document, the goods receipt or delivery confirmation, which verifies what was actually received. Two-way match confirms the vendor billed correctly against the PO; three-way match confirms the goods were delivered before payment is released. Three-way match is the stronger control because it prevents payment for items ordered but not yet received.

What happens to an invoice that fails three-way match?

A failed match routes the invoice to an exception queue for human review. The AP team or a designated approver investigates the discrepancy: contacting the vendor for a corrected invoice if the price is wrong, waiting for additional goods receipt records if the quantity is partially received, or escalating to procurement if the PO terms are disputed. Resolution may involve accepting the discrepancy within a business justification, requesting a credit memo for the overbilled amount, or rejecting the invoice and requesting resubmission. Every exception should be documented with the resolution reason and approver for audit purposes.

Do all AP invoices need to go through three-way match?

Three-way match applies to PO-based invoices, meaning purchases that went through procurement and have a purchase order. Non-PO invoices (utilities, recurring services, subscriptions, expense reimbursements) have no matching PO and go through a different approval process, usually a departmental or cost center approval workflow. A common gap in AP controls is the share of total spend that flows through non-PO invoices and so bypasses three-way match entirely. Reducing maverick spend (purchases made without a PO) increases how much spend the three-way match control covers.

What happens when a three-way match fails?

The invoice becomes an exception and routes for review instead of payment. Common causes are partial deliveries, price changes agreed after the PO was raised, and quantity differences on the receipt. The tolerance settings decide how many of these a human has to touch, which is the main driver of AP workload once volume grows.

ACH Payment, AP Aging Report, and Approval Workflow come up in the same workflow as three-way match, and the rest of the AP automation cluster is indexed in the finance operations glossary.