Executive summary

AI has become a board line item. For most CFOs, it is the one line they can't forecast, can't cap, and can't defend call-by-call the way they defend every other dollar. Twelve months ago it was a rounding error inside "software." Now it is the fastest-growing and least-governed thing on the P&L.

The scale is not a guess. IDC has worldwide AI spending more than doubling to roughly $632B by 2028 — a ~29% CAGR (IDC, Worldwide AI and Generative AI Spending Guide), with generative AI growing faster still. A line growing that fast, with that little control, is a governance gap — and it is new.

Here is the contrarian part. When you ask about AI spend, someone on the engineering team shows you a dashboard: token counts, latency charts, a per-model breakdown. It is 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?"

This playbook is the framework to close that gap. It covers the five controls a finance leader needs, the chargeback model that survives a finance review, the board conversation and the four-slide deck that carries it, and an eight-question checklist to tell governance from visibility. It closes with the "after" — how a spend control plane produces each artifact as a byproduct rather than a spreadsheet exercise.

The goal is simple: make AI spend a line you can forecast, cap, and defend. Every token counts.

Section 1 — The five controls a CFO needs

Everything in this playbook reduces to five controls. Each one is something you can demand of a vendor, a platform team, or an internal build. If you have all five, AI spend is governed. If you are missing any, you have visibility into a line you still can't defend.

Control 1 — Attribution to teams, projects, and customers

What it is. A per-transaction record of who spent each AI dollar — which team, which project, which end customer — captured at the moment of the call, not reconstructed after the fact.

Why it matters. The first question isn't "how much did we spend on AI?" You can answer that from the provider invoice. The real question is "which team, project, or customer spent it, and does it map to revenue?" Most AI infrastructure can't answer it, because the API key is shared — one key, every workload, no owner. When the invoice arrives there is no way to split it by the thing your chart of accounts actually tracks. A blended "$58,000 on Anthropic in June" is an operations cost with no owner; it is not something a board can act on.

What to demand. Attribution captured at call time across five dimensions — WHO (the person or agent persona), HOW MUCH (the budget), WHY (the project and task), WHERE (the location), WHEN (the timing). Insist that the roll-up be authoritative — a team's spend is the exact sum of the calls tagged to it, traceable down to the individual request — not a monthly estimate or an allocation guess.

Control 2 — Hard caps that stop overspend before it happens

What it is. A budget that is enforced ahead of the spend: when a key or project hits its cap, the next call is blocked before it reaches the provider.

Why it matters. AI spend has a failure mode no other line item has. A leaked deploy key or a runaway agent loop can turn $340 into $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.

What to demand. A hard budget cap enforced at the gateway — the layer that sits in front of every AI call. When the budget is exhausted, the next call should return HTTP 402, Payment Required, before it reaches the provider, not appear as a line on next month's invoice. Pair it with a one-click kill switch on any key, team, or workload, so a runaway agent is a contained incident, not a board conversation. The test question: is the cap a wall, or a warning?

Control 3 — Chargeback finance can reconcile to the invoice

What it is. An attribution export that reconciles to the provider invoice — to the row — and posts to the general ledger in finance's language, not engineering's.

Why it matters. Attribution is only useful if it survives a finance review. If the chargeback number is a black box, the model won't last a budget meeting where someone challenges it. And if the period in your chargeback doesn't match the period in the underlying invoice, reconciliation becomes a quarterly forensic exercise instead of a twenty-minute cross-check.

What to demand. A per-org chargeback CSV — one row per GL code, with total cost, call count, and period — derived from the same per-call record that generated the actual API spend. 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. Because both the chargeback and the actual bill derive from one record, period-close becomes a reconciliation, not an investigation. (The full model is Section 2.)

Control 4 — A forecast you can defend

What it is. Per-team, per-project run-rates that trend month over month, with variance you can explain — plus anomaly alerts that catch a deviation the day it happens.

Why it matters. You can't forecast a line built on one shared key with no owner. You can forecast run-rates that trend predictably. And because AI spend compounds faster than any other cloud category, the trend line matters more than the point estimate — a flat number hides a curve that's about to bend. A forecast you can defend is one where the surprises are caught while they're still small.

What to demand. A real run-rate per team and per project, built on attributed spend and budget windows — the input a defensible forecast is made of. And spend-anomaly alerts that fire the moment spend deviates from plan: a 40× spike at 03:14 should be flagged the instant it happens, not discovered in next month's variance analysis.

