Ask a team running two clouds for their total spend and you'll usually get two numbers added together, not one number that means anything coherent. That's not a tooling failure so much as a reflection of how differently Azure, AWS, and GCP actually structure their billing data underneath.
The same dollar means something different on each bill
A dollar of "cost" on an Azure invoice, an AWS Cost and Usage Report, and a GCP billing export isn't guaranteed to represent the same thing. Amortized versus billed cost, whether a credit is netted in or shown separately, how a discount gets attributed, all of it varies by provider. Add two of these totals together and the sum is technically a number, just not a meaningful one.
Three different words for the same discount idea
Commitment discounts are a good example of the terminology problem. All three providers offer some version of "commit to spend, get a discount," but they don't call it the same thing or structure it the same way:
- Azure splits this into Reserved Instances (resource-specific) and Savings Plans (spend-based, more flexible).
- AWS has its own Reserved Instances and Savings Plans, similar concepts, but not interchangeable with Azure's despite the matching names.
- GCP uses Committed Use Discounts, a third naming convention and a third set of mechanics for what is, at the concept level, the same underlying trade: commitment for discount.
A FinOps practitioner moving between clouds has to relearn the mechanics each time, even though the underlying financial idea barely changes.
Granularity isn't consistent either
Beyond terminology, the actual shape of the data differs: how costs get split across shared resources, what counts as a distinct line item, how usage gets aggregated before it reaches a report. Two providers can report what's genuinely the same underlying spend at meaningfully different levels of detail, which makes a side-by-side comparison harder than it looks even after the terminology is translated.
FOCUS: the industry's answer to this exact problem
This is precisely the gap the FinOps Foundation's FOCUS specification, the FinOps Open Cost and Usage Specification, was built to close. FOCUS defines one common schema, a shared set of column names and definitions, so billing data from different providers can be read and compared the same way. The specification reached version 1.4 in mid-2026, and native FOCUS exports are now available from a growing list of providers, including AWS, Azure, GCP, and Oracle.
In practice, that means a query written against FOCUS-formatted data from one provider should work against another provider's FOCUS export with little to no modification, a meaningful change from hand-mapping every provider's raw billing schema individually.
What FOCUS fixes, and what it doesn't
FOCUS solves the schema problem: consistent column names, consistent definitions of billed versus effective cost, a standard way to represent commitment discounts across providers. What it doesn't solve on its own is judgment: FOCUS gives you comparable data, it doesn't tell you whether an Azure Savings Plan or a GCP Committed Use Discount is the better call for a specific workload, or flag when a commitment across two different providers is sitting underused. That analysis still has to happen on top of the standardized data, not instead of it. Adoption is also still uneven across smaller providers and services, so FOCUS reduces the mapping problem significantly without eliminating it everywhere at once.
A practical approach until every bill is normalized
- Use FOCUS-formatted exports wherever your providers support them, rather than each provider's raw native billing format.
- Don't just add totals together. Confirm whether each provider's number is billed or amortized cost before combining them, mixing the two silently skews the total.
- Track commitment coverage per provider, not as one blended number. An Azure Reservation and a GCP Committed Use Discount don't average together meaningfully.
- Centralize before you optimize. Optimization decisions made on incomplete or mismatched multi-cloud data tend to look reasonable and be wrong.
CloudNomix ingests and normalizes billing data across Azure, AWS, GCP, and Oracle into one consistent view, FOCUS-aligned where providers support it, so the question stops being "how do I reconcile three different bills" and starts being "what does our total cloud spend actually look like."