Where does your company's AI spend actually go?

Ask a CFO what the company spends on AI and you get a number. Ask who spent it and the room goes quiet. That is not a failure of discipline. It is what the bills look like. An AI invoice is a total, sometimes a total per project, and almost never a total per person. The company knows it paid, and it does not know what it paid for.

This post is about closing that gap: why the number resists breaking down, where the pieces actually are, and what a complete picture looks like once you have assembled one.

Why the total is easy and the breakdown is hard

Three things make AI spend different from the rest of the software budget.

It bills by usage, not by seat. A CRM costs a fixed amount per user per month, and the finance team can divide the invoice by the headcount and be right. An API bill scales with tokens. One engineer running an agent in a loop can spend more in an afternoon than a whole department spends in a month, and the invoice will not say which.

The same company buys it in three shapes at once. There is the API, billed by the token to a workspace or a project. There are enterprise seats, like a Claude Enterprise or ChatGPT Enterprise contract, billed as a commitment with usage credits on top. And there is the long tail: a Max plan on a corporate card, a coding assistant a team expensed, a transcription tool someone signed up for. Each shape lands in a different place in the books and none of them share a key.

The identifiers are not people. Providers report usage by API key, by workspace, by project. A key is a string. It might belong to one person's laptop, or to a production service, or to a shared team login that fourteen people paste from a wiki page. Nothing on the invoice resolves it.

Put those together and you get the familiar state: a growing line item, a rough sense that engineering and sales are the big consumers, and no defensible answer to "who".

Where the pieces actually are

The good news is that the data to answer the question exists. It is just spread across five places that were never designed to be joined.

Each row is a source you can read today with the right credential. The work is not in getting the data. It is in the join.

The join is the whole job

Every piece above names something different. API usage names a key. API cost names a workspace. Seat usage names an email. The CRM names a person. The card program names a cardholder. To answer "who spent it" you need one identity spine that all of those resolve to, and the obvious candidate is the work email address.

A person is an email. A seat resolves to that email directly, because the enterprise products already know who was signed in. A CRM user resolves to it directly. A key resolves to it only if you know who owns the key, which is sometimes recorded by the provider and often not. A cardholder resolves to it by name, which is fuzzy but workable.

Once the spine exists, the arithmetic is straightforward. Take each day's cost bucket from the provider, split it across the keys that used tokens that day in proportion to their tokens, and now a dollar figure sits on each key. Follow the key to its person. Follow the person to their team. Sum.

What does not resolve is as important as what does. A key nobody has claimed is real money with no owner. The honest thing is to show it as unattributed, at the top of the list, rather than to spread it across everyone or to drop it. Unattributed spend is a queue of decisions waiting to be made, not an error to hide.

What a complete picture looks like

When the join is done, the shape of the answer is not a pie chart. It is a grid: one row per person, one column per day, darker where more was spent. A finance leader reading it for the first time tends to say the same two things.

The first is "I had no idea this person was spending that much." There is always one. Usually it is someone running an agent, sometimes it is a shared key that turns out to be a whole team, occasionally it is a service account that should never have been counted as a person at all.

The second is "most of it is a handful of people." AI spend concentrates the way most usage-based costs do. The median seat costs almost nothing. The top few percent of users account for most of the bill. That is not a problem to fix. It is the thing to understand, because the question that follows is whether those few are the people producing the most, and that is a question you can now ask.

What to do with it

Visibility on its own does not save money, and saving money is not the point. The point is that once spend sits next to a person, it can sit next to what that person produced: the deals they closed, the meetings they booked, the pull requests they merged. The number the board will eventually ask for is not "what did we spend on AI" but "what did we get for it", and you cannot answer the second without first answering the first, per person.

So the sequence is: read every source, resolve every identifier to a person, show what will not resolve, and then put spend and output side by side. That is the order, and the first step is the one most companies have not taken.

Arbitir does this join as a product. It reads usage from Anthropic and OpenAI, the API surfaces and the enterprise seats, resolves every key and seat to a person by email, keeps what will not resolve in an unmatched queue, and shows the result as spend by person and day next to the revenue from your CRM. It reads usage metadata only, never a prompt or a conversation.