How to attribute OpenAI and Anthropic API costs to teams

A seat is a paid license for one person, so seat spend labels itself. Buy 400 Copilot Business licenses and the vendor hands you 400 rows with 400 email addresses in them. Matching them to teams is a lookup against your HR system. The hard part is deciding what counts as active, not deciding whose seat it is.

Token spend does not work that way. A token — the unit AI vendors bill for, roughly a few characters of text — carries no name at all. A key gets issued once, pasted into a config file, copied into a second service six months later, then inherited by a team that never met the engineer who made it. The bill arrives as one number with a lot of tokens behind it and no owner in front of it.

The fix is a ladder. Split at the vendor level where the vendor supports it. Tag at the gateway — a middle layer that every request passes through — where it does not. And when you fall all the way to splitting a shared invoice by headcount, say out loud that you have stopped counting and started guessing.

The stakes are not academic. CloudBees' 2026 State of Code Abundance found organizations can attribute only about one-third of their AI spend to specific business outcomes. Most of the missing two-thirds is billed by use.

The ladder of ways to match spend to teams, best to worst

1. Vendor-level project or workspace separation

Both big vendors let you cut a company account into smaller units: projects at OpenAI, workspaces at Anthropic. Each unit gets its own keys, its own spend limits and its own line in the usage view. This is the strongest proof you can get, because the vendor's own billing system draws the line rather than your discipline. The number in the console is the number, and nobody downstream has to rebuild it.

The limits are real. The unit of separation is blunt. You get a container, not a label, so one project cannot later be cut by team *and* by feature *and* by environment. Consoles also differ in what they show and how far back they let you look. That is its own research problem, so what each AI vendor's admin console actually exposes is worth reading before you design around a report you assume exists.

Use this rung first. It costs one afternoon and it survives staff turnover.

2. Per-key naming, enforced when the key is issued

Below vendor separation sits the key itself. A key named `prod-key-2` tells you nothing. A key named `svc-search-rerank__platform-team__prod` tells you the service, the owner and the environment without anyone opening a ticket.

The word that matters here is *enforced*. A naming rule written in a wiki is a suggestion. A naming rule checked at the moment the key is issued — no key unless the name fits — is a control. Pick a separator, pick three fields, reject anything that does not match, and write the rule where keys are actually requested.

3. Tags on each request

Some endpoints accept an extra field on each call, usually named `metadata` or `user`. That lets you tag each call rather than each key. It is the finest level of detail on offer, and it is genuinely useful for splitting one service's spend across several internal customers.

Two catches. Support is patchy across endpoints and vendors, so a scheme that works for chat completions may not work everywhere you call. More important, that tag often lands in *your* logs rather than on the vendor's invoice. So you add the totals up yourself, and your total has to be checked against the bill rather than read off it. Useful. Not self-proving.

4. Tagging at the gateway

Route everything through a gateway — LiteLLM, OpenRouter, or a proxy you write — and the tagging becomes part of your own plumbing rather than part of each vendor's console. This is the only approach on the list that works the same way across every vendor. It is also the only one that survives adding a fifth model provider next quarter.

You pay for it. The gateway is one more hop in the request path, one more thing that can go down, and one more service somebody has to own. Its usage totals will drift a little from vendor invoices because of retries, streaming and caching. So you need a step that checks one against the other, and a tolerance you agreed on in advance. If your token spend is small, this is overkill. If it is your fastest-growing line item, it is the rung that stops the problem coming back.

5. Splitting a shared bill by headcount

This does not tell you who spent what. It is a rounding rule.

There is nothing wrong with using it, and you often have no other option for the current quarter. There is something very wrong with presenting it as a count. Split $180,000 of shared token spend across six teams by engineer count and you get six numbers that agree with each other and hold up as a policy. They still tell you nothing about which team is creating the load. Label it as a split policy in your AI spend chart of accounts — the list of buckets you file costs into in your books — and move on.

Splitting a shared API bill by headcount does not tell you who spent what. It is a rounding rule, and it should be labeled as one.

The operating rules that make it stick

The ladder tells you what good looks like. These four rules keep it good after the person who set it up changes teams.

One key per service per environment. Not one per team. Not one per person. The thing that burns tokens is a service, and the thing that makes a bill unreadable is a key with more than one user.

Never issue a shared "team key." It always outlives the team. It always ends up in a script nobody claims. Every shared key is a future line item you will describe in a meeting as "miscellaneous."

Rotate on a schedule, and reap what nobody claims. Rotation is a security habit that doubles as an accounting one. When a key rotates, somebody has to notice it, and the keys nobody notices are the ones to kill. A key with traffic and no owner is either an undocumented service or a dead one still burning money. Both are findings, and you want them shown each quarter rather than discovered at a renewal.

Set a spend limit on every project, even one you never expect to hit. Zylo's 2026 SaaS Management Index reports that 78% of IT leaders were hit with unexpected AI or consumption charges. A limit is the cheapest way to turn a surprise into an alert.

The problem with the past

Here is the part nobody wants to hear. You cannot match last quarter's spend to teams if the keys were not tagged last quarter. No vendor feature, no export and no clever cross-check recovers an owner that was never recorded. The tags are the record.

So the fix always starts today, and the past stays estimated. Turn on separation and naming now. Accept that the last four quarters get split by whatever stand-in you can defend: headcount, a service inventory, a sample of logs. Then put a hard line in your reporting on the date the good data starts, and stop re-arguing everything before it.

What this does to your proof level

Every number in a good AI cost report — one page that shows what your AI tools cost and what you get back — carries a proof level, so you know how much guessing sits behind it.

Counted — read straight off a bill, a seat list or a usage report. No guessing. Two people pulling the same numbers would get the same answer.

Compared — the difference between two similar teams inside your own company, over the same period. Real signal, but a difference is not proof of a cause.

Estimated — worked out from assumptions you can see and change. Always shown as a range, never a single number.

Token spend with no owner attached can never rise above estimated. It does not matter how confident the split feels, or how carefully you built the formula. If the underlying records name no owner, the result is a guess wearing a count's clothes. A CFO who marks it down is not being difficult. They are right, and the honest answer is to fix the plumbing rather than argue about the guess.

KPMG's Global AI Pulse for Q2 2026 surveyed 2,145 C-suite leaders and found 42% have only partial visibility into AI spending. Leaders with strong cost visibility were five times more likely to report established ROI than those without.

The honest caveats

Matching spend to teams tells you where the money went. It does not tell you whether the money was well spent, and a perfectly labeled $2M token bill can be perfectly labeled waste. Gateway totals will not tie exactly to vendor invoices, so expect drift from retries and cached calls, and agree on a tolerance rather than chasing zero. Vendor consoles change, sometimes quietly, so any scheme built on one export format needs an owner. The CloudBees and Zylo figures above come from vendor-published surveys whose respondents chose themselves: useful for direction, not for precision. If more than two-thirds of your own spend already has an owner attached, those benchmarks say nothing about you.

Find your recoverable AI spend

Spendassay reads your OpenAI and Anthropic usage read-only, alongside seats and repo activity. It shows you how much of your token spend has an owner attached and how much does not. That unowned share is usually the first number that changes how an engineering leader runs the budget.

`Start free` → /login?src=blog_attribute-api-costs-to-teams