The 13-Week Cash Forecast, and the Weekly Re-Score That Makes It Useful

A 13-week cash forecast that is built once, presented at a bank meeting and then left in a folder is a decoration. It cost two days, it was wrong within a fortnight, and nobody found out. The version that changes how a company behaves is rebuilt every Monday, compared line by line against the forecast it replaces, and scored. The score is the point. A forecast nobody grades is an opinion; a forecast that has been graded thirteen times is an instrument.

What follows is the model we build in the first fortnight of an engagement where cash is the binding constraint, the weekly routine that keeps it alive, and the re-score that tells you whether to trust it.

All figures below are Canadian dollars.

What this forecast is not

Getting this wrong wastes the first week, so it is worth stating plainly.

It is not	Because
A budget	A budget is a plan for the year in accrual terms. This is a prediction of bank balances in cash terms. They will not agree and they are not supposed to.
A cash flow statement	The statement in your financial statements is a backward-looking reconciliation built from the indirect method. This is built directly, from named receipts and named payments.
A P and L forecast with the timing adjusted	Revenue recognised in March and collected in June is a June line here. Depreciation never appears at all.
A one-off exercise for a lender	If the only copy is the one you sent the bank, you have a document, not a forecast.
A 12-month forecast in shorter buckets	Thirteen weeks is chosen because it is roughly the horizon over which a company can still act. Beyond that the weekly detail is false precision.

The structure

Thirteen columns, one per week, starting with the current week. Rows are grouped so that the parts you can influence are visually separate from the parts you cannot.

Block	Rows	Where it comes from
Opening bank	One row per operating account, plus one for the operating line drawn	Bank balance at Friday close, not the ledger balance
Receipts, contracted	Collections from the AR ledger, one row per customer above your concentration threshold, one aggregate row for the rest	AR aging plus a per-customer payment lag
Receipts, uncontracted	New sales expected to bill and collect inside 13 weeks, deposits and retainers, tax and grant refunds, financing draws	Sales pipeline, only where a deposit is contractually due
Payroll	Gross pay, source deductions, employer costs, and any commission or bonus cycle, on the actual pay calendar	Payroll register plus the pay calendar for the year
Trade payments	AP ledger by supplier with a payment terms rule, plus the recurring payments that never generate an invoice	AP aging and the vendor list
Fixed obligations	Rent, insurance, loan principal and interest, lease payments, licence and subscription renewals	The contract file, not memory
Statutory remittances	Payroll source deductions on their remitter schedule, sales tax on your reporting period, corporate instalments	Confirm each schedule with your practitioner and put the resulting dates in as fixed rows
Capital and one-offs	Equipment, deposits on new premises, professional fees for a transaction, settlement payments	Approved capital list
Net movement and closing bank	Calculated	Calculated
Headroom	Closing bank plus undrawn operating line, less the minimum cash floor	Calculated

Two rows in that table cause almost all of the argument. The recurring payments that never generate an invoice are the ones that get missed on the first build: the payment processor fee that nets off a deposit, the software billed to a corporate card, the vehicle lease debited directly. Pull three months of bank statements and tick every debit against a row. Anything you cannot tick is a missing row.

The other is statutory remittances. Do not estimate these and do not put them in from memory. Each obligation has its own schedule, and the schedule depends on facts about the company that need confirming rather than assuming. Get the actual dates confirmed once, then hard code them as fixed rows for all thirteen weeks.

The collection lag, which is the whole model

The receipts side is where forecasts die. Companies build it by taking the AR aging and assuming everything is collected on terms. Nothing is collected on terms.

Build a payment behaviour table instead. For each customer above your concentration threshold, look back over the last twelve months and record the median days from invoice date to cash in the bank. Not the average, because one 120-day outlier drags an average to a number the customer has never once paid at. Then band them.

Band	Median days from invoice to cash	Forecast treatment
Pays early or on terms	At or below stated terms	Forecast at invoice date plus terms
Consistently late by a fixed amount	Terms plus a stable lag	Forecast at terms plus that customer’s median lag
Erratic	Wide spread with no median worth using	Forecast at the 75th percentile, and flag the row
Requires a purchase order match or portal submission	Any	Forecast from submission date, not invoice date, and only after you have confirmed the submission happened
Disputed or in collections	Any	Zero. Never forecast a disputed balance. It is the single most common source of a large miss.

The portal row matters more than it looks. Large customers and public sector buyers frequently pay from the date an invoice is accepted in their system, which can be weeks after you issued it. If your forecast starts the clock at your invoice date, you will be wrong by that gap on every invoice, every month, in the same direction.

The weekly routine

The build is a two-day job. The routine is a ninety-minute job, and it happens on the same morning every week.

