Skip to content

Cost Allocation and Chargeback

Splitting a shared cloud account across several cost centres, in proportion, and proving the result adds up to the bill.

The Problem

An account boundary is the strongest cost boundary a cloud gives you, and RosettaOps uses it: every user and every project gets its own account wherever that is practical, so most cost needs no splitting at all. See The Landing Zone.

Some accounts are legitimately shared anyway. A platform account, a data account, a team account that predates the organization. For those, the question is not who owns this account but how much of it does each cost centre owe, and the usual answers are both wrong:

  • Charge it to one owner. Whoever is easiest to name absorbs the whole account. The number is defensible to nobody.
  • Leave it unallocated. A report with a mystery bucket beside it invites the reader to distrust the parts that are correct.

RosettaOps splits the account instead.

Cost Centres on Logins

Cost centres are carried by the login, not by the resource and not by a tag. A login can belong to several organizations, and each organization can name a cost centre and a weight.

At billing time RosettaHub takes a snapshot of the organization tree, flattened to cost centres, org paths and per-login weighted allocations, and writes it into the FOCUS billing data alongside the cost rows.

Allocation is resolved when the cost is incurred

The snapshot is taken as the billing data is written, not joined on at query time. A cost row keeps what was true in the month it happened.

This is what stops last quarter's report changing when somebody moves team, an organization is renamed, or a cost centre is retired. Reports are reproducible: running the same period twice returns the same numbers.

The Resolution Rule: Reduce, Then Split

A login can sit in several organizations at once, so its cost has to be divided between them. RosettaHub applies two steps, in order.

1. Reduce

Drop any organization that is implied by one of its own descendants. If a login is a member of both Eng and Eng/Platform, that is one membership stated twice, and only Eng/Platform survives.

Specificity is measured along an ancestor chain. It can establish that Eng/Platform is more specific than Eng, because one contains the other. It cannot establish anything about Eng/Platform versus Design/Research, because those are separate lineages.

2. Split

Divide the cost between whichever payers remain, equally unless weights say otherwise.

Why unrelated organizations are split rather than ranked

An earlier design compared organizations from different lineages by depth and broke ties alphabetically. That is not a neutral guess: it charges the entire cost to whichever organization happens to be named earliest in the alphabet. An equal split between genuine peers is the honest answer.

Chargeback and Showback Are Different Queries

Both are provided, they answer different questions, and their totals are not the same number by design.

Chargeback Showback
Question What does each cost centre owe? What is each part of the organization spending?
Method Unnests the weighted allocations, so a login split across two cost centres contributes to both in proportion Rolls each organization path up its own ancestry
Sums to the bill? Yes No, deliberately

Showback figures do not add up to the bill, and should not

A parent organization contains its children, so their spend is counted inside it. An account that sits in two branches shows in full under each. That is what showback means.

If you place the two totals side by side in a report without saying so, a reader will assume one of them is broken. Label them.

Showback exists so that a team with no budget code of its own can still see its spend. Chargeback exists so that finance can invoice.

Reconciliation

Every allocation run reports three numbers:

Figure Meaning
Allocated The total that landed on a cost centre
Total The account total for the period
Difference Anything that did not land anywhere

A non-zero difference produces a worklist of the cost that has not been attributed, so it can be chased rather than rounded away.

Aim for a difference of zero

The point of the reconciliation is not the number itself, it is that the number is visible. A chargeback report that quietly leaves a percentage unallocated costs the FinOps team more credibility than the missing percentage is worth.

Amortised Cost, Not Billed Cost

Allocation is calculated on effective cost, the amortised figure, throughout.

  • Billed cost puts an upfront commitment in the month it was purchased.
  • Effective cost spreads it across the term it covers.

Amortised is the fairer basis for charging a team, because it stops a single commitment purchase landing as a spike on whichever cost centre happened to own that month. Using it consistently is also what makes the sum of the linked accounts equal the account total in every month, including a purchase month.

Reconciling against the provider invoice

Billed-cost figures are retained separately for exactly this purpose. Amortised figures will not match an invoice line for a given month, and are not meant to.

Credits are the exception: they stay on billed cost. There is no term over which to spread a credit, and they are reported as consumption rather than netted off, because the budget a credit draws down belongs to the institution rather than to whichever account happened to redeem it.

Provider Coverage

Provider Cost centre allocation
AWS Available
Azure Not yet. Azure uses a separate billing path, and cost centre columns are left empty rather than filled with an attribution that was never calculated