8 min read
In most companies that do demand forecasting, the forecast lives in a spreadsheet. It's updated by someone on the operations or supply chain team, usually in the first few days of the month. That person opens the previous month's file, pastes in the new sales data, reviews the assumptions, adjusts a few cells where last year's pattern didn't repeat, and sends the file by email or uploads it to a shared folder. The commercial and purchasing teams download it from there.
That spreadsheet works. For many companies, an Excel forecast is more accurate than the first version of a predictive model built from scratch. An operator with years in the business has context the model takes time to learn: the promotion a large customer usually requests in March, the supplier that delivers late in August, the new SKU that hasn't accumulated enough history yet. Debating the spreadsheet's limit from the angle of forecast accuracy is debating the wrong front.
The limit appears somewhere else. The spreadsheet hits its ceiling when the cost of maintaining it exceeds the cost of a model, and that cost lives outside regression metrics like MAPE or absolute error — in three infrastructure fronts: person dependency, lack of scale, and loss of auditability. When all three accumulate, the spreadsheet is still accurate and yet has stopped being sustainable.
Limit 1: the forecast depends on one person being available
The spreadsheet has a property that's invisible while it works and obvious the moment it fails. The forecast depends on the schedule of one specific person. If that person is on holiday, pulled onto another project, or has left the company, the forecast doesn't exist until someone else rebuilds it from scratch or picks it up mid-stream.
That dependency has several layers. At the shallowest, the person is the only one who knows which file to open, where to paste the new data, and which cells to override manually before distributing. In the middle layer, they're the only one who remembers why the growth assumption for the largest product line was set at six percent last quarter. At the deepest layer, they're the only one who can defend the forecast when a commercial committee asks why the number changed month over month.
While that person is present, none of this is visible. The forecast circulates, purchasing decisions get made, margins hold. When the person is away for a month, the team discovers it's not just the file that depends on them. It's the entire chain of assumptions, adjustments, and number defence against the rest of the business. The cost is a process continuity cost, not an accuracy cost.
Limit 2: every new time series is a rewrite
The second limit activates when the business grows in complexity. The original spreadsheet covers, say, ten product categories and twelve months of history per category. That's a manageable matrix of one hundred and twenty data points that one person can read, understand, and adjust. But the business doesn't stay there.
The need arises to forecast by SKU within category. Ten categories with a hundred SKUs each means a thousand time series. The need arises to forecast by sales channel. Two channels double the count. Region, customer type, product configuration — every dimension the business asks for multiplies the number of series the spreadsheet has to hold.
Excel, as a tool, is not designed to scale by multiplication. It's designed for one person to see a range and adjust what doesn't add up. When the range no longer fits on screen, manual adjustment stops being possible and the person starts cutting corners: grouping SKUs that could be forecast separately, applying the same assumption to channels with different behaviour, postponing the regional breakdown for "when there's time". The forecast still exists, but it stops representing the granularity the business needs to make decisions.
Adding a new series to a mature spreadsheet is not an extension. It's a partial rewrite of the logic, with risk of breaking formulas that worked for the old series. What a well-designed predictive model does by design — the same input variables, one more call — the spreadsheet does by manual reconstruction. A model trained to predict a thousand series takes the same time to predict two thousand if the data is available. A spreadsheet configured for a thousand is a different project when two thousand arrive.
This limit is the one most teams detect first when they start thinking about moving to a model. The problem is that it's usually detected late. By the time teams recognise the pattern, the spreadsheet is already broken by growth and the forecast has started failing due to forced aggregations. Migrating from there is more painful than from a spreadsheet that works but doesn't scale.
Limit 3: manual decisions accumulate without traceability
The third limit is the least visible and the most underestimated. In any spreadsheet-based forecast, the final number is not the pure output of the formulas. It's the output after a series of manual adjustments the operator applies to correct what the formulas don't capture. A large customer changed its purchasing terms. A competitor launched an aggressive promotion. Last year had an unusual spike that shouldn't be projected forward. Each adjustment is a reasonable decision at the time, applied to a cell, with a justification living in the operator's head or in a brief comment in the spreadsheet.
This loss of auditability has two concrete consequences. The first is that continuous improvement of the forecast becomes impossible. You can't optimise a process when you don't know what portion of the output comes from the logic and what portion comes from the adjustment. The second is that the company loses the ability to defend the forecast when audit, management, or new team members legitimately ask how the number that drives next quarter's purchasing decisions gets built.
A well-designed predictive model inverts this dynamic. Manual decisions still exist, but they are separated from the model's output and recorded as overrides with date, author, and reason. There is a distinction between the algorithmic prediction, the human adjustment, and the final forecast. Each layer is auditable independently. Auditability of the output is part of the system's value, not an extra. In demand forecasting, that logic applies with even more weight. The forecast drives inventory decisions that tie up capital for months.
The crossover: when the three limits justify migration
The three limits rarely appear in isolation. They typically activate in sequence as the business grows. First scale, when the number of SKUs or channels starts to overflow the spreadsheet. Then person dependency, when the file's complexity becomes such that nobody can maintain it except whoever built it. Finally auditability, when the accumulation of untraceable manual adjustments starts complicating reviews and forecast improvement.
The question of when to move to a model is not when the Excel "fails". A spreadsheet can fail because of a broken formula and still get corrected. The operational question is when the accumulated cost of maintaining the spreadsheet — across all three fronts — exceeds the cost of building and maintaining a model.
One version of the argument deserves clarification. The contrast between "looking back" and "looking forward" is more useful for understanding the difference between BI dashboards and predictive models than for evaluating the limit of Excel as a forecasting tool. The forecast spreadsheet already looks forward. The problem is not what kind of question it answers, but the infrastructure with which it answers it.
The spreadsheet-based forecast is a reasonable tool as long as it depends on one person to maintain it, covers a number of series one person can see, and the manual adjustments are few and explainable. When those three conditions start to erode, the spreadsheet still produces numbers. What starts to fail is the ability to trust the process that produced them.