Did we order it, did we get it, is this the price? How three-way matching works, why the goods receipt is the only evidence, and what GRNI tells you.
A builders' merchant invoice arrives with forty lines on it. Thirty-nine are exactly right. Line 22 is a pallet of insulation that appears on no purchase order, delivered "as discussed" to someone on site who is no longer on that site.
Eyeball the total and you find nothing, because the total is internally consistent: it is the correct sum of forty lines, one of which you never ordered. The only way to catch line 22 is to check line 22.
Here is the thing worth noticing about your own process: you already do this check. You do it on the invoices that look wrong - the one that arrived too fast, the one from the supplier who has form, the one where the number ends in a way that feels off. You are already performing a three-way match, informally, on maybe five percent of your invoices, chosen by instinct.
Doing it systematically is not a more sophisticated version of that. It is the same check applied to the other ninety-five percent - the ones that look fine. Which is where line 22 lives, because a line you never ordered has no reason to look suspicious.
Three documents, and only one of them is evidence
The purchase order, the goods receipt, the supplier invoice. Everyone knows the list. What matters is what each one actually is.
The purchase order is what you intended. The invoice is what the supplier claims. The goods receipt is the only one of the three that is evidence - a record, made by a person who was physically there, of what came off the truck.
That distinction does the whole job. Consider what a two-way match between order and invoice can catch: a price that doesn't match what you agreed, a quantity that doesn't match what you asked for, a line item you never ordered at all. Genuinely useful. Now consider what it cannot catch, ever, by construction.
A short delivery always passes a two-way match. You ordered 12, the supplier invoiced 12, the documents agree beautifully, and 10 arrived. Both documents describe the same intention. Neither describes reality. The only document that describes reality is the one sitting on a clipboard in a van.
That is the real reason smaller companies don't do three-way matching, and it has nothing to do with sophistication. It is that the middle document doesn't exist as data. It exists as a signature on a piece of paper that gets handed in on Friday, if it gets handed in at all.
The three questions, and the eight answers
Three comparisons, run on every line:
- Did we order it? The invoice line is located on a purchase order line. If it can't be, that is a finding in itself.
- Did we get it? The invoiced quantity is compared against the posted receipt quantity.
- Is this the price we agreed? The invoiced unit price is compared against the PO's.
The answers are not pass and fail. Foxpedite grades each line as one of eight outcomes: matched, matched with warning, quantity mismatch, price mismatch, missing delivery, over receipt, unknown line, or pending. That vocabulary exists because "something's off" is not actionable and "quantity mismatch of two units against a posted receipt" is. (Invoices →)
Two design decisions underneath it are worth stating plainly, because they are the difference between a matcher you trust and one you learn to ignore.
An invoice rolls up to its most severe line, not its average. Thirty-nine good lines and one unknown line is an invoice with an unknown line on it. Averaging would let a single bad line in forty disappear into a reassuring summary, which is exactly what happened in the opening example.
Any unevaluated line rolls the invoice up to pending, never to matched. "We haven't checked this yet" and "we checked it and it's fine" must not produce the same badge. A system that lets the first quietly present as the second has taught you to trust a green light that means nothing.
Twelve helmets, ten helmets
A site supervisor orders 12 safety helmets at $107 each. $1,284 on the purchase order. (Purchase orders →)
The delivery turns up on a Thursday afternoon during a pour. Ten helmets. The driver has a note that says twelve, the supervisor has forty minutes of concrete and a signature to give, and he signs it. Everyone here is behaving reasonably.
Five weeks later the invoice arrives: 12 helmets, $107 each, $1,284. It matches the purchase order exactly, because both documents describe what was ordered. It goes through the payment run. The company has paid $214 for two helmets that do not exist.
And here is the part that makes it permanent: those two helmets will never show up in a stock count either, because they were never there to be counted. There is no second control downstream that catches this. The shortfall is invisible from the day the note was signed.
Now the version with a posted receipt. The supervisor - or the storeman on Friday - posts the receipt as 10, which takes about as long as signing a piece of paper. Five weeks later the invoice arrives and the match runs: invoiced 12, received 10, variance of 2 units, 16.7% over receipt. The line comes back as an over receipt and the invoice does not present as matched. Somebody looks at it before the payment run, not after.
Same delivery. Same invoice. Same supplier. The only difference is that the middle document became data.
Tolerances, and why matching to the cent is the wrong goal
A matcher that flags every one-cent rounding difference gets switched off within a week - by someone reasonable, for a reasonable reason. Tolerances are not a loosening of the control. They are what makes the control survivable.
Foxpedite's model works like this. A tolerance can be set as a percentage or as an absolute amount, and a variance passes if it is within either - so a small percentage on a cheap line doesn't trigger on twenty cents, and a tight absolute on an expensive line doesn't wave through a percentage that happens to look modest. Tolerances are configurable per company, with per-vendor overrides, because a supplier who delivers to the pallet and a supplier who delivers to the unit are not the same risk. The defaults applied when nothing is configured are 5% on quantity and 10% on price, with damaged quantities excluded from the comparison by default.
One honest caveat: those tolerances are configurable through the data layer and the API, but there is no settings screen for them in the product yet. Today, changing them from the defaults means an API call or our help. It is on the list. We would rather say so here than have you go looking for a page that isn't there.
The scale makes the defaults intuitive. One unit short on an order of fifty is 2% - inside the 5% quantity default, and an honest pallet-count difference. Two short on an order of twelve is 16.7% - outside it, and worth a human. That is the same rule producing two different answers because the proportions genuinely are different.
A variance that is within tolerance but not zero comes back as matched with warning, which is deliberately a different answer from matched. It means: this is inside the band you set, and it is not nothing. Over a quarter, a vendor whose lines are persistently warned rather than clean is telling you something, and it would be a shame to round that signal away.
What happens on a mismatch
Foxpedite flags, grades, rolls up and records. It does not refuse to pay.
The match computes flags - including whether a line can be approved without intervention and whether it requires an override - and a human decides what to do with them: short-pay, request a credit note, or accept the variance. Accepting is recorded as an override, with a reason, an author and a timestamp, in the audit log alongside everything else on that document.
That is deliberate, and worth defending, because "it should just block the payment" sounds stronger. A system that hard-blocks payment on any mismatch creates immediate pressure to make mismatches disappear - by editing a receipt to agree with an invoice, by approving a variance without recording why, by processing the invoice outside the system entirely because there is a supplier on the phone and a payment run in an hour. Mismatches that disappear stop being data. And the variance data is the asset here: it is what tells you, six months in, which supplier short-ships and which one quietly re-prices.
A flag that survives plus an override that is attributable beats a block that gets circumvented.
One related discipline, because it is the most common way receipt data gets quietly destroyed: a posted goods receipt is never edited. If you receive 10 and later find a box was miscounted, you post a reversal and a new receipt. The original entry stays. It has to, because the receipt is evidence of what someone observed at a moment in time, and evidence you can retroactively edit is not evidence. Deliveries work on compensating entries, the same way a ledger does.
GRNI, which falls out for free
Once receipts and invoices are matched line by line, a number appears that most companies at this size have never been able to produce: goods received, not invoiced.
It is a real liability. You have the goods. You owe the money. Your accounts payable does not show it, because nobody has billed you yet.
Foxpedite reports it per posted delivery line: received value, invoiced value, and the balance between them. (Reports →)
And the ageing is the diagnostic. A line sitting in GRNI for a few weeks is ordinary. A line sitting there for four months is almost always one of three things: an invoice the supplier forgot to send, an invoice that went to the wrong inbox and is sitting unopened in a shared mailbox, or a receipt posted against the wrong order. All three are worth an afternoon. None of them is findable without this report.
Where to start
You do not need a procurement department to run a three-way match. You need the receipt to exist as data, and a rule for what happens when the three documents disagree.
Three-way matching, goods receipt with reversal semantics, purchase orders, budgets and the GRNI report are all on the Regular plan at $30 per seat per month, minimum five users, with a 14-day trial and no credit card to start. (Pricing →)
Next week's article deals with the obvious follow-up question: if all three documents have to exist as data, who types them in? (The procurement work nobody should still be doing by hand →)
The invoices, deliveries and figures in this article are worked illustrations written for this piece, not customer data.