Purchase order and GRN matching
Three documents that should agree, compared by hand, usually after the payment has been queued.
Three-way matching is a rules problem sitting on top of a reading problem. Solve the reading and the rules run themselves.
Typical timeline: Live in 8–10 weeks
Three documents that should agree
These are the signs this is worth doing
If several of these are true, this is usually where the fastest return sits.
Three-way matching is not conceptually difficult: what was ordered, what arrived, and what is being billed should agree. Where it breaks down is that the three documents live in different places, in different formats, and comparing them is nobody's favourite task.
So it gets done partially, or in a hurry, or after the invoice is already in an approval queue — which is the worst moment to discover a short delivery, because the conversation with the supplier is now about a payment rather than about a delivery.
What the matching covers
Quantity
Ordered against received against billed, with tolerances you set — because a small variance on a bulk commodity is normal and on a serialised item is not.
Price
Rate checked against the agreed contract or last purchase price, with variance beyond tolerance flagged before approval rather than after payment.
Timing
Deliveries against schedule, so persistent lateness is visible as a pattern rather than as a series of individually forgiven incidents.
Exceptions, early
Anything unmatched surfaced at receipt, when the goods and the driver are still there and it can actually be resolved.
What changes operationally
- Clean matches approve automatically within your tolerances.
- Exceptions reach a person at receipt, not at payment.
- Tolerances are configured once and applied consistently by everyone.
- Supplier performance becomes measurable without a separate exercise.
- Disputes are evidenced by records rather than argued from memory.
Finding a short delivery at payment is not finding it. It is finding out you already accepted it.
We would rather tell you now than three weeks into a project. This work is usually the wrong call if any of the following describes you.
- Businesses without proper goods receipt records. Matching needs three documents; two is a different project.
- Very low purchase volumes.
- Operations where deliveries are genuinely variable by nature and tolerance ranges would have to be so wide they catch nothing.
The systems involved
We integrate rather than replace wherever it makes sense. These are the systems this work most commonly touches.
PO and GRN matching — questions we get asked
What if we do not raise formal POs?
Then start with two-way matching — receipt against invoice — which still catches quantity and price problems. Introducing POs is a separate process change we can advise on but would not bundle in.
Who sets the tolerances?
You do, per category, and they are visible and adjustable. We will suggest starting points from your own history rather than imposing a default.
Does this work with our existing ERP?
Generally yes — the matching layer reads POs and receipts from the ERP and writes results back. We integrate rather than asking you to move procurement somewhere new.
The services this work sits inside
Where this comes up most
The sectors where we most often do this work, and where the payback is usually clearest.
Others worth reading
Invoice data extraction and posting
Extraction is mature enough to post most invoices automatically. The design question is what happens to the ones it is unsure about.
Read itVision AIDelivery challans and weighbridge slips
Capturing proof of delivery at the gate, from a phone, closes the loop between what left and what was invoiced.
Read itThinking about po and grn matching?
Start with a short conversation. We will tell you honestly whether this is the right place to begin, or whether something else pays back faster.