LLM cost allocation across business units: splitting shared requests

Start with the allocation unit, not the split method

Provider invoices and usage reports are typically organized by API key, model or project. A single request, however, may combine a system prompt owned by the platform team, retrieval passages from two business units' knowledge bases, and a tool call into a system a third unit runs. The invoice has no field that says who benefited, so the attribution has to be built by you.

The first decision is the cost objective: the business unit, cost center or product that finance already recognizes. If a request cannot be mapped to that unit, no allocation model will make the result defensible. Agree on the unit with finance before any engineering work, and decide whether the output is showback (reporting usage to units) or chargeback (transferring cost to their budgets). The same attribution data can feed both, but chargeback demands stricter reproducibility because someone's budget changes.

US federal cost principles offer a useful analogy here, though they do not bind private internal chargeback. They say a cost benefiting two or more activities should be allocated by proportional benefit when the proportions can be determined without undue effort. When they cannot, any reasonable documented basis is allowed. They also distinguish direct costs, those assignable to one objective easily and with high accuracy, from shared costs. That gives a practical test: a request with a single owner is direct, and only the remainder needs a splitting rule.

Four allocation models and their trade-offs

Most teams choose among four models. They are not mutually exclusive. A common pattern is to assign each request class to one model and document why. Whichever model you pick, use one allocation base common to every unit sharing a cost pool, and test whether it distorts results. For example, one unit that routinely sends very large documents can dominate a token-based split without receiving proportionally more benefit.

• Proportional by tokens: Each unit is charged by its share of the tokens attributable to its inputs and outputs. Reproducible from counts, but it needs token counts per segment rather than request totals, and output tokens are hard to assign to a single contributor.
• By context source: Cost follows who owns each prompt template, retrieval source and tool involved. It reflects who contributed to the request, but it depends on reliable source-ownership metadata and does not measure who gained value.
• Fixed weight: A pre-agreed percentage split applies to a request class. It is simple and gives stable budgets, but it drifts from actual use and needs scheduled review and documented approval of weight changes.
• Primary owner: The whole cost goes to one unit, usually the calling application's owner. It is the easiest to explain and produces few disputes, but it systematically subsidizes the other contributing units.

Treat shared elements as explicit rules

Shared system prompts, cached context, retrieval results and tool calls are where allocation disputes usually start. The principle is to decide each treatment in writing, once, and apply it to like requests identically. Treating the same element differently from one request to the next creates inconsistencies that finance will find and that you cannot explain later.

A shared system prompt can be treated as a platform overhead pool spread across units by the common base, or charged to the calling unit as part of the direct cost. If your provider reports cached or discounted tokens separately from regular tokens, decide whether the split uses raw token counts or the billed amounts, and state which. Using raw counts against a billed total creates a reconciliation gap, so the rule must say how the difference is handled.

Retrieval context can be attributed through a source identifier that maps to an owning unit. Tool calls raise two separate questions: the tokens that tool results add to the model context, and any cost the tool itself incurs outside the LLM invoice. Keep these as distinct line items so each can follow its own rule. In activity-based costing terms, the request, the retrieval call and the tool call are each activities, and cost flows to them before it flows to a unit.

Keep allocation records reproducible and verifiable

A chargeback figure is defensible when someone else can recompute it. That means storing the inputs to each split (counts, source owners, weights) and the rule version, not just the final dollar amounts. Recomputing from stored inputs under the recorded rule should always give the recorded result.

Several design constraints follow. Shares for each request must sum to 100 percent of the underlying cost, with a stated rule for rounding residuals, so nothing is charged twice or left unassigned. Allocated totals for each period should reconcile against the provider invoice, and the unexplained difference should be reported rather than absorbed. Rule changes, such as a new base or new weights, should be effective-dated and approved, and corrections should be added as new records instead of overwriting old ones. Federal cost principles treat deviation from established written policy as a reasonableness concern, and the same logic applies internally: a written allocation policy gives reviewers something to test records against.

Retention period, immutability requirements and audit format are decisions for your finance and audit functions. Settle them before the first chargeback cycle, because retrofitting them onto existing records is difficult.

Limits of per-request attribution and where enforcement evidence helps

Per-request attribution is a rule-based allocation, not a measurement of business benefit. Token counts, source ownership and fixed weights are proxies. Provider reporting granularity limits how finely you can split, and any rule that cannot be tied to captured metadata will remain a judgment call. State these limits in the allocation policy so reviewers see them as documented assumptions rather than discovered flaws.

One further gap is proof that the attribution rules were actually applied to each interaction and tool call. Trussed enforces policy in the execution path at the level of individual interactions and tool calls, so attribution context can be attached when the interaction happens, and audit-ready evidence records what was attributed. That evidence supports reconciliation between the allocation records and what actually ran. It does not replace the allocation model or the finance decisions behind it, and it does not by itself trace a whole multi-step workflow.