Why a single-number forecast fails
Cloud spend is the hardest line in a SaaS budget to forecast well. It is variable — it moves with usage every day. It is lumpy — a launch, a migration, or a single enterprise customer can step it up overnight. And it is driver-linked — it tracks customer count, feature usage, and data volume rather than the calendar. A single forecast number flattens all of that into one figure and hides the assumption that produced it.
The failure mode is predictable. Finance forecasts cloud spend by eyeballing last quarter and adding a percentage. The number is wrong by month two. Nobody can say why, because the method was never written down, so the correction is another eyeball. The forecast never improves because there is nothing to improve — there was no model, only a guess.
The fix is not a better guess; it is an explicit model. A forecast that names its method and its assumptions can be checked against actuals, decomposed when it misses, and improved. That is the difference between a number and a forecast.
- Cloud spend is variable, lumpy, and driver-linked — three reasons one number cannot capture it.
- An eyeballed last-quarter-plus-a-percent forecast cannot be corrected because it has no method.
- An explicit model can be checked, decomposed, and improved; a guess cannot.
- Always forecast a method and a range, never a bare single figure.
Three models, three use cases
Run-rate extrapolation is the fastest. Take the current normalized monthly spend, apply a growth rate, and project forward. It is right for the near term — the next one or two months — and for a business whose spend is stable. It is wrong the moment a known step change is coming, because it cannot see a launch it was not told about.
Driver-based forecasting links spend to the things that cause it: cost per customer times forecast customers, or cost per unit of usage times forecast usage. It is the workhorse model for a SaaS finance team because it connects the cloud forecast to the revenue plan — when sales forecasts a hundred new customers, the cloud forecast moves with them automatically. It needs a clean per-driver cost figure, which is itself a reason to allocate spend properly.
Bottom-up build is the most accurate and the most work. It sums the known future: planned launches, migrations, environments being spun up or down, committed-use discounts starting or expiring. It is right for annual planning and for any period with large discrete changes. Most teams blend — driver-based for the base, bottom-up overlaid for the known step changes, run-rate as a sanity check.
- Run-rate: fast, good for the next one or two months and stable spend; blind to step changes.
- Driver-based: per-customer or per-usage cost times forecast volume; ties the cloud forecast to the revenue plan.
- Bottom-up: sum the known future — launches, migrations, commitments; best for annual planning.
- Most teams blend a driver-based base, bottom-up step changes, and a run-rate sanity check.
Putting a band on the number
A forecast without a band invites false precision. Saying cloud spend will be two hundred and twelve thousand dollars next quarter will be wrong to the dollar, and being wrong to the dollar reads as a process failure even when the method was sound. A band — between one-ninety-five and two-thirty, most likely two-twelve — is honest and, paradoxically, more useful, because it tells finance how much room to hold.
Build the band from your own variance history. If forecast-versus-actual has run plus or minus eight percent over the last year, that eight percent is your band; do not invent a tighter one because it looks more confident. The band is a measured property of your forecasting accuracy, not an aspiration.
For periods with real uncertainty, forecast scenarios instead of a band: a base case, an upside where customer growth runs hot, a downside where a migration slips. Scenario forecasting gives the board something to plan against — a downside it has already seen — rather than a single number that breaks the plan the day it misses.
- A single-point forecast invites false precision; a band is honest and more useful.
- Size the band from your own forecast-vs-actual variance history, not from optimism.
- For high-uncertainty periods, forecast base, upside, and downside scenarios.
- A confidence band tells finance how much budget room to hold.
Wire the forecast to actuals
A forecast only improves if it is measured. Every month, compare the forecast to actual spend and decompose the variance: how much was price (a rate changed), how much was volume (more usage than planned), how much was mix (spend shifted to a more expensive service or region). A decomposed variance tells you which part of the model to fix.
Feed that back. If volume variance is consistently positive, the driver assumption is too low — raise it. If mix variance keeps appearing, the model is missing a service that is growing — add it. The forecast that gets checked against actuals every month and adjusted is the one that is plus-or-minus five percent by year two; the forecast that is never checked stays plus-or-minus twenty forever.
This closes the loop with the rest of the finance workflow. The consolidated ledger produces the actuals, reconciliation confirms them, variance analysis decomposes the miss, and the decomposition tunes the next forecast. Forecasting is not a once-a-quarter spreadsheet — it is a monthly habit wired to the close.
- Compare forecast to actual every month and decompose the variance into price, volume, and mix.
- Feed the decomposition back: a persistent volume miss means the driver assumption is wrong.
- A forecast checked monthly reaches plus-or-minus 5%; one never checked stays plus-or-minus 20%.
- Forecasting is a monthly habit wired to the close, not a quarterly spreadsheet.
Related concepts
Who tovin.io is for
Frequently asked
Which cloud cost forecasting model should a SaaS finance team use?
Usually a blend: driver-based forecasting for the base — cost per customer or per unit of usage times forecast volume — with a bottom-up overlay for known step changes like launches and migrations, and a run-rate projection as a sanity check.
How far ahead can cloud spend be forecast accurately?
Run-rate models are reliable one to two months out. Driver-based models extend to a quarter or more when the revenue plan is solid. Annual forecasts need a bottom-up build and a wider confidence band — accuracy degrades with horizon, so the band should widen with it.
How do I put a confidence band on a cloud cost forecast?
Measure your own forecast-versus-actual variance over the last several months and use that range as the band. If you have run plus or minus eight percent, the band is eight percent — it is a measured property of your accuracy, not a number you choose.
What is driver-based cloud cost forecasting?
Forecasting cloud spend from the things that cause it — cost per paying customer, or cost per unit of usage — multiplied by forecast volume. It links the cloud forecast directly to the revenue plan, so when sales forecasts more customers, the cloud forecast moves with them.
Why does our cloud cost forecast keep missing?
Usually because it is a guess rather than a model — last-quarter-plus-a-percent cannot be corrected because it has no stated method or assumptions. Switch to an explicit model, decompose every miss into price, volume, and mix, and feed the decomposition back into the assumptions.
Do we need a data scientist to forecast cloud spend?
No. Driver-based and bottom-up models are spreadsheet arithmetic plus disciplined assumptions. What they need is a clean per-driver cost figure — which comes from allocating spend properly — and a monthly habit of checking forecast against actual.