The mapping problem is the gap between how the cloud bills, by resource, and how finance reports, by cost center and product, and it is where most chargeback programs stall. The buyer takeaway is that you solve it with a deliberate mapping layer that translates tagged resources into both a cost center view for accountability and a product view for unit economics, governed by documented rules for the shared costs that defy a clean split. Get that layer right and allocation becomes accurate enough that teams accept the bill instead of disputing it, which is the only state in which chargeback actually changes behaviour.
Here is why the two structures never line up on their own, how to build a mapping that serves both finance and product, and how to handle the shared costs that cause most of the arguments.
Why resources never line up with the org chart
A cloud account is a pile of resources: instances, databases, buckets, gateways, and managed services. A finance system is a hierarchy of cost centers and, increasingly, a set of products with their own margins. Nothing in the cloud knows about your org chart, so left alone the bill is a flat list that maps to neither structure. Tagging is the bridge, but tags alone are not a mapping; they are raw material a mapping layer turns into the views finance needs. The problem deepens because the two target structures answer different questions. A cost center view answers who is accountable for the budget. A product view answers what the spend produced and whether it earns its keep. The same resource often belongs to one cost center but serves several products, so a single tag cannot satisfy both. A real mapping carries multiple dimensions from the start.How do you build a mapping that lasts?
Durability is the goal, because the expensive failure is a mapping that breaks at the next reorganisation. Build it in layers so the volatile parts are isolated from the stable parts:- A resource tag that identifies the owning team, applied and enforced at provisioning so coverage is high and current.
- A lookup that maps teams to cost centers, held in one place finance controls, so a reorganisation is a single table edit rather than a retagging project across thousands of resources.
- A product dimension, either a second tag or a derived mapping, so the same spend can be rolled up by product for unit economics.
- A documented rule set for shared and platform costs, so allocation is reproducible and defensible when challenged.
How do you allocate shared and platform costs?
Shared costs are where allocation gets contested: a logging pipeline, a shared Kubernetes cluster, a data platform, network egress, and the management overhead of the landing zone. These serve many teams and products at once, so there is no single correct split, only defensible ones. The discipline is to choose a driver that reflects consumption and apply it consistently. Usage based drivers work best where you can measure them: container requests for a shared cluster, query volume for a data warehouse, data processed for a pipeline. Where usage is unmeasurable, fall back to a simpler proportional driver such as each team's share of directly attributed spend. Whatever you choose, write it down, review it on a set cadence, and keep an untagged backstop so unallocated spend is surfaced and assigned rather than silently absorbed.Does the cloud you run on change the approach?
The mapping logic is identical across AWS, Azure, GCP, and OCI, but the tagging primitives differ and shape the build. AWS uses cost allocation tags surfaced in the Cost and Usage Report. Azure layers resource tags beneath subscriptions and management groups, which gives you a natural hierarchy to map onto cost centers. GCP combines labels with a project and folder structure that often aligns to teams already. OCI uses compartments and tags, where the compartment tree can mirror the org structure directly. The cross cloud standard worth adopting is the FinOps Foundation FOCUS specification, which normalises billing data into one schema. With FOCUS, your mapping layer is built once against a common format rather than three or four times against provider specific exports, which is a material saving for any organisation running more than one cloud.A European SaaS company ran chargeback off a single owner tag and spent every month arbitrating disputes, because resources moved between teams faster than tags were updated and shared platform costs were split by a rule nobody had agreed. We separated the stable tag, the owning team, from the volatile mappings to cost center and product, which we moved into finance controlled lookup tables, and we set explicit usage based drivers for the shared cluster and the data platform. Disputes fell sharply because the numbers were now reproducible and the method was documented, and a later reorganisation that would have triggered a full retagging effort became a one afternoon table update. Figures are verified against billing data and anonymised.
Frequently asked questions
Why is cloud cost allocation so hard?
What is the difference between a cost center and a product view?
How do you allocate shared cloud costs?
Fix your allocation model with us
We help enterprises map cloud spend to cost centers and products across AWS, Azure, GCP, and OCI, with a mapping layer that survives reorganisations and an allocation method teams accept. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or a no risk Gainshare basis.
Our FinOps operating model guide places allocation inside the wider governance rhythm, and we send new analysis through The Cloud Spend Navigator.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.