AI Agent Cost Attribution: From Showback to Chargeback

The provider invoice can be exact to the cent and still be useless for ownership. It tells you what the company paid. It does not say which team, which agent, which customer, or which task burned the tokens. That gap is where internal AI cost programs stall. FinOps Foundation FOCUS cost-and-usage attribution exists so practitioners can enrich billing rows with organizational metadata and aggregate billed, effective, and consumed quantities. It does not invent the tags for you after the fact. If the call never recorded who it was for, that information is gone.

This guide is the internal-economy contract for one shared agent or LLM platform. It complements AI agents cost management, which owns runaway loop caps and spend circuit-breakers, and AI automation ROI, which owns proving a workflow earns its keep after launch. It assumes you already have or are deploying a metering boundary such as an LLM gateway. Here the job is narrower: capture authenticated attribution at call time, climb showback then budgets then chargeback, bill work units rather than raw tokens, publish shared-cost rules, watch for shadow integrations as pricing signals, and export records finance can join.

Why provider invoices fail agents

Provider consoles report exact totals by API key or project. That is accounting, not attribution. Agents widen the hole because one task fans out across model calls, tool APIs, sub-agents, retries, and cache reads. Without a propagated task identity, the orchestrator's spend attributes to the orchestrator and each sub-agent's spend attributes to itself. You still cannot answer what the workflow cost.

FOCUS 1.5 release scope is moving model identity and principal columns into the billing surface so a charge can name which model was billed and which person, service, or agent drove it. Until your platform emits those fields at request time, FOCUS export only packages ignorance more neatly. FinOps for AI phases the work as crawl, walk, run, puts monitoring and tagging ahead of quotas, and asks teams to review cost trends against business outcomes. Agents get no exemption from that order.

A principal column also does not settle who should pay. The FOCUS 1.5 scope notes that these columns do not show who benefits from a charge, because shared workloads and gateways act for people who never appear in the billing data. A service account that runs a nightly job for the finance team names the service account. Decide per workload whether cost follows the caller or the owner of the use case, and record that rule next to the data. Owner of the use case is usually the fairer charge, and it needs the ownership registry described below.

Capture attribution from the authenticated session

Never take attribution identifiers from caller-supplied parameters. A team_id or tenant_id in a JSON body is a claim, not proof, and once money moves between cost centers someone has a reason to edit it. Derive identifiers from the authenticated session at the enforcement point. DeepInspect's gateway design follows this pattern: tags come from the caller's identity token, from a required application header validated against a registered list, and from routing policy.

A minimal record that survives finance scrutiny looks like this:

request_id: req_01J8COST0001
timestamp: 2026-09-23T09:14:00+03:00
principal_id: user:alice@acme.example          # from session / token exchange
credential_id: svc:support-triage-agent
agent_id: agent.support_triage
connection_id: conn.zendesk_write
team_id: team.customer_support                 # derived from agent ownership, versioned
cost_center: CC-4402
tenant_id: tenant.acme
task_id: task.ticket_4821
application_id: app.support_triage
purpose: customer_support_response             # enterprise enum, not free text
environment: production
provider: anthropic
model: claude-sonnet-4
input_tokens: 4200
output_tokens: 860
cached_tokens: 1800
tool_calls: 3
pricing_table_version: prices-2026-09-01
estimated_cost_usd: 0.0412
outcome: completed
verdict: pass

Store the applied rate beside the usage. Provider prices change. Historical dollars must stay reproducible when the price table updates. Propagate task_id and the originating principal across every hop (model calls, tools, and sub-agent dispatch), or multi-agent rollups collapse.

Six dimensions cover most internal platforms: agent, connection, principal, team, tenant, and task. Derive team from recorded agent ownership rather than letting every call invent a cost center. When ownership changes, version it so history does not silently reassign prior months.

Record what went wrong and what you cannot price

Three details separate a ledger that finance trusts from one that drifts. Each is easy to skip and expensive to retrofit.

• One row per provider response, not per request. A retry loop can pay for several responses inside one logical call. A reply that returns 200 but fails JSON parsing still cost money, and a turn that dies on its fourth attempt spent the first three. Logging only the final success undercounts spend exactly where the system is unhealthy.
• Unknown cost is NULL, never zero. The cost column is filled from the provider's own figure when one is sent, else from the price table, else left empty. An unpriced call has to show up as visibly missing from a total instead of silently free. The token counts are the durable record, and a price can always be applied to them later.
• Cache writes get their own column. Anthropic's prompt caching pricing bills writes at 1.25 times the base input price for the 5-minute lifetime and 2 times for the 1-hour lifetime, so they cannot be folded into the input count. Store total input, the cached subset, cache-write tokens and the 1-hour subset separately, and normalize providers that report only the non-cached remainder.

