Industry
Part of Forecasting 2027: A Year-Agnostic Review Framework
Forecasting tools by class: how to run a trial that can fail
Names forecasting tools by class, gives published prices where vendors list them, and outlines a trial that can fail along with reproducibility and handover checks.
Forecasting tools sort into four classes before any brand matters. Microsoft Excel, Meta's Prophet, Anaplan and Databricks each sit in a different one. The class you need is set by how many series you run and how often a person overrides the number.
Each class below names its products, with published prices where vendors list them, and a trial built so the test can fail rather than flatter the tool.
What to take away
- Series count and override frequency pick the class. Work both out before you open a pricing page.
- Published prices run from free for Prophet and Google Sheets to $12.50 per user per month for Microsoft 365 Business Standard. Anaplan and Pigment publish nothing and quote per engagement.
- A team adjusting nearly every forecast every cycle has a workflow problem, and no statistical package fixes it.
- The costs that end a forecasting setup are reproducibility and handover, and neither shows up in an accuracy-only test.
- Run the trial on your worst series, set the pass condition in writing, and let a second person attempt the handover.
The four classes, by name
Spreadsheets. Microsoft Excel and Google Sheets. Microsoft 365 Business Standard lists at $12.50 per user per month, and Sheets is free with a Google account. Excel's FORECAST.ETS functions cover seasonal series, and Sheets caps a file at 10 million cells. The class fails on volume, on version history, and when the builder leaves.
Four classes of forecasting tools
Spreadsheets
- Examples
- Excel, Sheets
- Strength
- Transparent arithmetic
- Weakness
- Fails on volume
- Best for
- Few dozen series
Scripted environments
- Examples
- Python, R
- Strength
- Any number of series
- Weakness
- Opaque to colleagues
- Best for
- Reproducible output
Planning applications
- Examples
- Anaplan, Pigment
- Strength
- Override workflow
- Weakness
- Weak statistics
- Best for
- Forecast-adjust-commit
Embedded components
- Examples
- Snowflake, Databricks
- Strength
- Convenient and embedded
- Weakness
- Host-constrained methods
- Best for
- Existing platform users
Scripted environments. Python with Prophet, statsmodels or scikit-learn; R with the forecast package and fable. All are open source, so the license cost is zero and the engineering time is not. Nixtla's StatsForecast covers similar ground in Python, and both languages regenerate a past forecast from a stored script and a pinned environment.
The tradeoff is that a non-technical colleague cannot inspect the calculation. Version control keeps the change history, and a script nobody else maintains becomes the handover problem the tool was meant to solve.
Planning applications. Anaplan, Oracle Planning and Budgeting Cloud, SAP Analytics Cloud, Pigment and Workday Adaptive Planning. Vena sits in the same class and keeps Excel as its front end. All six are built around the forecast, adjust and commit cycle, with overrides, approvals and audit trails included.
Oracle and SAP publish rate cards, and planning editions typically list in the tens to low hundreds of dollars per user per month before any annual minimum. Anaplan, Pigment and Vena quote per engagement and publish nothing. You buy the workflow, not the statistics. Judging one on forecast accuracy alone misses what it is for.
Embedded components. Forecasting ships inside Snowflake, Databricks, Amazon Forecast, Power BI and Tableau. Power BI Pro lists at $14 per user per month, and Tableau Creator at $75 with Viewer at $15. Snowflake compute runs about $2 to $4 per credit, and Databricks bills by DBU at different rates for jobs and all-purpose clusters.
Methods and granularity follow the host, so a BI tool inherits the limits of the model behind it. Amazon Forecast is closed to new customers, so check the current status before you commit; AWS points new forecasting work at SageMaker.
The five properties that decide it
Five properties that decide it
The question to answer first
- Series count
- How many independent series, growing how fast?
- Override frequency
- How often does judgment change the number?
- Audience
- Who must be able to inspect the calculation?
- Cadence
- Weekly, monthly, or continuous?
- Handover risk
- What happens when the builder leaves?
Why it decides
- Series count
- Manual review stops scaling past a few dozen
- Override frequency
- Frequent overrides need workflow, not better math
- Audience
- Sets whether opacity is acceptable
- Cadence
- Continuous rules out anything with a manual step
- Handover risk
- The most common cause of abandonment
The override row is the one teams skip, and it decides more often than the rest. Anaplan and Pigment exist because of that row, not because their statistics beat Prophet's.
Five properties that decide the tool
- Series counthow many, growing how fast?
- Override frequencyhow often does judgment change it?
- Audiencewho must inspect the calculation?
- Cadenceweekly, monthly, or continuous?
- Handover riskwhat if the builder leaves?
Reproducibility is the property to test hardest
The question is whether someone else, six months on, can regenerate last quarter's published forecast exactly. That is reproducibility in the ordinary scientific sense. It decides whether you can ever explain why a past forecast was wrong.
How to make forecasts reproducible
- Snapshot inputs instead of re-querying live sources
- Keep configuration under version control
- Regenerate last quarter's published forecast exactly
- Explain why a past forecast was wrong
Inputs must be snapshotted rather than re-queried, because a live query against a restated source reproduces nothing. Configuration must sit under version control rather than as the current state of a file people edit.
A scripted environment gives you both by default. Excel and Sheets give you both with dated copies and a stored extract, which most teams never set up.
The plumbing no forecasting tool provides
Someone still has to assemble the history: pull the source data, align the calendar, handle definitional breaks, mark the gaps. That is ordinary extract, transform, and load work, it is most of the ongoing effort, and it is identical across Excel, Prophet, Anaplan and Databricks.
Price that work before you compare tools. A planning application bought to solve a data assembly problem will not solve it, and you will have paid to learn that.
A trial that can fail
Three rules make an evaluation informative, and the third is the one most teams skip.
- Use your own series, including the ugly onesthe intermittent series, the one with a definitional break, the product with four months of history. A trial on your three best-behaved series proves nothing.
- Write the pass condition before you start. For examplereproduces a stated past forecast exactly, handles the intermittent series without breaking, and lets a named non-specialist log an override in under ten minutes.
- Hand the documentation to someone who did not build the trial and have them produce next period's forecast alone. Most trials fail this, and most evaluations never run it.
Run the three steps in order and the first failure usually lands in the same place. A spreadsheet fails step three once the series count passes a few dozen and the builder has left.
A scripted environment passes steps one and two and fails step three, because nobody outside the builder can drive it. A planning application fails step one when the ugly series needs data work nobody scoped.
An embedded component fails step two when the host's methods or granularity cannot hold the intermittent series. Amazon Forecast fails earlier, on availability. A failure is only useful if the pass condition was written down first.
When the answer is to buy nothing
Under a few dozen series, reviewed monthly, by people who want to see the arithmetic, the answer is usually a spreadsheet with stored baselines, dated snapshots and a written override log. That satisfies every requirement that matters here and costs nothing.
Reconsider when series count passes what one person can review, when cadence outruns a person, or when overrides need approvals a file cannot enforce. The method itself is in how forecasts are built and reviewed, and the structure the tool must support is in a forecast register and a review cycle.
For the layer you shop, see buying analytics tooling, and for evaluation and lock-in more broadly, how to compare intelligence platforms. The publication end is covered in building a report worth keeping.
Common questions
Everyone in our sector uses one product. Is that a reason?
It is a reason to find out why, not to buy. Sector concentration usually reflects an integration with an operational system rather than forecasting quality, and if you do not run that system the argument does not transfer.
Can we start in a spreadsheet and migrate later?
Yes, and it is usually the right sequence, provided inputs and the override log stay in a form that can move. What does not migrate is arithmetic buried in undocumented cell formulas.
How long should a trial run?
At least two full cycles of your cadence, so you see a handover, a source failure and an override. One cycle shows you the happy path only.
Who should run the evaluation?
Whoever maintains it in year two, not whoever is most enthusiastic in year one. Those are rarely the same person, and the second one asks better questions.
