--- title: "Why your 13-week cash forecast keeps missing" url: "https://obserbi.com/blog/why-13-week-cash-forecast-misses" description: "Most 13-week cash forecasts are built from due dates and AR ageing, but cash moves on payment behaviour. Where the gap comes from, and a test to run this week." --- # Why your 13-week cash forecast keeps missing October 8, 2026·4 min read·Editorial team A brass barometer with a plain dial standing beside stacks of brass coins and an open pocket watch, lit by amber light against black Picture a Monday in week six of the quarter. The 13-week cash forecast that went to the bank in week one said the overdraft would peak at roughly half the facility. It is now heading for the limit, and nothing dramatic has happened: no customer went bust, no large order was lost. Three mid-sized customers paid twelve days after their terms, a supplier moved its payment run, and the VAT payment landed in the same week as payroll. Each of those was known somewhere in the company. None of them was in the forecast. The 13-week cash forecast is the one forecast a lender actually reads, and in many mid-market companies it is the least modelled number in the finance function — a spreadsheet rolled forward by hand every Friday, fed by an export from the ERP’s receivables and payables ledgers. ## The real cause: due dates are not cash The ERP knows when an invoice is due. It does not know when it will be paid. Almost every 13-week model starts from the due-date view anyway, because that is what the ageing report exports, and then corrects it with a percentage haircut someone set two years ago. Cash moves on behaviour. A customer on 30-day terms who has paid on day 44 for the last eight invoices will pay on day 44 again, whatever the ledger says. Your own outflows follow your payment-run calendar and your treasury’s habits, not the due dates on supplier invoices. So the forecast is wrong in a structured, predictable way — which is the good news, because a structured error can be modelled. ## Where 13-week forecasts break **Receipts forecast from terms, not from history.** The ageing report assumes everyone pays on time; the haircut assumes everyone is equally late. Both are wrong customer by customer, and the error concentrates in exactly the customers large enough to matter. **One haircut for the whole ledger.** A flat slippage percentage hides the shift that matters: one large customer drifting from day 35 to day 50 over a quarter. Averaged into the book, that drift is invisible until the week it lands. **Outflows on invoice due dates.** Most companies pay in runs — weekly, fortnightly, or ad hoc when cash is tight. Forecasting payables on due dates moves cash between weeks, and from the bank’s point of view the weeks are the whole point. **Fixed-date items kept off-model.** Payroll, social security, VAT and corporate tax advances fall on statutory dates and are often typed in by hand. Hand-typed lines are the first to go stale when a rate or a headcount changes. **No memory of its own error.** Most teams overwrite last week’s forecast with this week’s. Without each version kept, nobody can say whether the model is consistently optimistic, or in which weeks. ## What to do instead Start from the same ERP data, used differently. - **Forecast receipts per customer from payment behaviour.** For every customer that matters, compute days-to-pay over recent invoices — the median and the spread, not just the average — and place each open invoice on the date its history predicts. Customers without history get their terms plus a conservative default. - **Watch the drift, not just the level.** A customer whose days-to-pay rises invoice after invoice is an early warning in its own right, usually well before the first credit-control call. It is the first-loop behaviour described in [the article on continuous close](https://obserbi.com/blog/continuous-close-second-order-control): a deviation surfaced on the day it appears, not at quarter-end. - **Put outflows on your payment-run calendar.** Model when you actually pay, not when you owe. If the payment run moves, the forecast moves with it. - **Make fixed-date items rules, not cells.** Payroll from the HR system, taxes and social security from their bases, each on its statutory date. - **Keep every version and score it.** Store each week’s forecast. Thirteen weeks later, compare it with what happened, week by week. The shape of the error — its direction, its size, the weeks it clusters in — shows where the model is biased. None of this needs a large model. It needs read access to receivables, payables, bank statements and payroll, and the discipline to keep history. AI earns its place in the part people skip: re-estimating payment behaviour for hundreds of customers every night, and saying in plain language which three changes moved the forecast since Friday. Outside signal helps too. A customer whose own market is in trouble, as described in [OSINT for CFOs](https://obserbi.com/blog/osint-for-cfos), usually starts paying later before anyone tells you why. ## A test you can run this week You need one export: paid invoices for the last twelve months, with invoice date, due date and payment date. 1. For your twenty largest customers by receipts, compute the median number of days between due date and payment. 2. Count how many have a median more than five days late, and note the largest. 3. Take the forecast you sent out six weeks ago and find the receipts it expected from those same customers. Compare them with what actually arrived in each week since. If the late-paying customers explain most of the gap, your forecast is not unlucky — it is built on the wrong date. That is a modelling choice, and a fixable one. Re-making it every night, on your own hardware, before the bank asks, is the kind of work [ObserBI](https://obserbi.com/) is being built to do. - cash forecasting - 13-week cash flow - receivables - treasury ## Keep reading - [Where to run the finance model so the data stays home](https://obserbi.com/blog/where-to-run-the-finance-model) - [The board asks: can we afford it? The answer should already exist](https://obserbi.com/blog/can-we-afford-it-answer-should-already-exist)