Cashflow forecasting: the receivables lag problem

A sale recorded this month and the cash from that sale actually landing in the bank this month are two different events — and a simple forecast can accidentally treat them as one, counting revenue as cash the moment it's invoiced or booked rather than the moment it's genuinely collected. For any business extending payment terms — a b2b invoice due in 30 or 45 days, a client who pays late even against agreed terms, a retailer settling with a marketplace on its own schedule — this gap isn't a rounding error. It's the entire difference between a forecast that's actually useful and one that's dangerously wrong at precisely the moment it matters most.

The mistake is easy to make because it requires no error in the arithmetic — the multiplication is fine, the growth assumption might even be conservative. The problem is a missing line entirely: nowhere in the model is there a delay between a sale happening and the cash from it becoming spendable.

A forecast that ignores the receivables lag can show a healthy, growing closing cash balance every single month on paper, while the actual bank balance sits thin or negative — because the model is crediting cash for revenue that hasn't actually arrived yet. The owner reading that forecast has no reason to worry; the numbers say everything is fine, month after month, right up until a real payroll date or a real supplier payment lands on a day the bank account doesn't actually hold what the spreadsheet promised it would.

This is what makes the mistake genuinely dangerous rather than just imprecise — it doesn't produce a forecast that's obviously wrong in a way anyone would double-check. It produces a forecast that looks reassuring, confirms the plan is working, and gives no warning before the gap between what it shows and what the bank actually holds becomes a real, unavoidable problem.

A forecast that takes the receivables lag seriously needs one more explicit assumption beyond the usual revenue, cost and growth figures: a days-sales-outstanding number — on average, how long after a sale is booked does the cash from it actually land in the bank. With that single figure added, revenue earned in a given month gets spread across the weeks it's actually collected rather than counted as immediately available, and the resulting cash line reflects when money is genuinely spendable, not when it was merely promised.

This changes the shape of the forecast meaningfully — a business growing revenue quickly while extending generous payment terms can show strong revenue growth and a cash position that's tightening at the same time, which a model without the lag built in would never surface, because it would be crediting that growing revenue as cash the moment it was booked.

It might seem more realistic for a tool to default this figure to a typical industry benchmark — 30 days, 45 days — rather than leave it at zero, on the reasoning that most businesses do experience some delay. But a benchmark pulled from nowhere specific to this business is an invented number sitting in exactly the line an owner reads to decide whether payroll clears — and defaulting to zero, meaning money is counted as arriving the month it's earned, keeps the model's actual assumption visible rather than quietly optimistic.

Zero is obviously a placeholder nobody would mistake for real research; a plausible-looking 30 days hides the fact that nobody actually measured this business's real collection pattern. The responsible fix is for the business to supply its own real number, pulled from its own invoice and payment history — not for a tool to guess a comfortable-sounding one on its behalf and let that guess quietly drive a real financial decision.

A cash forecast typically rests on five or six assumptions, and they don't all matter equally to the final outcome — moving the payment-delay assumption might swing the ending cash balance far more sharply than moving the fixed-cost line does, or the reverse could be true, depending entirely on this specific business's own numbers. Guessing which assumption is 'probably the important one' based on a hunch is a different exercise from actually measuring it.

Ranking each assumption by how much it genuinely moves the final answer when nudged up and down by a stated, consistent percentage — rather than by which one instinctively feels riskiest — is what turns a single forecast number into an actual map of where the real risk in the plan is concentrated, and which assumption is worth double-checking most carefully before trusting the plan built on top of it.

Once a month closes, what actually happened — revenue collected, costs actually paid, cash genuinely on hand — is a different kind of fact from what was projected at the start of that month, and the two need to stay separate rather than blending into each other. An actual belongs in the forecast only as a measured record pulled from the business's own books — the bank statement, the till, the invoice ledger — compared against the original projection as a variance, never quietly folded back into the plan as if it had been the plan all along.

A forecast that rewrites itself to match what actually happened stops being a forecast in any meaningful sense — it becomes a record that can never be shown to have been wrong, which defeats the entire point of having projected anything in the first place. Keeping the two separate is what makes a variance between them worth learning from the next time a projection gets built. The full mechanics of how this separation is enforced, along with the receivables-lag default and the sensitivity ranking, are documented at /docs/yukti.