Control 5 — Audit-grade evidence for the board and auditors

What it is. An immutable record of who spent what, on which model, with an evidence pack mapped to the frameworks your auditors and customers care about.

Why it matters. 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. Governance you can't prove isn't governance.

What to demand. 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, a continuous evidence pack mapped to the standards that matter for AI: 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 — not assembled under deadline.

What finance needs vs. what an observability tool gives you

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.

Section 2 — The chargeback model

A chargeback model is the mechanism that moves AI spend from "operations cost" to "business-unit cost." Here is how to build one that survives a finance review.

The five dimensions

Every governed call should answer five questions before a token is spent. These are the dimensions your chargeback is built on:

• WHO — the person, team, or agent persona that made the call.
• HOW MUCH — the budget the call draws against.
• WHY — the project and task that generated it.
• WHERE — the location or environment.
• WHEN — the timing (the period the spend belongs to).

Because these are captured at call time, the attribution is authoritative rather than estimated. That is the difference between a number finance can post and a number finance has to defend on faith.

The three-layer attribution model

The cleanest chargeback has three layers:

1. Provider cost. The actual USD from your provider's invoice. This is the source of truth. Everything else is an allocation of this number.
2. Gateway allocation. Each call is attributed to an (org, project, task_class) at the time of the call — the authoritative per-transaction record.
3. GL mapping. Finance maintains a rule table that maps (org, project, task_class) tuples to GL codes and cost centers. This converts the gateway's technical attribution into the financial system's language.

Layers 2 and 3 together give you per-GL-code cost, per period, derived from the same transaction record that generated the actual API call.

The GL mapping rule table

The rule table is the piece that requires the most coordination with finance. The structure:

org    | project  | task_class | model | gl_code       | cost_center
-------|----------|------------|-------|---------------|------------
acme   | search   | retrieval  | *     | 7400-AI-PROD  | ENG-SEARCH
acme   | search   | *          | *     | 7400-AI-PROD  | ENG-SEARCH
acme   | *        | *          | *     | 7400-AI-MISC  | ENG
*      | *        | *          | *     | 7400-AI-MISC  | UNALLOC

Matching is most-specific-first. A call from org acme, project search, task class retrieval matches the first rule. A call with only org and project matches the second. A wildcard-only call falls through to the last rule — the UNALLOC catch-all. That catch-all is important: a high unallocated percentage is a signal the rule table needs updating, not a silent leak. Finance owns this table; engineering doesn't touch it after setup, and the lead who ships a new project owns the rule update before the feature goes live.

The worked example — what the monthly report looks like

This is the conversation finance wants to have — not "we spent $5,540 on Anthropic," but "the search team spent $4,760 on AI in May, $240 under budget."

The platform team is over budget — that's a conversation. The search team is under — potentially a sign the feature is underperforming, or that the budget was set conservatively. Either way, it's a managed number, with an owner and a variance you can explain.

Reconciliation — the step teams skip

At period close: export the ledger for the period, cross-check total estimated cost against the actual provider invoice (a small variance from rounding is expected — document it), produce the CSV (one row per GL code), and distribute to finance for posting. Skip the cross-check and you drift: a 2% variance per month is ~24% over a year — enough to make the whole model look unreliable. Monthly reconciliation is a twenty-minute procedure. Do it.

Don't forget embedded AI

Direct API costs attribute to the call level. Per-seat tools (Copilot, Cursor) don't — allocate those to the cost center that employs the seat holder. It's an approximation, but a chargeback that covers direct API but excludes per-seat tools understates engineering's true AI spend. Include it.

Section 3 — The board conversation

The board doesn't want a tour of your model stack. It wants defensible answers to four questions. Get all four right and AI spend becomes a governed line like any other. Get any wrong and it becomes the thing that gets flagged every quarter.

The four questions

Question 1 — "How much are we spending on AI?"

This sounds like the easy one. It isn't, because the honest answer is usually a range, and a range makes boards nervous. What the board wants is one number, trending, by month — the current figure, the prior twelve, and the trajectory. Most organizations can't produce this cleanly: spend is spread across direct invoices, per-seat tools, and embedded SaaS AI, each on its own billing cycle. The artifact that answers it: a monthly total drawn from the per-call ledger — one number, any period, always current, because it's a query rather than a reconciliation project.

Question 2 — "On what, and who?"

