Everything up to here was arithmetic with a defensible answer. This part has no defensible answer, which is exactly why the system stops at the number and hands it to a person.
Key takeaways
Most entitlements should never be invoiced. Almost all of them should be known.
A waiver shown on the statement is worth more than a claim nobody sends.
A customer who has stopped trading is the one case where claiming costs nothing.
The number belongs in the renewal conversation, not in the dunning sequence.
Never automate the send. Automate the calculation and the evidence.
What happens to a calculated entitlement
Fig 1. Five questions, four ways out. The default at the bottom is the one most businesses should be doing and almost none are.
Storage
Machine learning
Security & identity
Management
Analytics
People
The visible waiver
The strongest thing most businesses can do with this number is put it on the statement and then credit it to nil in the line underneath. Late payment compensation accrued: 340.00. Waived as a gesture of goodwill: -340.00. Nothing is charged, nothing is demanded, and the customer’s finance team now knows a real figure that was previously invisible.
This works because the awkwardness of the conversation was never really about the money. It was about being the supplier who sends a demand. A waiver is not a demand. It is a fact, presented, with a concession attached, and it costs you exactly nothing because you were never going to collect it anyway.
It also gives you something real to trade at renewal, which the same number sitting in a spreadsheet does not. A supplier who has visibly waived four thousand pounds over two years is in a different negotiating position from one who has silently absorbed it.
What the number is actually for
Fig 2. The same number, five jobs. Four of them never involve contacting the customer about it at all.
Concentration is the useful finding
In the worked example the thirty-five thousand six hundred and eighty pounds was not spread evenly. Nine customers accounted for twenty-four thousand three hundred of it, and a single customer — seventy-four late invoices, thirty-one days late on average — accounted for seven thousand five hundred and seventy on their own.
That customer was not a bad customer. They were a large one with a slow purchase ledger and a payment run on the twenty-eighth, and the workshop had been quoting them the same prices as everybody else for four years. The seven and a half thousand pounds was never going to be invoiced. It was worth knowing because it was, in effect, an unpriced financing service, and the next quotation could price it.
The sentence the evidence has to be able to write
Invoice 41,207 for 3,140.00 was for work completed on 4 March.
The invoice was received by the customer on 6 March, per the send log.
With no agreed terms, it became late on 6 April.
The rate pinned at that date was 12.25%, being base plus eight at the 31 December reference date.
It was paid on 9 May, 33 days late, accruing 34.79 of interest.
A fixed sum of 70.00 applied, giving 104.79, which was shown and waived on the May statement.
Where this ends
The system does not get anybody paid faster on its own. What it removes is the category of loss where nobody decided anything — the entitlement that accrued for six years and expired, the customer whose slowness was never priced, the fixed sum that nobody in the business had heard of.
It also puts the decision where it belongs. Software is good at establishing that an invoice became late on the sixth of April at a rate of twelve and a quarter per cent, and extraordinarily bad at knowing whether the customer’s finance director is about to put a much larger contract out to tender. Calculating is automated; sending is not, and no configuration flag makes it so.
The next post prices it and the one after gives the service names, the tables and the IAM. The interesting thing about the cost is that the model reads agreements, which arrive a few times a year, while the arithmetic runs nightly for free.