Here’s a shape that turns up in a lot of business software. An invoice row has a column called
paid. When the money arrives, something sets it to true. Reports read the column.
It works right up until the money doesn’t arrive in the shape the column assumes.
The day it stops working
A customer owes you for four invoices and pays one round figure covering three of them and a bit of the fourth. Another pays in two instalments, three weeks apart. A third overpays by the amount of a credit note they’d forgotten they were holding. A fourth pays exactly the right total, on the wrong reference.
None of these are exotic. They’re an ordinary Tuesday. And each one ends with somebody deciding which boxes to tick, which is the moment your receivables report stops being a record of what happened and becomes a record of what somebody thought had happened.
The symptom is always the same. The aged receivables report and the bank don’t agree, nobody can say when they stopped agreeing, and the difference is sitting inside a decision made in a hurry by someone who has since left.
Deriving it instead
There’s no paid flag to set. There’s a payment, and there are allocations: the amounts of that payment applied to specific documents. An invoice’s paid figure is the sum of the allocations against it, and nothing else.
Three things follow, and they’re the actual point.
- A part payment is a normal state, not a rounding problem. €400 allocated against a €1,000 invoice leaves €600 outstanding, and both numbers are real, rather than one being a flag and the other a memory.
- One payment can settle many documents. That round figure covering three invoices and part of a fourth is four allocations from one payment, which is what actually happened.
- Money you haven’t applied stays visible. A payment’s unapplied balance is what arrived minus what you allocated. It can’t quietly become zero, because nothing stores it. It’s arithmetic on two things you can both point at.
That last one matters more than it sounds. In the flag model an overpayment has nowhere to live, so it gets absorbed: somebody marks the invoice paid and the extra becomes a difference. Here it’s a number sitting on a payment, still asking to be dealt with, which is exactly the pressure you want.
What it costs
Deriving is more work than reading a column, and you have to be disciplined about never reintroducing the shortcut. A cached paid flag “for performance” is how systems like this go wrong, because the cache and the truth diverge on the one weekend nobody is looking.
It also means the allocation screen has to be good. If applying a payment across four documents is tedious, people will apply it to one and call it close enough, and you’re back where you started with extra steps. Matching against outstanding invoices when you import your bank statement does most of this automatically, and the manual path is there for when the automatic one guesses wrong.
Why this is a marketing-blog post
Because it’s invisible in a demo. Every invoicing product can show you an invoice going green. The difference between a system that stores that and one that derives it doesn’t surface until the first messy payment, and by then you’ve migrated.
So this is worth asking any vendor, us included. What happens to an overpayment? Where does an unapplied balance show up? Can one payment settle four invoices, and can you see which parts went where?
The detail on payments and reconciliation is in the guide: accounting and bookkeeping.