How to tell whether a cash forecast will bear weight

The question a client asks is “can I hire in October.” The question the adviser has to answer first is different: will this forecast bear the weight of that decision.

Those are not the same question, and the difference is where a great deal of advisory risk lives. Accuracy is a property of the forecast. Whether it can be leaned on is a relationship between the forecast and the size of the decision resting on it. A rough forecast may support a small, reversible spending decision and still be dangerous for taking on two permanent salaries. The same numbers, the same freshness, and a different answer about whether they will hold.

This guide is about how to find that out before the client acts, rather than after.

The short answer

A forecast bears weight when three things are true. The obligations that matter do not each depend on a single event landing on time. The assumptions layered onto the recorded facts are visible, dated and separate from the baseline, so the client can see what is known and what is expected. And the forecast has a track record: its earlier predictions have been scored against outcomes, so the adviser knows how far off it tends to run and in which direction.

Most advisory forecasts can be checked against the first two today, with effort. The third requires preserved forecast history; when a workflow overwrites earlier versions, that track record cannot be computed. Until it exists, the honest position is that the forecast supports small, reversible decisions and its support for large ones is unmeasured.

This guide draws on qualitative design-partner conversations with CPA and fractional CFO practices. Tool behaviour is described generically; we did not audit any specific product.

Why “is it accurate” is the wrong first question

Forecasting vendors like to say their forecasts are accurate. It is hard to say what that means, because accuracy without a decision attached has no scale. Accurate to within a week? A week is nothing for a quarterly planning conversation and everything for a payroll that clears on the twentieth.

So the practitioner’s question has to be anchored to the decision. What is the client about to do, when does it commit them, and what would have to be true for that to be safe. Framed that way, a forecast is not accurate or inaccurate. It is load bearing for this decision, or it is not, and the adviser’s job is to know which before the client finds out.

There are three tests that get you there. They are ordered the way an adviser would actually run them, and each one leans on the one before.

Test one: which obligations rest on a single event

Start with what cannot slip. Every business has a short list of obligations that must be met on the date: payroll, rent, the tax payment, the one vendor bill large enough to matter, the loan payment. Usually five or six. They are the moments the client actually worries about, and they are the only moments the forecast has to be right.

For each of those, look at the window before it and ask a single question. What has to arrive for this to be covered, and which one item, if it slipped by its own typical delay, would break it.

That last phrase matters. Not “if it slipped a week.” If it slipped the way this counterparty actually slips. A customer that has paid thirty days late all year is not a seven-day risk, and testing them at seven days produces a comforting answer that is not true.

The result is a small, finite list with names on it. Payroll on the twentieth depends on two invoices, one of which is a customer with a long record of paying late. Rent is covered regardless. The tax payment in April depends on nothing that could move. That is a different kind of information from an aging list. It tells the adviser which four or five events in the next six weeks are the ones worth watching, and lets them ignore the rest.

Two things are worth noticing about running the test obligation-first. Concentration is not one number for the client. A business can be comfortably diversified in March and hanging on one customer for the twentieth of April, and only the obligation-by-obligation view shows it. And the list is bounded. Starting from inflows produces a long tail of customers to judge; starting from obligations produces five questions, each with an answer.

How practitioners do this today is mostly by eye. They know the client’s cash is really two customers, and they keep it in their head. For the client they see monthly it works. Across a portfolio it is exactly the knowledge that goes missing on the client nobody has looked at in six weeks.

Test two: what the assumptions add to the baseline

A forecast is built from two kinds of material, and the second test is about keeping them apart.

The first kind is what the books and the bank can see: invoices issued, bills received, recurring payments with a stable pattern. That is the baseline. It contains recorded activity rather than forward-looking assumptions. It still needs an as-of date, the latest reconciliation date, and visibility into anything not yet categorised, because unreconciled books and lagging bank categorisation make the baseline stale in its own way.

The second kind is what the client and the firm know that the books do not: the customer who has promised a wire next week, the hire being considered for October, the contract expected to renew. These are assumptions, and they are the material that makes the forecast useful beyond the next few weeks. They are also the material that ages.

The mistake most workflows make is merging the two. The assumption is typed into the model and the model is now a single picture in which recorded facts and expectations are indistinguishable. When the outcome arrives, nobody can tell whether the forecast was right because the facts were right or because a guess happened to land. And there is no way to ask, three weeks later, which parts of the picture were confirmed on the last call and which have been sitting untouched since February.

The better practice is one baseline and one overlay. The baseline holds the recorded facts and is never edited by hand. Every assumption sits in the overlay, with a source, a date it was entered, and a date it was last confirmed. The overlay is what the client and adviser discuss; the baseline is what they discuss it against. As assumptions resolve or are withdrawn, the overlay moves and the baseline stays where the evidence put it.

This does three things at once. It makes each assumption an individually visible claim that can be aged and, later, scored. It shows the client the gap between what is known and what is expected, which is often the most useful thing on the call. And it makes the age test possible. Staleness stops being a single property of the whole forecast and becomes two separate questions: how current the recorded activity is, and how old each assumption in the overlay is. The as-of date, reconciliation status and visibility into uncategorised activity answer the first. An expectation entered five weeks ago about a payment due next week is old whatever the rebuild timestamp says.

The overlay also answers the client’s what-if without building a second model. “Can I hire two people in week five” is a proposed obligation that is not in the books yet. It goes into the overlay marked as a proposal rather than an expectation, the forecast reshapes, and the adviser reads the answer against the obligations from test one. When the client decides, the proposal either becomes an expectation, which will be tracked, or is removed. The same overlay handles a stress test: take an existing expectation, move it by its counterparty’s own historical delay rather than a round ten percent, and see whether the twentieth still holds. One overlay, three uses. What is expected, what is proposed, and what happens if the expectation is wrong.

