Methodology
Late is not lost: reading your receivables honestly
Unpaid invoices sort into two very different piles. Confusing them produces a number that is either alarming or useless.
- Value of invoices past 45 days, unpaid
- Share of aged value that never lands
Two piles that look identical
An invoice that is late gets paid. An invoice that is bad does not. On the day you look at your ledger, both appear as an unpaid line with a date on it.
Treating every unpaid invoice as lost revenue produces a frightening number that no finance person will believe. Treating none of them as lost produces no number at all. The work is in separating the two using evidence rather than instinct.
Old enough to have an answer
The loss rate is measured only on invoices old enough that the question is settled — issued more than 120 days ago. Whatever share of those never got paid is what genuinely goes bad in your business.
Including still-in-flight invoices in that rate would count ordinary lateness as loss, which is exactly the inflation this measurement exists to avoid. At least twenty settled invoices are needed before the rate is computed at all.
That rate is then applied to what is currently overdue: unpaid past 45 days. At least five of those, so it reads as a pattern rather than one late payer.
Weight by value, report the count
This one is a genuine correction to how the figure used to be computed, and the distinction matters more than it looks.
If one invoice in ten goes bad, that is a 10% count loss rate. But if the ones that go bad are systematically your small ones, applying 10% to a pile of large invoices overstates the loss badly — and if they are systematically your large ones, it understates it.
So the rate applied to money is weighted by value, while the count is still reported as the plainer statement of how often invoices go bad. Both are true; only one of them should be multiplied by a dollar pile.
Future dates and other export noise
Invoices dated in the future are dropped. They are a data-entry or timezone artifact, not a debt, and aging them would invent receivables that do not exist.
Similarly, the collected date has to survive the import intact. An early version of the importer parsed it correctly and then dropped it on the way through, so every invoice read as unpaid and the detector reported a 100% never-collected rate for a business that collects normally. That bug is the reason the mapping now renames it explicitly, and the reason the number is worth checking against your own bank.