Three-way matching, and the case it always misses

Three-way matching is the practice of not paying an invoice until three independent documents agree about the same event.

• The purchase order. What we agreed to buy, at what rate, in what unit.
• The goods receipt note. What our side says arrived.
• The invoice. What the vendor says we owe.

Each is written by a different person at a different moment with a different interest. That is the entire value of the method. If any two of them were written by the same side, the check that compares them proves nothing.

What you are actually comparing#

Not just the total. The total is the least informative number on an invoice, because two errors of opposite sign hide inside it perfectly.

Match line by line, and match four things per line:

1. The material. The same item, not a similar one.
2. The quantity. Invoice against receipt, not invoice against order — the order is what you wanted, the receipt is what came.
3. The rate. Invoice against order, because the rate was agreed in advance and the delivery has no opinion about it.
4. The unit. The most quietly expensive of the four. A rate agreed per tonne and invoiced per quintal is a factor of ten, and it looks like a perfectly ordinary line.

Then the arithmetic: quantity times rate, plus tax, equals the line total. Invoices are typed by people and the arithmetic is wrong more often than anyone expects.

The three ordinary outcomes#

All three agree. Pay it.

Receipt is less than invoice. The vendor is charging for material that did not arrive, or arrived short. This is what the method exists to catch. It is also where you find out whether your goods receipt notes were really written by your side or copied off the vendor's challan, because if they were copied this case can never occur.

Receipt is more than invoice. More arrived than is being charged for. Do not simply pay the lower figure and enjoy it. Either a second invoice is coming for the balance, or somebody has delivered to the wrong site, and both are better discovered now than at year end.

The tolerance question#

Nobody blocks a payment over a rupee. So a tolerance is set: a small percentage or absolute value inside which the three are treated as agreeing.

Two things about tolerances are worth stating plainly.

The tolerance must be defined once, centrally, and visible. A tolerance that each approver applies by judgement is not a tolerance, it is permission to approve anything.

And it must apply to the difference, not to the total. A tolerance expressed as a percentage of a large invoice is a large number of rupees, which means the checks get weakest exactly where the money is biggest. That is the wrong way round.

Where the method actually fails#

Not on the comparison. The arithmetic is easy. It fails on the cases nobody listed when the process was designed.

Partial deliveries. One order, five lorries, five receipts, one invoice. Now the match is many-to-one and every naive implementation either refuses it or matches against the first receipt and reports a shortfall that is not real.

One delivery, several orders. A vendor consolidates. The reverse problem.

Free material, samples, replacements. A load arrives with a receipt and will never have an invoice. If your process requires an invoice for every receipt, these sit open for ever and eventually somebody is told to ignore that queue, which kills the queue for everything.

Rate revisions mid-order. The order says one rate, a later agreement says another, and the agreement lives in a WhatsApp message. The match will fail correctly and for a reason nobody can find.

Payment before delivery. This one breaks more systems than the rest combined, and we broke ours with it.

The one we got wrong#

In our own process, money often has to move before a lorry will be dispatched. That is a commercial reality, not a policy choice.

Our software matched an incoming delivery challan against open purchases — and the matcher considered only purchases that had not been paid. So by the time material actually arrived, the correct purchase was always in the paid state, and was therefore never a candidate. The challan matched nothing, and a challan matched to nothing appears on no screen at all.

The three-way match was structurally impossible for the exact class of order it mattered most for. Nothing failed loudly. The photographs kept arriving and the result kept being invisible.

A related fault sat on the money side of the same process. A payment made in stages — an advance, then a balance — never wrote the field that meant this is paid, because when a payment has a schedule the stages are the payment record. Every query that asked "is the paid date set?" was blind to every rupee that had moved in instalments. That story is a fact that had no owner, and its lesson is the same as this one: the rule was right and the enumeration of cases was incomplete.

Asking rather than blocking#

There is a temptation, once you have a match, to make it a gate: no match, no payment.

We came to a different arrangement, and it has held up. On every payment awaiting signature the system says either delivery challans filed or, in amber, no delivery challan yet — money before material?

It is a question, not a block. Some payments rightly precede material, and the person signing is entitled to know they are making that choice rather than having it made for them. A hard block on a legitimate case teaches people to find the override, and once the override is habitual you have neither a block nor a question. It has a cost at the other end of the transaction too, where the same three documents decide whether a contractor is paid on time.

That distinction — between a system that refuses and a system that proposes and lets a person decide — turns out to matter far more than the strictness of the rule itself.

What to check on your own process#

Take one order that was delivered in parts and paid in stages. Follow it end to end and ask, at each step, which document the system compared against which.

If you cannot find three independently authored numbers, you do not have three-way matching. You have a form.