Day Nought, and What Starts Then
The clock does not start when you send the invoice. It starts when a document their system accepts as valid arrives — and the gap between those is yours to close.
Theirswho controls this stretch
Two readings of the same thirty-day term, on one invoice
The date I would have called day nought.
The order number was right; the goods receipt had not been entered.
Their day nought, twelve days after mine.
Paid on day forty-two of my own count, on thirty-day terms.
Both sides read the term honestly and arrived twelve days apart. The gap was validation, and nobody reported it. One supplier's own invoice, not a statement about anybody.
The clock on payment terms does not start when you press send. It starts at whatever event the contract names, and in most purchase terms that is receipt of a valid invoice.
The delay in “Day Nought, and What Starts Then” needs separate timestamps for work, approval, invoicing and settlement. Teams reviewing see the full platform outline for time tracking with screenshots can strengthen the work-record part of that chain without pretending to explain what happened inside the customer’s accounts-payable process.
Everything between sending and validity is time you have added, and it is the only part of the wait you can shorten.
Additional context for “Day Nought, and What Starts Then” is available through CFPB payment resources. A sound review separates the work record, invoice, approval and final settlement.
The events terms run from
The invoice date. Receipt. Acceptance of the work. The end of the month of invoice. Completion of the contract.
Five possibilities, each producing a materially different due date from the same document.
"End of month following"
The one that surprises people. An invoice dated the 2nd is due at the end of the following month: fifty-nine days, described as thirty.
It is entirely standard, and it should be in your cash forecast rather than in your grievance.
"A valid invoice"
The qualifier that does most of the work. Where validity requires an order number, a receipt and a portal submission, an invoice missing any of them has not started anything.
A month can pass with the supplier counting and the buyer not.
Who thinks the clock has started
You, from the day you sent it. Them, from the day it validated.
The difference between those two dates is the single most common source of a disagreement about lateness.
Establishing day nought
Ask, once, in week one: has this been received and matched, and what date are you working to.
The answer is a date. From then on both sides are counting the same days.
Why it is worth knowing early
Because if their date is three weeks after yours, you can fix the cause now rather than discovering it at sixty days.
The invoice that never validates
Sits in an exception queue, ages, and never becomes due at all.
To the supplier it looks like a slow payer. It is a clerical failure with no clock attached.
What the law may give you
Some jurisdictions set a default period where terms are silent, and limits on how long terms may be.
What applies where you are is a question for somebody qualified there, and it is worth knowing once.
Your own record of day nought
Invoice number, date sent, date confirmed received, date confirmed matched, due date.
Five fields. They turn every later conversation from a dispute about dates into a reading of a row.
Why the two sides disagree about it
You date the clock from the moment you sent the invoice, because that is the event you observed. The buyer dates it from the moment the invoice became valid in its system, because that is the event its process records.
Both are reading the same term honestly. Between the two dates sit the days spent unmatched, unreceipted or queried, and neither side necessarily knows the other's figure.
This is why a conversation about lateness so often produces two people who each believe they are correct. Establishing the buyer's day nought early — by asking, plainly, what date their system shows as the invoice's received or validated date — removes the disagreement before it has anything to feed on.
What to do with the difference
Once both dates are known, the gap between them is the most informative number available about a customer.
A gap of a day or two means validation is working and the terms mean roughly what they say. A gap of three weeks means the stated terms are a fiction and the real payment period is the term plus the validation delay — which is a figure you can price, plan around and quote on.
It also tells you where the fixable problem is. A long validation gap is almost always caused by something at the submission end: a reference format, a missing receipt, the wrong address. Those are the supplier's to fix, and fixing them shortens every subsequent payment without any negotiation.
A short validation gap with late payment anyway is a different problem, located in the approval chain or the payment run, and nothing you do to your own invoicing will touch it.
Keeping your own record of it
Whatever the buyer's system says, the supplier needs its own dated note: when the invoice was sent, to what address, with what reference, and what confirmation came back.
It takes seconds at the time and it is the only answer available to the question that arrives two months later, when somebody suggests the invoice was received in the following month.
Without it, the supplier is asserting a date. With it, the supplier is producing one, which is a different conversation entirely.
The habit at your end
Send immediately, confirm receipt in week one, record the agreed due date, and count from theirs rather than from yours.
It removes nothing from the wait that belongs to them, and everything that belonged to you.