Cash Flow Forecasting Without a Data Team

A thirteen-week cash flow forecast is a rolling weekly projection of receipts and payments over the next quarter. It is the operational standard because it is long enough that you can still act on what it tells you, and short enough that most of the flows inside it are already knowable rather than estimated. You can build one from an AR aging report, an AP listing, a payroll schedule, and a list of recurring commitments, no warehouse required.

Why thirteen weeks, and why weekly

Monthly cash forecasts hide the problem they exist to surface. A month that ends with a healthy balance can contain a week where payroll and a quarterly tax payment land three days before a large collection arrives. At monthly granularity that week is invisible; at weekly granularity it is the whole point.

Thirteen weeks is a quarter. Far enough ahead to change a decision (delay a hire, accelerate collections, draw on a facility) and near enough that the majority of receipts and payments are already contracted rather than forecast.

Build it from cash, never from the P&L

The most common structural error is deriving the cash forecast from the profit forecast. The two diverge for reasons that have nothing to do with performance:

• Depreciation and amortisation reduce profit without moving cash.
• Deferred revenue takes cash long before it appears as revenue.
• Accrued bonuses hit the P&L months before they are paid.
• Capital expenditure consumes cash without touching the P&L at all in the period it is spent.
• Working capital growth consumes cash in a profitable, growing business, which is exactly how growing companies run out of money.

Forecast the actual movements: money in, money out, week by week.

The four inputs

1. Collections, forecast from behaviour rather than terms

This is where most forecast error lives, and it has a specific cause: teams forecast collections from stated payment terms rather than from what customers actually do.

A customer on net-30 who has paid at day 52 for the last eight invoices will pay at roughly day 52 again. Forecasting them at day 30 puts three weeks of cash in the wrong place, every single month.

Build a simple payment-behaviour profile per significant customer: the median days from invoice to payment over the last six to twelve invoices. Use the median rather than the mean so one disputed invoice does not distort it. For the long tail of small customers, a blended average is fine.

Then apply that profile to your open AR to place each invoice in the week it will most likely land.

2. Payments, which are mostly known

Payables are easier because you control the timing. Take your open AP, place each invoice in the week you intend to pay it, and add the recurring items that never appear on an AP listing until they are due:

• Payroll, including the months with an extra pay period
• Payroll taxes and any quarterly filings
• Rent and lease payments
• Insurance renewals
• Annual software renewals: these cluster, and the cluster is usually invisible until it arrives
• Debt service and any covenant-driven payments

The annual and quarterly items are the ones that break otherwise-good forecasts. Build a calendar of them once and it stops being a recurring surprise.

3. New business, forecast conservatively

Revenue not yet contracted should enter the forecast weighted, and it should enter late. A deal expected to close in week four does not produce cash in week four: it produces an invoice, which produces cash once the customer's own payables cycle runs. For a new customer, assume the slower end of your collection profile.

4. The opening balance, net of what you cannot use

Start from cash you can actually access. Exclude restricted balances, customer deposits held in trust, and cash sitting in an entity you cannot easily move funds out of. Track undrawn credit separately rather than adding it to the balance: it is optionality, and facilities can be reduced exactly when conditions deteriorate.

The weekly rhythm

The forecast is only useful if it is rebuilt weekly and back-tested. A forecast nobody compares against actuals never improves.

1. Roll forward. Drop the week that closed, add a new week thirteen.
2. Compare. Last week's forecast against what actually happened, line by line.
3. Explain the variance. Which customer paid late, which payment moved, what was missed entirely.
4. Update the profiles. If a customer's behaviour has shifted, change their profile rather than treating each miss as a one-off.
5. Re-forecast. Rebuild the remaining twelve weeks with current information.

Step three is what turns the forecast into a management tool. The variance explanation is often more useful than the forecast itself, because it tells you which customers are drifting before it shows up in the aging report.

What good accuracy looks like

Expect roughly 5% accuracy at the total level in the first four weeks, widening after that. Near-term accuracy is largely a data-quality question, since those flows are mostly known. Further out it depends on collections behaviour and new sales, and no process makes those precise.

Measure accuracy weekly and by line rather than only in total. Offsetting errors, a collection that came early and a payment that went out late, can produce an excellent total from a forecast that was wrong twice.

The scenarios worth running

A single forecast line is a false precision. Run three:

• Base. Payment behaviour continues as profiled.
• Downside. Collections slip by ten to fifteen days across the board, and the two largest expected deals do not close. This is the scenario that identifies the week you would first have a problem.
• Stress. Your largest customer stops paying entirely. Not because it is likely, but because knowing the answer changes how you think about concentration.

What matters from these is not the closing balance. It is the decision date: the point at which you would have to act, working backwards from the week cash gets tight.

When to stop doing it by hand

Built manually, this is two to four hours a week, forever. It is genuinely worth doing at that price, because the alternative is not knowing.

But the cost is permanent and the work is the same work every week: export AR, export AP, reconcile against the ledger, apply the payment profiles, roll the model forward, compare against last week. That is assembly, not analysis, and it is the part that does not require judgement.

The point at which automating becomes obviously cheaper is when the person doing it is senior enough that four hours a week is displacing work only they can do, which in most mid-market finance teams is immediately.

Where a 13-week forecast actually drifts

Forecasts do not usually fail because the model is wrong. They fail in four specific places, and each has a fix that does not require a warehouse:

Drift source	What it looks like	Fix
Collections timing	Cash arrives a week later than terms imply, every month	Forecast from your actual average days-to-pay by customer, not from stated terms
Payroll timing	A month with three pay runs breaks the pattern	Calendar-driven, never averaged
One-offs	Tax, insurance renewals, annual software	A named list, reviewed quarterly
Optimism	Pipeline treated as cash	Forecast committed revenue only; keep pipeline in a separate scenario

The fourth is the one that does real damage, because it is the only one nobody notices until the cash does not arrive.

Forecast versus actual: the step most teams skip

A forecast you never check against reality is a projection, not a forecast. Every week, record what you predicted for that week alongside what happened, and keep the history.

Within two months this tells you something no model can: your own systematic bias. Most finance teams discover they are consistently optimistic on collections by a stable margin. Once you know the margin, you can correct for it, and a forecast with a known, measured bias is far more useful than one with an unknown one.

When automating starts to pay

Manual is genuinely fine up to a point. Automation earns its place when one of these becomes true:

• The forecast takes more than half a day a week to refresh.
• It is stale by the time anyone reads it.
• More than two people touch it and their versions diverge.
• You need scenarios on demand rather than once a quarter.
• Somebody outside finance (a lender, a board, an acquirer) needs to trust it.

Below that threshold a well-built spreadsheet is the correct tool and buying software is a distraction.

The scenarios worth keeping standing

Three, permanently, not built fresh each time somebody asks:

1. Base. Committed revenue, known costs, your measured collections bias applied.
2. Downside. Largest customer pays 30 days late, or does not pay. Renewals slip a quarter. This is the one lenders ask for and the one that changes decisions.
3. Investment. The two or three hires and the spend increase you are actually considering, so the question "can we afford this" has an answer before it is asked in a meeting.

Keeping them standing rather than building them on request is the difference between a forecast that informs decisions and one that documents them afterwards.

The habit that matters most

Of everything above, one practice separates forecasts that get trusted from forecasts that get ignored: recording what you predicted alongside what happened, every week, and keeping the history.

It costs about five minutes and within two months it gives you your own measured bias, which is more valuable than any modelling improvement, because it is specific to your business and no template can supply it.