Getting Paid Is a Design Problem

I have spent months treating late payment as a relationship problem. Chase harder, word the reminder better, book another call with the person who can unstick it. Some of that is necessary. Almost none of it is the highest-leverage thing available, and I only worked that out by watching four small mechanical decisions land in the same fortnight.

Collection is downstream. The design is upstream. Most of what makes an invoice slow to pay was decided before the invoice was sent.

Invoice on their calendar, not yours

I had been invoicing an enterprise client at month-end, which is the obvious date and, it turns out, close to the worst one. The last week of their month is when the finance function is running salaries, statutory filings, tax deposits and the vendor payment queue simultaneously. My invoice arrives into the single most congested window they have and joins the back of a line it was never going to win.

Moving to the 20th fixes it, and the reasoning is entirely about their internal calendar rather than mine. It lands before the payroll crush. It leaves roughly ten working days for approval and processing before their books close. And it still captures nearly all of the month's work, so I give up very little on my side.

The general rule: an invoice date is a scheduling decision about someone else's operating rhythm, not an administrative default. For any client large enough to have a payroll function, ask when their crush week is and land outside it. This is a one-time decision that pays every month, which is a much better shape than a chase that costs effort every month and works sometimes.

Make the invoice number do the reconciliation

A payment landed and matched itself to the right invoice with no work from me, because the invoice reference had travelled intact through the client's payment system into my bank alert. I saw the number, knew instantly which piece of work had been paid, and closed the item.

That sounds trivial. It is the difference between a receivables ledger that is current and one that is a guess. The unglamorous version of good financial hygiene is using one continuous, structured reference series and putting it everywhere — the invoice, the email subject, the payment instruction. When the reference survives the round trip, reconciliation stops being a task.

One thing worth knowing if you run multiple client relationships out of one entity: the numbering series is usually organisation-wide rather than per-client, so the sequence tells you the order you billed the world, not the order you billed any one client. Useful to know before you try to read a story into a gap in the numbers.

A short payment is information, not an error

A deposit arrived materially below the invoiced amount. The temptation is to pick the explanation that requires no work — withholding tax, probably, close enough, mark it paid.

That instinct is how a ledger silently drifts out of true. In this case the shortfall had at least two candidate causes: statutory withholding at source, and a part-payment made earlier under a separate conversation that neither side had explicitly netted off. Those are completely different facts. One means I have been paid in full and will reclaim the difference against my own tax liability. The other means I have an open balance and a client who believes the account is settled.

A payment that does not match the invoice is an unresolved question, and it stays open until the arithmetic is written down. Not assumed. Written down, in the books, with the reason attached. The cost of doing this at the moment the payment lands is about ten minutes. The cost of doing it nine months later, in front of an accountant, is considerably more than ten minutes.

The upstream fix is simpler still: state the tax treatment on the quote, before the work starts. For business-to-business work the convention is to quote exclusive of tax and add it on the invoice — if you quote a number that silently includes it, you have quietly discounted yourself and created an argument for later.

You cannot bill what you did not record

The most expensive item in this whole set is the one that looks least like finance.

A month's invoice for onsite consulting days stalled because I could evidence three days and believed I had worked more. There was no contemporaneous record — just my memory against a reconstruction assembled after the fact from messages and calendar entries. My memory is not evidence, and I knew it, so I could not push the number with any conviction. I have now carried that dispute across several weeks and it has blocked a whole billing cycle.

Consulting revenue depends on a record created at the moment of the work, and no amount of care afterwards substitutes for it. The fix is embarrassingly small: one line, sent to yourself, when you arrive at and leave a client's premises. Timestamped, unfalsifiable, thirty seconds. I have written that same fix into my journal four times across three weeks without implementing it, which is its own kind of lesson.

The adjacent version, from the same cycle: I billed a reimbursement line that the contract didn't clearly support — the agreement said the client provides accommodation past a threshold, not that it reimburses accommodation I book myself. I sent it anyway, knowingly. That may be the right commercial call, but the actual lesson sits before the booking: get the authorising email before you incur a cost you intend to pass on. A line item you have to argue for is a line item that delays the whole invoice, not just itself.

The through-line

Every one of these is the same shape. Timing, referencing, reconciliation and evidence are all decided before the money is due, and all of them are cheap to get right at that point and expensive to fix afterwards.

So the thing I would tell myself three months ago: stop optimising the chase. A chase is what you do when the design failed. It is unpleasant, it costs relationship capital, it works inconsistently, and it has to be repeated. The four decisions above cost a combined afternoon and remove most of the reasons a chase becomes necessary.

The honest counterweight

None of this touches the real problem, which is concentration. When one client is most of your revenue, their payment timing is your solvency, and no amount of invoice hygiene changes that arithmetic. A well-designed invoice from a supplier who cannot afford to be firm is still a well-designed invoice that gets paid late.

The mechanics reduce the friction and remove your own errors from the equation. They do not give you leverage. Leverage is a second client.