What a late invoice is actually costing you

Most people chasing an unpaid invoice ask for the invoice total, because working out anything more is fiddly. The arithmetic is not hard. It just has three places it goes wrong, and all three are worth knowing whether or not you ever use a tool for it.

One thing first, and it matters more than any of the sums below: working out interest is not the same thing as being able to charge it. Whether you can, and at what rate, comes from the contract you signed or from the law where you are. This page asserts no rate, no entitlement and no grace period, names no scheme, and is not advice. Every figure below is a clearly hypothetical example on stated inputs.

The formula

Simple interest, not compounded: balance × annual rate × days ÷ days in the year.

Take an invoice of 4,800 at an agreed 8% a year, due on 3 December and calculated to 31 January. The day count is real calendar days: 28 left in December plus 31 in January, so 28 + 31 = 59 days.

4,800 × 0.08 = 384 a year. 384 × 59 ÷ 365 = 62.07.

The daily figure is the one that changes behaviour: 384 ÷ 365 = 1.05 a day, which at that rounded daily figure is 1.05 × 7 = 7.35 a week. A debt that visibly grows is paid this week rather than next month, and it is the only sentence in a chasing email that does any work.

Mistake one: the year

The 365 above is a convention, not a fact of arithmetic. Some contracts specify a 360-day year, some use the true length of the year. On the same numbers, 384 × 59 ÷ 360 = 62.93 against 62.07 — a difference of 62.93 − 62.07 = 0.86 on one small invoice, and a great deal more across a ledger.

Whichever basis you use, state it on the statement. An unstated convention is a hidden assumption, and it is the first thing a disputing debtor will find.

Mistake two: rounding to months

“About two months” is not 59 days. Count real calendar days from the due date to the date you are calculating to, leap days included, and count to but not including that final date. The difference is small per invoice and systematic across all of them.

Mistake three: part-payments

This is the big one. An invoice of 3,000 falls due on 14 November. 1,000 arrives on 31 December. You are calculating to 31 January.

Split it at the day the money actually arrived. From 14 November to 31 December is 16 + 31 = 47 days on 3,000. From 31 December to 31 January is 31 days on 2,000. That is 47 + 31 = 78 days overdue in total, which checks out against the calendar.

Now sum the balance-days: 3,000 × 47 = 141,000 and 2,000 × 31 = 62,000, so 141,000 + 62,000 = 203,000. At 8%: 203,000 × 0.08 ÷ 365 = 44.49.

Compare that with the two shortcuts everyone actually takes. Apply the payment at the start of the period and you get 2,000 × 78 × 0.08 ÷ 365 = 34.19 — understating by 44.49 − 34.19 = 10.30. Apply it at the end and you get 3,000 × 78 × 0.08 ÷ 365 = 51.29 — overstating by 51.29 − 44.49 = 6.80.

Overstating is the worse error of the two. A figure a debtor can pull apart is worth less than the smaller figure you can defend line by line.

Round once, at the end

Total the balance-days as exact whole numbers first, then divide and round once per invoice. Rounding each period separately makes the sub-totals drift from the total, and a statement that does not add up invites an argument about the arithmetic instead of the debt.

What to keep

Per invoice: the invoice date, the due date, the amount, and every part-payment with the date it arrived. That is the entire input. If your records hold it, the statement takes minutes; if they do not, no tool can reconstruct it.

The Late Payment Interest & Statement tool does this per invoice across a whole ledger, splits the accrual on each payment date, and prints the daily growth figure. It has no clock — you type the date you are calculating to — and no rate, compensation amount or payment term is built into it, because those come from your contract or from the rules where you are, and a stored one would be confidently wrong.