AI spend variance analysis: why the forecast missed, in four numbers.

July 19, 2026

By the LLM CFO team

73% of enterprise AI projects exceeded budget in 2025. Most finance teams blame "uncontrolled usage" and move on. But the real miss is diagnostic: your forecast was off by $50k, and you have no idea which $50k, or who owns fixing it. This is the playbook to decompose any monthly variance into four independent drivers—each with a different owner, a different cause, and a different fix. The math is standard management accounting applied to tokens. The conversation moves from "we're over budget" to "we're over because of X, and here's who fixes it."

The decomposition that ends the guessing

Every month's AI spend variance (forecast vs. actual) splits into four independent components. Here's the framework:

These four drivers account for 100% of any variance. They have no overlap. Each points at a different team and a different fix. Once you decompose the miss, the conversation stops being "we spent too much"—which is useless—and becomes "we spent too much on volume and efficiency, and here's the plan."

Worked example: $50k miss splits into three fixable problems

Forecast for June 2026: $100,000 AI spend. Actual June spend: $150,000. Variance: +$50,000 (50% over). Where did it go?

Step 1: Volume variance

Forecast: 500M requests. Actual: 600M requests. Variance: +100M requests.

Average cost per request (from March baseline): $0.20.

Volume variance = +100M × $0.20 = +$20,000.

Signal: adoption accelerated. New team onboarded. This is usually good news, but needs to be separated from efficiency to know if the cost per request is the problem or the request count is.

Step 2: Rate variance

Forecast assumed average token price of $0.0015 per token (blended across models). Actual: $0.00145 per token.

You got a 3% price drop from Anthropic mid-month. That dropped the blended rate.

Actual 600M requests × 850 avg tokens per request = 510B tokens.

Forecast: 510B tokens × $0.0015 = $765,000. (part of the $100k budget is non-token, so actual token budget was ~$70k).

Actual: 510B tokens × $0.00145 = $740,000.

Rate variance = +$25,000 cost from higher blended rate because mix shifted to Opus (expensive) even as the per-token price fell.

Signal: procurement won on pricing, but engineering offset the win by choosing higher-cost models. These moves cancel out without visibility. This is invisible without decomposition.

Step 3: Mix variance

Forecast: 40% Claude 3.5 Haiku, 40% Claude 3.5 Sonnet, 20% Claude Opus.

Actual: 30% Haiku, 35% Sonnet, 35% Opus.

This shift costs 10% more per token (rough math: Opus is 3.5x Haiku; the shift from 20% to 35% Opus adds cost).

600M requests × 850 avg tokens × cost-per-token-shift = +$12,000.

Mix variance = +$12,000.

Signal: Product routed more requests to Opus for quality. This is intentional. Make sure it's ROI-positive. If Opus improved quality enough, great—but reconcile it to customer satisfaction or conversion lift, not just cost.

Step 4: Efficiency variance

Forecast: 850 avg tokens per request. Actual: 920 avg tokens per request.

The overage is +70 tokens per request.

600M requests × 70 tokens × $0.00145 per token = +$61,200.

Efficiency variance = +$61,200.

Signal: This is the red flag. Context windows grew, cache hit rate dropped, or retries increased. Engineering owns this. Audit prompt design, retrieval payloads, and cache strategy.

The reconciliation

Volume variance       +$20,000 (adoption won; good)
Rate variance         +$25,000 (mix shift offset pricing win; investigate)
Mix variance          +$12,000 (intentional, needs ROI check)
Efficiency variance   +$61,200 (bloated prompts; engineering fix needed)
────────────────────────────
Total variance        +$118,200 ≈ $50k actual (accounting for non-token spend)

Without decomposition, finance sees "+$50k" and launches an audit. With decomposition, finance sees four drivers pointing at three different owners. Product and procurement are meeting their targets. Engineering has a specific problem to fix (efficiency). This is how you move from "spend is out of control" to "here's the fix."

Why each driver has a different owner and a different fix

Volume variance is product's problem. If you forecast 500M requests and you made 600M, that's usually adoption accelerating. Good. But it means your model mix, efficiency baseline, and rate assumptions all assumed 500M. A 20% volume jump moves you into different pricing tiers or usage patterns. Re-forecast next month with the new baseline.

Rate variance is procurement's problem. Vendor prices change almost monthly. Reconcile your forecast rate to the actual invoice every month. Track: Did we hit our contract terms? Did we lose a volume discount? Did prices fall but we didn't update our forecast? Document the delta and update next month's forecast.

