Skip to content
allanninal.dev/build
Collaborate

Part 2 of 7 · Late payment interest claimer series ~5 min read

When an invoice actually becomes late

Everything downstream is arithmetic on one date, so this is the only part of the system where being approximately right is worthless. An interest claim that starts from the wrong day is not a slightly wrong claim; it is a claim the customer gets to reject on a technicality.

Key takeaways

  • An agreed date in the contract beats everything else, if there really is one.
  • Terms printed on your own invoice are not automatically agreed terms.
  • With nothing agreed, the default runs from the later of delivery and receipt of the invoice.
  • Payment terms beyond 60 days are open to challenge as grossly unfair.
  • Record which route produced the date, and the evidence behind it.

Three places a due date comes from

Three sources for a payment due date converging on one dateThree boxes on the left feed one box on the right. An agreed date in a contract both sides signed, described as strongest. Your invoice terms, printed but not necessarily ever agreed, marked check. Nothing agreed, meaning no contract and no accepted terms, in which case the statutory default applies. All three converge on Due date, holding the day and how it was derived, which feeds a box labelled Late from: the next day, and the clock starts. A note says the middle lane is where most businesses think they are and the right-hand lane is where most of them actually are, and the two produce different dates.An agreed datein a contract bothsides signedstrongestYour invoice termsprinted, but werethey ever agreed?checkNothing agreedno contract, noaccepted termsstatutory defaultDue datethe day, and howit was derivedLate fromthe next day, andthe clock startsThe middle lane is where most businesses think they are and the right-hand lane is where most of them actually are, and the two produce different dates.
Fig 1. Three routes, one date. Which route you took is stored, because it is the first thing a customer’s finance department will question.
  • Management
  • Analytics
  • Front-end & mobile

Printed terms are not agreed terms

Almost every invoice in the country says something like payment due within 30 days along the bottom. That line is a statement of what the supplier would like. It becomes a term of the contract if the customer agreed to it — in a signed agreement, in an accepted quotation, in a purchase order that incorporates it — and not otherwise.

This is not a reason to panic, because the statutory default is usually similar and occasionally better. It is a reason to store which one you are relying on. A business that claims interest from day 31 on the basis of its own footer, against a customer who never accepted the footer, has picked the weakest of the three available arguments for no reason.

The default has two sides

The statutory default due date derived from delivery and noticeA vertical chain inside an AWS account container, entered from a box on the left labelled No agreed date, nothing signed and nothing accepted. Date of performance is when goods were delivered or the service completed. Date of notice is the day the customer received the invoice, with a side exit reading unevidenced: Find it, from a send log, a portal receipt or a signature. Take the later of those two dates, not the earlier. Add the days, thirty unless a valid term says otherwise. Late from the next day, and the rate is fixed here. A note says both dates are needed, because an invoice sent before delivery does not start the clock and delivery without an invoice does not start it either.AWS ACCOUNTNo agreed datenothing signed,nothing acceptedDate of performancegoods delivered orservice completedDate of noticethe day they receivedthe invoiceFind ita send log, a portalreceipt, a signatureunevidencedTake the laterof those two dates,not the earlierAdd the days30 unless a validterm says otherwiseLate from the next dayand the rate isfixed hereBoth dates are needed. An invoice sent before delivery does not start the clock, and delivery without an invoice does not start it either.
Fig 2. Five steps and one hold. The third step is where the intuitive answer and the correct answer diverge.
  • App integration
  • Management
  • Analytics

Why the later of the two

Because the customer cannot reasonably be expected to pay for something they have not received, and cannot reasonably be expected to pay an amount they have not been told. Both conditions have to be satisfied before the countdown makes sense, so the clock starts from whichever happened second.

In practice this cuts both ways and businesses rarely notice either. An invoice raised on the first of the month for work finished on the twentieth is late from the twentieth plus thirty, not the first plus thirty, and the supplier has been under-claiming by nineteen days. An invoice emailed to an address nobody reads, chased in week six and acknowledged in week seven, has a notice date in week seven, and the supplier who claims from week five is over-claiming.

Storing both dates separately is therefore not bookkeeping fussiness. It is the difference between a claim that survives being questioned and one that gets withdrawn in the first phone call.

What the due date record holds

  • The date. The last day payment could arrive without being late.
  • Basis. agreed | invoice_terms | statutory_default.
  • Performance date. When the goods or the work were actually delivered.
  • Notice date. When the customer received the invoice, with evidence.
  • Verification period. Any agreed window to check conformity, and its length.
  • Challengeable. Set where the agreed terms run beyond 60 days.

Two edges worth handling

The first is a verification or acceptance period: a term giving the customer time to check that what arrived conforms to what was ordered before the payment clock starts. These are legitimate and common in manufacturing, and they push the due date out. They are also capped, and an unusually long one is itself open to challenge, so the system stores the length rather than silently absorbing it into the due date.

The second is long payment terms. Where terms extend well beyond sixty days there is a route to argue they are grossly unfair to the supplier and should not stand. Whether to run that argument against a customer worth a third of your turnover is emphatically not a decision for software, so the system flags the invoice and moves on. The flag is useful precisely because nobody currently counts how many of these there are.

The next post is the rate. It is a single number, it applies to the whole life of a debt, and the date it was fixed on is not the date you would guess.

All posts