Skip to main content

AI Chargeback Allocator

Split a shared AI bill across teams and projects with defensible allocation rules.

100% client-side⎘ exportable output⌁ zero network calls
$
Teams
%
%
%
shares sum to 100.0%
$4,200.00

split across 3 teams using proportional allocation — rounded to the cent with the largest-remainder method, so the column sums to exactly $4,200.00.

Per-team allocation of the monthly AI bill
TeamShareAllocation
Platform45%$1,890.00
Product35%$1,470.00
Data20%$840.00

The exported document includes the per-team table plus a short allocation-policy section finance can file with the invoice.

markdown export, no lock-in
100%
generated locally
0
signup walls
0
network requests per keystroke

How it works

A shared AI bill is fine at $300 a month and a political problem at $30,000. This allocator turns one invoice into defensible per-team charges. Enter the total, list your teams with either declared usage shares or measured token consumption, pick an allocation method, and get a per-team dollar table, proportional bars, and an exportable allocation-policy document finance can file alongside the invoice. Everything computes in your browser.

Three methods cover the realistic policy space. Proportional splits the bill by usage weight and is the right default once you have credible measurement. Even split divides equally — defensible only when usage is genuinely similar across teams. Floor plus proportional charges every team a base amount first, then allocates the remainder by usage; this is the most common mature pattern because it prices shared baseline value while keeping heavy consumers accountable for their tail. In percentage mode the tool validates that shares sum to exactly 100% and dims the result until they do, because an allocation built on shares that sum to 97% is an argument waiting to happen.

Rounding gets unusual care because it is where naive chargeback spreadsheets fail reconciliation. All allocations are computed in integer cents using the largest-remainder method: each team is floored to whole cents, and the leftover cents are handed out one at a time to the largest fractional remainders. The column therefore sums to the invoice exactly — to the cent, every time — which is the property your finance system actually checks.

The exported markdown includes more than the table: a short policy section stating the method, the basis, the dispute path and the rule that methods change only at quarter boundaries. Writing those rules down before the first contested month is the cheapest governance you will ever buy. The harder prerequisite is measurement — per-team token consumption has to come from somewhere, and that somewhere is usage tracking like FORG. Pair this tool with the spend report generator for the monthly narrative and the token budget policy builder when allocation graduates into enforcement.

Frequently asked questions

Which allocation method should I choose?

Proportional is the default when you have credible usage data — teams pay for what they consume and nobody subsidizes anyone. Even split works only for small organizations where usage is genuinely similar or measurement is impossible. Floor plus proportional is the pragmatic middle: every team pays a base fee covering shared infrastructure and tooling, and the remainder follows usage, which softens the penalty on small teams while keeping heavy users accountable.

What is the largest-remainder rounding method and why does it matter?

Naive percentage rounding routinely produces allocations that sum to a cent or two more or less than the actual bill, and finance systems reject splits that do not reconcile exactly. The largest-remainder method floors every team's allocation to whole cents, then distributes the leftover cents one at a time to the teams with the biggest fractional remainders. The result always sums to the invoice exactly, with each team within half a cent of its true share.

Should I use declared percentages or measured tokens as the basis?

Measured tokens whenever you have them — declared shares drift from reality fast and invite quarterly arguments, while measured consumption is self-justifying. The tool accepts either: in percentage mode it validates that shares sum to exactly 100% before showing a confident result, and in token mode it normalizes whatever totals you enter. If you cannot currently measure per-team tokens, that gap is itself worth fixing before chargeback gets political.

What is the difference between chargeback and showback?

Showback reports each team's share of the bill without moving money — visibility intended to change behavior through awareness. Chargeback actually transfers cost into team budgets, with real budget consequences. Most organizations should start with showback for a quarter or two to let the numbers stabilize and surface measurement disputes cheaply, then graduate to chargeback once teams trust the data. The exported policy document works for either model.

How do I handle costs that no single team caused?

Carve them out before allocating. Platform-level spend — a shared evaluation pipeline, centralized embeddings, the AI gateway itself — should sit in a platform budget line rather than being smeared across product teams who cannot control it. Allocate only controllable usage, because chargeback changes behavior precisely where the charged team can act. The floor in the floor-plus-proportional method is a reasonable home for genuinely shared baseline costs.

Budgeting AI spend for a team? FORG is $15/dev with hard budget caps and per-seat attribution.

See FORG pricing