Mix variance is product and engineering's problem. Model routing decisions—"use Opus for this, Haiku for that"—shift your cost structure. This is not a bug. It's a feature choice. But it has to be tracked and justified. If Opus improves conversion by 2% and costs 3x Haiku, the math works. If Opus is the default because "it's safer," that's waste. Measure the ROI.

Efficiency variance is engineering's problem. Tokens per request grow when: context windows expand (you're pasting bigger documents), cache hits fall (your cache key strategy changed), retries increase (reliability degraded), or prompts get bloated (stale examples, oversized retrieval). These are code and architecture problems. This is where most of the savings live. A 10% efficiency improvement—from 850 to 765 tokens per request—is a permanent cost drop.

The monthly close cadence: make it a ritual

Here's the operating model that keeps variance visible:

1. T+1 (one day after month end): Reconcile invoice to logs. Pull the actual invoice from your provider. Pull your actual token consumption from logs (instrumented via OpenTelemetry or your vendor's native API). The two should match within 2–3% (accounting for cache behavior and regional pricing). If they diverge by more, investigate. Document the delta.
2. T+3: Decompose the variance. Calculate the four drivers (volume, rate, mix, efficiency). Assign dollar impact to each. This is a mechanical calculation—use a spreadsheet or dashboard. The output should be: "We were +$50k over. Here's why: volume +$20k, rate +$25k, mix +$12k, efficiency +$61k."
3. T+5: Assign ownership and action. Take the decomposition to your steering committee (CFO, VP Eng, VP Product, Procurement lead). Each driver gets assigned to an owner. Rate variance goes to procurement for contract review. Efficiency variance goes to engineering for optimization prioritization. Volume variance goes to product for re-forecasting. Mix variance goes to product for ROI audit.
4. T+10: Re-forecast next month. Armed with actuals and drivers, update your forecast for the next month. If efficiency variance was +$61k this month and you have a fix in progress, forecast it down next month. If a new feature launched and volume jumped, adjust volume up. Document your assumptions so you can track them.
5. T+20: Publish the variance report. Share a one-page summary with the executive team. Template below. Make this a ritual. The conversation moves from "our bill is too high" to "here's what we learned this month and here's the plan."

Forecast bands, not point estimates

The trap is forecasting a single number: "We will spend $100k this month." Then actuals come in at $95k or $108k and finance asks "Why?" The answer is usually "variance" or "adoption." Both are unhelpful.

Instead, forecast a range. "We expect $90–110k based on these assumptions: [list assumptions]. Here's how we'd know if we're off track: [list leading indicators]."

The width of the band depends on your maturity:

A ±10% band at "established" maturity is realistic. A ±5% band is rare and requires automation. Don't oversell precision you don't have.

When variance signals "re-forecast" vs. "intervene"

Not every variance deserves immediate action. The question is: Is this a forecast error, or is it a cost control error?

Re-forecast if:

• Volume variance: adoption accelerated (good). Re-forecast, don't punish the team.
• Rate variance: vendor repriced (outside your control). Reconcile and update forecast.
• Mix variance: intentional shift to better models (check ROI, but don't panic).

Intervene if:

• Efficiency variance > 5% of monthly spend. More tokens per request than baseline is a code problem. Set a recovery plan.
• Any driver persistent across 3+ months. If efficiency is bad in June, bad in July, and bad in August, it's not a one-time miss. It's a structural problem.
• Volume variance + efficiency variance together > 15% of budget. Two bad drivers stacking is a signal to pause new features until you get cost under control.

Variance report template

A standard framework solves the guessing game

Variance analysis is textbook management accounting. It's been used in manufacturing for 50 years: standard cost minus actual cost, decomposed into price variance, usage variance, and efficiency variance. LLM spend follows the same pattern. The only difference is the jargon: "price variance" becomes "rate variance," "usage variance" becomes "volume variance," and "efficiency variance" stays the same.

Finance teams know this framework. Engineering teams don't, but they understand ownership once the driver is named. That alignment—when finance says "efficiency variance is the problem" and engineering hears "tokens per request need to drop"—is when cost control becomes possible.

73% of AI projects overspend. Most stop there. The ones that fix the problem do it by separating signal from noise, assigning ownership, and tracking the same drivers every month. This is how.

Related

• AI FinOps: the operating model for LLM spend
• Token prices fell 80% and your bill still went up
• LLM cost monitoring: what to track and how to control it
• Your GenAI telemetry schema is now a cost decision
• Context window creep is eating your budget