How practitioners do this today is on the call. The good ones walk the large items and ask “is this still right.” That is the age test performed verbally, and it works. What is missing is the stamp. The answer does not attach itself to the assumption, so the next person to open the forecast cannot tell what was confirmed and what was assumed.

Test three: what the track record says

The first two tests can be run by hand on any forecast. The third is the one that gives them meaning, and it requires something the first two do not: preserved forecast history.

Test one asked what happens if a customer slips by its typical delay. Test two asked whether to stress an assumption by its historical error. Both of those phrases assume something: that the forecast’s past predictions have been compared with what actually happened, and that the results were kept. Without that record, “typical delay” is the adviser’s memory and “historical error” is a guess. The tests still run, but on assumptions about how wrong the forecast might be, which is a strange foundation for telling a client it will hold.

Scoring a forecast properly has been covered in the previous guide. The short version: preserve the forecast as it stood on the date, score timing and amount separately, keep the counterparty and any override, and feed the outcome forward without erasing the record. Here the question is what to do with the scores once they exist.

Per item, they make the model better. Each resolved expectation yields a timing error and an amount error tied to a counterparty, and that is what a behaviour profile is built from. This is machinery, mostly not shown to the client.

In aggregate, they make the forecast trustworthy, and the aggregate has to be computed carefully or it flatters. If one receivable is a week early and another a week late, averaging the errors reports zero while both were wrong. So the useful measures are two: mean absolute error, which says how noisy the forecast is, and the signed mean, which says which way it leans. Both should be weighted by amount, because a three-day miss on a hundred thousand dollars and a three-day miss on eight hundred are not the same event. And timing and amount should stay separate all the way up. They mean different things and they get corrected differently.

If a firm shows a client one line, it should combine direction and magnitude for collections over a rolling window. “Collections have run six days optimistic over the last two quarters, with a typical absolute timing miss of nine days.” Direction alone is not enough; a forecast can have zero average bias and still miss every payment badly. That sentence is worth more than any accuracy percentage, because the client can act on it. They know which way to lean, and how wide the band is.

It also does something for the adviser that accuracy claims cannot. It converts the previous guide’s asymmetry into a measurement. A forecast that runs optimistic will produce visible cash stress; one that runs pessimistic will suppress hiring quietly. Knowing which way this forecast tends is the difference between correcting for it and being surprised by it every quarter.

When to say the picture will not hold

The three tests produce an answer, and sometimes the answer is that the forecast does not support the decision the client wants to make. That conversation is the hardest part of advisory work and the part vendors never write about, because it sounds like the adviser failing.

It is not. A forecast that cannot yet bear a large decision is a finding, not a fault, and the honest way to deliver it is as a finding: here is what the decision depends on, here is what we know about how those items behave, and here is what would have to be true for the answer to be yes.

“The hire is safe if the two largest customers pay on their usual schedule. One of them has run a month late all year. If you make the hire, I would set the start date after their invoice clears, or chase it now rather than in three weeks.”

That is not a refusal. It is the forecast doing its job, which is to name the conditions the client is actually betting on. The client who hears it makes the hire with their eyes open, or delays it for a reason they can articulate, and either way they are acting on something that will bear their weight.

The alternative, a single number delivered as if it were certain, is what the previous two guides were about. A forecast built from recorded facts alone does not know what the client said last week. A forecast that is never scored does not know how wrong it tends to be. And a forecast that cannot say what it rests on cannot tell a client whether to lean on it. The three tests are how an adviser closes that gap by hand, until the tooling closes it for them.

Where AgentLink fits

AgentLink holds assumptions in an overlay on the baseline forecast rather than merging them into it. Each assumption carries its source, the date it was entered and its confidence, and when it comes due the firm is prompted to confirm whether it still holds. Verified outcomes update per-counterparty behaviour profiles, which is what “its own typical delay” means in test one. When an adviser enters an expectation that departs from a counterparty’s record, the entry is accepted and the disagreement is recorded alongside it.

Reading the tests, deciding what they mean for this client, and having the conversation about whether the picture will hold remains the firm’s judgement.

Frequently asked questions

Isn’t this just scenario planning?

Scenario planning usually means building two or three alternative versions of the whole forecast. The tests here are narrower and cheaper. They ask which specific obligations depend on which specific events, and they stress those events by their own history rather than by a blanket percentage. Most of the value comes from the specificity.

We rebuild the forecast every night. Doesn’t that make it current?

It makes the recorded activity current, provided the books are reconciled and categorised behind it. The assumptions are as old as the day someone last confirmed them, and a nightly rebuild does not touch them. That is why the second test separates the two: so that freshness of data and age of assumptions can be seen apart.

We don’t have a scored history. Can we still run the first two tests?

Yes, with the adviser’s knowledge of each counterparty standing in for the record. It is less precise, and it is the thing to be honest about. “Typical delay” based on memory is a reasonable starting point and a poor final one. The third test is what turns it into a measurement.

Won’t clients find “the forecast doesn’t support this yet” frustrating?

Less than they find a confident yes that turns out to have been conditional. The framing matters: name what the decision depends on and what would make it safe. That is advice they can act on. A single number is not.

About the author

Nilanjan Raychaudhuri is the founder of AgentLink (Tublian LLC, Columbus, Ohio), which builds controller-layer software sold through CPA and fractional CFO firms. He has spent the past year interviewing practitioners at fractional CPA and CFO practices about how advisory work is actually delivered. Team page

The practitioner observations in this guide come from design-partner conversations and are used with permission where attributed. Tool behaviour is described generically and as practitioners experienced it; we did not audit any specific product. Corrections to nilanjan@agentlink.finance.