What Is Three-Way Matching? (PO, Delivery, Invoice)
The control that stops you paying for goods you never received, at prices you never agreed — what three-way matching is, how it works, and when two-way or four-way matching fits better. It checks that a charge is correct; it does not ask whether the charge was yours, which is [a separate question about freight](/blog/whose-freight-is-it).
Three-way matching is an accounts payable control that compares three documents before a supplier invoice is paid: the purchase order (what you agreed to buy, at what price), the goods received note or delivery record (what actually arrived), and the invoice (what the supplier is charging). Payment is released only when all three agree — same items, same quantities, same prices, within tolerance. If any pair disagrees, the invoice is held until the difference is explained.
Why it exists: the three failure modes it blocks
- Paying for what never arrived. The invoice says 100 units; the receiving record says 80. Without the match, the missing 20 are paid for and written off later as "shrinkage".
- Paying a price you never agreed. The PO said 45.00 per unit; the invoice says 48.50. Unit-price drift across hundreds of invoices is one of the quietest margin leaks in any operation.
- Paying twice. Duplicate and re-sent invoices get caught because the PO they reference has already been fully matched and closed.
The match, step by step
- 1. PO ↔ Receipt: was everything received actually ordered, and did everything ordered arrive (or is the balance still open)? Over-deliveries and substitutions surface here.
- 2. Receipt ↔ Invoice: is the supplier billing only for what was received? Partial deliveries should produce partial invoices — or partial payments.
- 3. PO ↔ Invoice: do prices, discounts, and terms on the invoice match what was agreed on the order?
- 4. Exception handling: any mismatch outside tolerance routes to a human with the three documents side by side — approve with a reason, or dispute with the supplier.
| Variant | Documents matched | Best for |
|---|---|---|
| Two-way match | PO ↔ Invoice | Services and utilities where "receiving" is not physical |
| Three-way match | PO ↔ Receipt ↔ Invoice | All physical goods — the standard |
| Four-way match | PO ↔ Receipt ↔ Inspection ↔ Invoice | Goods requiring quality acceptance before payment (pharma, food, regulated inputs) |
Tolerances: strictness that survives reality
A zero-tolerance match holds every invoice over a rounding cent and teaches the team to bypass the control. Practical setups allow small tolerances — commonly 1–2% on price or a fixed small amount, and exact quantity matching for discrete goods — with everything outside tolerance requiring an explicit, logged approval. The tolerance is policy; the log is the audit trail.
The match is only as honest as the receiving record
Three-way matching assumes someone actually counted the delivery. If receiving means signing the driver's note unread, the match automates a fiction. The control chain is: independent receiving (not the person who ordered), counted against the PO, then the match. Weighing and counting at the door is where the money is defended.
Implementing it without drowning in paper
Manual three-way matching is a filing exercise that fails at volume — which is why it belongs in the purchasing system: the PO, receiving record, and invoice live as linked documents, matching runs automatically, and only exceptions need eyes. It is one link in the wider procure-to-pay chain, and the payoff compounds with volume: the hundredth invoice costs nothing to check.
For sector-specific applications, see how the match protects NGO procurement, hotel receiving bays, and clinic supply chains.
What AWRA OpsHub does today
- Ordered against received, on every purchase order — quantity compared line by line, with the result shown on the order itself rather than returned to a developer.
- The linked chain the match depends on: requisition → RFQ → quotation → purchase order → check-in → invoice → payment, each step referencing the last.
- An over-receipt guard at the door. Receiving more than the order allows is refused before anything is written, counting what was already received so a split delivery cannot creep past the ordered quantity one receipt at a time.
- Configurable tolerances, quantity and price, per organization — because a control that flags a rounding difference gets ignored within a week.
- A persisted match status and an exception queue, so "which orders do not reconcile?" is a list somebody works rather than a calculation nobody runs.
- Payment blocked when the order does not reconcile — on every payment route, not just the obvious one. Releasing it anyway needs a separate permission and a written reason, recorded against the order with who and when, and that authorisation is withdrawn automatically if the discrepancy later changes into a different one.
- Approved purchase orders counted as commitment, so a budget reflects the order before the invoice arrives.
More we can add to your workspace
- A data source for the third leg, which is what turns this from a two-way match into a three-way one. Supplier invoice lines are the piece to capture: what the system stores as an "invoice" today is a goods-received valuation it generates itself at check-in from our own cost price, carrying no vendor and no supplier invoice number. A supplier's actual invoice attaches as a file and is read by nobody. Billed quantity and price are therefore compared only where line detail exists, and never for orders received before this was addressed.
- Case management on the exception queue. It lists today: discrepancies are unassigned, carry no resolution status or ageing, and clear when the underlying documents change. An "approve with a reason" disposition of the kind step 4 above describes is the build.
- An inspection or quality-hold gate at receipt, so four-way matching is not achievable.
- An invoice capture or OCR, and no payment run or batch payment approval.
We would rather correct ourselves in public than leave this tidy. An earlier version of this page claimed the service compared all three documents. It did not: it looked up invoice lines by a field the stored data never contained, so it reported a phantom discrepancy on every order — and because the result had no screen, nobody found out. The surface is now built, the calculation is fixed, and payment is genuinely held when an order does not reconcile; the honest name for what it does is a two-way match. If matching against a supplier invoice is a live requirement rather than a principle you are reading up on, we do not have it yet, and you should ask us for a date rather than a demo.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsThe linked chain a match needs
Requisition to payment with every step referencing the last, ordered-against-received reconciled on the order itself, an over-receipt guard at the door, and approved POs counted as commitment.
See receipt matching in AWRAFrequently asked questions
What is the difference between two-way and three-way matching?
Two-way matching compares only the purchase order and the invoice; three-way adds the receiving record. For physical goods, three-way is the standard because it verifies delivery, not just agreement. Two-way suits services, subscriptions, and utilities where nothing physical arrives.
Does three-way matching slow down supplier payments?
Clean invoices actually pay faster, because matching is automatic and approval queues shrink. What slows down are mismatched invoices — which is the control working. Suppliers who deliver and bill accurately quickly notice they get paid on time, every time.
What tolerance should we set?
A common starting point: 1–2% or a small fixed amount on price, zero tolerance on quantity for discrete goods, and looser quantity tolerance for weighed/bulk goods where scale variance is physical reality. Review the exception log quarterly and tune — a tolerance that generates constant exceptions is set wrong in one direction or the other.
Can small businesses use three-way matching without an ERP?
The principle scales down: staple the PO copy, the counted delivery note, and the invoice together, and pay only complete staples. It works at low volume — and its breakdown point (volume, multiple approvers, partial deliveries) is usually the signal the business has outgrown manual controls.
