The Invoicing Calendar, Because Cash Starts Here

The cheapest cash in a company this size is sitting in the gap between the day work becomes billable and the day the invoice actually leaves. Releasing it costs nothing. Nobody is telephoned, no discount is offered, no relationship is spent and no facility is drawn. The invoice simply goes out earlier, every month, on a date somebody agreed to in advance.

Hardly anyone works that lever, because it does not present itself as a cash problem. It presents itself as administration. So the effort goes to the far end of the cycle instead, where somebody is chasing a balance that would not have been overdue at all if the invoice had gone out in the first week of the month rather than the third.

That is the position of this piece, stated at the front: billing timing is the first lever on cash and collections is the second, and most companies work them in the wrong order. What follows is the calendar that fixes the first one, by revenue type, with the person who prepares each run, the person who reviews it, and the gate an invoice has to pass before it is allowed to leave.

Measure the gap before you build anything

One month of issued invoices, two columns. The date the work became billable, meaning the date the last thing that had to happen before you could invoice actually happened, and the date the invoice was dispatched to the customer. Take the median and then read the worst five individually.

The median tells you the size of the prize. The worst five tell you the cause, and in almost every file the worst five have one cause between them: an input that only one person can produce, who was not asked for it until the billing run had already started.

Do this before you redesign anything. A billing calendar built without it is a guess about which step is slow.

Why a day of billing delay costs more than a day

Two reasons, and the second is the one that surprises people.

A day of billing delay sits in front of everything else in the cycle. It does not compress. Whatever a given customer’s payment behaviour is, and the way to build that properly is the payment behaviour table in the 13-week cash forecast piece, the delay is added to it rather than absorbed by it.

The second reason is that your customers pay on their own cycles rather than continuously. A large customer runs a payment run on a fixed rhythm, and an invoice that arrives after the cut-off for one run waits for the next one. Cross that boundary and you have not lost the day you were late by. You have lost the interval between their runs, which you do not control and usually cannot see.

Billing is not one calendar

This is the design error underneath most late invoicing. The company runs a single billing pass, at the end, and every invoice in it waits for whichever input is slowest. So the recurring book, which needs no approval from anybody outside finance and could have been dispatched on the first business day, sits waiting on a milestone certificate that a project manager has not signed.

Separate them by revenue type. Each type has its own precondition, its own supplier of that precondition, and therefore its own natural cut-off.

Revenue type	What has to be true before it can be billed	Who produces that	Where the cut-off sits	The failure that delays it
Fixed recurring, billed in advance	The contract register is current: starts, ends, price changes effective this period, suspensions	Finance, from the contract file	Before the period starts	A signed contract that never reached the register
Fixed recurring, billed in arrears	Same, plus confirmation that service was not suspended in the period	Finance, with a service check	First business day after period end	Nothing, usually. This is the easy block.
Time and materials	Time entry closed and approved by the delivery lead, with non-billable time already marked	Delivery leads	Last business day of the period for entry, first business day after for approval	Approvals treated as a background task rather than a dated obligation
Milestone or progress billed project	A signed or otherwise evidenced milestone certificate	Project manager, and often the customer	Continuous, not monthly. Bill the day the milestone is certified.	Waiting for the monthly run to bill something that was certified on the ninth
Usage or metered	A frozen meter reading for the period, with the disputed lines already identified	Operations, or the platform	Period end, with the reading frozen rather than re-queried later	A meter that keeps moving after the read, so the invoice and the source disagree
Pass-through and reimbursable expenses	The underlying supplier invoice, coded to the customer	AP, at the point of entry	Same run as the service it attaches to	Expenses coded to a project with no customer reference, found months later
One-off deliverable	Delivery evidence, and acceptance where the contract requires it	Delivery lead	The day of delivery or acceptance	Nobody told finance the thing shipped
Renewal carrying a price change	The renewal, confirmed with the customer, and the register updated before the run	Whoever owns the account	Before the first run of the new term	The register still holding the old price, which is then billed and has to be corrected

Read the milestone row again. Milestone invoices are the ones most often swept into the monthly batch, and they are the ones with the least reason to be there. A certified milestone is billable that day. Holding it for the month end run adds delay for no purpose other than tidiness.

One boundary, because these two get confused in the same conversation: this calendar decides when an invoice is dispatched. It does not decide what revenue is recognised, which is a separate question settled once in the revenue recognition policy and then applied, not re-argued monthly.

The monthly calendar

Day 0 is the last business day of the period. Positive days are business days after it. This is the shape we install, and it compresses or stretches by a day or two depending on how many revenue types a company actually sells.

Day	Step	Preparer	Reviewer	Gate before it moves on
Day -3	Billing input notice goes out, naming every person who owes an input and what is due from them, with the date	Coordinator	None	None
Day -3	The pending billing list is circulated to delivery leads: everything currently sitting unbilled, by customer, with an age against it	Coordinator	Finance lead	None
Day -2	Contract register reviewed: new contracts started this period, contracts ended, price changes effective, anything suspended	Finance	Finance lead	Register signed as current for the period
Day -1	Usage meters frozen for the period, disputed lines flagged before the run rather than after the invoice	Operations	Finance	Reading frozen and stored, not re-queried later
Day 0	Time entry closes at a fixed hour. Late entry goes into next period and is billed then.	Delivery leads	Coordinator	The hour is fixed and it is not moved for anyone
Day +1	Recurring run generated and dispatched. This block does not wait for anything else.	Finance	Finance lead	Dispatch gate below
Day +1	Time approvals due, with non-billable time already marked as such	Delivery leads	Finance	Unapproved time is carried, not guessed at
Day +2	Time and materials, usage and pass-through invoices prepared	Finance	Finance lead	Each traced to its source: approved hours, frozen meter, coded supplier invoice
Day +2	Review pass on everything prepared since Day +1	Finance lead	None	Dispatch gate below
Day +3	Dispatch, including portal submissions, and each submission confirmed as accepted rather than as sent	Finance	None	Portal acknowledgement captured, not assumed
Day +4	Exception sweep. Anything not billed is written on the unbillable list with a reason and an owner.	Finance	Finance lead	The list is published, not filed

