How to Update a Cash Flow Projection Without Losing Its Accuracy

A cash flow projection is not a report you build once and file away. It is a working paper that decays the moment reality diverges from its assumptions. Updating one well is a discipline in its own right, and it sits squarely in the bookkeeper's hands because the evidence you need lives in the ledger.

Why a projection needs regular editing?

Every projection rests on assumptions: when customers will pay, when suppliers will be settled, what payroll and rent will cost next quarter. The moment an assumption is wrong, the projection is wrong, and the further out it runs the more wrong it becomes. We treat a projection as stale once the current month's close is done, because that close is the freshest evidence you have.

The other trigger is a change in the business itself. A new customer with different payment terms, a supplier moving from 30 to 45 days, a planned equipment purchase: each one invalidates part of the model. Edit when the facts change, not just on a calendar.

What should you update, and what should you leave alone?

Separate the projection into its two layers before you touch anything. The first layer is actuals: cash movements already recorded and reconciled. Those are history, and you should never retype them to make the projection look better. If an actual looks wrong, fix the ledger, not the projection.

The second layer is assumptions. These are the ones to edit. Typical items include expected collection dates for open receivables, expected payment dates for open payables, forecast payroll runs, tax instalments, loan repayments, and any one-off items such as a dividend or an asset purchase.

Keep an assumptions log alongside the projection. One line per assumption, the date it changed, and why. Six weeks later, when someone asks why March looked different, that log is the answer.

How do you roll the projection forward?

Work in a fixed sequence. Start by replacing the oldest forecast week or month with actuals from the closed period, reconciled to the bank. Then re-base the opening cash balance to the true closing balance from the reconciliation, not from the previous projection.

Next, refresh the receivables and payables ageing. An invoice the model expected to collect last week that is still open needs a new expected date, and that date should come from evidence: the customer's payment behaviour, a promise to pay, or a dunning stage. Do not simply push everything out by a month.

Then revisit the recurring items. Payroll, rent, insurance, loan repayments. These change rarely, but when they do the effect is large, so check them every cycle rather than assuming they are unchanged.

Finally, re-run the projection and compare it to the previous version. The comparison is the point. A projection that swings wildly after a routine update usually means an input error, not a change in the business.

How do you keep an edited projection honest?

The discipline is the same as for any working paper: the projection should be reproducible from its inputs. Anyone reviewing it should be able to trace each forecast line back to the ledger, the ageing report, or the assumptions log.

Version the file. Keep each dated version rather than overwriting, so you can show what you knew and when. This matters if the projection is being used to support a borrowing request or a board conversation, because the question "what did you expect in January?" will come up eventually.

Reconcile the boundary every time. The single most common error in an updated projection is a seam between actuals and forecast: an opening balance that does not match the bank, or a receivable counted in both layers. A five-minute tie-out at the seam prevents most of it.

When does updating stop being routine?

Most updates are ordinary bookkeeping and stay with you. Two situations do not. If the projection is being prepared for a lender or an insolvency practitioner, the format and the evidence requirements are theirs, and you should confirm those before editing anything. And if the numbers depend on a data file whose integrity you doubt, for example a ledger where balances shift between runs, get the file looked at first. A projection built on damaged data is worse than none, because it carries false confidence. Our sister service handles that kind of file repair, and we would rather send you there than let a corrupted balance quietly poison the forecast.

Everything else, the sequencing, the evidence, the assumptions log and the tie-out at the seam, is yours, and done well it turns the projection from a one-off exercise into a tool the business can actually steer by.