An invoice arrives. It looks plausible, it names a vendor you use, and refusing to pay it would take more work than paying it. So it gets paid. That — multiplied by every invoice, every month — is the problem three-way matching exists to solve.
Three-way matching is the check a buyer runs before paying an invoice: the invoice is compared against the purchase order (what was agreed) and the receiving record (what actually arrived). Only when all three tell the same story is the invoice cleared for payment.
The three documents, and what each one proves
| Document | Created when | What it proves |
|---|---|---|
| Purchase order | The purchase is approved, before the vendor starts | What was agreed: items, quantities, prices, terms |
| Receiving record | The goods arrive or the service is delivered | What you actually got, and how much of it |
| Invoice | The vendor bills you | What you’re being asked to pay |
Each document comes from a different moment and, importantly, a different motive. The PO records intent, receiving records reality, and the invoice records the vendor’s view. Fraud and honest error both live in the gaps between them — which is why comparing any two is good, and comparing all three is the standard.
What the match actually catches
- Price creep — the invoice charges £13.40 a unit where the PO agreed £12.00. Small per-line, structural over a year.
- Quantity mismatches — invoiced for 10, received 8. Without a receiving record, nobody catches this at payment time.
- Invoices for goods that never arrived — the classic failure of paying from the invoice alone.
- Duplicate billing — the same delivery invoiced twice, months apart. A PO that’s already fully matched refuses the second invoice.
- Uncommitted spend — an invoice with no PO behind it at all, which is less often fraud than a process leak: someone bought outside the approval flow.
Tolerances: why the match must not be exact
A naive matcher that demands equality to the penny generates constant false alarms — rounding, freight variations, a legitimate £2 price adjustment — and a control that cries wolf gets overridden by default, which is worse than no control. Real matching uses tolerances: a percentage band, an absolute cap, or both. Differences inside the band pass; anything outside becomes a named exception a human decides on. The goal is that an exception is rare enough to be taken seriously.
Two-way vs three-way
Two-way matching compares invoice against PO only — right for spend with nothing physical to receive, like software subscriptions. Three-way adds the receiving record, and matters exactly when delivery can differ from the order: physical goods, materials, part-shipments. (Some enterprises run four-way, adding a separate inspection/acceptance step — past the point of diminishing returns for most teams.)
Honestly: when does a small team need this?
If you pay a handful of invoices a month and one person both ordered and received the goods, you are the three-way match — a careful look at the invoice does the same job, and tooling would be ceremony. The check starts earning its keep when volume means invoices get paid on plausibility rather than verification, when the person who ordered isn’t the person receiving, or when part-deliveries make “did we get what we’re paying for?” genuinely hard to answer from memory. Most teams adopt it after finding one overcharge, not before — adopting it one incident earlier is the whole trick.
How this works in SpendCue
SpendCue runs the full loop: approved requests become numbered purchase orders, deliveries are logged against the PO, and invoices are entered and reconciled line by line against both — with the tolerances you set, and exceptions flagged before anything is cleared to pay. One honest caveat: invoices are entered manually — there’s no OCR capture or e-invoicing. The matching itself is automatic; getting the invoice in takes a minute of typing. For teams coming from spreadsheets that trade-off is usually right, and it’s part of why the whole thing works without an ERP at one flat monthly price.