How to build a 12-month cash-flow forecast

Forecast cash, not profit

A profit-and-loss statement tells you whether the work you did was worth doing. A cash-flow forecast tells you whether you can pay for it in March. They disagree constantly, and the disagreement is entirely about timing: an invoice raised in January and paid in April is revenue in January and cash in April.

So the unit of a cash-flow forecast is the movement of money, not the recognition of a transaction. Every line answers the question "when does this actually hit the bank account?" — which means a forecast built by copying the P&L into twelve columns is not a cash-flow forecast at all.

This is why companies that are profitable on paper still run out of money. Nothing in the profit figure knows about payment terms.

Start from the opening balance and work forwards

The structure is fixed and worth writing down before any numbers go in. Each month has an opening cash balance, receipts, payments, a net movement, and a closing balance that becomes next month's opening balance. That chain is the whole model.

Receipts are money arriving: customer payments, a loan drawdown, a grant, a tax refund, an equity injection. Payments are money leaving: payroll and the employment taxes that follow it, suppliers, rent, software, professional fees, loan repayments, tax.

Keep receipts and payments gross rather than netting them off. A month where a large payment lands two days before a large receipt looks fine on a net line and is a crisis in the bank account.

Model timing explicitly

For every receipt line, the question is not how much but how late. If your terms are thirty days and your customers average forty-five, model forty-five. Forecasting the terms you wrote rather than the behaviour you observe is the single most common way these models go wrong.

Do the same on the payment side, in both directions. Suppliers you pay on receipt cost you cash earlier than the accounting suggests; suppliers you pay on sixty days quietly fund you.

Then put the lumpy items where they actually fall. Annual software renewals, insurance, corporation tax, VAT or sales-tax quarters, bonuses, the months with three pay runs if you pay weekly. These are the items a flat monthly average hides, and they are usually the months that break.

Write the assumptions down as sentences

Every number in the forecast rests on an assumption, and an assumption that exists only in your head cannot be argued with. Write each one as a sentence next to the line it drives: "new customers pay on day 45", "we hire the second engineer in month 4", "pricing does not change".

This turns the forecast from a prediction into an argument. A reader who disagrees can point at the sentence they would change rather than rejecting the whole model, and you can change it and re-run.

It also makes the forecast survive contact with the next three months. When a month misses, you find out which assumption was wrong, which is the only way a forecast ever gets better.

Build two or three cases, not seventeen

A base case built on the assumptions you actually believe. A downside where the things most likely to slip do slip — collections stretch, one big customer leaves, the hire lands two months late. Optionally an upside, mostly to check that growth does not consume more cash than it produces.

The purpose is not precision. It is to find the month where the downside runs out of cash, because that month is your real deadline for a raise, a cost decision or a collections push.

More than three cases produces a spreadsheet nobody reads and a false sense of coverage. Two well-argued cases beat seven arbitrary ones.

Then use it every month

A forecast built once is a document. A forecast rebuilt every month is a control. At each month-end, put the actuals next to the forecast, look only at the lines that missed, and ask which assumption was wrong.

Roll the window forward so you always have twelve months ahead of you rather than a shrinking stub, and re-run the downside case after any decision that changes a recurring line.

Most of the value is in this loop rather than in the first build. The first version is mainly there to be wrong in a specific, correctable way.

Frequently asked questions

Monthly or weekly?

Monthly for a twelve-month view. Move to weekly for the next eight to thirteen weeks when runway is short or receipts are lumpy — at that horizon the day a payment lands starts to matter.

Where should the opening balance come from?

The bank, not the accounts. Use the actual cleared balance across every account on the day you build it, and note any cheques or transfers already in flight.

How accurate should I expect it to be?

The first two or three months should be close, because most of what happens in them is already committed. Months six to twelve are a structured argument about assumptions, not a prediction — and that is still the most useful thing you will have.

Keep reading

Or see what the Financial Agent can produce, and the example deliverables it has already produced.