Cash forecast variance review: start from the version you approved
The bank shows 34,000 at the end of week 1. The forecast approved the previous Monday expected 40,000. By the time anyone asks why, the spreadsheet has been rolled forward and the week 1 column holds actuals, so the approved figures have been overwritten. The 6,000 gap could be a customer paying a few days late, a payment nobody planned, or both. Telling them apart requires the forecast as it stood when it was approved. The figures below are hypothetical, in generic currency units.
Freeze the approved version
Canada's Business Development Bank (BDC) advises recording inflows and outflows when cash actually moves, comparing actual movements with projections and adjusting the forecast where they differ. It also describes updating a 13-week forecast every week. That is general business guidance, not a UK or US reporting requirement.
The comparison only works against a fixed baseline. We recommend saving the approved version with its approval date and time before any actuals go in, then building the next forecast as a new version. The categories and steps that follow are our method.
Sources and context, checked :
Tie actuals to the bank first
Take actual receipts and payments from statements for the same accounts and cutoff the forecast used. Explain any difference in opening cash before anything else, because it flows through every later week. The example excludes financing, restricted cash and foreign exchange. Where the forecast combines several bank accounts, transfers between those included accounts do not change their combined cash.
Classify each difference
Payments are shown as positive outflows. The last column shows the effect on closing cash.
| Item | Frozen week 1 | Actual week 1 | Effect on closing cash |
|---|---|---|---|
| Opening cash | 40,000 | 40,000 | 0 |
| Customer receipts | 30,000 | 22,000 | -8,000 |
| Supplier payments | 18,000 | 14,000 | +4,000 |
| Payroll | 12,000 | 12,000 | 0 |
| Software payment omitted from forecast | 0 | 2,000 | -2,000 |
| Closing cash | 40,000 | 34,000 | -6,000 |
Timing, omission or saving
In this example, the evidence supports an expected week 2 date for the missing 8,000 receipt, and the supplier agreed to move a 4,000 payment to week 2. Neither amount changed. The 2,000 software payment was left out of the forecast. So -8,000 + 4,000 - 2,000 = -6,000, fully explained.
Split a difference into its supported causes, then label each component as timing, changed amount, omission or classification error. Anything without evidence stays as unexplained, shown on its own line. The delayed supplier payment is not a saving; the cash still has to go out.
Carry timing items forward once
The frozen week 2 forecast was 40,000 + 20,000 - 15,000 - 10,000 = 35,000. The revised week 2 starts from the actual 34,000, adds the delayed 8,000 to the original 20,000 of receipts and the delayed 4,000 to the original 15,000 of supplier payments: 34,000 + 28,000 - 19,000 - 10,000 = 33,000.
Under those timing assumptions, the timing items unwind and the 2,000 omission still lowers cash two weeks out. Move each timing item rather than copying it. The 8,000 appears in week 2 only, and the receivable behind it must not also sit in a later week's collection assumption. Not every delay reverses the following week. Without a confirmed date, treat the receipt as uncertain and test what happens if it slips again.
Log the changes, not an accuracy score
A single accuracy percentage hides the detail. Offsetting errors can leave closing cash near the forecast while individual receipts and payments were wrong. A change log records:
- Each timing item's revised date and the evidence for it
- Each assumption change, its reason and its owner
- Each unresolved question, who is answering it and by when