Who spent it? A practical guide to attributing AI agent spend

Every finance team running AI eventually gets the same question from the CFO: which team, which agent, which project spent this?

The invoice answers a different question. It tells you how much you owe Anthropic, OpenAI, AWS or Microsoft this month. It rarely tells you who caused it.

AI is becoming a workforce. Agents answer tickets, review code, draft contracts and run research, and like any workforce, their cost needs an owner, a cost center and an audit trail. That's what attribution is: deciding which agent and which department each dollar belongs to, in a way you can defend to an auditor.

This guide is about how to set that up, platform by platform. It's written for the platform engineer who configures the accounts and the finance person who checks the result.

The one idea that explains everything

Here's what we learned after mapping how every major AI platform reports cost:

The identity that reaches the bill is coarse. The identity that's precise never reaches the bill. Attribution is the join between the two.

Your provider's bill knows about the things the provider bills: a workspace, a project, an API key, a tagged resource, a seat. It doesn't know about your agents, your tasks or your users. Meanwhile, your own systems (gateways, traces, application logs) know exactly which agent made each call, but none of that appears on the invoice.

So good attribution does two things:

1. Make the bill carry as much identity as possible, by structuring accounts and tagging the right resources.
2. Join the precise identity from your own systems to the bill, and show clearly what can't be joined.

Everything below is one of those two moves.

Five kinds of identity

Every mechanism we've found falls into one of five patterns:

Knowing which pattern you're using tells you what you can attribute, and what you can't.

1. Structure your accounts so the bill carries the owner

On Anthropic and OpenAI, there's no tag channel on the bill. The only identity that reaches cost data is the account structure itself. So the most effective attribution decision you'll make is organizational: give each agent or cost object its own partition.

