# How to attribute AI spend to the initiative that owns it
> A single AI bill assigned to 'IT' teaches you nothing. Give each initiative its own metered credential up front, and spend attributes itself. The mechanism, the topology decision, and why you cannot reconstruct it later.
Published 2026-06-23 · 8 min read · AI enablement
Source: https://prasad.tech/blog/attribute-ai-spend
---
At the end of the month a single number arrives: the company's AI bill. It is assigned to "IT." Nobody can say which of the last month's initiatives spent it, so the only conversation available is whether the number is too big. That is the conversation that kills AI programs, and it comes from how the spending was set up.
I run internal AI enablement as a [P&L](/blog/ai-enablement-pnl/), and the whole model depends on answering one question for any project: what did it cost, and what did it return. You cannot answer the second half if you cannot answer the first. So attribution is not a reporting nicety I add at the end. It is the first thing I set up, before the first token is spent.
## The mechanism is a credential
The instinct is to attribute spend after the fact by tagging logs or building a chargeback spreadsheet. That work is tedious and it ages badly. The cleaner approach uses a fact about how providers already bill: they group cost and usage by workspace and by key. So if each initiative gets its own metered credential before the work starts, the provider's own reporting does the attribution for you.
Concretely, give each initiative either its own API workspace or, at minimum, a key named after it. Every request made for that initiative flows through its credential, and the provider's cost API rolls the spend up by that dimension. When you want to know what an initiative cost, you read it off the dashboard. You do not reconstruct anything.
```mermaid
flowchart LR
subgraph init["Per-initiative credentials"]
k1["key: crm-cleanup"]
k2["key: support-agent"]
k3["key: analytics-copilot"]
end
k1 --> api["Provider cost + usage API"]
k2 --> api
k3 --> api
api --> roll["Spend rolled up
by key / workspace"]
roll --> view["Monthly view:
cost per initiative"]
```
There is a second plane that has to meet the first, because AI spend is only half of what an initiative costs. The other half is the engineering effort. On our side, hours map to an initiative through a simple rate, and that number lands in the same monthly view as the token spend. The result is one report where each initiative shows its full cost against what it returned, and finance can read it without anyone doing archaeology.
## The topology decision you have to make up front
Here is the honest wrinkle, and it is the reason this has to be a day-one decision. Provider cost reporting often groups cost by workspace or by description rather than by individual key. So if you want clean per-initiative cost, you decide the workspace-and-key layout before the work starts and give each initiative its own bucket.
If you skip that and run everything through one shared key, you are left estimating each initiative's cost from its share of total tokens. That estimate is workable at small scale and degrades as usage grows and initiatives overlap.[^estimate] The gap between reading the real number and inferring it is the gap between a P&L and a guess, and it is decided entirely by how you set up credentials on the first day.
A useful gateway pattern helps here without adding much work. Route all model traffic through one place that holds the real provider keys and issues a scoped virtual key, a stand-in credential the gateway maps back to the real one, per initiative or per developer. Every token, whether it went to an expensive frontier model or a cheaper one, then shows up in a single stats view keyed by initiative. The [FinOps Foundation's "FinOps for AI"](https://www.finops.org/wg/finops-for-ai-overview/) work has good tooling and vocabulary for exactly this, and it is worth borrowing from rather than inventing your own.
## Go further: cost per outcome
Once you can see spend per initiative, take one more step and divide it by the work it produced. Cost per support ticket resolved. Cost per lead qualified. Cost per document processed. Total spend on its own is a number with no meaning attached; a bill that doubled is a problem if the output stayed flat and a win if the cost per resolved ticket halved.
Cost-per-outcome is also what makes the "turn it off" decision easy and unemotional. An initiative whose cost per outcome is not moving in the right direction gets paused, and because its spend was attributed all along, turning it off actually removes the cost rather than leaving it buried in the shared bill. The showback and chargeback ideas from cloud FinOps carry over cleanly: showback to make each initiative's cost visible to its owner, chargeback when you want the owning department to actually carry it.
## Attribution comes first
Of the four moves in running enablement as a P&L, attribution is the one that gets skipped, and skipping it quietly breaks the other three. You cannot gate projects on a number if you cannot see what they cost. You cannot decide which pains were worth automating if the spend is pooled. You cannot defend the budget to a CFO with a story; you defend it with a table that shows each initiative's cost against its return.
The phrase I keep coming back to is that the spend you cannot see is the spend you cannot cut. A token that flows through a labelled credential is a token you can later decide was wasted and stop spending. A token that flows through an anonymous shared key is gone with no lesson attached. The whole apparatus above exists to make sure every dollar carries the label of the thing that spent it, from the first day rather than the last.
## Key takeaways
- A single AI bill assigned to "IT" hides the one thing you need: what each initiative cost. Attribution turns that number back into per-initiative cost you can act on.
- Give each initiative its own metered credential (a workspace or a named key) before the work starts, and the provider's cost reporting attributes spend for you.
- Decide the workspace-and-key topology up front. Provider cost reporting groups by workspace or description, so per-key cost recovered after the fact is an estimate rather than the real number.
- Meet the spend plane with an effort plane (hours mapped to an initiative through a simple rate) in one monthly view finance can read.
- Divide spend by the work it produced. Cost-per-outcome, rather than total spend, is what tells you whether an initiative is worth continuing.
This is the deep version of one move in [running AI enablement as a P&L](/blog/ai-enablement-pnl/). If you are setting this up and want to compare notes on the topology before you commit to it, you can [book a short call](/book/).
[^estimate]: If you are running two or three initiatives that barely share models, the token-share estimate is close enough to act on. It is when initiatives multiply and share the same models that the shares blur, so the point where you have to switch to real per-credential metering is worth watching for rather than guessing at.
---
## Common questions
**Why is a single AI bill assigned to 'IT' a problem?**
Because it hides the one thing you need to run AI as a business: what each initiative cost. If the whole bill sits under IT, you cannot tell which projects earned their spend and which were experiments that never paid off, so the budget conversation collapses into a single unhelpful sentence, 'AI is getting expensive.' Attribution is what turns that one number back into per-initiative cost you can act on.
**What is the simplest way to attribute AI spend to an initiative?**
Give each initiative its own metered credential before any work starts. That can be a separate API workspace, or at minimum a key named after the initiative. Provider cost and usage reporting groups spend by workspace or key, so every dollar already carries the label of the thing that spent it. You read the number off the provider's own dashboard instead of reconstructing it.
**Why can't I just work out per-initiative cost later from the logs?**
Provider cost reporting usually groups spend by workspace or description rather than by individual key, and token-level logs do not carry a clean initiative label unless you put one there. You can approximate an initiative's cost from its share of total tokens, but it is an estimate, and it gets less trustworthy as usage grows. Designing the workspace-and-key topology up front is the difference between reading the real number and guessing at it.
**What is cost-per-outcome and why does it matter more than total spend?**
Cost-per-outcome divides the spend by the unit of work it produced: cost per support ticket resolved, per lead qualified, per document processed. It matters because total spend on its own says nothing about value. A bill that doubled is bad if the work stayed flat and fine if the cost per resolved ticket halved. Attribution by initiative is what lets you compute cost-per-outcome at all.