1. Update the opening bank balance from the actual Friday closing balances. Do not use the ledger. The ledger is not the bank.
2. Record last week’s actual receipts and actual disbursements against the forecast rows they were meant to hit.
3. Produce the variance table for the week that just closed.
4. Roll the model forward one column. Week 2 becomes week 1, and a new week 13 is added at the far end.
5. Re-forecast the receipts side from the current AR aging and the payment behaviour table. Do not carry last week’s receipt assumption forward unchanged; that is how a stale forecast survives for a quarter.
6. Update the disbursement side from the current AP aging and the approved payment run.
7. Recompute headroom against the cash floor and check the trigger table.
8. Circulate a one page summary. Closing bank by week, headroom by week, and the three largest changes since last week with a reason for each.

Step 5 is the one that gets skipped when the week is busy, and skipping it converts the exercise into copying a spreadsheet sideways.

The re-score

Here is the artifact that separates a forecast that is trusted from one that is tolerated. Every week, score the forecast that expired against what actually happened. After a quarter you have thirteen scores and you know exactly how much to believe the current one.

The worked example below covers the first four weeks of a rolling model. Opening bank was 412,000.

Week	Receipts forecast	Receipts actual	Variance	Disbursements forecast	Disbursements actual	Variance
1	186,000	171,300	(14,700)	214,500	209,800	4,700
2	240,000	226,400	(13,600)	176,200	181,900	(5,700)
3	155,000	168,900	13,900	268,900	271,400	(2,500)
4	198,000	205,700	7,700	181,600	179,300	2,300
Total	779,000	772,300	(6,700)	841,200	842,400	(1,200)

Brackets are unfavourable in both columns: less cash in, or more cash out, than forecast.

Now the balance that actually matters, which is the closing bank position:

Week	Closing bank forecast	Closing bank actual	Variance	Absolute error
1	383,500	373,500	(10,000)	2.6%
2	447,300	418,000	(29,300)	6.6%
3	333,400	315,500	(17,900)	5.4%
4	349,800	341,900	(7,900)	2.3%

Read the two tables together, because separately each one lies to you.

The cumulative receipts miss across four weeks is 6,700 on 779,000 forecast, which is under one percent and looks excellent. The weekly mean absolute error on receipts is 6.6 percent, which is a different and more honest story: the weeks were individually wrong by a lot and the errors happened to net off. A company that read only the cumulative line would conclude its forecast was accurate and would be surprised by a week where the errors ran the same way.

The closing bank position tells the third version. Mean absolute error of 4.2 percent, and every single week negative. Four weeks in the same direction is not noise, it is bias, and bias has a cause you can name. Here the cause is visible in the receipts column: weeks 1 and 2 both came in short, weeks 3 and 4 both came in over. Cash arrived later than forecast rather than not at all. That is a lag assumption that is too short, not a collections problem, and the fix is in the payment behaviour table rather than in a phone call to a customer.

Reading the score

Pattern in the score	Almost always means	Fix
Errors alternate in sign and are small	The model is behaving. Leave it alone.	None
Receipts short in consecutive weeks then over in later weeks	Collection lag assumptions are too short	Rebuild the payment behaviour table on twelve months, not three
Receipts short and never recovered	A real collections problem, or revenue that was never going to bill	Escalate to collections, and zero the row until it moves
Disbursements consistently over forecast	Payments are leaving outside the payment run	See the AP control matrix. This is a control problem, not a forecast problem.
A single very large miss with everything else tight	One item, usually a statutory remittance or a lease payment, is missing a row	Add the row and tick three months of bank statements again
Errors grow the further out you look	Normal and expected	Report weeks 1 to 4 as a commitment and weeks 5 to 13 as a projection, and say so

The trigger table

The forecast exists to cause a decision at a defined point, not to be admired. Set the triggers before you need them, when nobody is under pressure, and write them down.

Condition	Trigger	Owner
Headroom in any of weeks 1 to 4 falls below the floor	Payment run is re-sequenced; discretionary spend paused	Controller, same day
Headroom in any of weeks 5 to 13 falls below the floor	Written plan to the owner within two business days naming the specific levers	Controller
Closing bank forecast negative in any week	Lender conversation opened before the week arrives, not during it	Owner
Operating line drawn above an agreed proportion for two consecutive weeks	Structural review, not a cash review	Owner
Forecast accuracy on closing bank worse than an agreed tolerance for three consecutive weeks	Model rebuilt from source rather than adjusted	Controller

The last row is the one that gets left out and it is the one that protects everything else. A model that has stopped predicting needs to be rebuilt, not patched, and deciding that in advance stops the argument about whether this week’s miss was “unusual”.

Who owns what

One preparer, one reviewer, one decision maker. The preparer updates the model and produces the variance table. The reviewer checks the opening balances against the bank, checks that every disputed balance is at zero, and checks that the statutory rows are still present. The decision maker reads the summary page and acts on the trigger table. When the preparer and the reviewer are the same person, the model drifts toward optimism, and it does so gradually enough that nobody notices for a quarter.

What we do not do with this model

We do not use it to forecast profit, and we do not let it become a thirteen week P and L with a different title. We do not extend it past thirteen weeks; if the question is about next year, that is a different model with different rows and different owners. We do not build it inside the accounting package. And we do not produce a version for the lender that differs from the version the company runs on. If the internal number is uncomfortable, the answer is to change the plan, not the copy that leaves the building.