FinOps FOCUS spec gives AWS, Azure and Google Cloud billing data one shared schema

One schema for three bills

Anyone operating workloads across AWS, Azure and Google Cloud has probably assembled a spreadsheet or SQL script to reconcile the three providers' invoices — and then watched it fail the moment a field gets renamed. A practical guide published on dev.to by CloudSkill Consulting argues that the FinOps Open Cost and Usage Specification (FOCUS) solves the problem upstream: it is an open standard for billing data, and all three major cloud providers can now export cost data in that format.

Why translation layers break

Each provider writes its bill differently, according to the dev.to post. Column names, date fields and terminology for the same concept all diverge, so even a basic question from finance — total compute spend last month — requires someone to first map three separate files onto each other. That work is slow and error-prone. A shared schema removes the mapping step entirely: when every bill uses identical column names with identical meanings, one query can answer for all three clouds.

What the specification defines

FOCUS standardises column names and their meanings for cost and usage data. The dev.to guide highlights the columns used most often: ProviderName identifies which cloud produced a charge, ServiceName names the service in the provider's own terms, SubAccountId maps to an AWS account, Azure subscription or Google Cloud project, ChargePeriodStart records when the charge applied, and ChargeCategory distinguishes usage from purchases, taxes, credits and adjustments. Two cost columns exist: BilledCost, which reflects what appears on the invoice, and EffectiveCost, which spreads discounts and prepaid commitments across the usage they cover. A Tags column carries ownership information such as team, application or environment.

Providers may add their own columns, but these must be prefixed with x_. AWS, for instance, adds x_ServiceCode, x_UsageType and x_Operation. The guide recommends keeping such columns out of cross-cloud queries. It also notes a version caveat: the column names it describes follow FOCUS 1.0, while AWS already offers a FOCUS 1.2 table, and newer revisions add columns and alter values — so teams should confirm which version each export uses before hard-coding anything.

Enabling the exports

The setup differs per provider, as described on dev.to. In AWS, you create a Data Export under Billing and Cost Management and select the FOCUS table (1.0 or 1.2), which lands in S3. In Azure, you create an export in Cost Management using the Cost and usage details (FOCUS) dataset, written to a storage account. On Google Cloud, the Billing export page has an option to enable a FOCUS export, which produces a read-only linked BigQuery dataset named gcp_billing_immutable_ followed by the billing account ID and location, containing a table named gcp_billing_export_focus_ plus the billing account ID. Google's export is still in Preview under its Pre-GA Offerings Terms, meaning support may be limited, and Google advises querying through a view so future schema changes do not break queries — advice the author extends to all three clouds.

The post also covers operational hygiene: land every export in one warehouse you already run (BigQuery, Amazon Athena or Azure Synapse are cited), give each export its own table, and restrict read access because billing data exposes account names and tags. New exports often begin with the current month, though some providers let you request older history.

One view over three exports

Once loaded, a thin view unions the three export tables, selecting only the shared columns by name rather than using SELECT *, so that provider-added x_ columns never disturb the view. A sample query groups by ProviderName and month, filters ChargeCategory to usage and sums EffectiveCost for a per-cloud monthly cost figure. When a provider changes its export, fixing the view once keeps every downstream report working.

The guide closes with a common pitfall: BilledCost suits invoice reconciliation with finance, while EffectiveCost suits showback, unit costs and trends — and the two must never be added together.

Why it matters

Multi-cloud cost reporting has historically depended on fragile, hand-built translation layers. A vendor-neutral open schema, supported natively by all three hyperscalers, collapses that work into a single view and makes practices like showback and chargeback achievable without bespoke glue code. The caveats are real — spec versions are already diverging and Google's export is pre-GA — but the direction is clear: standardised billing data is becoming table stakes for FinOps work.