Your invoice matching never checked whether the goods arrived
A purchase order says what you asked for. An invoice says what a supplier wants paid. Neither one is evidence that anything was delivered, and most automated matching stops right there.
This article was generated by AI. Labelled in accordance with Article 50 of the EU AI Act. Responsible for publication: Sophera Consulting.
Two documents are easy to compare, which is why most people stop at two
A purchase order sits in your ERP with line items, quantities and prices. An invoice arrives as a PDF with line items, quantities and prices. The automation almost designs itself: read the invoice, find the order, compare the numbers, release for payment when they agree. Most accounts payable queues will clear seventy or eighty percent that way.
That number becomes the thing everyone reports.
What nobody reports is that neither document has anything to do with goods. A purchase order records what you asked for. An invoice records what a supplier wants to be paid for. Both can be produced by people who have never seen the pallet.
Backorders get paid
This usually surfaces during a stock count.
A supplier bills for items they are carrying as backordered, month after month, and never ships them. The invoice matches the order line for line, because it was generated from the order. So the workflow releases it. Nothing in the data looks wrong, because the only record that would contradict it was never consulted.
The goods receipt is the one document in the process that comes from somebody actually looking at a box.
The receipt is the awkward one
Accounting has called the complete version a three way match for decades: order, receipt, invoice. Everyone knows the term. The middle step still gets skipped, and not because it is technically hard.
It gets skipped because it is messy. The receipt is created in the warehouse rather than at a desk, often in a different system from the order. It gets posted late, sometimes on a Friday for the whole week. The delivery note is a piece of paper riding on the pallet. One order produces three receipts because the supplier shipped three times.
Matching order to invoice means joining two clean records. Bringing in the receipt means dealing with the warehouse. Automation projects follow the path of least friction, and the friction is here.
One invoice, three deliveries, two orders
Then there is the joining problem.
Consolidated invoices cover deliveries from several orders. Partial shipments split one order across several invoices. Freight shows up as a line with no order reference at all. A credit note refers to an invoice that itself only billed part of a line.
Document level matching falls apart on all of it. The comparison has to run per line and keep running totals per line: how much was ordered, how much has been received, how much has already been billed. Without those totals the same carton can be paid for twice while every individual document looks internally consistent.
Tolerance is a commercial decision
Once receipts are in the comparison, differences appear that nobody was looking at before.
Anything sold by weight or by length arrives slightly off. Converting between pack size and base unit produces rounding differences of a few cents. Prices move between order and delivery, sometimes legitimately.
Set the tolerance to zero and you get an exception list nobody opens after a fortnight. Set it wide and you give away a little money on every invoice. That trade off belongs to whoever owns the margin, and it belongs somewhere readable. Buried as a number inside a filter step, it becomes unexplainable within a year.
A usable tolerance has two dimensions, absolute and percentage, and differs by product group. Ten euros on a pallet of gloves is not ten euros on a reagent.
In healthcare the receipt is not only commercial
Hospitals and their suppliers carry an extra layer here.
Batch numbers and expiry dates are captured at goods receipt. Not for finance, but because without them there is no traceability. If the receipt degrades into a tick box someone clicks so the invoice can clear, the recall trail is exactly as reliable as that tick box.
An automation that treats the receipt as an obstacle does more damage there than a mispaid invoice ever would.
What we build instead
No release without a receipt reference. An invoice line with nothing received against it is not approved, it is open.
Three outcomes rather than two: approved, blocked with a reason, unresolved. The third one carries the value, because backorders live there.
Line level matching with cumulative quantities across every document in the chain.
A tolerance agreed with purchasing, written down where someone can find it.
A separate route for invoices with no order at all, instead of forcing them through logic built for something else.
The step that quietly disappeared
Before any of this was automated, someone in accounts payable pulled the delivery note out of a folder and laid it next to the invoice. Nobody would have written that down as a control. It was not in any process document.
The automation did not replace it. It removed it, the throughput number went up, and that looked like progress.