Multi-Cloud Billing: How to Combine AWS, Azure, and GCP Bills Into One Report

To combine AWS, Azure, and Google Cloud bills into one report, turn on each provider's billing export (AWS Cost and Usage Report 2.0 to S3, Azure Cost Management exports to storage, Google Cloud billing export to BigQuery), land all three in one warehouse, and normalize them to FOCUS, the FinOps Foundation's open billing standard. The exports are the easy part. What actually breaks the comparison is currency, billing period boundaries, and amortization: the three clouds handle all three differently, and a report that ignores them produces a total that looks right and is wrong.

Almost every company that ends up on two clouds gets there by accident. An acquisition arrives with a Google Cloud estate, a data team picks BigQuery, a customer contract requires Azure, and suddenly the monthly finance ritual involves three consoles, three CSV downloads, and a spreadsheet that one person understands. The question being asked is simple. What did infrastructure cost, and who spent it. Neither cloud can answer it, because each one is bounded by itself.

Why the three bills do not line up

Each provider models cost as if it were the only one you use. That shows up in four places at once.

None of those commitments transfer between providers, which is the quiet tax of running multi-cloud: splitting committed spend three ways costs you leverage in all three negotiations. That is a strategy problem rather than a reporting one, but it belongs in the same conversation, because a unified report that hides it is doing you a disservice.

Step 1: turn on every billing export properly

Do this first and do it before you need the data, because none of these exports backfill indefinitely. Enable the AWS Cost and Usage Report in version 2.0 writing Parquet to S3, with resource IDs included. Configure Azure Cost Management to export amortized cost daily to a storage account. Set up the Google Cloud billing export to BigQuery, and enable both the standard usage export and the pricing export, since the detailed one carries the resource-level data.

Two details people skip and regret. Enable resource-level detail on every export even though it makes the files much larger, because without it you can attribute to a service but never to a specific workload. And turn on your cost allocation tags in the AWS billing console, since AWS tags do not appear in the CUR until you explicitly activate each key, and activation is not retroactive.

Step 2: land all three in one place

You now have Parquet in S3, blobs in Azure storage, and a BigQuery table, in three clouds, in three formats. They have to meet somewhere. Most teams pick their existing warehouse (BigQuery, Snowflake, Redshift, or Databricks) and schedule the other two into it, which means a recurring job per provider and someone owning the schema drift when a provider adds a column. If you would rather not hand-build and babysit three ingestion pipelines, this is the kind of routine plumbing a managed data integration layer handles more reliably than a cron job nobody has looked at since it was written.

Budget for the size of this. A mid-size estate with resource-level detail produces tens of millions of rows a month, and the CUR in particular is wide. Partition by date on ingest and you avoid the most common failure of these projects, which is a query that takes four minutes and so nobody runs it.

Step 3: normalize to FOCUS

FOCUS, the FinOps Open Cost and Usage Specification, is an open standard maintained by the FinOps Foundation that makes cost records from different providers use the same column names, the same cost definitions, and the same semantics. Before FOCUS, every company built and maintained its own mapping between three vendor schemas. It is the single biggest reduction in effort available to a multi-cloud reporting project.

One nuance buyers and builders both miss: the specification is currently at version 1.4, but AWS, Azure, and Google Cloud natively emit version 1.2 today. So "supports FOCUS" is not one claim. When you are evaluating a vendor, ask which version it reads and which it writes. When you are building it yourself, target the version your providers actually produce and treat the newer spec fields as something to grow into.

What you get for the work is a table where BilledCost, EffectiveCost, ChargePeriodStart, and ServiceCategory mean the same thing regardless of which cloud produced the row. That is the moment a cross-cloud report becomes possible rather than merely plausible.

Step 4: fix the four things that silently corrupt the total

This is where do-it-yourself multi-cloud reports go wrong, and the errors are invisible because the number still looks reasonable.

