Purchase and delivery matching
Three-way matching against the order and the goods received note, with exceptions surfaced rather than hunted — and the tolerance your team already applies informally written down as an actual policy.
The work being done today
Somebody has an invoice, and needs to know three things: was this ordered, did it arrive, and is the price the one that was agreed. Answering that means finding the purchase order, finding the receipt, comparing quantities and unit prices line by line, and then deciding whether a small difference is worth an email to the supplier or worth letting go.
On a good day that is a few minutes an invoice. On a bad day it is an afternoon chasing an operations manager who has not receipted anything for a fortnight, which is the real reason matching gets skipped and invoices get paid on trust.
What replaces it
- Invoice lines matched to order lines automatically, including partial deliveries and orders that span more than one invoice.
- Quantity checked against what was actually receipted, not against what was ordered and assumed to have arrived.
- Price checked against the agreed order price, so a supplier uplift shows up as a variance rather than as a slightly larger payment nobody noticed.
- Tolerances applied consistently, by value and by percentage, and by category where that makes sense.
- Genuine mismatches routed to the person who can resolve them — usually the requisitioner, not finance — with the order, the receipt and the invoice already assembled.
- Missing receipts chased automatically, which quietly fixes the discipline problem that caused most of the mismatches.
The control question
Three-way matching is not an efficiency measure. It is the control that stops you paying for goods you did not order, did not receive, or agreed a different price for — and it is one of the first controls an auditor asks about.
Which means an automation here has to make the control stronger, not merely faster. The tolerance has to be a stated policy rather than an individual’s judgement on the day. The override has to be attributable to a named person with a recorded reason. And an invoice that cannot be matched must not be able to drift into the payment run because it has been sitting in the queue for three weeks and somebody wants it gone.
A finding you may not want. Matching automation regularly reveals that a meaningful share of spend has no order behind it at all. That is a procurement problem rather than a finance one, and we will say so plainly rather than building around it.
Common questions
Our purchase orders are not reliable enough to match against.
That is common, and it is a finding rather than a blocker. If orders are raised late, raised for round numbers, or raised after the invoice arrives, matching will fail for reasons that have nothing to do with the automation. The honest sequence is to fix the ordering discipline first, and a plan that says so is more useful than one that automates a broken input.
What tolerance should we set?
Whatever you are already applying informally. Most teams have an unspoken rule — a few pounds, or a small percentage, gets waved through. Writing that down turns an inconsistent habit into a policy you can audit, and it is usually the first time anyone has asked what the number should be.
Does this need a goods received note?
For a true three-way match, yes. Where receipting is not reliably done — common in service purchasing — two-way matching against the order still removes most of the work, and the plan says which of your spend categories can support which.
See it against your own process
The quickest way to know whether this is worth doing is to walk one of your own processes through it. That is what the Finance Automation Review is —one week, ending in a ranked build plan.
How the Review worksBook a call
A first call needs nothing prepared and no system access. We reply within one working day.