Guide · Govern
How to track AI spend by team and by project
The invoice is a single number. The questions being asked of you are which teams are driving it, whether the expensive usage is the valuable usage, and what to do when the number doubles — and none of those are answerable from a bill.
before you start
- Admin access to every AI provider account, including ones bought on cards.
- A decision on your attribution unit — team, project, or repository. Pick one first.
- Awareness that per-seat and per-token pricing attribute completely differently.
Why the obvious approach does not work
AI spend lands on finance as an aggregate and arrives with an implicit demand for a story. But the two dominant pricing models attribute in incompatible ways. Per-seat licences are a headcount question — the spend is fixed and the real metric is activation, whether the seats you bought are used at all. Per-token API usage is a consumption question with enormous variance between individuals. Most organisations have both, and reporting them as one line hides the only actionable part.
Attribution is genuinely hard because the identity does not travel. A developer's API key, a shared service account in CI, a team key someone pasted into a script — by the time usage reaches the provider it often carries no reliable link to a person, a team or a project. This is an identity problem before it is a reporting problem, and no dashboard fixes it downstream. If you skip the identity work, you will produce a chart nobody trusts.
The more useful question is worth separating from cost control. 'Which team spends most' is answerable and mildly interesting. 'Is this spend producing anything' requires tying cost to an outcome — a merged change, a closed ticket, a shipped feature — and that is where budget decisions actually get made. Cost per unit of delivered work is the metric that survives a CFO conversation; cost per team is the one that starts an argument.
One warning about what you do with the numbers. Publishing per-developer token spend reliably produces gaming, not savings: people avoid the tool, or split work to look cheaper, and you lose both the productivity and your telemetry. Attribute at team and project level, keep individual data for capacity planning, and say so publicly before anyone asks.
The procedure
Inventory every account and separate the pricing models
List every AI provider account including ones on personal cards, then split spend into per-seat and per-token. Report them separately from here on. Seat spend is an activation problem — are the licences used — and token spend is a consumption problem. Mixing them produces a single number that hides the only lever you have on each.
you now haveAn account inventory with spend split by pricing model, and an owner per account.
Fix identity before you build any reporting
Decide your attribution unit — team, project or repository — then make every credential carry it. Provider-side projects or organisations, one key per team rather than per person, and CI keys named for their pipeline. This is the step that determines whether your numbers mean anything, and it is unglamorous plumbing that cannot be retrofitted from an invoice.
you now haveOne credential per attribution unit, with a documented key-to-unit mapping.
Measure seat activation, not just seat cost
For per-seat tools, pull usage per licence and bucket it: unused, occasional, daily. Unused seats are the fastest saving available and require no behaviour change from anyone — and the number is usually higher than the team that requested the licences expects. Report activation rate alongside cost, because cost alone makes a fully-used tool look identical to a shelf-ware one.
you now haveActivation rate per tool, and a list of reclaimable seats.
Attribute token spend to teams and projects only
Aggregate consumption to your attribution unit and publish at that level. Deliberately do not publish per-individual token spend: it produces avoidance and gaming rather than efficiency, and you lose the telemetry along with the productivity. Keep individual data for capacity planning if you need it, and state the reporting boundary openly so nobody discovers it later.
you now haveTeam- and project-level consumption reporting, with a stated individual-data policy.
Tie cost to an outcome, however coarse
Pick one denominator you already measure — merged pull requests, closed tickets, shipped features — and compute cost per unit by team. It will be rough and it is still the most useful number you will produce, because it turns 'this team spends more' into 'this team spends more per merged change', which is either fine or a finding. Be candid about the denominator's flaws when you present it.
you now haveCost per unit of delivered work, by team, with the denominator's limits stated.
Attribute cost to artefact versions, if you can
The most valuable attribution is also the rarest: cost per session tied to the artefact versions that were active. That is what tells you whether v3 of a skill made a workflow cheaper or three times more expensive, which is the difference between guessing at prompt efficiency and knowing. Few setups can do this today; if yours cannot, note it as the gap it is.
you now haveSession cost joined to artefact versions, or a written note that this is not yet possible.
AI spend attribution model
Report the two pricing models separately at every level. Combining them is what makes AI spend reports useless.
AI spend attribution model
LEVEL 0 — ACCOUNT INVENTORY
provider · account · pricing model [ seat | token | hybrid ] · owner ·
payment method (watch for personal cards) · contractual terms
LEVEL 1 — SEAT SPEND (an activation problem)
licences purchased
licences assigned
licences used in last 30 days <- the number that matters
activation rate = used / purchased
reclaimable seats and their annual value
LEVEL 2 — TOKEN SPEND (a consumption problem)
spend by team [ publish ]
spend by project [ publish ]
spend by surface [ publish ]
spend by individual [ DO NOT PUBLISH — capacity planning only ]
month-on-month change by team
LEVEL 3 — EFFICIENCY
cost per merged change, by team
cost per closed ticket, by team
state the denominator's weaknesses openly when presenting
LEVEL 4 — ARTEFACT ATTRIBUTION (rare; the most decision-useful)
cost per session
artefact versions active in that session
cost delta across artefact versions of the same workflow
>> answers: did shipping v3 of this skill make it cheaper or worse?
IDENTITY PREREQUISITE (without this, every level above is noise)
[ ] attribution unit chosen and written down
[ ] one credential per unit, not per person
[ ] CI keys named for their pipeline
[ ] key-to-unit mapping documented and maintained
[ ] no shared keys crossing team boundariesWhere this goes wrong
- Reporting seat and token spend as one number
They have opposite levers — activation versus consumption — so a combined figure conceals both. It is the most common reason AI spend reports produce no decisions.
- Building dashboards before fixing identity
Attribution cannot be recovered downstream from an invoice. A dashboard built on shared keys shows precise, confident, meaningless numbers, and it is hard to walk back once people have seen it.
- Publishing per-developer spend
It produces avoidance and gaming rather than efficiency, and it costs you the productivity you were trying to measure. Team level is the right granularity to publish.
- Measuring cost with no denominator
Spend with no output measure can only ever be read as too high. Even a flawed denominator converts the conversation from cost control into value assessment.
Doing this without us
Levels 0 through 3 are provider consoles, a spreadsheet and the identity discipline in step two — real work, no product needed, and the seat-activation number alone usually pays for the effort. Level 4 is the one that needs instrumentation, because joining session cost to the artefact versions active in that session is not something any provider invoice can express. That join is what Vincosha Ledger exists to produce.
Frequently asked
- Why not just use each provider's own usage dashboard?
- Use them — they are the source data. Two limits: they attribute to whatever identity made the call, which is only meaningful if you did the identity work first, and they cannot see across providers, so multi-provider organisations still need a layer that reconciles them into one attribution unit.
- Should we set per-team budgets and hard limits?
- Soft limits with alerts, generally yes. Hard caps tend to fire mid-task and destroy more value than the overspend they prevented, and they train teams to hoard quota. Rate limits on the specific expensive operations are usually a better instrument than a spend ceiling.
- How do we handle CI and automation spend?
- Give every pipeline its own credential named for the pipeline, and attribute to the owning team. Automation spend is the fastest-growing and least-attributed category precisely because it starts as one shared key in a secrets store that nobody revisits.
- What is the fastest saving available?
- Unused seats, almost always, and it needs no behaviour change from anyone. Pull assignment against 30-day usage per tool before you optimise anything about consumption — the gap is routinely larger than the team that requested the licences expects.
Sources
Checked on 2026-07-25. Where a vendor control is changing quickly this guide describes the mechanism rather than asserting a current state — verify against the vendor's own documentation, and tell us if we have drifted.