Comparing the Forecast Against What Actually Happened

The first real week of this forecast missed by roughly 16 times! not adjusting the numbers, but tracking each transaction until the true cause was identified.

The first real test

A forecast is not only tested by how it looks. It can look solid — clean formulas, reasonable-sounding numbers, no typos — but that doesn't tell you if it's actually good. A forecast is tested by comparing it to what actually happened.

A gap this size means small mistakes are not the cause. Wrong dates or slightly wrong amounts explain a gap of maybe 20 to 30 percent, not a gap of 16 times. A gap this large means something much bigger: most of the cash that came in was never in the source data used to build the forecast, in any form.

Finding the real cause

The next step was not guessing how to fix the situation. It was to go through every single transaction that made up that week's actual cash, one at a time, and sort each one into a category based on what actually happened.

Once every transaction from that week was sorted this way, one category was clearly larger than the rest:

One category explained almost everything

The week ending 7 Jun 2026 was the sharpest miss in the table above - about €754,000 actual against a forecast of only €600. Eleven separate payments made up that week's actual total. Only two of them matched orders already known before the forecast was built, arriving a little earlier than expected. The other nine — including the largest single payment of the eleven, €478,181 — were new. None of the nine existed in any form when the forecast was made.

The pattern behind those nine was the same each time: a customer sends an email, a sales manager replies, an order gets created, an invoice gets sent, the customer pays. All of this can happen within days. None of it existed yet when the forecast was built. The conversation, the order, and the payment all happened afterward, within days. There was nothing to see in advance, because nothing had happened yet.

The largest of the nine payments required more investigation. The payment reference included a proforma invoice number. This situation is different from a payment that contains no useful reference at all. After further checking, I found that the related sales order had been created four days before the payment was received. However, both the sales order and the payment were created after the cash flow forecast had already been prepared. They did not exist when the forecast was built, so there was no information available that could have been used to predict this receipt.

Once I confirmed this, the picture for the whole week became clear. Orders that did not exist yet when the forecast was built explained close to 90% of that week's gap between forecast and actual. Not one unusual payment — nine ordinary ones, each following the same fast pattern: nothing existed when the forecast was made, then within days, an order was created and paid.

Getting earlier visibility, and where that stops working

It is likely that the sales managers already knew about some of these nine orders while they were still being negotiated with customers, before either a sales order or a payment existed in the system. That information never reached the person preparing the cash flow forecast because there was no quick or reliable way to obtain it from the sales team.

This was not the result of forgetting to ask a single question. It was a process problem. Information about future sales was either passed on too late or not shared at all, preventing it from being incorporated into the forecast.

For larger, slower-moving opportunities, the solution is straightforward. Sales can provide early visibility through a Large Deal Pipeline that tracks each significant opportunity by customer, expected value, expected timing, and confidence level. Because these opportunities develop over weeks, they can usually be incorporated into the forecast before cash is received.

Most of these nine payments were different. The time between the first customer contact, the order, and the payment was often only a few days. A weekly discussion with the sales team would not necessarily capture them because the entire sales cycle could begin and end between two forecasting updates.

This is an inherent limitation of relying on sales information alone. It improves visibility into larger opportunities but cannot reliably capture every fast-moving transaction.

The practical solution is to combine both approaches. Use information from the sales team wherever advance notice is available, and use historical patterns to estimate the cash generated by fast-moving deals that cannot realistically be identified beforehand. Historical analysis does not replace communication with sales; it fills the forecasting gap that communication alone cannot eliminate.

The fix that came out of this

89% of a week's cash coming from orders with no advance warning is not a data problem to be solved by looking harder. It is a fact about how this business gets a large part of its orders — placed and paid within days, with nothing to see in advance. A forecast built only from known invoices and open orders will always show close to zero for this part of the business, every single week, and be wrong every single week in the same direction.

The fix was not to try harder to predict which specific new order would arrive in which specific week. That is not possible — the order does not exist yet at the time the forecast is built. The fix was to stop treating this part of the business as zero, and instead measure how much of this kind of cash usually shows up in a week, based on many past weeks. This is the trailing average method covered in Part 3, and it is the direct result of this investigation, not a separate idea added later.

Large, one-off deals get a different fix again — tracked by name, with an expected amount, a date, and a confidence level, sourced directly from conversations with sales, rather than guessed from history that does not have enough events to average.

Why this matters to a client

Almost no forecast is accurate from the very first week — especially for a business where a large part of the cash comes from new orders that did not exist yet when the forecast was built. The first week here was a real miss, not a small one. What happened next is what actually matters: instead of leaving that miss unexplained, or just adding a bigger safety margin without understanding why, the gap got traced transaction by transaction. That work found the real cause and led to a real fix — the statistical baseline covered in Part 3. The forecast in use today is more accurate because of that specific investigation.

A forecast that gets checked every week, and corrected with a clear reason whenever it is wrong, becomes more accurate over time. A forecast that never gets checked stays wrong, silently, for as long as nobody looks.

This closes the five-part case study. The workbook used throughout it — the same Payment Schedule, Historical Transactions, Historical Weekly, and 13-Week Forecast sheets shown in Part 3 — is available to download below. It is the real file, not a cleaned-up version, including the forecast that missed by 16 times before this investigation.