What should an AI chargeback policy include?

Six clauses: what spend is in scope, how usage is attributed to a cost center, how shared and unattributable spend is handled, the freeze date after which a period's numbers are final, the dispute process and its deadline, and who owns changes to the allocation rules. Everything else is detail; those six are what disputes turn on.

How do you handle AI spend that can't be attributed to a team?

Publish it as its own line — an unallocated bucket — rather than spreading it across teams. A visible number creates pressure to fix the underlying mapping and is honest about what you do and don't know; a silent proportional allocation buries the problem and gives every team a small figure they cannot verify, which is how trust in the whole report is lost.

Should we start with showback or chargeback?

Showback, for at least one full cycle. Showback publishes what each team spent without moving money, which surfaces the attribution errors — misassigned keys, shared service accounts, untagged workloads — while they are still cheap to fix. Chargeback moves the cost onto a team's budget, and the first disputed invoice will be about the mapping, so the mapping needs a cycle of scrutiny first.

How do you make an AI chargeback number defensible?

Three properties. It has to reconcile to the provider invoice rather than being estimated from a price table. The mapping from usage to cost center has to have been recorded at ingestion, so it can be shown rather than re-derived. And every change to an allocation rule or budget has to be in an append-only audit log with a timestamp and an author, so 'why is this different from last month' has an answer.

Writing an AI spend chargeback policy: what to put in it

The disputes are never about the amount. They are about the mapping, the timing, and what happens to shared spend — so write those down before you move any money.

By Quordo · Published 2026-07-27 · Updated 2026-07-27 · 7 min read

Key takeaways

An AI chargeback policy needs six clauses: scope, the attribution method, the treatment of shared and unattributable spend, a freeze date after which the number is final, a dispute process with a deadline, and a named owner for rule changes.
Every real chargeback dispute is about the mapping or the timing, not the amount — so the policy's job is to make both auditable and agreed in advance.
Unattributable spend should be published as its own line rather than spread silently across teams; a visible unallocated bucket creates pressure to fix the mapping, whereas a silent allocation hides it.
Run showback for at least one full cycle before charging back — the first cycle exists to surface attribution errors while they are still cheap to fix.

Steps

Define scope List exactly which spend the policy covers: which providers, which account or subscription boundaries, and whether AI features embedded in third-party SaaS are in or out. Name the exclusions explicitly rather than leaving them implied.
Fix the attribution method State how a usage event maps to a cost center — per-connection (each team holds its own provider key or project) or per-request tagging — and state that the mapping is applied when usage is recorded, with cost stored denormalized at that moment so historical periods do not move.
Decide the treatment of shared and unattributable spend Choose one rule for shared platform workloads (a fixed platform allocation, a usage-weighted split, or absorbed centrally) and one for spend that maps to nothing. Publish unattributable spend as its own visible line rather than distributing it silently.
Set a freeze date Name the day of the month after which the prior period's numbers are final, chosen to sit after every provider has posted late charges. Corrections found later go to the current period as an adjustment rather than reopening a closed one.
Write the dispute process Give teams a deadline (typically ten working days from publication), require a dispute to identify the specific events or mapping believed wrong, and state that the audit log of allocation-rule and budget changes is the evidence both sides argue from.
Name an owner for rule changes Say who can change an allocation rule, that changes are announced before the period they affect, and that they are never applied retroactively to a closed period. Record every change in an auditable log.
Run showback for at least one cycle first Publish the same numbers without moving money for at least one full period. The first cycle exists to surface misassigned keys, shared service accounts, and untagged workloads while correcting them is still free.

The direct answer

A chargeback policy for AI spend needs to answer six questions in writing: what is in scope, how usage maps to a cost center, what happens to shared and unattributable spend, when the number becomes final, how a team disputes it, and who is allowed to change the rules. Those six exist because they are what every real dispute is about. Nobody argues that $6,200 is not $6,200; they argue that half of it belongs to another team, or that the number changed after they saw it.

The policy is short — a page or two — and its value is entirely in having been agreed before the first invoice rather than negotiated after it. What follows is what each clause needs to say and the failure mode it prevents.

Scope: name the exclusions

State which providers and which account boundaries are covered, and be explicit about the awkward edges: AI features inside third-party SaaS billed to a corporate card, individual seat subscriptions for AI coding assistants, and spend inside a cloud account that also carries non-AI workloads. Each of these is defensible to include or exclude; what is not defensible is leaving it implied, because the first team to receive a charge they didn't expect will contest the whole report rather than that line.

Write exclusions as a list, not as silence. 'Seat-based assistant subscriptions are charged to the owning department directly and are out of scope for this policy' takes one sentence and closes an entire category of argument.

Attribution: say how the mapping works and when it is applied

Name the method. Per-connection attribution — each team holds its own provider key or project, and the key implies the team — is the one most organizations can actually deploy, because it needs no application code changes. Per-request tagging gives finer granularity within a team but requires every caller to stamp requests, which in practice means it covers the services someone remembered to update. Many organizations run per-connection as the baseline and tagging where the granularity is worth the effort. The mechanics of both are worth settling before the policy is written, because the policy has to describe what you actually do.