Attribution has to be built into the call, because some clouds only let you tag a billing resource and not a request. On Amazon Bedrock, the inference profiles documentation says tags for cost monitoring attach to an application inference profile, which you create and then call by its ARN. Cost allocation by team or tenant therefore means creating one profile per owner before launch, and a call made with a plain model ID has no owner tag to carry into the bill. Decide the owner of each call at request time, write it into your own ledger row, and reconcile the ledger against the cloud bill monthly to find calls that bypassed the tagged path.

Climb the ladder: showback, then budgets, then chargeback

Tian Pan's chargeback design names the failure mode most platform teams hit: jumping straight from free inference to invoices. Chargeback against disputed meters becomes a political fight about the dashboard instead of a conversation about usage.

Climb the ladder in order:

1. Showback. Attribute every request, convert tokens to dollars with a versioned pricing table, and publish weekly numbers to owning teams. No money moves yet. Visibility alone usually finds the nightly batch job nobody remembers approving.
2. Budgets. Soft-alert around 80%. Hard-gate at 100% with a cheaper-model fallback before a hard refusal. Keep a separate experimentation pool so prototypes do not compete with shipped features for tokens.
3. Chargeback. Move money between cost centers only after teams have lived with showback long enough to trust the numbers, and only after the dispute path and allocation rules are written down.

Skip a rung and you train teams to attack the meter instead of their usage. Billing people who cannot yet see or predict spend is how platforms lose adoption.

Some programs should stop at showback. If total AI spend is small next to the effort of running disputes, rate tables, and reconciliation, weekly visibility to owning teams does most of the work. Add chargeback when budgets are contested between teams, not because the ladder has another rung.

Bill work units, not tokens

Bill mature workloads in work units, not tokens, so teams pay for what they can change and the platform keeps efficiency margin. Product teams control which features they ship and roughly how many tasks those features perform. They do not control how many tokens the shared RAG pipeline stuffs into context, how verbose the default model is, or how the agent framework structures retries. Charging them list-price tokens taxes quantities the platform largely determines.

Prefer units a product manager can read without a tokenizer:

• resolved support conversation
• completed document classification
• evaluated pull-request summary
• finished internal research brief

Price each unit from measured costs, revise on a published cadence, and let the gap between the rate and actual token spend become platform margin for caching, routing, and pruning. The consuming team then owns volume and product mix. The platform team owns token efficiency. Token budgets also drift as prices fall and consumption rises, so quarter-over-quarter token totals stop meaning much to the business.

Keep early prototypes on a metered, non-chargebacked pool. Chargeback belongs on mature workloads with stable task definitions, not on week one of an agent experiment.

Publish shared-cost rules and keep them boring

Not everything attributes cleanly. Gateway overhead, audit stores, reserved capacity, and shared agents have fixed costs. Cached-token savings can make one team's call cheap because another team warmed the cache.

Allocate what attributes directly. Distribute the remainder by a rule you publish and keep stable. Proportional to attributed spend is the most defensible default for most platforms. Every rule is arguable. An unpublished or frequently rewritten rule is worse than an imperfect one because it gives teams grounds to dismiss the entire program. DeepInspect also argues that the record set must be tamper-evident, because a record set that can be silently altered after the fact loses the trust a chargeback pipeline needs. If a team challenges a line item, the request records behind it must still hold up.

Reconcile metered totals against the provider invoice monthly. Token counts are exact; pricing-table staleness and missing cache or batch discounts are the usual error sources. A few percent variance is usually good enough for showback and for most internal chargeback. Larger gaps mean your meter is incomplete, not that finance should invent an allocation spreadsheet.

Watch shadow integrations as a pricing KPI

Treat shadow provider integrations as a pricing-and-friction KPI before treating them only as a security block. When a team puts a corporate card on a public LLM API, they are telling you something precise: the internal platform's price, latency, or approval friction exceeds the public market once they account for hassle. Blocking egress without fixing the rate card or the two-week quota ticket drives the behavior into personal keys and browser paste, where governance risk is worse.

Instrument sanctioned-path friction: time-to-raise-budget, p95 gateway overhead, model coverage gaps, and denied experimentation requests. Pair that with egress detection. Every shadow deployment is a data point about where the internal market failed. The sanctioned path must bundle things a rogue card cannot cheaply replicate: negotiated rates, compliance review, injection defenses, observability, and failover. Otherwise enforcement alone will not stick.

Export what finance already knows how to join

