Three-way matching, and why it breaks in small manufacturing

Three-way matching is the practice of not paying a supplier invoice until three documents agree: the purchase order that says what you agreed to buy, the goods receipt note that says what actually arrived, and the invoice that says what you are being asked to pay. Where all three agree, the invoice is safe to pay. Where they do not, something needs a person.

The control is genuinely old and genuinely effective. It catches rate revisions nobody approved, short deliveries invoiced in full, duplicate invoices, and quantities that drifted between the order and the lorry. In a factory buying steel, bearings, fasteners and consumables from thirty suppliers, those are not rare events.

It is also the control most small manufacturers stop doing properly, usually without deciding to. This guide is about why that happens and what to do instead of either heroic manual effort or quiet abandonment.

What the match actually catches

It helps to be specific about which errors this control exists to find, because that determines how much effort it deserves.

Note the fourth row. A supplier delivering against one order in four instalments produces four invoices that are each individually correct and collectively over the agreed value. No single-document check finds that. It is the reason matching has to run against the order's running balance rather than against the order line in isolation.

Why it breaks in a small factory

The textbook version of this control assumes a purchasing department, a stores function and a payables clerk who are three different people. A factory doing twenty crore a year often has one person covering all three, and the failures follow from that rather than from carelessness.

The purchase order does not exist

Urgent purchases get made on the phone. The PO is raised afterwards, if at all, and is written to match the invoice that has already arrived — which means the match will always pass and the control has become theatre. This is the most common failure and the least discussed.

The goods receipt is a signature on a delivery challan

If receipt is recorded on paper at the gate and entered into the system days later, the invoice frequently arrives first. The person matching then has two documents and an absence, and the pressure is to pay rather than to wait.

Units do not agree

The order is in kilograms, the challan is in pieces, the invoice is in kilograms at a converted rate. Every one of those is correct in its own context and none of them match automatically. This single issue defeats more matching implementations than any other.

GST makes the totals disagree by design

A purchase order is usually raised at basic value. The invoice carries GST, and often freight and rounding as well. Comparing an invoice total to a PO value will flag every correct invoice by roughly the tax rate, and a control that fires on everything is one that gets switched off within a fortnight. The comparison has to be like for like — taxable value against order value, with tax checked separately.

This is not a hypothetical. It is the most common modelling error we see in spreadsheets built for this purpose, and it is why the first question to ask of any matching report is what exactly it is comparing to what.

Tolerances are the real decision

A match that demands exact agreement produces an exception on nearly every invoice — rounding, freight, a two-paisa rate difference. A match with generous tolerances passes things it should have caught. The tolerance is where the control actually lives, and it deserves an explicit decision rather than a default.

Three separate tolerances are worth setting, because they behave differently:

• Unit price — usually tight, because a rate change is a decision somebody made. A percent or two absorbs rounding without absorbing a revision.
• Quantity — usually tighter still for discrete items, looser for anything weighed or measured, where a genuine delivery variance is normal.
• Order balance — the cumulative check, and the one worth being strict about, because breaching it means the order itself has been exceeded.

Set these by watching what your own exceptions look like for a month before committing. A tolerance chosen from a template is a guess about your suppliers.

What to automate, and in what order

The instinct is to start with reading the invoice, because that is the visibly tedious part. It is usually the wrong first step. Extraction is the part most likely to be imperfect, and automating it first means the whole thing is only as trustworthy as its weakest component.

1. 1Start with the rules, run on data you already have typed. If the matching logic is wrong, everything downstream inherits the error, and this is the cheapest place to find out.
2. 2Add the exception queue. The value is not in approving clean invoices — it is in making sure the unclean ones reach someone with the reason attached, rather than sitting in a mailbox.
3. 3Add approval routing by value, so a small variance does not need the same signature as a large one.
4. 4Add extraction last, behind a confidence threshold, with anything uncertain routed to a person.

Done in that order, each step is useful before the next one exists. Done in the reverse order, nothing is useful until all of it works.

What to leave alone

Automating the decision to pay a disputed invoice is a mistake. The matching engine's job is to say this one is clean, this one is not, and here is precisely why. Whether to pay a supplier anyway — because the relationship matters more than a four percent variance this month — is a commercial judgement, and it belongs with a person who carries the consequence.

The same applies to vendor master changes. A system that can silently create a new supplier from an incoming invoice has created a payment channel, and that is the exact mechanism invoice fraud uses.