A blended provider invoice fails this completely. The board wants attribution: by team, by product, by customer — the difference between a cost you report and a cost you can manage. The artifact that answers it: the five-dimension attribution rolled up into the chargeback CSV — per-team, per-product, per-customer cost, reconciled to the invoice total.

Question 3 — "What's the return?"

A number without a denominator is just a bill. The unit that matters is cost per successful task, per feature, tied to the outcome — not cost per token. If support-triage costs $0.14 per resolved ticket and each ticket saves twenty minutes, that's a defensible ROI story; if half the calls are retries that resolve nothing, that's a conversation to have now rather than at the annual review. The artifact that answers it: per-request, per-task cost attribution, divided by the outcome that matters for that feature.

Question 4 — "What stops it running away?"

The one that keeps a CFO up at night. A single misconfigured agent can 100× the bill overnight, and native dashboards show the damage a day later. The board wants a mechanism, not "we monitor it closely." The artifact that answers it: hard caps enforced at the gateway (a 402 before the call), spend-anomaly alerts that fire while the spend is happening, and an append-only audit of every allocation and denial.

The mapping

The four-slide board deck

Four questions, four slides. Build them once and reuse the shape every quarter.

Slide 1 — The number. One headline figure for the current month, a twelve-month trend line behind it, and a single annotation on the trajectory ("up 18% QoQ, driven by the new agent feature"). Nothing else.

Slide 2 — The attribution. A stacked bar or table: AI spend by business unit, with the top product and top customer called out. The slide that proves the number has owners. Sourced directly from the chargeback CSV.

Slide 3 — The return. For the two or three AI features that matter, cost per successful task next to the outcome it drives. The slide that reframes spend as investment.

Slide 4 — The controls. The caps in place, the budget headroom remaining, and the anomaly-alert posture. One line: "hard caps enforced at the gateway; no single workload can exceed its budget." The slide that lets the board stop worrying.

The reason most AI-spend board slides are late, hedged, or wrong is that they're assembled by hand — three invoices, a spreadsheet, a guessed team split, and a hope that nobody asks a follow-up. That model doesn't survive a board that's paying attention. Generate all four from the ledger instead, so when a director asks "why did the search team jump in May," the drill-down is already there.

Section 4 — The governance checklist

Is your AI spend actually governed? Eight questions. Run this checklist. If you answer "no" to three or more, you have visibility, not governance.

1. Can you attribute last month's AI spend to a specific team, project, or customer — without asking engineering to run a query?
2. Is there a hard cap that blocks a call when a budget is exhausted, or only an alert?
3. When an agent or key runs away, can someone freeze it in one click?
4. Does your AI chargeback reconcile to the provider invoice, to the row?
5. Can finance post AI spend to the GL without a manual spreadsheet step?
6. Do you have a per-team run-rate you'd put in a forecast?
7. Would a spend spike be caught the day it happens, or in next month's close?
8. 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.

Closing — the "after"

A spend control plane is the layer that sits in front of every AI call and produces each of these artifacts as a byproduct — not a spreadsheet exercise. Here is how each control maps to something the platform generates:

• Attribution → the Token Ledger. Every call flows through a governed Virtual AI Key (tk_live_…) and is recorded across five dimensions — WHO, HOW MUCH, WHY, WHERE, WHEN — at call time. The authoritative per-transaction record a chargeback needs.
• Hard caps → a 402 before the call. Budgets are enforced at the gateway. When a key or project hits its cap, the next call returns HTTP 402 and never reaches the provider — plus a one-click kill switch on any key, team, or workload.
• Chargeback → CSV + GL. A per-org chargeback CSV, one row per GL code, mapped through finance's rule table and reconciled to the same per-call record that generated the actual bill.
• Forecast → run-rate + anomaly alerts. Per-team, per-project run-rates you can defend, with anomaly alerts that fire the instant spend deviates from plan.
• Evidence → append-only audit + framework pack. An append-only audit trail enforced at the database layer, plus a continuous evidence pack mapped to SOC 2, ISO 27001, ISO 42001, and the NIST AI RMF.

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."

Make AI spend as governed as every other dollar — a line you can forecast, cap, and defend. Every token counts.

See it live: run a real call through the gateway at the playground, or request a board-report demo. Tokenality — the AI spend control plane. Make every token count.

Preview product; design-partner customers awaiting sign-off. Framework references — SOC 2, ISO 27001, ISO 42001, NIST AI RMF, and FinOps Foundation practice — are provided as governance guidance, not certification. IDC figure: IDC Worldwide AI and Generative AI Spending Guide.