Three-way matching without an ERP

8 September 2026 · このページは英語で提供されています。

Anna Lindqvist

Three-way matching sets the order, the delivery note and the invoice side by side and asks the three to agree. A small team without an ERP can still run it, one supplier at a time, keyed on the item code, gated on the printed total, and with the price list read as a fourth document.

Price Double Check runs that comparison on documents forwarded by email, which is a fair description of what this article asks you to do by hand. The method below comes out of one real chain of thirty documents, and the point of it is not thoroughness. It is knowing which of the three pairs to compare first, and which differences to leave alone.

The fourth document is the one that makes the match worth running

Textbook three-way matching compares the purchase order, the goods received note and the supplier invoice. Quantity against quantity, price against price, and a variance report at the end. In a company with an ERP the module does it overnight and nobody thinks about it again.

In a company without one, that description is misleading, because it leaves out where the expected price came from. The order carries a price only because somebody typed one in, and what they typed came off a price list. In the chain behind this article the connection is unusually clean: the supplier's order sheet is the price list itself with quantities filled into a column. The buyer's price expectation is therefore recorded line by line, in a machine-readable file, at the moment of ordering. That is better than most business-to-business chains manage, and it turns the question of what changed between the order and the bill from a recollection into a join.

So treat the price list as a fourth document and give it the same standing as the other three. Without it a variance tells you that the invoice disagrees with the order. With it you also know which of the two is wrong.

Nothing is compared until the invoice agrees with itself

Before a single line is matched, add up the lines you have read off the invoice and check the sum against the total printed on it. To the cent. If it does not agree, you have misread the document, and every comparison built on top of that misreading will be confident and wrong.

This sounds like ceremony and is not. It is the only check that catches a figure read across a column boundary — a quantity and a price that run together into one number that looks entirely plausible. In the acceptance run all eleven invoices in scope agreed with their own printed totals to the cent, and across the wider folder all seventeen did. Nothing was misread, and the gate is why anyone can say so.

It has a second use, which is what you tell the person who asks whether you checked everything. The sum of the lines equals your total is a sentence with no wriggle room in it.

The item code is the key, and the description is not

Descriptions do not survive the trip between two systems. Out of 442 invoice lines in the validation folder, 335 carried a description that did not match its own price-list row: the same electrolyte tablet spelled with and without a hyphen, a chocolate bar that is dark in one file and black in the other. Matching on prose fails on the majority of lines, and it fails silently.

The code works, with three caveats worth knowing before you rely on it.

• Codes arrive with undocumented suffixes — the same item as 5116 and 5116_1. Normalise them, and confirm the normalisation by checking that the price agrees.
• One code can appear twice in a list at two pack sizes. Taking the first match is safe only while the two prices are identical. When they are not, that is a conflict to report, not a coin to toss.
• Some lines print no code at all. Those can often be recovered from documents further up the chain, where the supplier's own invoice carries both the code and the identical description string. In the acceptance run 101 lines were recovered that way, leaving none without a code — which works only because the buyer had kept everything.

If your supplier has moved to structured invoices, some of this gets easier and none of it goes away. The European semantic model gives an invoice a purchase order reference and lets each line point at an order line, but the specification is explicit that line-level referencing is optional even when the order reference is present, and that order lines and invoice lines are not always one to one. A structured invoice still has to be matched. It just arrives already typed.

Which pair to compare first

Do not run all three comparisons at once. They answer different questions and they cost different amounts of time.

Start with the invoice against the price list. It needs two documents rather than three, it can be done the day the invoice arrives, and in the acceptance run it produced 41 real price differences across 382 lines with 327 matching exactly. Then run the order against the invoice, which is where substitutions surface: one item was swapped for a larger one at a higher price with no notice, and the only evidence was that the code on the invoice was not the code on the order.

Five differences a match must show and must not judge

A routine that reports everything gets switched off in a month. These five look like findings and are not, and a two-person team should agree in advance to pass them to a human rather than to a variance report.

1. Freight. There is no reference price for it anywhere. Seven lines and 901.65 euros in the validation folder. Show the amount and its share of the goods, name the delivery term from the contract, and stop there.
2. Unit-of-measure collisions. One supplier's order template computes units as units per box multiplied by boxes, so a 1 in the box column means 240 units and not 40. Five apparent short deliveries in the set were almost certainly this form and not a missing pallet.
3. Pack size against description. A list says 550cc where the invoice says 600ml at the same price. Nothing in either document settles which is right.
4. Items with no row in any price list. Six of them here — display stands, catalogues, branded clothing. That is an absence of basis for a verdict, not an overcharge.
5. Rounding. The list holds four decimals and the invoice two. One cent per unit is a tolerance. Round half-up: with truncation instead, one ordinary line in this set would have been flagged on every single invoice.

What the week actually looks like

One supplier, one sitting, and a folder that keeps every document you were ever sent. The first pass on a new supplier takes an afternoon because you are building the crosswalk. After that it is the length of a coffee.

1. Pull the invoices that arrived since last week and the price list in force for each supplier, choosing the list by the delivery date rather than the invoice date.
2. Sum each invoice and check it against its printed total. Anything that does not agree goes back to be read again, not forward to be compared.
3. Match line by line on the code. Set aside the five categories above.
4. Look at what is left: the price differences, in euros, with the list price beside the billed price.
5. Once a month, put the newest price list against the previous one, because pack sizes and quiet drift are only visible there and never on an invoice.

Forward one invoice and the price list it should have been billed on, with the order if you have it, and the reply comes back as a line-by-line comparison rather than a variance report to interpret. The plans, and what a month of checking costs, are listed on the front page.