Cloud chargeback model template: policy, rules and statement layout

1. Purpose and scope

This policy sets out how the organization allocates cloud costs to the business consumers that drive them, how those costs are reported, and, once the model is trusted, how they are charged back to consumer budgets. It exists so that every line of every cloud invoice lands with an owner, the total reconciles to what the providers charged, and a disputed number is settled by drilling into the data rather than by negotiation.

Scope: all spend invoiced by Amazon Web Services, Microsoft Azure and Google Cloud under the organization’s billing accounts, including marketplace purchases, support plans and commitment programs. Out of scope until named here: software-as-a-service subscriptions billed outside the cloud providers, and on-premises infrastructure.

The model runs in two modes. In showback mode the statements are informational and no budget is affected. In chargeback mode the statement totals are posted to consumer budgets as internal recharges. Each cost category is assigned a mode in section 5, and a category moves from showback to chargeback only by the process in section 9.

2. Roles and responsibilities

3. Principles

• Reconciles to the invoice. The sum of every statement plus the unallocated remainder equals the providers’ invoices for the period, to the cent, every period.
• Direct before shared. A cost with an identifiable owner is never spread. Only genuinely shared costs use a driver or a fixed split.
• Unallocated is reported, never hidden. The remainder is shown with its cause (missing tag, unmapped account, provider-level charge) and an owner for fixing it.
• Rules are data. Every allocation rule is written down, versioned and applied by the tooling, not by hand in a spreadsheet.
• No mid-period changes. A rule change takes effect from the next period; the first statement after a change shows the old and new treatment side by side.
• Fair beats precise. A driver the recipients understand and can influence is preferred to a more accurate one they cannot.
• Drill-down on every line. A consumer can trace any statement line to the resources and the rule that produced it.

4. Allocation rules

Rules are applied in this order. A cost is allocated by the first rule that matches and is not considered by later rules.

1. Direct by container. A cost incurred in an account, subscription, project or resource group that is mapped to exactly one consumer belongs to that consumer. The mapping table is maintained by the FinOps lead and reviewed quarterly.
2. Direct by tag. A cost carrying a valid cost-center, product or team tag belongs to the consumer that tag maps to. The tag keys and allowed values are defined in the tagging standard; an invalid value is treated as missing.
3. Proportional by driver. A cost in a shared service is split among its tenants by the driver named for that service in section 5, measured from the service’s own metrics for the same period.
4. Fixed split. A shared cost with no measurable driver is split by the percentages named in section 5, which are agreed by the recipients and reviewed twice a year.
5. Unallocated. Anything not matched above is reported as unallocated under one of three causes: missing or invalid tag, unmapped container, or provider-level charge. Each cause has an owner and the amount is tracked as a data-quality measure, with a target agreed in section 9.

Worked example. A month’s Azure invoice includes a virtual machine in a subscription mapped to the payments product (rule 1, payments), a storage account in a shared subscription tagged cost-center 4410 (rule 2, whichever consumer 4410 maps to), a Kubernetes cluster node pool shared by six teams (rule 3, split by requested CPU and memory), a security scanning subscription with no driver (rule 4, fixed split), and a one-off support credit applied at the billing account (rule 5, provider-level, reported unallocated and reviewed by finance).

5. Shared cost categories and their default treatment

6. Commitments and discounts

Reserved capacity, savings plans and committed-use discounts are bought centrally and benefit whichever usage they match. This policy allocates the discounted rate to the consumer whose usage was covered, so a team that runs steady workloads sees the benefit of the commitment made on its behalf, and a team that runs bursty workloads sees the on-demand rate it actually caused.

Unused commitment, meaning capacity paid for and not matched by any usage, is carried by the central budget as the cost of the decision to commit, and reported to procurement as a separate line. It is not spread across consumers, because none of them made the decision and none of them can change it.

Enterprise discount programs and negotiated rates that apply to the whole bill are passed through proportionally to each consumer’s spend, so every statement shows the organization’s effective price rather than list price.

7. The statement layout

Every consumer receives one statement per period. The layout is the same in showback and chargeback mode; only the posting changes. Each statement carries:

• Header: consumer name and code, period, statement date, mode (showback or chargeback), currency, and the policy version applied.
• Summary: total for the period, prior period, variance in amount and percent, and budget for the period with variance to budget.
• By provider: total per cloud provider, with the share of direct, proportional and fixed allocation shown separately.
• By service: the top services by cost, each with prior period and variance, so the reader sees what moved before they see why.
• Shared services received: each shared category, the driver value for this consumer, the share it produced and the amount.
• Commitment benefit: the discount received from central commitments and the on-demand equivalent, so the saving is visible.
• Unallocated attributable to this consumer: costs held back because of missing tags on resources in the consumer’s own containers, with the count of resources to fix.
• Drill-down: a link from every line to the underlying resources and the rule that produced the line.
• Footer: the dispute window, how to raise a dispute, and who signed the statement.

8. Disputes and corrections

1. A consumer may dispute any line within ten working days of the statement date by naming the line, the amount and the reason (wrong owner, wrong driver, wrong rule, data error).
2. The FinOps lead investigates using the drill-down and answers within five working days with the evidence: the resources, the tag or mapping, and the rule applied.
3. If the data was wrong, the correction is made in the model, a corrected statement is issued, and in chargeback mode a credit and re-posting follow in the next period.
4. If the rule was wrong, the rule is changed from the next period by the finance owner; the current period stands unless the amount is material by the organization’s own threshold.
5. A dispute that is not resolved between the consumer and the FinOps lead escalates to the finance owner, whose decision is final for the period and recorded with the reason.
6. Disputes are counted and reported monthly. A category with repeated disputes is reviewed for a better driver before it moves to, or stays on, chargeback.

9. Cadence and the move from showback to chargeback

Statements are produced monthly, within five working days of the providers’ invoices being final. A category moves from showback to chargeback when the criteria below have been met for two consecutive periods and the finance owner signs the change.

1. Reconciliation: the model reconciles to the invoices for the period with no manual adjustments.
2. Coverage: the unallocated remainder is below the agreed target (a common starting target is five percent of the bill) and its causes each have an owner.
3. Stability: no rule change affecting the category in the last two periods.
4. Disputes: disputes on the category are in single figures and were resolved within the window.
5. Acceptance: the recipients of the category have seen at least two showback statements with the exact treatment that chargeback will use.

Direct costs typically meet these criteria within two to four cycles. Shared categories follow one at a time as their drivers prove out. A category may be returned to showback by the finance owner if disputes rise or the driver stops being measured.

10. Sign-off checklist

• The mapping of every billing account, subscription and project to a consumer is complete and dated.
• The tagging standard names the keys, the allowed values and the owner of each value.
• Every shared category in section 5 has a method, a driver or split, an owner and a mode.
• The commitment treatment in section 6 has been read and accepted by procurement and by the largest consumers.
• A sample statement in the section 7 layout has been produced from real data for at least one consumer and reviewed by finance.
• The dispute process has a named investigator, a named escalation and a tracked count.
• The move criteria in section 9 have agreed numbers, not placeholders.
• Signed by the finance owner and the FinOps lead, with the policy version and date.