How a scaling business stopped making decisions on numbers that were already wrong

There is a specific kind of meeting that finance teams in scaling businesses dread more than any other. Not the board meeting where results come in below expectations. Not the audit review where an uncomfortable question surfaces without a clean answer. The one that is worse than both of those is the meeting where someone presents a forecast, and halfway through the presentation, someone else in the room quietly points out that the assumptions underlying it no longer reflect reality.

The forecast was built on last month’s pipeline. The deal it was anchored to closed last Tuesday – at a lower value than expected. The headcount assumptions don’t reflect the two offers that were accepted last week. The numbers on the slide are, in a meaningful sense, already wrong. And everyone in the room is now aware of it.

This meeting happened, in some variation, every single quarter at a technology business that had grown from thirty employees to just over a hundred and twenty in the space of three years. Not once or twice. Reliably. Almost every forecasting cycle contained at least one moment where the plan met reality and reality won.

After the third consecutive quarter where this happened in front of the board, the CFO stopped treating it as a forecasting problem and started treating it as a process problem. That reframing was what eventually changed things.

The company built and sold a mid-market software platform. Their revenue model combined annual licences, professional services, and a relatively new managed services offering that had been growing faster than anyone had originally projected. The combination of those three revenue streams – each with different recognition profiles, different margin structures, and different relationships to the sales pipeline – made forecasting genuinely complex.

What made it unnecessarily complicated was the architecture that had grown up around that complexity

The sales team maintained their pipeline in a CRM. The finance team maintained their forecast in a spreadsheet. The two were connected by a netsuite integration process that involved a member of the revenue operations team exporting pipeline data every two weeks, cleaning it, reformatting it, and sending it to finance, who would then incorporate it into the model. Between that export and the next one, anything that changed in the pipeline – deals that moved, deals that closed, deals that were lost – was invisible to the finance model.

In a business where pipeline movement was frequent and meaningful, a two-week lag in financial visibility was not a minor inconvenience. It was structurally significant. By the time the team built, reviewed, approved, and presented a forecast, it often reflected a commercial picture that was already two to three weeks old. In a company growing as fast as this one, two to three weeks was enough time for the picture to shift materially.

There was a second problem sitting beneath the pipeline lag, and it was in some ways more fundamental.

The previous head of finance built the forecasting model, and successive team members maintained and expanded it. Over time, the spreadsheet grew into a tool that required significant specialist knowledge to operate. This was not because the underlying financial logic was particularly complex, but because the team had added adjustments, workarounds, and NetSuite integration over three years without fully documenting them.

Formulas referenced cells in tabs that no longer served an obvious purpose. Hardcoded assumptions were buried inside calculations where a reader would expect to see a live input. Some rows appeared inactive, yet deleting them would break something elsewhere in the model. The person who best understood how it worked was a senior financial analyst who had been with the business for two years and had spent a significant portion of that time learning the model’s idiosyncrasies.

Her eight-week extended leave increased the next forecast cycle time by 40% and forced the team to manually correct the outputs before they were fit for sharing. The model was not just slow and outdated – it was fragile in a way that the business had not fully appreciated until it was temporarily without the person whose knowledge held it together.

The assessment that EcobSoft conducted started not with the model itself but with the decisions the model was supposed to inform

This is a distinction that matters. A forecasting process is not an end in itself. It exists to support decisions – about hiring, about investment, about where to allocate resources and when. If the output of the process consistently fails to support those decisions accurately, the question is not only how to make the model faster or more technically correct. It is whether the model is structured to answer the questions the business is actually asking.

When the decision-making landscape was mapped out, several things became apparent

The business made hiring decisions on a quarterly cycle using a revenue forecast built on pipeline data that was already two weeks old. By the time managers approved a headcount decision and extended an offer, the underlying revenue assumptions had often shifted. In the previous year, the company approved headcount twice based on a revenue forecast that it later revised downward before the new hires had even entered their notice periods.

The business made investment decisions in its managed services offering-a growing segment that required infrastructure spending before revenue-without a rolling view of cash flow. The P&L forecast existed. The cash flow model was a separate exercise, built quarterly, which meant that for most of the year the business was making investment decisions without a live view of the liquidity implications.

