The moment an invoice goes out, something odd happens to how it is treated. It gets filed, marked as done, and mentally counted as revenue. The work is finished, after all, and the number is agreed.
But an invoice is not money. It is a claim on money, and the distance between the two is where small businesses lose both cash and time. Ask any freelancer what their annual revenue was and they can tell you within a few hundred. Ask what they were paid, in cash, in the bank, after everything — and the answer takes a week to assemble, if it can be assembled at all.
The gap has four causes, and none of them is a client refusing to pay.
Why "paid" is not a checkbox
Consider an invoice for $4,000. The following are all things that routinely happen to it:
- The client pays $2,000 now and $2,000 in six weeks.
- The client pays $3,960, because their bank took $40 in correspondent charges.
- The client pays in euros, and after conversion $3,987 arrives.
- The client pays $4,000, but you had agreed a 2% early-settlement discount, so $80 of it is arriving as a credit against the next one.
- The client pays $3,600 and, after two months of chasing, you agree to call it settled.
In every case a paid/unpaid flag forces a lie. Tick it and your records claim you received $4,000, which contradicts your bank. Leave it unticked and an invoice that is functionally closed sits in your outstanding list forever, polluting every report that depends on it.
The correct model is that an invoice's status is computed, never typed. It has a total, and it accumulates two kinds of things against it: cash that arrived, and non-cash amounts that close the gap. When those add up to the total, it is settled. Until then it is partially settled, by a specific amount, and the outstanding figure is a fact rather than an opinion.
One payment, several invoices
The second thing a checkbox cannot handle is the client who pays three invoices with one transfer. It is extremely common, and it breaks naive systems in both directions: either the payment gets attached to one invoice and the other two stay open, or someone edits the amounts to make things line up and the records stop matching the bank.
What is needed is an allocation: a link between a payment and an invoice, carrying its own amount. One payment can allocate across many invoices; one invoice can receive many allocations. The payment keeps its true bank amount; the invoices each receive their share; nothing is edited to make it fit.
This is standard practice in accounting — it is called cash application — and it is the single most useful idea to steal from proper bookkeeping if you are running a small operation without it. It is also what makes the awkward cases tractable: an overpayment leaves an unallocated remainder that you can carry to the next invoice, rather than an amount you have to reconcile by hand.
Allocate against the oldest first
When a client pays a lump sum without saying what it covers, apply it to the oldest outstanding invoice first, and say so in your terms. It is the standard convention, it keeps your ageing honest, and it removes an argument later. The alternative — applying it to whatever is most convenient — quietly makes your oldest debt look younger than it is, which is the one thing your ageing report exists to prevent.
The gap that is not a payment
The residue after all cash has arrived needs somewhere to go, and it is not a payment. Give each of these a name, because the annual totals are worth knowing:
Bank and correspondent charges. Deducted in transit, especially on international transfers. Small individually. Across a year of cross-border invoicing they are frequently a four-figure number that nobody has ever added up.
Exchange differences. You invoiced in one currency, were paid in another, and the rate moved between issue and settlement. This is not a fee and not a loss of business — it is FX, and grouping it with charges hides both.
Discounts. Early settlement, a goodwill reduction, a rounding-down at the client's request. Deliberate, and worth tracking separately so you can see what your discounting actually costs.
Write-offs. The amount you decided to stop pursuing. Nobody enjoys recording these, which is exactly why they should be a named category — an untracked write-off is indistinguishable from an invoice you forgot about, and the two require completely different responses.
Four categories, all closing the same gap, each answering a different question at year end. In Capital Wizard these are invoice adjustments, sitting alongside allocations, and both feed the same computed status.
Revenue is what you agreed. Cash is what arrived. The difference is not an error — it is a number, and it deserves a category.
What a settled invoice actually looks like
Ageing is the only report that changes behaviour
Every invoicing system produces an ageing report: outstanding amounts bucketed by how overdue they are — current, 1–30 days, 31–60, 61–90, over 90. It is the plainest report in accounting and the only one that reliably changes what people do.
The reason is that overdue debt does not decay gracefully. Recovery rates fall sharply with age, and by the time something is a year old it is usually a conversation about how much you are prepared to write off. Ageing makes that visible while it is still cheap to act on.
A practical routine that costs about ten minutes a month:
- Look at the buckets, not the total. A rising total with everything current is growth. A flat total with mass moving right is a problem.
- Anything over 30 days gets a friendly, specific chase. Attach the invoice again. Most late payment is administrative, not adversarial — an invoice that landed in the wrong inbox or missed a payment run.
- Anything over 60 days gets a person, not an email. A phone call to the individual who signs off payments, not a reply on the original thread.
- Anything over 120 days gets a decision. Escalate, settle for part, or write it off and stop spending attention on it. Leaving it open is the one option that costs you every month and never resolves.
What each approach can represent
| Paid/unpaid flag | Spreadsheet with a paid column | Invoices with allocations | |
|---|---|---|---|
| Partial payment | No | With manual maths | Yes |
| One payment, many invoices | No | Painfully | Yes |
| Bank charges taken in transit | Becomes a mismatch | Manual note | A named adjustment |
| Exchange differences | Invisible | Mixed in with fees | Separate, totalled |
| Ageing report | Not possible | Manual, so rarely done | Automatic |
| Matches the bank exactly | No | Rarely | Yes |
The point of all this is not bookkeeping neatness. It is that "we invoiced $180,000 last year" and "$171,400 arrived" are different sentences, and only one of them describes what you can actually spend. Most small businesses can say the first with confidence. The second is the one that pays the rent.
See your own number instead of reading about someone else’s.
Import a statement, add your accounts, and get a real net-worth figure in an evening. Six months free, no card required.
Start free