Anthropic. The Admin Cost Report can be grouped by workspace, daily. One workspace per agent (or per team, if that's your cost object) means the bill itself separates them. Two things to know: the default workspace has no workspace ID in cost reports, so treat it as its own bucket, and Priority Tier dollars don't appear in the cost report at all. If you're on Priority Tier, reconcile that spend from the invoice. Meridian's notes for this source are on Anthropic attribution.

OpenAI. The Costs API groups spend daily by project and by API key. One project per agent, or one key per agent within a project, gives the bill real identity. One exception: Scale Tier bundle cost is attributed to the organization, not to projects, so project structure can't split it. See OpenAI attribution.

The mistake to avoid: one shared key used by every agent. It's the easiest setup and the hardest to unwind later.

2. Tag the resource the provider copies onto the bill

On AWS, Azure and Google Cloud, you can attach your own labels, and the provider copies them onto cost rows. The catch is knowing which resource to tag and how long it takes.

AWS Bedrock. Call models through an application inference profile, not a bare model ID, and tag the profile. Then activate the tag key for cost allocation in Billing. It can take up to 24 hours for a new key to become available to activate, and up to 24 hours more to take effect. Tags apply going forward, though AWS can backfill up to 12 months on request, for months the resource already had the tag. One profile is one model, so a workload that calls several models needs one profile per model, each with the same tags. Step-by-step: How do I allocate Amazon Bedrock costs by department?.

Azure. Tag the Foundry resource and model deployments with user-defined tags. New tags take about a day to appear on usage records. Foundry's automatic project tag is in preview and covers only models sold by Azure.

Google Cloud. Add labels to each PayGo request. Labels are lowercase, at most 63 characters, and Provisioned Throughput silently ignores them. The one that catches people: a label key can be dropped after 1,000 distinct values over the billing account's lifetime, counting values you've since retired.

The mistake to avoid: tagging a resource that serves several agents with one agent's name. If a profile or deployment is shared, tag it with the cost center, not the agent.

3. Never put per-request IDs in tags

Trace IDs, session IDs, request IDs, user IDs, email addresses and timestamps don't belong in tags or labels. They're unique on nearly every request. On Google they burn through the 1,000-value limit and can get the key dropped. On AWS they waste the cost-allocation tag space. Everywhere, they make grouping useless.

Per-request identity belongs on your usage records and traces. That's where it's precise, and that's what you join to the bill later.

4. Seats are people, not agents

Microsoft 365 Copilot is licensed per user. A seat tells you who's licensed, not which agent spent it. You can attribute seats to departments, through the person's team, but not to agents. Meridian's seat file rules are on seats and licenses.

Copilot Studio is different: its credit reports break consumption down by agent, environment and user, by day, but not by message. That's real agent-level attribution, and it's worth using. See Copilot Studio attribution.

The mistake to avoid: treating "Copilot" as one product. A seat file that just says "Copilot" could mean Microsoft 365 Copilot or GitHub Copilot, which are different products, different budgets and often different owners. Use full product names.

5. Gateways and telemetry give precision, but don't split the invoice

An AI gateway like LiteLLM, Kong or Portkey sees every request, and a virtual key per agent gives you per-request attribution. OpenTelemetry traces do the same from inside your applications. This is the most precise identity you can get.

But a gateway's ledger is the gateway's own calculation. The provider's invoice still shows only the credential the gateway used upstream. To connect the two, you either give each agent's upstream calls their own provider partition or tag (pattern 1 or 2), or you reconcile: compare the gateway's measured totals to the invoice, and scale them so the books tie out.

For telemetry, put your application's agent ID in a stable attribute. OASA uses oasa.agent.id. Note that the OpenTelemetry GenAI attribute gen_ai.agent.id is now defined as the ID of a hosted agent resource, like an assistant ID or an agent ARN, not your application's own agent ID.

6. Use one convention everywhere

If every team invents its own tag keys, attribution falls apart at the first merge. Pick one convention and apply it on every platform. We use the OASA convention, an open specification, because its keys fit within the strictest platform's rules:

• oasa_cost_center: the finance object that carries the cost
• oasa_agent: the agent's stable ID
• oasa_owner: the team accountable for the agent
• oasa_project: the project or use case
• environment: prod, staging or dev

Prefixed keys avoid colliding with the project and owner tags your company almost certainly already has, which mean something else.

7. Make unattributed spend visible

Some spend will always arrive without an owner: a call that bypassed the gateway, an untagged resource, the default workspace. The worst thing you can do is spread it across departments by headcount. That hides the gap and teaches teams tagging is optional.

Instead, book it to a visible suspense line with the reason attached (no tag, no mapping, not on the bill) and fix the source. A shrinking suspense line is the best measure that your attribution is working.

8. Corrections shouldn't rewrite closed months

You'll find mistakes: a resource tagged with the wrong cost center, a mapping that pointed at the wrong team. Fix them, but never by changing a month that's already closed. A correction to a locked month should arrive as an adjustment in the next period, so the books you've already reported stay exactly as reported.

The same goes for duplicates. If spend can arrive twice, for example an uploaded invoice and a connector pulling the same vendor, default to holding the possible duplicate, not booking it.

A checklist

• One workspace, project or key per agent or cost object on Anthropic and OpenAI
• Inference profiles, not bare model IDs, on Bedrock, with tags activated for cost allocation
• Tags on Azure resources and labels on Google Cloud PayGo requests
• One tag convention, prefixed, lowercase, short values
• No per-request IDs in any tag or label
• Seats mapped to departments, with full product names
• A gateway or telemetry for per-request precision, reconciled to the invoice
• A visible suspense line, reviewed every month
• Corrections as adjustments, never rewrites

Where Meridian fits

We built Meridian to do the joining. It pulls bills from the providers, ingests gateway logs and OASA events, maps workspaces, projects, keys and tags to agents and cost centers, keeps unattributed spend visible in an inbox, and posts chargeback and journal entries to your general ledger, with every journal line traceable to the spend behind it.

It works with what each platform actually provides, and our attribution docs say exactly what Meridian reads from each source today, including the limits.

If you'd like to see where your own AI spend stands, start with a free, read-only, two-week Agent Spend Assessment. You'll get a report of your total AI spend and how much of it has an owner today, and you keep it either way.