• Amortized versus unamortized cost. If you paid a Reserved Instance upfront in January, unamortized cost shows the whole charge in January and nothing for eleven months. Amortized cost spreads it. Mixing the two across providers means one cloud looks seasonal and another looks flat, for no real reason. Pick amortized for trend analysis and be consistent everywhere.
• Billing period boundaries and timezones. The providers do not close a day at the same instant, and their billing months are not identical. For monthly totals this is noise. For "what happened last Tuesday" during an anomaly investigation, it moves spend between days and sends you looking at the wrong window.
• Currency. If any account bills in a non-USD currency, decide once whether you convert at the provider rate on the invoice or at your own treasury rate, then apply it consistently. Mixing methods across clouds produces a total that never reconciles to the general ledger, and finance will find that before you do.
• Credits, discounts, and egress. Enterprise discount programs, private pricing, sustained use discounts, and free credits all land differently in each export. Egress deserves special attention in multi-cloud, because moving data between providers is a cost that only exists because you are multi-cloud, and it usually shows up as an unremarkable networking line item that nobody attributes to the architecture decision that caused it.

Step 5: allocate across clouds, not within each one

A unified total is worth less than a unified breakdown. The goal is that a team running services on AWS and Google Cloud gets one number, not two that someone adds up.

Pick one business dimension that can exist everywhere, usually team or product, and map each provider's native construct into it: AWS accounts and activated cost allocation tags, Azure subscriptions and resource groups, Google Cloud projects and labels. Then accept that tag coverage will never be complete in three estates at once and write rules for the remainder, splitting shared and untagged spend by measurable usage or an agreed proportion. Waiting for perfect tagging is the reason most of these projects stall, and it is why we wrote a separate guide on building a cloud cost allocation tagging strategy that survives contact with real engineering teams. The same logic drives cost allocation software generally: rules on top of imperfect tags beat a retag project that never finishes.

How do you compare costs across AWS, Azure, and GCP?

Compare by normalized service category and by unit of work, never by raw line item. FOCUS gives you a common ServiceCategory, so compute is compute and storage is storage regardless of whether the invoice says EC2, Virtual Machines, or Compute Engine. Beyond that, compare cost per unit that matters to your business, such as cost per thousand requests or per active customer. Comparing sticker prices between clouds is close to meaningless once committed use discounts, sustained use discounts, and negotiated enterprise agreements are applied, because almost nobody pays list.

Can you see AWS and Azure costs in one dashboard?

Not with the native tools. AWS Cost Explorer sees only AWS, Microsoft Cost Management sees only Azure, and Google Cloud billing reports see only Google Cloud. Each is free and genuinely good inside its own boundary, and if roughly 90 percent of your spend sits in one provider you should exhaust the native console before buying anything. Getting all three into one dashboard means either building the pipeline described above or buying a platform that has already built it. We compare the options honestly, including where each one beats us, in our guide to the best multi-cloud cost management tools.

Should you build this or buy it?

Build it if cloud cost reporting is close to your core business, you already run a warehouse with a team that owns it, and your requirements are unusual enough that no product fits. Some large engineering organizations reach that conclusion honestly and are right.

Most companies should buy, for a reason that has little to do with the initial build. Standing up three exports and a FOCUS mapping is a few weeks of competent work. Keeping it correct is permanent: providers add services and columns, discount structures change, someone opens a new account outside the export configuration, and the pipeline breaks quietly in a way that produces a smaller number rather than an error. The maintenance, not the build, is what makes this expensive. A useful test is to price the engineering time at a fully loaded rate and compare it with a year of tooling. If your combined cloud bill is above roughly 50,000 dollars a month, the tool is almost always cheaper than the person maintaining the alternative, and it arrives with anomaly detection and allocation you would otherwise build next.

Whichever way you go, the sequence matters more than the tool: exports on and complete, one landing place, FOCUS normalization, the four correctness fixes, then allocation. Skipping to a dashboard before the correctness work is how teams end up confidently reporting a total that finance later disproves. If you would rather have multi-cloud cost management that already handles the normalization, and that puts your SaaS subscriptions in the same ledger as the three cloud bills, that is what we built Costanalyst to do, read-only, from 99 dollars a month.