Paying less than agreed is a statement, not a typo

An order is agreed at one figure. The payment that goes out is smaller.

This happens all the time, for good reasons: short quantity, damaged material, a rate correction, a recovery, an agreed discount for late delivery. It is ordinary commercial life.

What is not ordinary is what most systems do with it, which is accept the smaller number and say nothing. The result is a record showing an agreed amount and a paid amount that do not match, with no explanation attached to either, and a permanent open balance that nobody can close because nobody can remember why it is there.

The two readings of an unexplained gap#

Six weeks later somebody looks at that order. The agreed figure is one number, the paid figure is smaller. There are exactly two possible readings and no way to distinguish them:

• We still owe the difference. Somebody must chase it, and the vendor is right to be waiting.
• We settled for less, deliberately. The difference is not owed, the order is complete, and chasing it will be embarrassing.

Both readings are consistent with the record. Whichever one the reader assumes becomes the truth, and different readers assume differently.

That is the actual cost of a silent short payment. Not the money — the money was correct. The cost is a record that cannot answer a question about itself. It is also the commonest reason a vendor's ledger and yours will not agree — when your ledger and theirs disagree.

Ask at the moment, because it is the only moment#

The information exists exactly once: when the person entering the payment knows why it is short. Ten minutes later it is in their head, next week it is gone, next month they have left.

So the intervention has to happen at entry. In our own system, recording a stage payment below the agreed figure now asks why less before it accepts. It is one field and it is required.

Three things then happen with the answer.

The gap and its reason land on the stage row itself — an amount deducted and a short phrase saying what for. Not in a comment, not in an attachment: on the row, where anybody reading the payment reads the reason at the same time.

The order total revises to what was actually paid. Said out loud in a comment on the task and written to the audit trail, under the name of the person who did it.

The originally agreed figure stays reconstructible. Paid plus deducted equals what was agreed. Nothing is destroyed — the revision is a derived view, not an overwrite, which matters for the reasons set out in append-only records.

Why the total should self-correct#

This was the part that took an argument.

The instinct is to leave the agreed total alone, on the grounds that it is what was agreed. The problem is that everything downstream then reports a permanent shortfall on an order that is in fact complete: the outstanding balance is overstated, the ageing report shows an old open item, and any queue built on "agreed minus paid" carries it for ever.

So the rule we settled on is that the moment a payment schedule's last stage is paid or written off, the order total corrects to what the stages actually recorded — with an audit entry always, and a comment naming the person. And a sweep does the same for every order settled before the rule existed, converging to zero writes once history has caught up.

There is one deliberate exception. A correction of this kind does not void management signatures on the order. The rule that protects signatures exists for money still to move; this is money that already moved, and it moved downward of what was signed for. Voiding an approval because less was spent would be a machine punishing the right outcome.

Short payment is not the same as a deduction, or a write-off#

Three things look similar on a bank statement and are completely different in the ledger.

A short payment is the whole payment for that stage, at a revised amount, by agreement. The balance is not owed.

A set-off is a full payment reduced by a separate obligation running the other way. The full amount is still owed on this contract, and a counter-claim exists on its own account. Netting the two into one number destroys both facts — that is the subject of set-off.

A write-off is a decision that money owed will never arrive. It is not a payment at all. It has its own piece: writing off money that is never coming.

If your system offers one field for all three, it will be used for all three, and the ledger will lose the distinction permanently.

The reason has to be defensible, not free text#

A reason field accepting anything will receive "adjustment", "as discussed" and a single full stop.

Two things help. A short list of the reasons that actually occur — short quantity, quality deduction, rate correction, agreed discount, recovery — so the common case is a tap rather than typing. And a free field beside it for the specifics, because the list will never cover everything and forcing a category onto an unusual case produces a wrong category rather than a blank one.

The categories are what make the pattern visible later: one vendor consistently short-delivering, one material consistently disputed. A pile of free text cannot be counted, and a pattern you cannot count is a pattern nobody will find.

The general shape#

Any time your system accepts a number different from the number it expected, it is watching a decision being made and choosing not to record it.

That is the moment to ask. Not with a warning that can be dismissed, and not with a block — the payment is legitimate and blocking it teaches people to route around the system. Ask for the one piece of information that only exists right now, put it on the record beside the number it explains, and let the arithmetic reconcile itself.

A difference with a reason is information. A difference absorbed in silence is a question your records will be asked and cannot answer.