Who Ordered All These Tokens? Giving AI Spend a Name in FOCUS

A pattern to steal, not a product to buy.

Your CFO leans over and asks a reasonable question: “How much are we spending on Copilot versus the agents our own team built?” You open the cost report, confident. You find… a bucket called “Other.” Next to another bucket called “SaaS.” Somewhere in there is the answer, finely shredded across a few hundred meters with names only a billing engineer’s mother could love.

AI is now a line item leadership cares about, and the pressure to allocate it — showback, chargeback, unit economics per agent or per million tokens — arrives long before the data is ready to cooperate. This post is about a small, customer-owned pattern that closes that gap. It is deliberately not an end-to-end solution; it is an idea you can adapt to whatever stack you already run.

Scope check. We’re talking about attributing the token-, Copilot- and agent-shaped AI meters — the model-consumption spend. Self-hosted model compute, storage and networking are their own conversations and stay out of this one.

The problem: two great data sources, neither of which will just tell you

FinOps practitioners have two authoritative sources for cost, and AI attribution falls neatly through the gap between them.

FOCUS — the FinOps Foundation’s open cost and usage specification — gives you a clean, vendor-neutral fact table of what you were billed. What it does not give you is a column that says “this is an output token” or “this belongs to Copilot.”

The Azure price sheet — the authoritative list of every meter you can be billed on — has the detail, but in the worst possible shape for reporting:

• AI spend scatters by how the model is sold. First-party Foundry / Azure OpenAI models land under ServiceFamily = “AI + Machine Learning”, MeterCategory = “Foundry Models”. Partner models sold through Marketplace — say, Anthropic’s Claude — land under SaaS / “Other.” The same economic thing, token consumption, ends up in different buckets. Group by the native columns and your AI cost is confetti.


• Token type isn’t a column — it’s a vibe. Whether a meter is input, output, cached, reasoning or embedding tokens is encoded only as fragments inside the meter name. Consider this meter (real in shape, invented in name):The word “input” never appears. Inp does. Every query that needs token type re-parses that string and hopes.


• Foundry Models · gpt-4o · gpt-4o-0513 Inp Global 1M Tokens

So the challenge isn’t missing data. It’s that the dimension you want to report on lives inside free text, and the grouping you’d rely on depends on a procurement accident. You can’t filter your way out of this.

Exhibit A: yes, it really is this messy

A short, illustrative sample of what the price sheet actually hands you — showing only MeterCategory, MeterSubCategory, and MeterName, because that’s all you need to feel the pain:

Look at what a naïve report has to survive: input vs. output distinguished by Inp vs. Outp; reasoning and embedding tokens hiding in the name; a Claude meter with a blank subcategory sitting under SaaS pretending it isn’t AI; and an agent meter whose name doesn’t contain “token” or “copilot” at all. One filter will never catch all of these. That’s the whole point.

The idea: classify the meters once, then join

The move is to stop asking the fact table to describe itself, and instead build a small piece of reference data you own: a meter map. You classify each meter once — with a ruleset you control — into the attributes you actually want to report on, then join that map onto every FOCUS cost row.

Four things make this work and keep it honest:

• The price sheet is the right raw material. It’s the authoritative list of meters you can be billed on — including the partner ones stranded under “Other.” Classifying from it means Claude gets put back where it belongs (Provider = Vendor, a token meter) instead of lost in SaaS.


• One row per distinct meter. The map is keyed on the meter identifier, and because FOCUS carries that same identifier as x_SkuMeterId, the join is a clean lookup — enrichment, not a cost fan-out.


• You infer, gently, from shape. A first-party meter’s identifier looks different from a partner one — enough to derive Provider without trusting the inconsistent native service name.


• It’s a classification aid, not a pricing one. Prices still come from your normal cost data. The map only adds labels.

The ruleset: four questions, not a spec

The temptation here is to publish a rulebook. Resist it — the value isn’t the regexes, it’s deciding what business question each layer answers. Structure your ruleset in layers, each earning its keep:

A few notes on why each layer exists, because the “why” is what you’ll actually adapt:

• General rules draw the boundary and the ownership line. Inclusion is broader than one keyword — token meters name themselves with tokens, Copilot meters with copilot, but agents often do neither, so you fold in known agent subcategories explicitly. Provider comes from the meter’s shape, not its service name, so partner spend stops hiding.


• Token rules manufacture the dimension FOCUS never had. Input vs. output is the difference between “cheap context” and “expensive generation,” and it’s only legible if you decode Inp / Outp / reasoning / embed and normalize the deployment location. This is the layer finance quietly cares about most.


• Copilot rules un-scatter a product family that’s spread across service families, and flag the commitment purchases (credits, reservations) that behave differently from consumption. Normalizing to a handful of reporting groups is what lets one chart say “Copilot spend by kind.”


• Agent rules exist because agents are the new cost center and the meters are the least self-describing of the lot. Give them precedence over the Copilot logic so an agent meter is reported as an agent, not misfiled as a generic Copilot.

Keep the layers ordered and let earlier, more specific rules win. That precedence is the difference between “explainable” and “why is Dragon in the GitHub bucket.”

The payoff: the row that finally makes sense

Here’s the before-and-after that makes it real. One opaque FOCUS cost row, as it arrives:

…and the same row after the join with your meter map:

Multiply that across every AI meter and the reports you couldn’t build yesterday fall out for free:

• Input vs. output vs. cache token spend, trended — first-party and partner models on the same axis, without touching Microsoft’s native columns.


• Copilot spend by reporting group (M365, Security, GitHub, Fabric) in one chart instead of a scavenger hunt.


• Top agents by cost — a real answer to “what is Agent X costing us this month,” which is exactly the chargeback question that started this whole thing.


• Unit economics — cost per million tokens, cost per agent — because the dimensions finally exist as columns.

Note how this is a different thing than the diagram three sections up. That was the plumbing. This is water coming out of the tap.

“Isn’t this Microsoft’s job?” — and what it really takes

A fair objection: shouldn’t the spec just add these columns and save you the trouble? Two honest answers.

First, FOCUS is a vendor-neutral standard that evolves deliberately — new columns land across releases, not overnight, and they arrive when every cloud can populate them consistently. Betting your Q3 chargeback on that timeline is optimistic.

Second, and more fundamentally: the mapping from meter to your business — which Copilot belongs to which team, which agent rolls up to which cost center — is inherently yours to own no matter how good the spec gets. A standard can tell you it’s an output token. It can’t tell you it’s the marketing team’s output token.

So, expectations set honestly:

• This is ongoing, not one-and-done. New models and meters show up every month. Give the map an owner, not just an author.


• It’s only as good as the meter name. Where a coarse plan or credit meter doesn’t name the token type, don’t guess — take type and volume from your application telemetry and let the map handle Provider and product.


• Keep it honest with a bucket named “Unclassified.” Anything the ruleset can’t confidently place goes there, visibly. A new model launch should show up as a growing Unclassified slice you investigate — not silently miscounted into a number you’ll defend in a meeting. Reconcile the classified total back to your overall AI spend before anyone publishes a chargeback.

Go build your own

You don’t need this exact ruleset, or this exact stack. You need three moves: a list of the meters you’re billed on, a classification you own and can explain, and a join back onto your FOCUS cost data. The rest is deciding which questions are worth answering — and giving the thing an owner so it’s still true next month.

Your CFO is going to ask again. Next time, have a column ready instead of a shrug.

Illustrative meter names and figures above are invented for clarity; the shapes and behaviors are real. FOCUS is a FinOps Foundation open standard; see also FOCUS in Microsoft Cost Management and the Azure MCA price sheet schema.