PO matching is a control that compares what you agreed to buy, what arrived, and what you've been billed. Where they disagree, the invoice stops.
It's a genuinely strong control and it's also more process than many small businesses need. This covers how it works, the tolerances that make it survivable, and how to tell whether you should be running it at all.
Two-way and three-way
Two-way matching compares the invoice against the purchase order. Does the price match what was agreed, and the quantity match what was ordered.
Three-way matching adds the goods receipt — a record of what physically turned up. Now you're checking that you agreed the price, that the goods arrived, and that you're being billed for what arrived rather than what was ordered.
The third leg is the one that catches the expensive errors. An order for 100 units, a delivery of 80, and an invoice for 100 passes a two-way match cleanly and overpays by twenty per cent.
Some businesses add a fourth check — an inspection or quality record — but that's mostly manufacturing.
What you need before it works
Matching only functions if the upstream discipline exists. This is where most attempts fail, and the failure is never in the matching step itself.
Purchase orders actually raised. If half the spend arrives without a PO, half the invoices can't be matched and you've built a control with a hole in it. This is the usual sticking point, and it's a behaviour problem rather than a systems one.
PO numbers on invoices. Suppliers need to quote your reference. Ask at the point of ordering, put it on the PO document, and chase the ones that don't.
Goods receipts recorded. Somebody notes what arrived, when, in what quantity. For three-way matching this is non-negotiable, and it's usually the leg that isn't happening.
Consistent units. The PO says 10 boxes, the delivery note says 240 units, the invoice says 20 cases. Matching against three unit conventions produces exceptions that aren't errors — and it only works at all if your capture tool reads the line items, not just the header.
If you can't get the first three reliably, matching will generate more work than it prevents.
The process
- Invoice arrives and is captured with its PO reference.
- Retrieve the PO using that reference. No reference means it drops to manual.
- Retrieve the goods receipt for that PO.
- Compare price, quantity and total across the three.
- Within tolerance — the invoice passes for payment, usually without human approval, because the PO already carried the authorisation.
- Outside tolerance — the invoice is held as an exception and routed to whoever can resolve it.
Step 5 is the point of the whole exercise. A matched invoice doesn't need a separate approval, because the approval happened when the PO was raised. Businesses that run matching and full approval on every invoice have paid for the control twice.
Tolerances make it workable
Exact matching fails constantly on rounding, part-deliveries and small carriage charges. So matching runs with a tolerance — a band inside which a difference isn't worth stopping for.
Typical shapes:
- Percentage tolerance: anything within 2% of the PO value passes
- Absolute tolerance: any difference under £5 passes
- Both, whichever is lower, which stops a 2% tolerance becoming £400 on a large order
- Quantity tolerance for part-deliveries, so an under-delivery invoiced correctly doesn't stop
Set them too tight and everything becomes an exception, which means people start waving exceptions through and the control is worthless. Set them too loose and small overcharges pass unchallenged.
Start looser than feels comfortable, then tighten once you can see how many exceptions you're actually generating.
The common failure modes
Part-deliveries. One PO, three deliveries, three invoices. Each invoice matches part of the order, and the system needs to track cumulative quantity rather than compare each invoice to the whole PO.
Carriage and surcharges that appear on the invoice but weren't on the PO. Common, legitimate, and a permanent source of small variances. Decide the treatment once.
Price increases applied by the supplier without renegotiating. Matching catches these, which is exactly what it's for — but only if somebody acts on the exception rather than approving it.
Blanket orders for ongoing services, where there's no discrete delivery to receipt. Matching doesn't really apply; these need a different control.
Nobody owning exceptions. The most common failure of all. A matching system that generates a queue nobody works is a queue, not a control.
When it isn't worth it
Genuinely, for a lot of small businesses, it isn't.
Matching earns its place when spend is committed in advance and delivered in discrete lots — stock, materials, equipment. It works poorly for services, subscriptions, utilities and professional fees, where there's no meaningful goods receipt.
If most of your purchases are services, or if POs aren't reliably raised, the honest answer is that the effort is better spent elsewhere. Getting the right context to the right approver prevents most of the same errors at a fraction of the process cost.
A reasonable middle position: run matching on the categories where it fits — usually stock and materials — and route everything else through ordinary approval. Partial coverage on the spend that suits it beats a universal process people work around.
A lighter alternative
If full matching is more than you need, most of the benefit comes from three habits:
Keep related documents together. The invoice, its delivery note and any credit note against it are one commercial event. Most of the value of matching is simply having them in one place when someone looks.
Check the arithmetic on arrival. Net plus VAT equals gross, line totals sum to the total. Catches supplier errors without any PO.
Send the approver what they need to recognise it. Who ordered it, what it relates to, what was expected. Most invoice errors are caught by the person who placed the order, if they're given enough to recognise it.
That's not a substitute for matching in a business that needs matching. For one that doesn't, it's most of the protection for almost none of the overhead.
A note on what Cribble does here: it reads the documents around an invoice — delivery notes, credit notes, statements — and links related ones together, so what reaches a person arrives with its supporting paperwork. That's reference linking, not variance matching: Cribble doesn't compare quantities against a purchase order or enforce tolerances. If you need true three-way matching, you want a dedicated procurement system.