Milestone invoices are absent from that table on purpose. They are billed on certification, whenever that falls, and the only monthly step is a check that no certified milestone is still sitting unbilled.

The days after Day 0 overlap the front of the close, which is deliberate. Billing has to be finished before receivables can be reconciled, so the billing calendar and the close calendar we run are published as one document with one set of owner names on it. Two calendars maintained separately drift within a quarter, and the drift shows up as an invoice dated in a month that has already been locked.

The dispatch gate

Five checks, run by one person on everything about to leave. They exist because a re-issued invoice does not merely cost the correction. It restarts the customer’s clock from the date of the corrected invoice, so a billing error is a collections delay wearing a different coat, and it is the one delay the customer is entitled to be right about.

The customer is the right legal entity, and the invoice is addressed to the person or mailbox that entity actually processes from. Group companies change which entity contracts, and the change reaches finance late.
Any reference the customer requires is present. Purchase order number, contract number, cost centre, project code. An invoice missing a required reference is not late until it is rejected, and then it is very late.
The amount traces to a source that is not the previous invoice. Approved hours, the frozen meter reading, the contract register, the milestone certificate. Copying last month is how a cancelled service gets billed for a further four months.
The tax fields come from the customer master rather than from the person preparing the invoice. Registration status and place of supply are set when the account is opened, confirmed with the accountant who prepares the company’s returns at that point, and then left alone. A biller deciding tax treatment at four in the afternoon is a control gap, and it is not one this calendar is designed to solve.
The delivery channel is the one that customer uses. Emailing an invoice to a customer who only pays from a portal produces a document that is filed by nobody.

The billing detail sheet

Most of the gate above can only be answered if somebody captured the answers at the start. The artefact is one sheet, completed when the contract is signed rather than when the first invoice is due, and stored against the customer record.

Field	Why it is on the sheet
Contracting legal entity, exactly as it is to appear	The most common cause of a rejected first invoice
Billing contact, and the mailbox invoices are processed from	Frequently different from the person who signed
Submission channel, with portal credentials held by more than one person	A portal login known to one person is a single point of failure in the cash cycle
Reference required on the invoice, and who issues it	Purchase order regimes fail silently: the invoice looks fine and simply is not queued
Billing frequency, first billing date, and whether in advance or arrears	Removes the argument in month one
What has to accompany the invoice	Timesheets, sign-off sheets, receipts for recharges. Missing backup is a rejection, not a query.
Where remittance advice will be sent	Determines whether cash arriving can be matched or sits unapplied
The date the sheet was completed and by whom	So a stale sheet is visible as stale

The purchase order row is the one that repays the effort. A customer whose accounts payable process requires a purchase order will not usually tell you that your invoice failed. It sits in a queue that nobody works, and you find out when somebody finally telephones about a balance that was never going to be paid in the form it was sent.

When an input is late

The rule is short and it needs to be agreed before the first time it bites: the run never waits. Bill everything that is supported, and carry the rest, named.

A delivery lead who has not approved time by Day +1 does not delay eleven other customers. Their customer is billed for approved hours only, the unapproved balance moves to the unbillable list with their name on it, and it bills next period. That is uncomfortable exactly once. After the first month in which a manager sees their own name against carried revenue on a list the owner reads, the approvals arrive.

The alternative, which is the normal practice, is that finance chases the input for three days, the whole run goes out late, and the cost is spread across every customer instead of landing on the person who caused it.

The unbillable list

This is the output of the calendar that companies do not currently produce, and it is the one that changes behaviour.

Every month, one page: work delivered that was not invoiced, with the customer, the amount where it can be quantified, the reason, the owner, and the age. Reasons cluster into a small set, and the clusters are the finding.

Reason it could not be billed	What it usually means
Awaiting approval of time	An approval habit, and a named manager
Awaiting a milestone certificate	Either the work is not actually complete or nobody is chasing the customer for sign-off
Scope delivered that is not in the contract	A change order that never reached finance, which is its own problem and has its own control
Customer disputes the underlying work	Belongs in dispute resolution today, not in the ageing in six weeks
No purchase order issued	The customer’s own process, and it needs an account owner to work it
Contract expired and not renewed, work continuing	The most expensive item on the list and the one that sits longest

The last row is worth a standing check of its own. Work continuing past the end of a contract is a commercial exposure before it is a billing problem, and it is normally discovered by finance rather than by the person who owns the account.

Two numbers, reported monthly

Billing lag, as the median days from billable to dispatched, and the re-issue rate, as the count of invoices credited and re-billed in the month.

Report them together, always. Lag on its own creates pressure to push invoices out faster, and the fastest way to reduce lag is to skip the dispatch gate, which raises re-issues, which lengthens cash. A company that watches one number and not the other will get exactly what it measured.

What we do not do

We do not offer a discount for early payment as a substitute for invoicing on time, because that is buying back days the company was giving away for free. We do not bill an estimate for time that has not been approved, because an invoice the customer can dispute is worse than an invoice issued next month. We do not let a single portal login live with one person. And we do not run a billing calendar without the unbillable list, because a calendar reports what went out and the list reports what did not, and only one of those two tells you where the money is.

The Invoicing Calendar, Because Cash Starts With a Date