The clause that matters most is about timing: the mapping is applied when usage is recorded, and the cost is stored denormalized at that moment. This is what makes past periods stable. Without it, rotating a key or a provider changing a price silently rewrites last quarter, and a report that changes after publication is a report nobody trusts again.

Shared and unattributable spend: pick a rule and publish the leftovers

Some AI spend genuinely belongs to no single team — a shared retrieval service, a platform-owned evaluation harness, a model gateway everyone calls. Choose one treatment and write it down: a fixed platform allocation, a usage-weighted split, or absorbed centrally in the platform budget. All three are legitimate; deciding case by case is not, because it makes every month a negotiation.

Unattributable spend — usage that maps to nothing, usually a shared key or an account nobody claims — deserves its own clause and its own visible line in the report. The tempting alternative is to spread it proportionally across teams, which is worse than it looks: it gives every team a figure they cannot verify, and it removes the pressure that would otherwise get the mapping fixed. An unallocated line that shrinks quarter over quarter is a healthy report. A tidy report where every dollar has a home and nobody can explain how is not.

Timing: a freeze date, and adjustments forward

Providers post charges late, some of them days late, so the numbers for a period keep moving after the period ends. Pick a freeze date that sits after every provider you use has settled, state it in the policy, and treat the figures as final from that day. Corrections discovered afterwards go into the current period as a named adjustment rather than reopening a closed one.

This clause prevents the most corrosive failure mode in chargeback: a team plans against a number, then receives a different one. Reopening closed periods, even to correct them in a team's favour, teaches everyone that no number is final — after which the report stops driving behaviour, which was the entire point of charging back.

Disputes and rule changes: make the evidence auditable

Give teams a bounded window — ten working days from publication is typical — and require a dispute to point at specific events or a specific mapping rather than the total. That constraint is what makes disputes tractable: it moves the conversation to a factual question with an answer in the data.

Then name who owns the allocation rules, state that changes are announced before the period they take effect, and state that they are never applied retroactively to a closed period. Every change lands in an append-only audit log with a timestamp and an author, and that log is the evidence both sides argue from. Most chargeback programmes that fail do not fail on arithmetic — they fail because nobody could explain why this month's rules differed from last month's.

Run showback first, then flip

Publish the same report, with the same mapping and the same freeze date, without moving any money, for at least one full cycle. Showback exists to surface exactly the errors that would otherwise become disputes: keys assigned to the wrong team, a shared service account carrying four teams' traffic, a workload nobody tagged. Fixing them while nothing is at stake costs an afternoon; fixing them after a cost-center owner has escalated costs a quarter of credibility.

The signal that you are ready to flip is boring: two consecutive periods where the unallocated line is small and stable, and no team is surprised by their number. That is also, not coincidentally, the point at which the policy has been tested by real use rather than drafted in the abstract.

Where Quordo fits

Quordo provides the mechanics the policy describes: per-connection team attribution applied at ingestion across OpenAI, Anthropic, Azure OpenAI, Amazon Bedrock, and Google Vertex, with provider, model, team, and cost stored denormalized on every usage event so past periods stay stable. Attributed spend exports to CSV for the chargeback run, and every allocation-rule and budget change lands in an append-only audit log — the evidence a dispute needs.

Budgets with deduplicated threshold alerts and anomaly detection cover the other half of the loop: catching the overrun during the period rather than explaining it during the chargeback meeting. The FinOps guide walks the whole sequence in order, from first connection through to a defensible chargeback number.

Frequently asked questions

What should an AI chargeback policy include?: Six clauses: what spend is in scope, how usage is attributed to a cost center, how shared and unattributable spend is handled, the freeze date after which a period's numbers are final, the dispute process and its deadline, and who owns changes to the allocation rules. Everything else is detail; those six are what disputes turn on.
How do you handle AI spend that can't be attributed to a team?: Publish it as its own line — an unallocated bucket — rather than spreading it across teams. A visible number creates pressure to fix the underlying mapping and is honest about what you do and don't know; a silent proportional allocation buries the problem and gives every team a small figure they cannot verify, which is how trust in the whole report is lost.
Should we start with showback or chargeback?: Showback, for at least one full cycle. Showback publishes what each team spent without moving money, which surfaces the attribution errors — misassigned keys, shared service accounts, untagged workloads — while they are still cheap to fix. Chargeback moves the cost onto a team's budget, and the first disputed invoice will be about the mapping, so the mapping needs a cycle of scrutiny first.
How do you make an AI chargeback number defensible?: Three properties. It has to reconcile to the provider invoice rather than being estimated from a price table. The mapping from usage to cost center has to have been recorded at ingestion, so it can be shown rather than re-derived. And every change to an allocation rule or budget has to be in an append-only audit log with a timestamp and an author, so 'why is this different from last month' has an answer.