By Yair Knijn · February 13, 2026

The forecast that was last month times twelve, and the budget that believed it

Every annual cloud budget starts the same way. Finance pulls the most recent month off the invoice, multiplies by twelve, adds a polite buffer, and ships it to the board. The CFO signs it because it reconciles to a number they can see. The trouble is that the number they can see is the worst possible basis for the number they need to defend.

A month-times-twelve forecast assumes cloud spend is flat, paid in cash, and frozen at today's workload. None of those three things is true, and the budget breaks the first time reality says so.

Why last-month-times-twelve always misses

FinOps practices publish accuracy bands for a reason: an early-stage practice is expected to land within roughly a fifth of actual spend, a mature one inside the low double digits. Naive extrapolation gets you to neither, because the error is not random noise you can buffer against. It is structural. You picked one month as the shape of the whole year, and that month had a shape of its own that you erased when you multiplied it.

The variance does not arrive evenly either. It hides for a quarter, then lands all at once when one driver moves, and by then the budget is the document everyone is arguing about.

Seasonality and the launch that wasn't in the model

Pick the wrong base month and you bake its bias into all twelve. A January extrapolation misses the Q4 retail peak entirely. A November one projects twelve Novembers and overshoots the whole first half of the year. Either way the curve you drew is flat and the real one is not.

Worse is what the base month cannot contain at all: the workload that hasn't launched yet. The product engineering has spent all year building does not appear in last month's bill, so the model forecasts a year in which it never ships. When it does, the budget has no line for it.

Amortized commitments vs cash-basis billing

This is where the math quietly inverts. Buy a one-year Savings Plan or Reserved Instance with an upfront payment, and your UnblendedCost spikes in the month you paid, then reads near zero afterward. Extrapolate the upfront month and you forecast twelve upfront payments. Extrapolate a later month and you forecast a discount already paid for that will expire mid-year.

Forecast on AmortizedCost instead. It spreads committed spend evenly across the term, the way the economics actually work. Track the expiry dates as their own line too, because a Savings Plan that lapses in August is a price increase you scheduled yourself.

Driver-based forecasting tied to workload growth

The credible alternative is not a fancier extrapolation. It is forecasting from the things that move the bill, then converting those into cost.

• Active tenants or seats, and the per-unit infrastructure each one consumes
• Data volume processed and stored, with its own growth and retention curve
• Dated launch milestones from the engineering roadmap, costed before they ship
• Commitment coverage and the exact dates each Savings Plan or RI expires
• Known seasonal peaks, sized from last year's actuals rather than guessed

When Finance and Engineering own the forecast together, far more teams hit predictable spend than when Engineering owns it alone. A driver-based model is what makes that possible: both sides argue about the drivers instead of the bill.

A budget finance can defend when reality diverges

When the number moves, a driver-based forecast tells you which assumption broke: tenant growth ran hot, a launch slipped, a commitment lapsed. You report the cause on day 10, not the surprise on day 28, and the conversation is about a known variable instead of a mystery.

Cloud Horizons builds the forecast from the drivers, not the rear-view invoice. Every workspace tracks amortized commitment cost, seasonal baselines, and roadmap-dated growth, so the budget bends with reality instead of breaking against it. See how the model is built on /finops.