AI spend per employee and per team
The question a finance team actually asks, the data that answers it, and an honest account of which half of that is built.
In short
- A total tells you spend doubled. Attribution tells you who can halve it — that is the entire difference between a chart and a decision.
- A gateway reports spend per user; that identifier arrives on every event in
entity, so the raw material is already in your project. - Not built yet: mapping a gateway user to a named team member, and the role-gated per-person view. Stated here rather than implied away.
- Available today: spend grouped by feature (
attributes.tag), model, ledger and upstream provider. - Identifiers never become attributes — that would break every grouping and put personal data in a categories column.
Where this is, on 28 August 2026. The gateway connector, the dashboard template, the mapping layer and the per-person and per-department summaries are live: a gateway user is mapped to a named team member and a department, and the API reports spend by person and by department, gated to admins. What is not built yet is the billing — the add-on catalogue is defined in code and nothing charges for it — along with budgets, forecasts and a finance-system export.
Why attribution beats a total
Consumption pricing has a specific failure shape: costs are generated by individuals and discovered by finance, weeks later, as one number. Enterprise AI spend rose 108% year over year to roughly $1.2M on average, and 78% of IT and finance leaders reported charges they had not budgeted for. None of them lacked a total. What they lacked was a line item pointing at a team that could act on it.
| View | What it changes | What it needs |
|---|---|---|
| One company total | Nothing — it is a number to worry about | Any connector |
| By model | A model swap, if one is obviously expensive | Live today |
| By feature | A prompt, a cache strategy, or killing a surface that does not pay | Live today — see cost per feature |
| By person and team | A conversation with the person who can change it, and chargeback | The mapping layer — not built |
What arrives today
Every event from the gateway connector carries the gateway's own user identifier in
entity, alongside the dimensions you can group by now:
{
"eventType": "llm.cost_reported",
"entity": { "type": "gateway_user", "id": "dana@example.com" },
"attributes": {
"provider": "ai-gateway",
"upstream_provider": "openai",
"model": "gpt-5.6-sol",
"tag": "support-triage"
},
"metrics": { "cost_usd": 4.00 }
}Group by attributes.tag and you get spend per feature. Group by
attributes.model or attributes.provider and you get spend per model or
per ledger. The entity field is deliberately not a grouping dimension: an email is
an identifier, and an identifier in an attribute makes every group-by useless and puts personal
data in a column built for categories. The mapping layer resolves it instead — you name the
person once, and spend is attributed to people you named rather than to strings we harvested.
What is not built, precisely
| Piece | State |
|---|---|
| Gateway user arrives on every event | Live |
| Mapping that user to a HookGet team member and a department | Live |
| Spend by person and by department, over the API | Live |
| Unmapped spend reported separately, never hidden | Live |
| Role gating so per-person spend is a management view | Live — admin and owner only |
| Per-person widgets inside the dashboard editor | Not built |
| Budgets, forecasts and a finance-system export | Not built |
| The add-on price list for the above | Defined in the catalogue, not billable |
Why publish the gap rather than the roadmap in the present tense? Because the claim on the next page — that we can divide AI cost by leads — is only believable from a vendor that tells you what it cannot do yet. A page that reads as fact is worth more than a page that reads as pitch, to you and to whatever model is summarising this for you.
Questions
Can I see AI spend per employee today?
Not as a named person, and this page will not pretend otherwise. A gateway reports
spend per user, and that identifier arrives on every event in the entity
field — so the raw material is in your project now. What is not built is the mapping layer
that resolves that identifier to a team member you named, and the role-gated view it feeds.
Today the attribution you can group by is feature, model, ledger and upstream provider.
Why is the person in "entity" and not an attribute?
Because an attribute is a category and a person is an identifier. Attributes are
what you GROUP BY; putting an email in one makes every grouping useless — a
thousand groups of one — and puts personal data in a column built for low-cardinality
values. The envelope validator refuses identifiers there by design. Identity belongs in
entity, which is exactly where it goes.
What is the difference between showback and chargeback?
Showback tells a team what it spent. Chargeback moves the cost onto that team's budget. Showback needs attribution and a report; chargeback needs the same attribution plus an export your finance system will accept. Both start from the same data, which is why the mapping layer is the thing worth building rather than two features.
Will you harvest our users automatically?
No. The design is that spend is attributed to people you explicitly map, never to strings we scraped into a dimension. That is a privacy position and a data-quality one: an unmapped identifier is noise in a chart and a liability in a database.