AI budgets built the way software budgets are built, as a list of contracts and seats, tend to be wrong in a predictable direction. Unit prices fall, so the budget is set lower. Then usage spreads to new teams, agents make several calls where a person made one, and someone moves a workload to a stronger model. The total rises while every individual price falls. Why cheaper AI will cost more explains the mechanism. This piece is about what to do with it when setting a budget.
The approach is the one FP&A teams use for any variable cost: forecast the drivers, not the invoice, then explain variance by driver.
The forecasting model
For usage-based AI, spend for a workload is roughly:
AI spend for a workload =
workload volume (tasks, cases, sessions per month)
× calls per task (1 for a simple assistant, often many for an agent)
× tokens or compute per call (context length, output length, reasoning depth)
× model mix (share of calls going to each model tier)
× effective unit rate (list price after discounts, caching and batching)
+ platform (gateway, retrieval, vector storage, observability)
+ data (pipelines, embeddings refresh)
+ human verification (review and correction time, costed)
+ engineering and operations (build, run, incident response)
+ licences and embedded AI (seat-based tools and AI tiers inside SaaS)
Two things follow. First, the unit rate is one driver among five in the variable part, so a 30% price cut does not mean a 30% budget cut. Second, the last five lines are often larger than the first five and are not on any model provider's invoice. The AI TCO framework breaks them down.
Seat-based and embedded AI behave differently from usage-based AI: the cost is fixed per seat but tends to rise at renewal as vendors move AI into higher tiers. Forecast those from the contract calendar, not from usage.
Explaining variance
When actual spend differs from budget, split the difference into effects that point to different owners:
| Effect | What changed | Who usually owns it |
|---|---|---|
| Price | Unit rates moved, through list price, discount or caching | Procurement, platform engineering |
| Volume | More tasks, more users, more workloads | Business owners, line managers |
| Mix | A larger share of calls went to a more capable model | Platform engineering, product |
| Workflow | AI was added to workflows that were not in the plan | Business owners |
| Agent depth | Each task triggered more calls, tool use or retries | Platform engineering, product |
| Architecture | Changes such as routing, retrieval or self-hosting moved the cost base | Platform engineering |
Overruns are now the norm in finance teams' own accounts. In Pigment's survey of 2,000 CFOs and finance executives in the US, UK, France and Germany, 83% said consumption-based AI costs had pushed spending above expectations. The typical overrun was 11% to 25%, and 17% were more than 50% over (Pigment, 7 October 2026). A separate US survey found 13% of finance leaders said their AI budget had no clear owner (Datarails, 6 October 2026). Both are vendor surveys and measure spend against expectation, not invoices. They are a reason to budget consumption with a variance split from the start.
The split matters more than the total. A variance that is mostly volume in a workload with a strong value claim may be good news. The same variance from agent depth, with no change in outcomes, is a design problem.
A worked bridge
Illustrative figures. Not survey data. A business spent £4.0m on AI last year and is forecasting next year.
| Effect | £m | Assumption |
|---|---|---|
| Last year actual | 4.0 | |
| Price | −0.6 | Effective unit rates fall about 15%, applied to last year's spend for simplicity |
| Volume | +1.0 | Two business units move from pilot to production |
| Mix | +0.3 | Complex document workloads move to a stronger model tier |
| Workflow | +0.4 | AI added to procurement and HR service workflows |
| Agent depth | +0.7 | A support agent moves from one call per contact to around five |
| Architecture | −0.2 | Routing simple queries to a smaller model |
| Forecast | 5.6 |
The agent-depth line is the one most budgets miss, because it does not show up in a pilot. A pilot agent handling the easy tenth of contacts makes few calls. In production it meets the hard cases, retries, and calls tools.
Seven scenarios to run before you commit
A single forecast for AI is false precision. Run at least these, and set the budget against the range. The AI budget stress test runs the price and demand cases against a case's value.
- Base case. Current workloads, planned rollouts, expected price change.
- Adoption surge. Usage in the largest workload doubles in six months.
- Agentic expansion. One or two workloads move to agents, multiplying calls per task.
- Price reduction. Unit rates fall faster than planned. Check how much of the saving is likely to be consumed by extra use.
- Mix shift. A new model tier becomes the default for complex work.
- On-device or self-hosted substitution. Some inference moves off metered APIs: lower variable cost, higher fixed cost.
- Reserved capacity. A commitment lowers the rate in exchange for a floor. Check the cost of under-use.
Controls that keep the forecast honest
- Budget by workload, not only by supplier. A supplier view tells you who to pay. A workload view tells you whether to keep paying.
- Set envelopes with thresholds, not hard caps. A hard cap on a customer-facing agent stops service; a threshold triggers a review.
- Reforecast monthly in the first year. Driver assumptions for new workloads are usually wrong at first.
- Tie the variance review to the value review. Spend that rises in step with a measured outcome is a different conversation from spend that rises alone. See how to measure AI value.
What would change this view
- If providers move most enterprise AI to fixed-price capacity or flat subscriptions, driver-based forecasting matters less and contract management matters more.
- If agent architectures become much more efficient per task, the agent-depth effect may shrink. The direction so far has been the opposite, but the evidence is early.