AI spend has become a board line item at most companies. And for many CFOs, it's the one line they can't forecast, can't cap, and can't defend call-by-call the way they defend every other dollar.
That's a governance gap, and it's new. Twelve months ago AI was a rounding error inside "software." Now it's compounding — IDC has worldwide AI spending more than doubling to $632B by 2028, a 29% CAGR, with GenAI growing at 59%. The line is growing faster than any cloud category before it, and it's the least governed thing on the P&L.
Here is the contrarian part. When you ask about AI spend, someone on the engineering team will show you a dashboard — token counts, latency charts, a per-model breakdown. It's a good dashboard. It is not financial governance.
An observability dashboard tells you what already happened, in engineering's language. Financial governance tells you whether the spend was authorized, whose budget it draws on, and whether you can defend it to a board or an auditor. Those are different jobs. The dashboard answers "what did it do?" Governance answers "was it allowed to, whose is it, and can we prove it?"
Here are the five things a CFO actually needs — and how a spend control plane, the layer that sits in front of every AI call, delivers each one.
1. Attribution you can put in a chargeback
The first question isn't "how much did we spend on AI?" — you can answer that from the provider invoice. The question is "which team, project, or customer spent it, and does it map to revenue?"
Most AI infrastructure can't answer that, because the API key is shared. One key, every workload, no owner. When the invoice arrives, there's no way to split it by the thing your chart of accounts actually tracks.
A spend control plane fixes this at the source. Every call flows through a governed Virtual AI Key (tk_live_…), and the Token Ledger records five dimensions before a token is spent: WHO — the person or agent persona. HOW MUCH — the budget. WHY — the project and task. WHERE — the location. WHEN — the timing.
That's not an after-the-fact estimate. It's the authoritative per-transaction record, captured at call time — which is exactly what a chargeback needs.
2. Hard caps that stop overspend before it happens
Every CFO has lived the AI version of a surprise invoice: a leaked key, a runaway agent loop, and $340 becomes $34,000 in eighteen hours. By the time the bill posts, the money is gone.
An alert that fires at 80% of budget and then lets the remaining 20% get spent is not a control. Neither is a monthly report. Real enforcement stops the spend before the call is made.
A spend control plane enforces a hard budget at the gateway. When a key or project hits its cap, the next call returns HTTP 402 — Payment Required — and never reaches the provider. The check runs ahead of the spend, not after it. That's the difference between a budget you set and a budget that holds. Pair it with a one-click kill switch on any key, team, or workload, and the runaway agent is a contained incident, not a board conversation.
3. Chargeback finance can reconcile to the invoice
Attribution is only useful if it survives a finance review. That means the chargeback number has to reconcile to the provider invoice — to the row — and post to the general ledger in your language, not engineering's.
The control plane exports a per-org chargeback CSV: one row per GL code, with total cost, call count, and period. Finance maintains a mapping table that translates the gateway's technical attribution — (org, project, task_class) — into GL codes and cost centers, most-specific-rule-first, with a wildcard catch-all so nothing goes unallocated silently. A high unallocated line is a signal, not a leak.
Because both the chargeback and the actual provider bill derive from the same per-call record, the period-close cross-check is a twenty-minute reconciliation instead of a quarterly forensic exercise. That's showback and chargeback that hold up in a budget meeting where someone challenges the number.
4. A forecast you can defend
You can't forecast a line built on one shared key with no owner. You can forecast per-team run-rates that trend month over month, with variance you can explain.
Once every call is attributed and every team has a budget window, run-rate becomes a real number per team and per project — the input a defensible forecast is built on. And because the control plane sees spend in real time, anomaly alerts fire the moment spend deviates from plan: a 40× spike at 03:14 is flagged the instant it happens, not discovered in next month's variance analysis. A forecast you can defend is one where the surprises are caught while they're small.
5. Audit-grade evidence for the board and auditors
Eventually someone asks you to prove it — the board, an auditor, a customer's procurement team. "Trust the dashboard" is not an answer, because a dashboard is a log, and application code can rewrite a log.
A spend control plane keeps an append-only audit trail enforced at the database layer — the application role literally cannot UPDATE or DELETE audit rows, and a deploy-time check verifies the invariant on every rollout. On top of that sits a continuous evidence pack mapped to four frameworks: SOC 2, ISO 27001, ISO 42001 (the AI management-system standard), and the NIST AI RMF. When the audit question comes, the evidence is already collected. A leaked key adds a second factor here too: a tk_live_… without its binding key is a dead key, so a stolen credential doesn't become a spend event.
What finance needs vs. what an observability tool gives you
| What finance needs | Observability dashboard | AI spend control plane | |---|---|---| | Attribution to team / project / customer | Per-model token counts | Five-dimension Token Ledger, per call | | Hard cap that blocks overspend | Alert after the fact | 402 at the gateway, before the call | | Chargeback reconciled to the invoice | Export of raw traces | GL-mapped chargeback CSV | | Defensible forecast | Historical charts | Per-team run-rate + anomaly alerts | | Audit-grade evidence | Mutable logs | Append-only audit + SOC 2 / ISO 42001 pack |
The dashboard was built for the engineer debugging a chain. The control plane was built for the dollar. You need both, but only one of them is governance.
Is your AI spend actually governed? 8 questions
Run this checklist. If you answer "no" to three or more, you have visibility, not governance.
- Can you attribute last month's AI spend to a specific team, project, or customer — without asking engineering to run a query?
- Is there a hard cap that blocks a call when a budget is exhausted, or only an alert?
- When an agent or key runs away, can someone freeze it in one click?
- Does your AI chargeback reconcile to the provider invoice, to the row?
- Can finance post AI spend to the GL without a manual spreadsheet step?
- Do you have a per-team run-rate you'd put in a forecast?
- Would a spend spike be caught the day it happens, or in next month's close?
- If an auditor asked for an immutable record of who spent what, on which model, could you produce it today?
Every "yes" is a control you already have. Every "no" is a line you can't yet defend.
Where to start
The fastest way to see the difference is to watch a call get attributed, hit a cap, and get denied — before it costs anything. The live playground does exactly that: issue a governed key, set a budget, watch the 402 fire ahead of the spend, and export the chargeback CSV that comes out the other side.
From there, the artifact that changes the board conversation is a board-ready spend report — AI spend by business unit, against budget, with variance, drawn from the same per-call ledger your auditors would trust. Not "we spent $13,440 on providers last month," but "the search team spent $4,760 on AI, $240 under budget, and here's the row that proves it."
That's the goal. Make AI spend as governed as every other dollar — a line you can forecast, cap, and defend. Every token counts.