The finance team spent four to five days each month building the board pack, which included a monthly reforecast against the annual plan. The process required the team to manually pull actuals from the system, reconcile them against the model, update pipeline assumptions, and rebuild the revenue schedule. The analysis itself was not complex, but the manual assembly of inputs prevented the team from meaningfully parallelising the work.

The team spent four to five days every month producing a document that became partially outdated before they distributed it.

The solution that was implemented operated on three levels, each addressing a different layer of the problem

The first was connectivity. The CRM and NetSuite were integrated directly, with netsuite integration pipeline data flowing into the planning environment in real time rather than through a fortnightly export process. Deal stages, weighted values, expected close dates, and product line attribution were all mapped across and kept current. When a deal moved in the CRM, the financial model reflected it. Not the next time someone ran an export – immediately.

This change alone did not fix the forecast. But it changed the nature of what the forecast was working with. The team connected the financial planning environment to a live commercial view instead of relying on a static pipeline snapshot that slowly aged over time. This integration removed the structural lag.

The second level was the planning architecture itself. The finance team retired the existing spreadsheet model and rebuilt it inside NetSuite Planning and Budgeting. They structured it around the business’s three revenue streams-licences, professional services, and managed services-and made the logic for each stream explicit, documented, and accessible to any team member who needed to work with it.

The company implemented driver-based forecasting for the first time. Instead of building revenue projections from a single aggregate number adjusted by growth assumptions, the team built the model using the inputs that actually drove revenue in each part of the business through NetSuite integration. Pipeline volume, average deal value, and stage-weighted close probability drove licence forecasts. Professional services projections relied on headcount capacity, utilisation rate, and average day rate. Managed services forecasts incorporated the contracted recurring base, expected churn, and new business from the pipeline.

Each input linked to a live data source where available, otherwise a documented manual entry. The model clearly separated data from assumptions at all times.

The team rebuilt the cash flow model as a continuous output in the same planning environment, automatically updating cash flow as revenue assumptions changed. This enabled rolling 13-week cash flow views for infrastructure decisions instead of outdated quarterly snapshots.

The third level was the board reporting process. Monthly reforecast was automated with NetSuite actuals, cutting 4–5 days of work to 2–3 hours.

After the redesign, the board pack that once took a week was completed in just a day and a half. The reduction was not because less analysis was being done. It was because the analysis was no longer buried in a manual data assembly process.

The first quarterly forecast cycle on the new process produced a result that the CFO described, with some understatement, as a different experience

The team built the forecast in three days instead of the seven to eight days that had become normal. The model used current pipeline inputs at the time of presentation rather than data that was already two weeks old. When a deal moved during the presentation, the team updated the model live and recalculated the full-year forecast instantly.

That last point landed differently than the team had expected. It was not just a demonstration of a technical capability. It changed the character of the board conversation. The finance team ran a live model that updated in real time instead of a static document. The conversation shifted from scrutinising the numbers to thinking about the business. That is what a board conversation should be.

The hiring decision process changed as a direct consequence of the cash flow integration. The team compared two headcount approvals using a 13-week cash flow view versus a P&L forecast. We approved one hire on schedule and deferred the other for six weeks after cash flow showed tighter liquidity. This showed improved, real-time decision-making over outdated models.

The financial analyst returned from leave to find the system no longer depended on her. That was not, she said, an entirely comfortable experience initially. But it was the right outcome. A forecasting process relying on one person’s memory isn’t a process-it’s an unmaterialised risk. When it does materialise, it tends to materialise at the worst possible moment.

Forecasting is, at its core, an act of controlled uncertainty. Nobody knows what the next quarter holds. Decision-makers use financial plans to reflect uncertainty and get a clear, realistic view of business direction.

What undermines that purpose is not the inherent unpredictability of a scaling business. It creates unnecessary lag, fragility, and manual effort between commercial reality and the financial picture. People don’t call forecasting “hard”; they see it outdated before it finishes because it can’t keep up with the business.

A connected, driver-based, automated planning process does not make the future more certain. It makes the present more visible. In a fast-moving business, a three-week-old number is not a minor error—it’s significant.

It separates decisions made on information from decisions made on memory. EcobSoft helps scaling businesses build financial planning processes connected to commercial reality. Forecasts reflect the business as it is, not as it was. If planning takes too long and goes stale, the architecture needs review.