Showback and chargeback for AI spend

When a company's first AI feature ships, its provider invoice has one owner. By the fifth feature, three teams share two provider accounts, a retrieval index serves all of them, and finance asks which budget the invoice belongs to. The invoice cannot answer: providers bill per account, and at best split by workspace or project.

Showback and chargeback are how that question gets a defensible answer. This guide covers the pieces in the order you need them.

Showback, chargeback and the difference

The FinOps Foundation separates the two by formality. Showback shows any group, at any granularity, the costs of the scope it is responsible for. Chargeback goes further and sends those costs to official accounting budgets¹. Neither is more mature than the other: showback is required in any FinOps practice, while chargeback depends on the organization's accounting policies¹.

For AI spend the practical consequence is to build showback first, with numbers each team recognises, and move to chargeback only when the allocation has survived a few months of scrutiny. Both run on the same allocation; chargeback adds a close and a sign-off.

Tag at the source

Allocation assigns cost using accounts, tags, labels and other metadata². Provider-side structure gets you part of the way: Anthropic's cost report can be grouped by workspace, and Anthropic lists allocating expenses by workspace for chargebacks as a use of its API³. But a workspace or project is coarse. It tells you which application ran, not which feature, which customer or which team's workflow.

The dimensions that matter for AI spend are ones only your application knows:

• Workflow — the stable name of the work, such as support-answer or nightly-indexer.
• Feature — the product feature it served.
• End customer — whose request it was, as an opaque id.
• Team or cost code — where your organization books it.

Attach them to every model call when it is made. Attribution cannot be backfilled honestly: a request that ran without a feature tag has no feature, and guessing one after the fact produces numbers nobody can audit.

import os
from openai import OpenAI

client = OpenAI(base_url="https://api.infro.io/v1", api_key=os.environ["INFRO_API_KEY"])

response = client.chat.completions.create(
    model="openai/gpt-5.6-sol",
    messages=[{"role": "user", "content": "Summarize this ticket"}],
    extra_body={
        "metadata": {
            "workflow": "support-agent",
            "trace_id": "run_8f2c",
            "feature": "summarize",
            "user_id": "cust_123",
            "tags": {"team": "support"},
        }
    },
)

Keep tag values low-cardinality where they drive grouping (team, feature) and opaque where they identify people (use a customer id, never an email address). Measure coverage: the share of cost with no workflow or team is the first number to drive down, and the FinOps Foundation uses the percentage of costs that cannot be allocated as a key indicator of allocation success².

Book with ordered rules

Tags describe a request; rules decide whose budget it lands in. The simplest scheme finance can audit is an ordered rule list where the first matching rule wins:

1. feature = summarize → Support
2. workflow = nightly-indexer → Platform
3. project = research-sandbox → Research
4. anything else → Unallocated

First-match rules make every booking explainable ("rule 2 matched"), and they make overlaps harmless: a request that matches two rules goes to the earlier one, predictably. Preview a new rule against last month's traffic before saving it, both on its own and after the earlier rules have taken theirs.

The Unallocated line must stay on every report. Spreading it across teams in proportion to their spend looks tidy and teaches everyone that tagging is optional.

Shared costs, stated openly

Some AI spend genuinely serves several teams: a shared embedding index, an evaluation suite, a platform team's routing experiments. The FinOps Foundation lists the options — hold shared costs centrally or allocate them based on consumption — and says the choice is made between the FinOps team and finance¹; some organizations deliberately budget shared items centrally rather than allocating them².

If you allocate, use one of two methods and write it down:

• Fixed weights, for example 70/30, when the split is a management decision.
• Proportional to direct spend in the same period, when the shared resource is used roughly in line with each team's own traffic.

Label the result as allocated on every report. A team reading its statement should see its own usage and its share of shared costs as separate lines.

Close the month

Chargeback needs a number that stops moving. That means a close:

• Draft, then final. Generate a draft soon after month end, regenerate it while late usage arrives, and make it final on a fixed day.
• Final is final. Never edit a final statement. Fix a mistake by issuing a new version for the same month with a written reason, and keep every version readable.
• Late usage moves forward. Usage metered after a month is final goes on the next statement as a prior-period adjustment, so the number a team already filed does not change underneath it.
• Rules are versioned by period. A reorganisation in October must not rewrite what September's statement said.

Estimates, invoices and platform fees

Every per-team figure built from requests is an estimate of what the provider bills. Say so on the statement, count unpriced requests beside the total so it reads as a lower bound when there are any, and if you reconcile against the provider's reported cost, show each team's proportional share of that reported figure as an allocation, because provider cost APIs report organization totals, never one team's. Keep AI provider cost and the fees for any tooling you use in separate lines; they are different financial concepts and do not belong in one sum.

A checklist before the first chargeback

• Workflow, feature, end-customer and team tags on every model call, validated rather than silently dropped.
• Unallocated share measured and trending down.
• Ordered rules with a preview, and a history of every change by period.
• Shared-cost method written down and labelled on statements.
• A close date, a final state, and corrections by new version only.
• Unpriced requests counted beside totals.
• Statements exported in a format finance already ingests.

Cost centers and statements in INFRO

In INFRO, attribution is on every plan: send workflow, trace_id, step, feature and user_id in the request's metadata (or as X-INFRO-* headers), and promote up to five of your own tag keys for grouping. A malformed value is refused with 400 invalid_attribution, not dropped. GET /v1/usage?group_by=feature groups estimated cost by any of them. See cost attribution.

From the Team plan, cost centers book each request by the first matching rule, lowest order first, on project, key, member, environment, workflow, feature, a promoted tag or an end-customer prefix; anything unmatched is booked to Unallocated. A rule can split by fixed weights or in proportion to direct spend, rounded by largest remainder and labelled allocated. Editing a rule closes its version and starts a new one.

Monthly statements draft on day 2 at 06:00 UTC, regenerate every 12 hours, and become final on day 5. A final statement is never updated; corrections are new versions with a reason, and late usage appears as a prior_period_adjustment. Each cost center's owner gets a signed link to their own lines. Statements download as CSV or FOCUS JSON, or through the API:

curl "https://api.infro.io/v1/statements/$STATEMENT_ID?format=csv" \
  -H "Authorization: Bearer $INFRO_API_KEY"

Every amount on a statement is an estimate of what your own providers bill you. INFRO platform fees are never on it; the subscription is invoiced separately. Where reconciliation is enabled, each line also carries its allocated_reported_cost, its proportional share of the provider's reported figure.