Split the AI bill across the teams that caused it
Enterprise Tier
The provider invoice arrives as one number for the whole organization. Nothing in it says which team ran the benchmark, which product line drove the growth, or whose budget the increase belongs to, so every question about it lands back on the operator. This guide produces the missing breakdown: a spend statement for a closed period, attributed to the people, teams, or projects that caused the spend, in a form finance can charge against or simply report back.
Persona: Platform operator working in the Admin Console, producing the figures that finance and the business owners consume.
Estimated time: 15 to 20 minutes per reporting cycle, once the dimension is chosen and the group-to-team mapping is in place.
What this guide produces, and what finance does with it
Chargeback is a finance process with several steps, and Agent Router owns exactly one of them: turning request traffic into an accurate, attributable statement of spend. Nothing here moves money, issues an invoice, or posts to a ledger. Knowing where the handover sits prevents the common disappointment of arriving at this page expecting a billing feature.
| Step in the chargeback process | Who owns it |
|---|---|
| Deciding that AI spend is charged back at all, and to which cost centers | Finance and the business owners |
| Making requests attributable to a person, team, app, or project | Platform operator, with the developers who own the workloads |
| Producing the spend statement for a closed period | Platform operator, in the Admin Console (this guide) |
| Reconciling that statement against the provider invoice | Finance, working from the figures this guide exports |
| Posting the allocation to ledgers and deciding whether money moves | Finance |
The output is therefore an allocation basis: the defensible per-team split that finance applies to the invoice it actually received.
Agent Router works spend out from token counts and published model prices rather than reading the provider's bill, so the statement and the invoice agree in some situations and diverge in others. What that means for a chargeback allocation is covered in Calculated cost is not the invoice, which is worth reading before any statement is handed over.
Outcomes
By the end of this guide:
- The dimension each cost center is billed along (user, team, or project tag) has been chosen deliberately, and matches how finance books the cost.
- A spend statement for a closed reporting period exists, read against the ceilings the same spend was measured against.
- That statement has been exported for chargeback or showback in a downstream finance or billing system.
- The gap between the calculated figure and the provider invoice is understood, so the allocation survives scrutiny.
Chargeback or showback
Both terms describe reporting consumption back to whoever caused it, and they are frequently used interchangeably in conversations where the difference matters.
| Chargeback | Showback | |
|---|---|---|
| What happens to the money | The business unit's budget is charged for its own consumption | Nothing moves; the cost stays central |
| What the team receives | A cost on its own books | A report of what its consumption is worth |
| What it is for | Making consumption a cost the team owns and manages | Making consumption visible before anyone is asked to own it |
| What Agent Router does differently | Nothing | Nothing |
The last row is the useful one. The export is identical in both cases; the difference lies entirely in what the finance process does with the file. Organizations commonly run showback for a few cycles first, so that teams can see their own consumption and correct the obvious waste before the numbers start affecting budgets.
Prerequisites
- Administrator access to the Admin Console, typically the
super_adminorbilling_adminrole. - API keys that follow the per-purpose convention, so that spend attributes to one owner rather than blurring across a shared credential. The convention is established in Onboard developers and issue keys.
- Group identity flowing in from the identity provider, so that per-team statements attribute spend to the right cost center. See Map Entra ID groups to business functions.
- Per-user and per-team budgets set, so that a statement can be read against the ceiling the same spend was measured against. See Set a budget and track spend against it.
- Agreement with finance on which cost centers exist and how they are identified. Producing a statement along a dimension finance cannot book against means re-allocating it by hand every cycle.
Step 1: choose the dimension the cost center is billed along
Spend can be grouped three ways, and the choice is a reporting decision rather than a preference. It is made once, with finance, and then holds for every cycle.
| Dimension | Question it answers | Fits when |
|---|---|---|
| User | Who issued the requests | Consumption is owned personally, or a single named user drives a cost center |
| Team | Which organizational unit the requester belongs to | Cost centers follow the org chart, which is the common case |
| Project or app tag | What the spend should be booked against | Cost centers follow initiatives that cut across teams |
The failure mode is a mismatch: a statement grouped by team, handed to a finance function that books cost against product lines, has to be re-cut manually every month, and the manual step is where disputes begin. Where the cost centers are initiatives rather than org units, the tag dimension is the one that fits, and it is set up in Know what every app and project actually costs.
The dimensions coexist. A single request carries its user, its team membership, and whatever tags the caller set, so the same period can be reported along more than one axis without re-running anything.
Step 2: produce the statement for the closed period
- Open Usage → Analytics and set the time range to the closed reporting period. A closed period matters: a statement covering a cycle still in progress changes after it is sent.
- Select the breakdown that matches the dimension chosen in Step 1: By User for a per-person statement, the team view for a per-cost-center statement, or a tag grouping for a per-project statement.
- Sort by cost descending, so the largest consumers sit at the top. This is the order a review reads in, and it is where an unexpected line item is spotted first.
- Check for a No team assigned row. Spend from people who belong to no team is real spend that no cost center will claim, and it has to be either attributed or accepted centrally rather than quietly dropped from the total.
To narrow or compare specific people or teams before exporting, the multi-select filters in Compare user and team spend in Analytics apply the same selection to the chart, the table, and the export.
Step 3: read spend against the ceilings before sending it
A statement of spend and the ceiling that spend was measured against are far more useful together than either alone: the pair shows not only what was consumed but whether the consumption was expected.
- Compare each row against the budget set for that user or team in Set a budget and track spend against it.
- Investigate any row that overran its ceiling before the statement leaves, rather than after a business owner asks. An overrun with an explanation attached is a conversation; an overrun discovered by its owner is an escalation.
- Trace an unexplained line item to its cause. The spot-the-anomaly-then-find-the-change workflow is covered in Audit Agent Router activity, and a single expensive request is diagnosed in Smart routing.
Step 4: export the statement and hand it over
- Confirm the time range, the grouping, and any user or team filter still match the reporting period and the cost-center structure. The export follows the same selection as the chart and the table, so a filter left over from an investigation ends up in the file.
- Use the Export function to download the data, typically as CSV.
- Load the file into the billing, finance, or reporting system that owns the allocation, or hand it to the finance contact who does.
What the export carries
The exported rows carry the dimensions an allocation needs: the consumer, the cost, the token totals, and the period covered.
| What the rows carry | What it is for downstream |
|---|---|
| The consumer (user, team, or tag value) | The join key onto finance's own cost-center records |
| Cost in US dollars | The figure the allocation is calculated from |
| Token totals | The volume behind the cost, which explains a change in it |
| The period covered | The cycle the allocation belongs to |
Cost and tokens both matter for a defensible statement. Cost answers what a team owes; tokens answer why the figure moved, since the same spend can come from more traffic or from a switch to a more expensive model, and only the token figures separate the two.
Calculated cost is not the invoice
Spend is worked out from the tokens in each response and the price of the model that served it, with prices drawn from a catalog of published provider pricing. It is not read from the provider's bill. For a budget that is a reasonable approximation. For an allocation that charges real money to a real cost center, three consequences matter.
- A negotiated rate has to be entered and kept current. Discounts are entered as per-model overrides, and nothing detects a rate changing, so an override left behind after a contract renegotiation shifts every statement that touches that model.
- Where capacity is bought rather than tokens, the two numbers are not comparable. Provisioned throughput, committed spend, and subscriptions cost the same whether one request is sent or a million, so a figure calculated per token cannot track that invoice at all.
- The totals will differ, and the difference has to have an agreed treatment. Left unaddressed, it surfaces as a challenge from the first business owner who compares the statement against the finance system.
None of this makes the statement unusable, and it is the reason the output is described as an allocation basis rather than a bill. The proportions are sound even when the absolute total is not: a team responsible for 35% of the calculated spend is responsible for roughly 35% of the invoice, whatever the invoice total turns out to be. Agreeing with finance that the split is applied proportionally to the real invoice keeps the allocation defensible and removes the argument about the totals entirely.
Budgets are calculated the same way, and the same caveats are set out from the budgeting side in Enforce a budget cap.
Making the allocation hard to dispute
A statement is challenged along whichever dimension is weakest, so the attribution is worth hardening before the first cycle rather than after the first dispute.
- Keep one key to one purpose. Spend on a credential shared by two teams cannot be split after the fact. The convention is in Onboard developers and issue keys.
- Keep the group-to-team mapping correct. A person counted in the wrong team is spend charged to the wrong cost center, and team figures are only ever as good as the membership behind them.
- Constrain project tags by policy where they carry money. A tag any caller can set to any value invites arguments about whose line item it is; a tag Agent Router required and validated carries the same authority as the user dimension. See Know what every app and project actually costs.
- Send each team its own statement before finance sees it. A team given a cycle to query its own figures has far less to dispute once the numbers are in a budget conversation.
- Keep the record of what changed. Budget, tagging, and policy changes that affect a statement are recorded in the audit trail described in Audit Agent Router activity, which is what explains a figure that moved between two cycles.
A worked cycle
Northwind charges AI spend back to three cost centers: Customer Support, Data Science, and Platform Engineering. Teams follow the org chart, so the team dimension is the one finance books against, and the cycle is monthly.
On the second working day of the month, the operator sets the Analytics time range to the closed month, selects the team breakdown, and sorts by cost. The figures below are illustrative.
| Cost center | Calculated spend | Monthly ceiling | Share of total |
|---|---|---|---|
| Customer Support | $4,120 | $5,000 | 41% |
| Data Science | $3,480 | $3,000 | 35% |
| Platform Engineering | $1,900 | $2,000 | 19% |
| No team assigned | $500 | none | 5% |
| Total | $10,000 | 100% |
Three things need handling before the statement goes anywhere, and all three are visible in the table:
- Data Science overran its ceiling by $480. The operator checks the audit trail, finds a model evaluation that ran for eight days, and attaches that explanation to the row rather than letting the business owner discover the overrun unannounced. Whether the ceiling is raised is a separate decision, covered in Raise a spend ceiling without interrupting delivery.
- $500 belongs to nobody. Four contractors were never mapped to a team. Until they are, that spend is accepted centrally, and the mapping is fixed for next cycle so the unattributed row shrinks to zero.
- The provider invoice is $10,600, not $10,000. The 6% gap comes from a committed-spend agreement that no per-token calculation can reproduce. Finance applies the share column to the real invoice, so Customer Support is charged 41% of $10,600 rather than the calculated $4,120, and the difference stops being an argument.
The operator exports the CSV, sends each cost center its own rows, and sends finance the full file with the share column. Total time is under 20 minutes, because the dimension, the mapping, and the invoice treatment were all agreed once rather than renegotiated every month.
Where to go next
Know what every app and project actually costs
Add a project or app dimension when cost centers cut across teams.
Set a budget and track spend against it
The ceilings each statement is read against before it is sent.
Get alerted to cost spikes as they happen
For organizations that need always-on cost dashboards rather than a periodic export.
Audit Agent Router activity
The record that explains a figure which moved between two cycles.