A 13-week cash flow forecast is a rolling, week-by-week forecast of the cash coming in and going out over the next quarter, starting from the actual bank balance today. It's built from real items (open sales invoices and when they'll be paid, open purchase invoices and when you'll pay them, payroll, VAT, rent, loan repayments) plus expected sales that haven't been invoiced yet. Thirteen weeks because that's a quarter, which is far enough to see a problem coming and near enough to forecast with actual invoices rather than guesses.
It's the most useful single report a growing business can have, and it's usually built in a spreadsheet that one person updates on a Friday afternoon. This post gives you the template, the habits that keep it accurate, and then the version that updates itself.
What does a 13-week cash flow forecast look like?
Weeks across the top, starting with the current week. Cash movements down the side, grouped into receipts and payments. Opening balance at the top, closing balance at the bottom, and the closing balance of one week becomes the opening balance of the next.
| Row | What goes in it | Where it comes from |
|---|---|---|
| Opening cash | Bank balance at the start of the week (actual for week 1, previous closing thereafter) | Bank |
| Receipts: customer payments on invoiced sales | Open sales invoices, placed in the week you expect them to be paid | Sales ledger, adjusted for each customer's real paying habit |
| Receipts: sales not yet invoiced | Expected orders and their likely payment week | Pipeline, order book, seasonal pattern |
| Receipts: other | VAT refunds, grants, loan drawdowns, asset sales | Known events |
| Payments: suppliers | Open purchase invoices by due date, plus regular suppliers not yet invoiced | Purchase ledger, standing commitments |
| Payments: payroll | Net pay, PAYE and NI, pensions, on the dates they actually leave | Payroll calendar |
| Payments: VAT and corporation tax | Quarterly VAT, corporation tax instalments | Tax calendar |
| Payments: rent, loans, leases, subscriptions | Fixed dates, fixed amounts | Contracts |
| Payments: capex and one-offs | Anything planned that isn't routine | Decisions already made |
| Net movement | Receipts minus payments | Calculated |
| Closing cash | Opening plus net movement | Calculated |
| Headroom | Closing cash plus any undrawn facility | Calculated |
The headroom row is the one to watch. Closing cash can look fine while headroom is disappearing, and the week it crosses zero is the week you need to have known about ten weeks ago.
How do you keep a 13-week cash flow forecast accurate?
Accuracy comes from three habits more than from any formula.
Roll it every week. Week one drops off, a new week thirteen is added, and the opening balance is reset to the actual bank balance. A forecast that was built in January and "updated" in March isn't a forecast, it's a memory. Rolling weekly also gives you the best accuracy check there is: compare last week's forecast for this week against what actually happened, and see which lines you're consistently wrong on.
Use paying habits, not due dates. A customer whose terms are 30 days but who pays on day 52 goes in the week of day 52. The sales ledger will tell you the due date; your own history tells you the truth. This one change fixes most receipts forecasts.
Separate committed from expected. Invoiced sales and dated payments are committed; you're forecasting timing, not whether. Uninvoiced sales are expected; you're forecasting both. Keep them on different rows so the reader can see how much of the forecast is solid. A forecast that's 80% committed in week two and 30% committed in week twelve is normal, and showing that is more honest than a single total.
There's a fourth habit, which is the reason the spreadsheet version is hard to keep up: the inputs change daily. New invoices are raised, payments land, suppliers' due dates shift. By Thursday the Friday-afternoon version is out of date on both sides. Not badly, but enough that people start to treat it as a rough guide, and once that happens it stops driving decisions.
How do you build a cash flow forecast that updates itself?
Take the rows in the table above and notice how many of them are already sitting in a system. Open sales invoices are in the sales ledger. Open purchase invoices are in the purchase ledger. Payroll dates are in the payroll calendar. The bank balance is in the bank. The only rows that genuinely need a human are the expected (uninvoiced) sales, the one-off payments, and the judgement about which customers pay late.
So the automated version is a data model that reads the ledgers and the bank every night, places every open item in its expected week using each customer's and supplier's actual paying history, adds the fixed calendar of payroll, tax and rent, and leaves a small table for the human inputs: expected sales by week, one-off payments, and overrides where you know something the ledger doesn't ("they've promised to pay on the 20th").
In Power BI, that's a model with a calendar of weeks, a receipts table built from open invoices and a payment-timing rule per customer, a payments table built the same way from the purchase ledger and the fixed commitments, and the human inputs read from a small spreadsheet or a form. The report is the 13-week grid, with a committed/expected split, a headroom line, and a page showing last week's forecast against actual so the timing rules can be tuned.
What that gives you:
- The forecast is current on Monday morning without anyone touching it over the weekend, because the ledger and bank refreshed overnight.
- The human inputs are five minutes, not five hours. Someone updates expected sales and one-offs when they change, rather than re-keying the whole thing.
- Accuracy improves on its own. The forecast-versus-actual page shows which customers' timing rules are wrong, and fixing a rule fixes every future week.
- It's shareable. The FD, the MD and the bank can all look at the same grid. Microsoft's published UK price for Power BI Pro is £10.80 per user per month as of September 2026, paid yearly.
If your ledger is Xero, Sage, QuickBooks or Business Central, the connection is a known route. What takes the time is the modelling: the paying-habit rules, the calendar, the reconciliation to the bank so the opening balance is always true. It's a well-shaped piece of work for a fixed price, and it's one of the more common things I build inside a Reporting Sprint, usually alongside the management accounts pages that use the same ledger data.
What should you do with the forecast once you have it?
Read it once a week, in the same meeting, and look at three things: the lowest headroom in the thirteen weeks and which week it falls in; the lines that moved since last week and why; and whether this week's actual matched last week's forecast. That's a fifteen-minute conversation, and it's the conversation that prevents the emergency overdraft call.
Then use it to make the decisions it exists for. When to chase which customer. Whether the capex can go ahead this month or next. Whether the new hire starts in week six or week ten. Whether to take the early-payment discount a supplier is offering. Every one of those is a cash-timing question, and the forecast is the only document that answers it.
Common questions
What is a 13-week cash flow forecast?
A 13-week cash flow forecast is a rolling, weekly projection of cash receipts and payments over the next quarter, starting from today's actual bank balance. It's built from open invoices, known payment dates and expected sales, and it's rolled forward each week so the horizon always stays thirteen weeks out. It answers the question "will we have enough cash, and when might we not?".
Why 13 weeks rather than 12 months?
Thirteen weeks is a quarter. It's far enough ahead to see a shortfall coming and do something about it, and near enough that most of the forecast can be built from actual invoices rather than estimates, which makes it accurate. A 12-month forecast is useful for planning but is mostly assumptions; the 13-week view is mostly facts.
What is the difference between a cash flow forecast and a P&L forecast?
A P&L forecast shows income and costs when they're earned or incurred. A cash flow forecast shows money when it actually moves. A profitable business can run out of cash if customers pay slowly and suppliers are paid fast, which is exactly what the cash flow forecast shows and the P&L hides. Both matter; the cash forecast is the one that keeps the lights on.
Is there a 13-week cash flow forecast template?
The table in this post is the template: weeks across the top, opening cash, receipts split into invoiced and expected, payments grouped by type, net movement, closing cash and headroom. Built in a spreadsheet it works well; the limitation is keeping it updated, which is why the automated version reads the ledgers directly and leaves only the expected sales and one-offs for a person to enter.
Can a cash flow forecast be automated?
Largely, yes. Open sales and purchase invoices, the bank balance, payroll and tax dates are all in systems and can be read automatically, and each customer's real paying habit can be calculated from history. The parts that still need a person are expected sales that haven't been invoiced, one-off payments, and any known exception. A Power BI model does the first part overnight and gives the second part a five-minute input.
How accurate should a 13-week cash flow forecast be?
Very accurate in the first two or three weeks, where nearly everything is a committed item with a known amount, and progressively less certain further out, where more of the forecast is expected sales. The useful measure is to compare each week's forecast with what actually happened and track the gap by line; if the receipts line is consistently optimistic, the customer timing rules need adjusting.
What accounting systems can feed an automated cash flow forecast?
Any system that can expose its sales ledger, purchase ledger and bank feed. Xero, Sage 50, Sage 200, Sage Intacct, QuickBooks and Business Central all have routes into Power BI. The forecast model is the same regardless of the source; only the connection changes.