The invoice total is not what arrives

Most invoicing software rests on an assumption that holds in some markets and not others: that an invoice is a promise to receive its own total. Bill a hundred, collect a hundred, mark it paid.

Where tax is withheld at source, that is not what happens. The payer deducts a portion before paying, remits it to the revenue authority on the supplier's behalf, and transfers the remainder. The supplier billed one number and received a smaller one, and neither of them got it wrong.

Every downstream problem in this domain comes from software that cannot represent that sentence.

Three numbers per invoice

An invoice in this model carries at least three amounts, and only the first is under the issuing firm's control:

• Billed — what was invoiced.
• Withheld — what the payer deducted, decided by the payer's interpretation of the rules.
• Received — what actually landed.

Systems that store an invoice total and a paid flag force a choice between two wrong answers. Mark it paid in full and the bank reconciliation is short. Mark it partially paid and it sits in receivables forever, chased by someone who eventually learns to ignore the report — which is how a genuinely unpaid invoice gets missed.

The fix is not complicated, but it has to be there from the start: the deduction is its own recorded amount with its own lifecycle, not a discrepancy to be explained.

The rate is not a property of your business

What gets deducted depends on the nature of the service, on the status of the counterparty, and on the period. It is prescribed rather than negotiated, it differs by category, and it changes.

Two consequences follow.

First, the rate cannot be a setting. It belongs to a combination of client and service category, resolved at the time of invoicing, and stored against the invoice so that what was expected then can be compared with what happened later. A rate looked up at read time answers today's question about last year's invoice.

Second, the rules are periodic. A system in use for several years will hold invoices governed by different versions of the same rule, and will be asked about an old one after a new one has shipped. Encoding the current version as the only version is the failure that appears exactly once, and expensively.

Thresholds make it retroactive

The complication that catches most implementations: deduction frequently applies only once cumulative payments to a supplier pass a threshold within a period.

So the first four invoices to a client attract nothing, and the fifth crosses the line — at which point the deduction may be calculated on the aggregate rather than on that invoice alone. An invoice issued in good faith with no deduction expected is now part of a calculation triggered months later by an unrelated one.

This is why the deduction cannot be derived purely per invoice. It is a running position per client per period, and invoices are events against it. Modelled that way, thresholds are ordinary. Modelled per invoice, every threshold crossing is a manual correction someone has to notice.

Certificates are the reconciliation problem

Deducted tax is not lost. It is credit against the supplier's own liability — but only provable with the certificate the payer issues, and those arrive later, in batches, on the payer's schedule rather than the supplier's.

So there is a second ledger running alongside the first: for each deduction, has the certificate arrived, does it match the amount deducted, and does the period agree. The mismatches are all ordinary and all need chasing:

• A certificate that never arrives, making the deduction unrecoverable in practice.
• A certificate for less than was deducted.
• A certificate issued against the wrong period, so the credit cannot be claimed where expected.

None of this is exotic. It simply requires that somebody, or something, is watching — and that is exactly the work that does not happen in a firm of six people who are busy delivering.

What automation is actually for

The value is not in calculating a percentage. It is in noticing.

The useful rules are dull: this client, this service category, this rate. What makes them worth encoding is what they enable — comparing expected deduction against what the remittance actually shows, and raising the difference while it is still a conversation rather than a year-end reconstruction.

The alerts that earn their place are similarly unglamorous: a payment received that does not match billed minus expected deduction, a certificate overdue past the period it should have covered, a client approaching a threshold, a recurring invoice whose rule has not been updated after a rate change.

Recurring invoices deserve particular attention, because they are the case where a stale rule propagates silently. One wrong rate on a monthly retainer is twelve wrong invoices before anyone reconciles.

Who carries the error

Under-deduction is the payer's exposure. Over-deduction is the supplier's money sitting with the revenue authority until a return is filed, and if the certificate never arrives it may not come back at all.

That asymmetry is the argument for building this properly. The firm doing the work has the least control over the deduction and the most to lose from it going unrecorded. A system that tracks only what was invoiced is measuring the one number that was never in doubt.

The general shape

This is a specific instance of a pattern worth recognising elsewhere: a business process where a third party's decision alters what your records should say, after you have already written them.

The design answer is consistent. Record the expectation, record what actually happened, keep them as separate facts rather than reconciling one into the other, and put something in place that notices when they diverge. What you must not do is store a single number and let it mean whichever of the two is convenient — because by the time anyone checks, nobody remembers which it was.