Every finance team has a cash forecast, and most of them are a workbook that one person rebuilds on Friday afternoon. It is accurate when they finish and wrong by Tuesday.

The problem is not the modeling. Most controllers model cash perfectly well. The problem is the input: the forecast is fed by hand, from data that was already stale when it was copied.

A forecast that reads live operations data is a different object. It is less precise in places, because it does not let you smooth over an awkward assumption, and considerably more useful, because it moves when the business does.

What a forecast is actually made of

Strip away the presentation and a cash forecast is four things: the balance you start with, the money you expect in, the money you have committed out, and the timing of both. Everything else is formatting.

Three of those four already exist in your operations queues. The starting balance is in the bank. The committed outflow is your approved but unpaid invoices plus recurring payments. The expected inflow is your open receivables with a date attached. Only the timing involves judgment, and that judgment is the part worth your attention.

Where the workbook actually breaks

Not in the formulas. In the gap between the sheet and the queue. An invoice gets approved on Wednesday, the sheet was built on Friday, and nobody updates the sheet because updating it means redoing the week.

So the forecast slowly describes a company that no longer exists. It still opens, it still calculates, and it still gets presented. That is what makes it expensive: nothing about it looks broken.

Connect the queues instead of exporting them

The fix is to stop treating the forecast as a document. If approved payables feed the outflow line directly, and open receivables feed the inflow line with their expected collect dates, the forecast updates when the work updates.

This also changes who can touch it. A hand-built model has one author, and it is unusable when they are out. A forecast built from shared queues can be read by anyone who understands the queues, which is the whole finance team.

Make the assumptions visible

Every forecast rests on assumptions, and the dangerous ones are the assumptions nobody wrote down. Days to collect, whether vendor terms are honored, which recurring payments are genuinely fixed, what happens to a held invoice.

Put each assumption next to the number it drives, with the source it came from. An assumption you can see is an assumption someone can argue with, and arguing about assumptions is the useful part of a forecast review.

Model two or three scenarios, not twelve

Scenario analysis goes wrong when it becomes a matrix. Pick the handful that reflect real decisions you might make or real risks you actually face.

• Base case, using the collect dates you genuinely expect.
• Slow collections, where your largest customers move out by two or three weeks.
• Delayed payment run, where you push one batch and see what it buys.
• A large one-off, if you have a known capital purchase or a tax payment coming.

Each scenario should differ by one lever so you can attribute the change. If two things move at once, you learn nothing except that the number got worse.

Forecast the decision, not the year

Twelve-month cash projections are useful for a board conversation and nearly useless for running a week. Most of the decisions a controller makes live inside six to twelve weeks: release this batch or hold it, chase this customer or wait, take the discount or keep the cash.

Build the near horizon in detail and the far horizon roughly. A precise number for week forty is false precision, and it costs you attention you should be spending on week three.

The mistakes that show up most

Four errors account for most bad cash forecasts, and none of them are arithmetic.

Treating invoice terms as collection dates is the first and the most common. Terms are what you agreed. Collection dates are what happens. Using the first in a cash model builds optimism directly into the structure, where it is hard to see and impossible to argue with.

Forgetting the irregular outflows is the second. Quarterly tax, annual insurance, the bonus accrual that becomes real in March. They are predictable and they are routinely missing, because they do not appear in the payables queue until the month they are due.

Modeling the average is the third. Average weekly outflow is a useful statistic and a poor forecast, because cash problems happen in specific weeks, not average ones. Two large payments landing together is exactly the event an average hides.

Rebuilding rather than adjusting is the fourth. When a forecast is rebuilt from scratch each month, no assumption is ever tested, because the previous version is gone. You lose the only feedback loop the model had.

How often to rebuild, and how often to look

Those are different questions. The structure of the model should change rarely, ideally a few times a year when something real changes about the business. The numbers inside it should update continuously, which is the argument for connecting queues rather than exporting them.

Look weekly at the near horizon and monthly at the rest. Weekly keeps the decisions small. Monthly is where you compare, adjust assumptions, and notice that the pattern you have been correcting for three months in a row is not noise.

Check yourself against what happened

The habit that improves a forecast fastest is also the least popular: go back and compare. Each month, look at what you expected to collect and what actually landed, then adjust the assumption rather than the spreadsheet.

Most teams discover their days-to-collect assumption is optimistic by a week or more, and that single correction does more for forecast quality than any amount of additional modeling.

Where Control fits

Control builds the forecast from the same AP and AR records your team already works. Approved payables become the outflow line, open receivables with expected dates become the inflow line, and the assumptions sit next to the numbers they drive so a reviewer can see what the model believes.

Capvolta is not a bank and does not lend, and Control does not replace your ledger. It removes the copying step between the queue and the model, which is the step where the forecast quietly stopped being true.