Reconciling a vendor bill against what actually arrived

An invoice arrives. Somebody has to decide whether to pay it.

That decision looks like a single act and is really five comparisons, done in order, each of which can send the invoice back. Most organisations do two of them properly, skip one, and do the remaining two by feel.

The five comparisons#

1. Is this invoice ours at all? Correct legal entity, correct site, correct project. Multi-entity groups get this wrong constantly, and an invoice paid by the wrong entity is a tax problem as well as an accounting one.

2. Is it a duplicate? Same vendor, same invoice number, same amount. Also: same amount and same date with a different number, which is the version that gets through. Duplicate payment is one of the largest recoverable losses in any purchase ledger and it is caught by a check that takes a second.

3. Does it match the order? Rate, unit, terms, tax treatment. Compare the invoice against the purchase order, because the rate was agreed in advance and the delivery has no opinion about it.

4. Does it match the receipt? Quantity, against what your side recorded as arriving — not against what the order said, and not against the vendor's challan. This is the comparison that requires an independently written goods receipt note, and it is the one most often skipped.

5. Does the arithmetic work? Quantity times rate, plus tax, equals total. Invoices are typed by people.

Steps three and four together are three-way matching. Steps one, two and five are the ones nobody writes a procedure for and everybody assumes somebody else did.

Why the receipt comparison fails#

Not because people are lazy. Because of four ordinary situations that a simple one-to-one comparison cannot represent.

One order, several deliveries. Five lorries, five receipts, one monthly invoice. The comparison is many-to-one and a naive check either refuses it or compares against the first receipt and reports a shortfall that is not real.

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

Deliveries that straddle the period. Material received on the last day of the month, invoiced in the next. Nothing is wrong; the two documents simply live in different periods and any comparison restricted to a period misses them both.

Receipts recorded from the challan. If the receipt was written by copying the vendor's own document — which is fast, and common — then the comparison is between the vendor's number and the vendor's number. It always passes. It proves nothing.

The fourth is the serious one, because it is invisible. The other three cause visible friction and get fixed. This one produces a clean report.

The mismatch that is not a mismatch#

A large proportion of investigated mismatches turn out to be unit differences rather than quantity differences. Ordered per tonne, invoiced per quintal; received in bags, invoiced in kilograms.

The comparison must include the unit or it will confidently report a quantity discrepancy and send everybody looking in the wrong place. It has its own piece: the unit of measure.

Tax lines are part of the reconciliation#

The tax on an invoice is not decoration and should be checked against the order rather than accepted.

Two things to look at. Whether the tax treatment matches what was agreed — the place of supply, the rate category, whether the vendor is charging tax at all. And whether the invoice contains the details your own credit claim depends on: the vendor's registration, a valid invoice number, the correct particulars.

The reason this belongs in the reconciliation rather than later is that an invoice with defective particulars is easy to have corrected while the money is still unpaid and nearly impossible afterwards. The mechanism, and why the vendor's own filing behaviour becomes your problem, is in input tax credit.

What to do with a genuine mismatch#

Not hold the whole invoice indefinitely. That is the default behaviour and it is bad for everybody: the vendor is unpaid on the correct lines as well as the disputed one, the relationship deteriorates, and the disputed line gets settled under commercial pressure rather than on the facts.

Better: pay what is agreed, hold what is not, and say in one sentence what is held and why. A vendor who knows exactly which line is in question and why can resolve it. A vendor whose invoice is simply unpaid can only chase, which is the same five comparisons seen from the other end — getting paid on time, from the contractor's side.

And record the held amount as its own entry with its own reason, rather than paying a net figure and letting the difference vanish. That distinction — between netting the payment and netting the record — is covered in set-off.

Automate the comparison, not the decision#

The checking is arithmetic and belongs to a machine. There is no reason for a person to compare five hundred invoice lines against five hundred receipt lines.

The decision is different. Whether to pay an invoice with a small discrepancy, whether to accept an explanation, whether this vendor's pattern is worth a conversation — these need somebody who knows the relationship.

We hold to that separation firmly in our own systems: the machine proposes, a person decides. When our software matches a delivery document to a purchase, the match is recorded as a suggestion and only a person's tap makes it a link. When it suggests a bank transaction belongs to a particular order, that is an ask, not an attachment. The reasoning is in the machine proposes, a person decides.

It is not caution for its own sake. A machine that attaches money to the wrong order does not merely make an error — it makes an error that looks like a record, and the next person to read it has no way of knowing a human never agreed.

The short version#

An invoice is a claim. Five comparisons decide whether to honour it, and the one that matters most needs a receipt your own side wrote.

Check the entity, check for duplicates, match the rate to the order and the quantity to the receipt, and redo the arithmetic.

Then pay what is agreed, hold what is not, and say which is which.