Three-way matching is widely recognised as the gold standard for enterprise accounts payable control. Compare the purchase order, the goods received note, and the supplier invoice. If they agree, pay. If they do not, investigate.
The logic is simple. The execution is where most enterprises struggle.
Of the three documents in a three-way match, two are relatively easy to manage. The purchase order exists in the procurement system from the moment of approval. The invoice arrives from the supplier and can be ingested digitally. But the GRN — the document that confirms what was actually received — is the one that most AP automation programmes get wrong.
The Three Documents — and What Each One Proves
| Document | What It Proves | Who Creates It | When It Exists |
|---|---|---|---|
| Purchase Order | That the purchase was authorised, at a specific price, for a specific quantity | Procurement team | At PO approval — before delivery |
| Goods Received Note | That the goods were physically received, in the correct quantity and condition | Receiving team | After delivery — created at the point of receipt |
| Supplier Invoice | That the supplier is claiming payment for specific goods at a specific amount | Supplier | Sent after delivery — may arrive before or after GRN |
Three-way matching works by comparing all three documents at line level. When all three agree — at item, quantity, and price — the invoice proceeds to payment automatically. When they disagree, the mismatch is routed for human review and resolution.
Why the GRN is the Weakest Link
In a functioning three-way matching system, the purchase order and the invoice are both digital, structured, and timely. The GRN is frequently none of these. Three reasons the GRN creates three-way matching failures:
- The GRN does not exist when the invoice arrives — In many enterprises, the invoice arrives before the GRN is created. The invoice is on-terms — the supplier sends it immediately after dispatch. The GRN depends on a human in the warehouse creating it, which may happen hours or days later. The invoice sits in the AP queue. The matching engine has two of the three documents — and no way to complete the match.
- The GRN is inaccurate — A GRN created after the fact — from memory, or estimated from the delivery note rather than from a physical inspection — may not accurately reflect what was received. Quantities may be wrong. Partial deliveries may be logged as full receipt. Quality issues may not be documented. When the invoice arrives, the matching engine either creates false matches (paying for goods not received) or false exceptions (flagging a mismatch that does not exist).
- The GRN is in a different system from the invoice — In many enterprise environments, the GRN is created in a WMS or ERP goods receipt module while the invoice is processed in an AP automation system. Without real-time integration between the two, the matching engine cannot see the GRN when it needs it.
The Matching Process at Line Level
Best-in-class three-way matching does not happen at header level — it happens at line level. This distinction matters enormously in practice. Header-level matching compares total quantities and values. Line-level matching compares each item individually — catching mismatches that coincidentally balance at the header level.
For example: if Line 1 has a quantity shortage of 2 units and Line 2 has a quantity surplus of 2 units, the header total matches but both lines are incorrect. Line-level matching catches both issues. Header-level matching misses them both.
The value of line-level matching is particularly significant for: multi-item orders where individual line quantities differ, partial deliveries where some lines are fully delivered and others are short, and substituted items where the supplier delivered a different variant.
The AI Item Matching Problem
One of the most persistent causes of three-way matching exceptions is item description mismatch — where the PO uses one terminology and the supplier invoice uses another, even though they refer to the same product.
| PO Description | Invoice Description | Human Judgement | System Result Without AI |
|---|---|---|---|
| Apple MacBook 13 | Apple MacBook Pro 13-inch M3 Chip 8GB 512GB Space Grey | Same product | Exception — no text match |
| Stainless Steel Shelf 4-Tier | Industrial Shelving Unit SS 4-Level 48×18×72 | Same product | Exception — no text match |
| HP LaserJet Toner 85A | HP CE285A Black Toner Cartridge for LaserJet P1102W | Same product | Exception — no text match |
| Safety Gloves (Medium) | Ansell HyFlex 11-840 Cut Resistant Gloves Sz8 Medium Safety Work | Same product | Exception — no text match |
AI semantic matching solves this by understanding the meaning of item descriptions rather than just comparing text strings. The matching engine extracts and compares key attributes — brand, product family, model, specification, size — and determines whether the PO and invoice describe the same product, even when the language is entirely different. The result: fewer false exceptions and higher straight-through processing rates.
Three-Way Matching Configurations
| Matching Type | Documents Compared | When to Use |
|---|---|---|
| Two-way matching | PO + Invoice | Low-value purchases, services without a receipt document, pre-approved recurring payments |
| Three-way matching | PO + GRN + Invoice | Standard goods procurement — most common configuration |
| Four-way matching | PO + GRN + Inspection record + Invoice | High-value goods, technical items requiring quality inspection, regulated industries |
| Service matching | PO + Service receipt + Invoice | Services, contractors, consultants — no physical GRN |
| Consolidated matching | Multiple POs + Multiple GRNs + One Invoice | Consolidated supplier billing, frame agreements, blanket orders |
Tolerance Rules: The Key to High Straight-Through Processing
Not every discrepancy between PO, GRN, and invoice is a genuine exception. Without tolerance rules, every minor variance generates an exception — consuming AP time reviewing cases that should be auto-approved. With tolerance rules, only genuine exceptions require human review.
| Variance Type | Auto-Approve Threshold | Flag for Review | Escalate to Finance |
|---|---|---|---|
| Price variance | < 1% | 1–3% | > 3% |
| Quantity variance | < 2% | 2–5% | > 5% |
| Invoice amount variance | < ₹500 | ₹500–₹2,000 | > ₹2,000 |
Measuring Three-Way Matching Performance
| Metric | Definition | Target |
|---|---|---|
| Straight-through processing rate | Percentage of invoices that match automatically without human intervention | 80–90% |
| Time-to-GRN | Average time between delivery and GRN creation | < 4 hours |
| GRN accuracy rate | Percentage of GRNs that match the invoice without discrepancy | > 95% |
| Exception resolution time | Average time from exception raised to resolution | < 48 hours |
| Duplicate invoice detection rate | Percentage of duplicate submissions caught before payment | 100% |
| Early payment discount capture rate | Percentage of eligible early payment discounts captured | > 70% |
The Connection Between GRN Automation and Straight-Through Processing
| GRN Process Maturity | Typical Straight-Through Processing Rate |
|---|---|
| Paper-based, created after the fact | 20–40% |
| Digital but created end-of-day | 40–60% |
| Digital, created same day | 60–75% |
| Mobile, created at point of delivery | 75–90% |
| Mobile + AI item matching + multi-channel GRN ingestion | 85–95% |
Frequently Asked Questions
Two-way matching compares only the purchase order and the invoice. Three-way matching adds the goods received note as a third document — confirming that the goods were actually received before the invoice is approved for payment. Three-way matching provides significantly stronger financial control because it prevents payment for goods that were never delivered.
The most common failure is the GRN problem: the invoice arrives before the GRN is created, or the GRN is inaccurate because it was created from memory rather than at the point of delivery. Automated invoice ingestion cannot compensate for a missing or inaccurate GRN. The second most common failure is item description mismatch — where vendor terminology differs from PO terminology and the system cannot resolve the difference without AI semantic matching.
Tolerance rules define acceptable variance thresholds between PO, GRN, and invoice. When variances fall within tolerance, the invoice is approved automatically. When they exceed tolerance, the invoice is routed for human review. Tolerance rules are typically configured by vendor, category, and value — different thresholds for strategic suppliers of critical goods vs spot purchases.
Yes — but only if the matching engine is built to support it. In consolidated billing scenarios where one supplier invoice covers multiple purchase orders, the matching engine needs to allocate invoice lines across the appropriate POs and GRNs before evaluating variances. This requires a more sophisticated matching architecture than simple one-to-one PO-to-invoice matching.
Best-in-class enterprises target 85–95% straight-through processing — meaning 85–95% of invoices match automatically without human intervention. Rates below 70% typically indicate a GRN quality problem, a tolerance rule problem, or an item description matching problem.
Three-way matching is one of the most effective controls against payment fraud. It prevents: payment for goods never ordered (no PO), payment for goods never received (no GRN), duplicate payment (duplicate invoice detection), and payment at the wrong price (price variance detection). Each of these controls depends on the matching engine having accurate, timely GRN data.
Three-way matching that works — because the GRN is always there
Hubler's three-way matching engine operates at header and line level, with AI semantic item matching, multi-channel GRN ingestion, and configurable tolerance rules. Part of the full procure-to-pay suite.
See Three-Way Matching in Hubler →