A department breakdown that lives only inside an AI dashboard is still an island. Export attributed rows that map onto FOCUS-shaped cost-and-usage fields finance already uses for cloud: billed and effective cost, consumed quantity and unit, tags, and, once FOCUS 1.5 lands, principal and model identity. Keep purpose and application as stable dimensions so budget reviews can ask which business reasons consumed spend, not only which team owned it.

Do not wait for perfect FOCUS 1.5 columns. Start with call-time tags and a normalized dollar record now, then adopt principal and model-identity fields as generators support them. Authenticated attribution comes first. Schema polish comes second.

Worked example: support-triage agent on a shared gateway

This is an illustrative scenario, not a customer case. A customer-support team runs a triage agent through the shared gateway.

1. The agent authenticates. The gateway resolves principal_id, agent_id, and owned team_id and cost_center from the session and the ownership registry. Request headers may carry application_id and purpose, validated against a registry. They cannot name the billable team.
2. Each model and tool hop inherits the same task_id, so sub-agent enrichment spend rolls into one task.
3. Showback in week one shows that a nightly job re-embedding unchanged macros costs more than the daytime triage it supports. The team pauses the job, and no invoice was needed to find it.
4. The production budget soft-alerts at 80 percent. At 100 percent, new interactive traffic moves to a cheaper model, and the experimentation pool stays untouched for a summarizer prototype.
5. After a quarter of showback the team trusts, finance sets a per-resolved-conversation rate from measured cost and revises it on a published schedule. Caching improvements that lower real spend widen platform margin and do not penalize the support team.
6. A personal API key appears in egress logs. Platform reads it as a pricing signal, finds that the experimentation request path was slow, fixes the approval step, and then closes the key.

Implementation checklist

1. Put every agent model and paid-tool call behind a metering boundary that can see authenticated identity.
2. Emit the attribution record with session-derived principal, versioned team ownership, task propagation, purpose enum, usage, and applied pricing version.
3. Reject forgeable caller-supplied team or tenant IDs for billing decisions.
4. Ship showback dashboards and weekly digests before any money moves.
5. Add soft and hard budgets with a separate experimentation pool.
6. Define work-unit rates for mature workloads; keep prototypes on metered showback.
7. Publish the shared-cost allocation rule and a dispute path with tamper-evident records.
8. Reconcile meter totals to provider invoices monthly.
9. Track shadow integrations and sanctioned-path friction as pricing KPIs.
10. Export FOCUS-compatible fields finance can join; close direct provider egress after parity so untagged spend cannot bypass the meter.

Verification

The contract works when a FinOps partner can open one month of agent spend and, without a provider console, name the owning team, application, purpose, principal class, task rollup, estimated dollars, and whether the line is showback-only or chargebacked. Editing a request body must not reassign cost. Mature workloads need a unit rate a product manager can compare to business value. A shadow key should open a pricing review, not only land on a block list.

Common mistakes

• Treating the provider invoice as attribution.
• Accepting team_id from the request body in a chargeback path.
• Jumping to chargeback before showback trust exists.
• Billing tokens for quantities the platform controls.
• Mixing experimentation and production in one hard budget.
• Leaving shared-cost rules unpublished and renegotiated monthly.
• Metering only inference while tool APIs and sandboxes dominate cost.
• Blocking shadow AI without fixing rate, latency, or approval friction.
• Building an AI-only CSV that finance cannot join to existing FinOps pipelines.

Next action

List every path that can call a model or paid tool today, including notebooks, CI, and "temporary" scripts. For each path, decide how principal, team, application, purpose, and task_id will be bound from authentication and ownership and never from free-form headers alone. Send no internal invoice until forgeable identifiers are off the chargeback path and showback has survived a month of team scrutiny.

References

1. FOCUS Cost and Usage Attribution (v1.4): Official FinOps specification for enriching billing rows with organizational tags.
2. Fire in Belly AI agents cost management: First-party runaway-spend baseline that this attribution contract extends.
3. FOCUS 1.5 Release Scope: Official scope adding model identity and PrincipalId for AI spend attribution.
4. FinOps for AI Overview: Official FinOps Foundation guidance on tagging, quotas, and outcome-aligned AI cost management.
5. AI Cost Attribution Per Team (DeepInspect): Gateway tagging from identity tokens, normalized multi-provider costs, and tamper-evident records for disputes.
6. Anthropic prompt caching documentation: Cache write and read price multipliers.
7. Who Pays for the Tokens? (Tian Pan): Showback-then-chargeback ladder and work-unit billing for internal LLM platforms.
8. Amazon Bedrock inference profiles: Application inference profiles as the place cost-allocation tags attach.

---