Your Matching Process Approved the Invoice. That Does Not Mean It Was Right
The invoice came in with the correct PO number. The price matched. The AP team ran the check, found no issues, and released payment. No exception was raised. No flag appeared.
What the check did not catch: only 160 of the 200 units had been delivered. The goods receipt note was never entered. The system matched the invoice to the PO, found agreement, and approved payment for 40 units that were still sitting in the supplier's warehouse.
This is the specific gap that three-way matching closes. A two-document check confirms you were billed correctly for what you ordered. It cannot confirm you were billed correctly for what you actually received. This guide explains the difference, how the matching process works at each stage, when each type applies, and what to do when a match fails.
What Is Three-Way Matching, and Why Does a Two-Document Check Not Always Hold?
Three-way matching compares three documents before any payment is authorised: the purchase order, the goods receipt note, and the supplier invoice. All three must agree on quantities, prices, and totals within defined tolerance limits. A clean match auto-approves the invoice. A mismatch creates an exception that must be resolved before payment proceeds.
Each document answers one specific question:
Purchase order (PO): What did we agree to buy, at what price, in what quantity?
Goods receipt note (GRN): What actually arrived, confirmed at point of delivery?
Supplier invoice: What is the vendor claiming we owe them?
Why all three matter: A PO and invoice can agree perfectly while goods were never fully delivered. A GRN and invoice can align while the price differs from what was negotiated. Only comparing all three simultaneously catches both billing errors and delivery discrepancies.
The Benefits of Three-Way Matching: What Financial Risk Does It Actually Eliminate?
The business case for three-way matching is not just process discipline. It is the financial exposure that exists without it.
Overpayment and short delivery
The most common risk. A supplier invoices for 100 units, only 85 were delivered, and the AP team approves payment for 100 because the invoice matched the PO. Without a goods receipt check, the discrepancy is invisible at approval time. It surfaces weeks later during a stock count or a supplier statement reconciliation, at which point recovery requires raising a credit note, chasing the supplier, and documenting the dispute. Three-way matching catches it before payment leaves the account.
Invoice fraud
In 2024, 79% of organisations experienced payment fraud and the average loss per incident exceeded $130,000 Source: AFP 2025 Payments Fraud and Control Survey. Fraudulent invoices typically mimic legitimate ones: correct supplier name, plausible PO reference, realistic amount. Three-way matching breaks this pattern because a fraudulent invoice cannot produce a matching goods receipt note for goods that were never ordered or delivered. Without the GRN check, a convincing fake invoice can pass a two-document verification.
Duplicate payments
The same invoice submitted twice, either accidentally by the supplier or deliberately, is one of the most common sources of financial leakage in AP. Three-way matching reduces this risk at the point of processing. Combined with deduplication at invoice capture, it closes the gap that duplicate invoice fraud exploits.
Audit and compliance exposure
When auditors request evidence that payments were made for goods actually received, the goods receipt note is the document that provides it. Organisations relying on two-way matching can confirm they were billed correctly. They cannot confirm what was delivered. For regulated industries, capital projects, or any spend subject to audit scrutiny, that distinction matters.
How Does the Three-Way Match Actually Work? Each Stage Explained
The matching process runs in a specific sequence. Understanding what is being checked at each stage explains why certain exceptions occur and where they need to be resolved.
Stage 1: PO validation
The system first confirms that a valid, approved purchase order exists for this vendor and that the PO number on the invoice matches an open PO in the ERP.
If there is no PO reference on the invoice, or the number does not match any open order, the invoice fails here before matching begins. This is the most common source of non-PO invoice exceptions: purchases were made informally, without a PO, and the invoice arrives with nothing to match against.
Stage 2: GRN confirmation
With the PO confirmed, the system retrieves the goods receipt note for the items being invoiced. If the GRN has not been entered yet, the match is blocked.
GRN entered same day as delivery: matching proceeds immediately
GRN entered two days late: invoice waits, payment terms erode, vendor escalates
GRN never entered: invoice stays in exception queue indefinitely
Late GRN entry is the single most preventable cause of AP cycle delay. It has nothing to do with the invoice itself.
Stage 3: The three-way comparison
With both documents retrieved, the system compares all three at the line-item level:
Quantity on invoice vs. quantity on PO vs. quantity confirmed on GRN
Unit price on invoice vs. unit price on PO
Line-item descriptions and SKU references across all three documents
Invoice total vs. calculated total from PO prices and GRN quantities
Real example: a vendor invoices 100 units at $42.50 each, total $4,250. The PO agrees. The GRN shows only 95 units received. The invoice is for 5 units more than what was delivered. Without three-way matching, that $212.50 overpayment proceeds to payment.
Stage 4: Tolerance check
Not every discrepancy triggers a manual exception. Organisations set tolerance thresholds: a ±2% price variance, for example, auto-approves. A 3% variance flags for review. The threshold governs whether a small difference is treated as acceptable rounding or a genuine mismatch. More on setting these correctly in the tolerance section below.
2-Way vs 3-Way Matching: Key Differences and When to Use Each
The difference between 2-way and 3-way matching is a single document: the goods receipt note. 2-way matching compares the invoice to the purchase order only. 3-way matching adds the GRN to confirm delivery actually happened.
2-Way Matching | 3-Way Matching | |
|---|---|---|
Documents compared | PO + Invoice | PO + GRN + Invoice |
Confirms billing accuracy | Yes | Yes |
Confirms delivery occurred | No | Yes |
Catches undelivered goods | No | Yes |
Processing speed | Faster | Slightly slower (GRN needed) |
Fraud protection | Partial | Stronger |
When to use 3-way matching
Three-way matching applies wherever there is a physical deliverable that can be independently confirmed at the point of receipt:
All physical goods and inventory purchases
High-value purchases regardless of spend category
New or unverified vendors where trust has not yet been established
Regulated spend categories where delivery proof is a compliance requirement
Capital expenditure invoices above your defined threshold
When 2-way matching is appropriate
Two-way matching suits purchases where there is no physical delivery to confirm. Professional services, software subscriptions, consulting fees, recurring utility payments under blanket orders, and low-value routine spend from established suppliers are the natural fit. The PO establishes the agreed price and terms; the invoice either matches it or it does not. Adding a GRN requirement where no goods were delivered creates administrative friction without adding meaningful control.
Most organisations run a mixed policy rather than choosing one approach for everything. The decision logic is straightforward: if goods physically arrived at your premises, three-way matching is the right control. If the purchase was intangible or recurring, two-way is sufficient.
A Match Failed. Now What? Exception Types, Owners, and How to Resolve Them
A matching failure produces an exception. The invoice cannot proceed to payment until the exception is resolved. The most common mistake AP teams make is treating all exceptions the same way, routing everything to a generic queue and waiting. Different exceptions have different root causes, different resolution paths, and different owners.
Exception type | What caused it | Who resolves it | Resolution path |
|---|---|---|---|
Price mismatch | Invoice price differs from PO price | Procurement | Query vendor for credit note or amended invoice; or raise PO amendment if price change was legitimate |
Quantity mismatch | Invoice quantity differs from GRN | Receiving team | Confirm whether goods are in transit or genuinely short-shipped; request credit for undelivered units |
Missing GRN | Goods received but GRN not entered | Operations / warehouse | Enter the GRN immediately; if goods not yet received, hold invoice until delivery confirmed |
No PO reference | Invoice arrived with no PO number | Requester / business owner | Retrospectively raise PO or confirm approval through management override with documented justification |
Duplicate invoice | Same invoice submitted twice | AP team | Cross-reference invoice number and vendor; cancel the duplicate and document for audit |
The single biggest driver of AP cycle delays is exceptions with no named owner. When a price mismatch lands in a generic exception queue and sits for four days because nobody knows it is their responsibility, the invoice misses its payment window, the vendor escalates, and the AP team spends time on a problem that a clear routing rule would have resolved in hours.
Before implementing any matching automation, define each exception category, assign a default owner, and set a resolution SLA.
Without those three things, automation moves exceptions from one unresolved queue to another.
What Are Tolerance Thresholds and How Tight Should Yours Be?
Tolerance thresholds define the acceptable variance between matched documents. A discrepancy that falls within tolerance auto-approves. A discrepancy that exceeds tolerance becomes an exception.
Example: your tolerance is set at 2% on price and 5% on quantity. A vendor invoices $102 instead of the PO price of $100. That is a 2% variance, exactly at the threshold. Depending on whether your rule is 'within 2%' or 'up to and including 2%', this either auto-approves or flags. For quantity, if 95 units were delivered but 100 were invoiced, that is a 5% variance. At a 5% threshold, it passes. At 6%, it flags.
Setting the right threshold
Tolerances need to reflect the actual risk profile of each spend category, not a single number applied to everything.
Tight tolerances (1 to 2%): High-value purchases, precision components, capital expenditure, regulated spend where accuracy is a compliance requirement
Moderate tolerances (3 to 5%): Standard inventory, general goods purchases, established vendor relationships
Higher tolerances (5%+): Low-value routine spend, consumables, categories where minor variance is expected and inconsequential
A practical test: if your exception rate is running above 20 to 25%, your tolerances are probably too tight, generating false positives that waste AP team time. If exceptions are rarely surfacing but you are seeing payment errors, your tolerances may be too loose. Review exception data quarterly and adjust accordingly.
What a tolerance rule does not solve
Tolerances are designed to handle minor, expected variances in well-run processes. They cannot compensate for structural problems: invoices routinely arriving without PO references, GRNs never recorded at delivery, pricing agreements not reflected accurately in the ERP. If exception rates are high, check the upstream process before widening the tolerance.
Why Does Manual Matching Still Cause Problems Even When Teams Try Hard?
Manual matching works when invoice volumes are low and supplier relationships are simple. It stops working reliably as volume, vendor diversity, and invoice format complexity increase.
Volume and time
A manual three-way match on a simple single-line invoice takes a few minutes. On a complex invoice with twenty line items, partial shipments across multiple PO lines, and freight surcharges not in the original PO, it takes significantly longer. The process does not scale linearly. At 500 invoices a month it is manageable. At 5,000 it becomes the bottleneck.
Consistency
Human matching is not consistent across time or pressure levels. The same AP team member applies different judgment to a Tuesday morning invoice versus one on the last day of month-end close. Tolerance decisions shift. PO references get assumed rather than verified. GRNs get treated as received when they have not been formally recorded. Automated matching applies identical rules at identical thresholds to every invoice, regardless of the day, the volume, or the pressure.
Exception rate growth
As invoice volumes double, manual exception work doubles too. An AP team handling 50 exceptions a month at 500 invoices is not equipped to handle 500 exceptions at 5,000 invoices without hiring proportionally. The exception queue eventually overtakes the routine processing queue, which inverts the entire purpose of having a structured matching process.
AP Automation Guide: How to Automate Three-Way Matching Without Creating New Bottlenecks
Automated matching changes the matching process structurally, not cosmetically. Understanding what each layer of automation handles, and what it does not, is what separates a successful implementation from one that moves the bottleneck rather than removing it.
What to configure before turning anything on
Two things need to be defined before any matching automation goes live, or it will not deliver the expected results:
Exception ownership: every exception category needs a named owner and a resolution SLA. Price mismatches to procurement. Quantity mismatches to receiving. Missing GRNs to operations. Without this, automation routes exceptions to a queue nobody actively manages.
Tolerance thresholds by spend category: not a single blanket percentage. High-value and regulated spend warrants tighter tolerances (1 to 2%). Standard inventory can carry wider ones (3 to 5%). This configuration determines your exception rate from day one.
What rule-based matching automates
Standard PO-backed invoices in familiar formats from established vendors match automatically. The AP team only touches exceptions. For a team processing 80% PO-backed invoices, that is 80% of volume handled with no manual document retrieval or comparison. The exception queue shrinks immediately but does not disappear.
What rule-based matching does not automate
Non-standard formats, non-English language invoices, and handwritten documents often fail data extraction before matching even begins. Complex exceptions where a price difference reflects a contract amendment not updated in the ERP require judgment, not rules. The exception queue shrinks, but its contents are harder, not easier, to resolve.
Where agentic AI changes the equation
Agentic AI matching platforms deploy specialist agents that investigate and resolve exception categories without human input. When a price mismatch occurs, the agent checks the vendor's contract in the ERP, reviews historical invoice patterns for that vendor, and either resolves the exception automatically or routes it with a resolution recommendation. The AP team's role shifts from investigating exceptions to reviewing what the AI resolved.
The practical difference shows up in the touchless rate trajectory. Rule-based systems reach their initial rate at go-live and stay there. Agentic systems improve over 60 to 90 days as the matching agent learns the specific patterns of that organisation's vendor base. At 90 days, the gap between rule-based and agentic matching touchless rates is typically 20 to 30 percentage points.
When the Volume Grows, Does Your Matching Process Grow With It?
Most organisations reach a point where their matching process, whether manual or rule-based automated, stops keeping pace. Invoice volumes grow. Supplier bases become more international. Multi-entity structures create cross-entity matching requirements. Non-standard invoice formats increase. The exception queue grows faster than the team can resolve it.
At that point, the question is not whether to invest in better matching, but what kind. Rule-based automation is the appropriate first step: it eliminates manual work on clean invoices and creates structure around exceptions. The limitation is that exceptions still require human resolution, and the system cannot learn from its own resolution patterns to improve over time.
Agentic AI matching platforms close that gap. Instead of flagging exceptions and waiting, specialist AI agents investigate, resolve, or escalate each exception category with a recommendation. The AP team's role shifts from matching and exception investigation to exception oversight: reviewing what the AI resolved and intervening only on genuinely novel cases that fall outside learned patterns.
SprintAP by Mindsprint is built on this agentic model. The AI Matching agent handles 2-way and 3-way matching at scale, learns from organisation-specific vendor patterns, and resolves common exception categories autonomously. For organisations that want the matching process operated on their behalf with committed outcome targets, Augmented Finance Operations from Mindsprint provides the platform plus managed operations with milestones at 30, 60, and 90 days. The Mindsprint team can walk you through what those outcome targets look like for your invoice volumes and vendor mix.
