The FOCUS spec, explained: one billing format for every cloud

If you’ve ever tried to put an AWS bill and an Azure bill in the same query, you’ve met the problem FOCUS exists to solve. AWS calls a cost line_item_unblended_cost; Azure calls it CostInBillingCurrency; Google calls it cost. Same concept, three names, three schemas, and a week of your life spent hand-mapping columns before you can ask “what did we spend last month” across clouds. FOCUS makes them speak one language.

FOCUS — the FinOps Open Cost and Usage Specification — is an open standard from the FinOps Foundation. In their words, it “is a technical specification that normalizes billing data across technology vendors.” This is a plain-English explainer: what it standardizes, where the spec is today, who’s actually shipping it, and — honestly — what it does and doesn’t change in practice.

What FOCUS actually standardizes

FOCUS defines a common schema: a set of column names, each with a precise definition, that every conforming billing export uses the same way. Instead of learning each provider’s dialect, you learn one. The columns that do the heavy lifting are the cost ones, because that’s where the dialects diverge most:

• ◦BilledCost — what actually landed on the invoice for the period.
• ◦EffectiveCost — amortized cost, spreading upfront commitment payments across the term so a reserved-instance prepayment doesn’t spike one month.
• ◦ListCost — cost at public on-demand rates, before any discount.
• ◦ContractedCost — cost at your negotiated rates. Together with ListCost, this makes your discount visible as a number, not a vibe.

Beyond cost, a consistent set of dimensions: ServiceName and ServiceCategory for what you bought, BillingAccountId and SubAccountId for whose it is (the FOCUS equivalents of an AWS payer and linked account), ChargeCategory for what kind of charge it is (usage, purchase, tax, credit), and ChargePeriodStart / ChargePeriodEnd for when. Once these mean the same thing everywhere, a query written against FOCUS runs against any conforming provider’s data unchanged.

That’s the whole promise: portable queries. A cost allocation report, an anomaly query, a coverage calculation — write it once against FOCUS columns and it works on AWS, Azure, and GCP data alike, instead of three provider-specific versions you maintain forever.

Where the spec is now

FOCUS is at version 1.4, ratified by the FOCUS Steering Committee on June 4, 2026. That release added invoice reconciliation, commitment detail, and — notably — a formal notion of specification maturity for individual columns, so implementers know which parts are stable. The cadence is quick: 1.3 landed in December 2025, and the spec has been moving roughly twice a year. Always check focus.finops.org for the current number rather than trusting a blog post’s — including this one, dated August 2026.

The version number matters because the spec moves faster than the exports do — which brings us to who’s actually shipping it.

Who’s adopted it (and the catch)

The three major clouds all produce FOCUS-formatted exports, and as of August 2026 all three are at FOCUS version 1.2 in their shipping exports — behind the 1.4 spec, which is normal: providers implement a ratified version and catch up over time.

• ◦AWS was first to ship native FOCUS exports, via Data Exports / CUR 2.0, delivering FOCUS-formatted Parquet to an S3 bucket.
• ◦Azure exports FOCUS-formatted data from Cost Management to a storage account you own — the “Cost and usage (FOCUS)” export template.
• ◦Google Cloud offers a FOCUS billing export as a BigQuery view, alongside its long-standing Detailed usage export.

Beyond the big three, adoption is broadening — Oracle Cloud, Alibaba, and a growing set of SaaS vendors (Databricks, Vercel, Grafana Cloud, Redis) publish FOCUS exports, most at 1.0–1.3. The direction is clear even where coverage is uneven: FOCUS is becoming the default interchange format for cost data, the way OpenTelemetry became one for traces.

The catch to internalize: a provider “supporting FOCUS” means it can emit a FOCUS export, usually a version behind the spec, sometimes in preview, sometimes with a column or two left empty. FOCUS narrows the mapping work dramatically; it doesn’t eliminate the need to check what your specific export actually populates.

What it changes in practice — and what it doesn’t

What FOCUS changes: the multi-cloud mapping tax largely goes away. If you build your own cost tooling, you write allocation and anomaly logic once against FOCUS columns instead of maintaining a per-provider adapter each. If you buy tooling, FOCUS makes it far easier for a vendor to add a provider without a bespoke integration. Either way, adding a cloud stops being a schema project.

What it doesn’t change: FOCUS is a data format, not a FinOps practice. It gives you clean, comparable columns; it does not allocate your shared cost, tell you which service is running hot, or decide your commitment strategy. And it doesn’t erase the genuinely provider-specific behavior underneath — a Savings Plan and an Azure reservation map to the same FOCUS commitment columns, but the products still behave differently. FOCUS is the on-ramp, not the destination.

Where CloudQuell fits — honestly

Here’s the part where a vendor usually claims “FOCUS-compliant” and moves on. We won’t, because it wouldn’t be accurate. CloudQuell normalizes every provider — AWS, Azure, GCP, Snowflake, OpenAI, Anthropic — into a single internal cost model so they share one dashboard, one allocation engine, and one set of alerts. That model is the same idea FOCUS is built on: one schema for many sources. But it’s our schema, not the FOCUS schema, and we don’t currently export your data in FOCUS format or claim FOCUS certification.

Where FOCUS shows up for us concretely is on the ingestion side. Our Azure connector reads the Cost and usage (FOCUS) export as its recommended input — the invoice-accurate path — so if you’ve already stood up a FOCUS export for Azure, we consume it directly. For Google Cloud we currently read the Detailed usage export, with FOCUS support on our roadmap. So: we speak FOCUS as an input where the provider offers it, we normalize everything into one model regardless, and we don’t overstate it as compliance. If a FOCUS export from CloudQuell is something you need, it’s a fair thing to ask us about — just not something we’ll pretend already ships.

What is the FOCUS specification?

FOCUS (the FinOps Open Cost and Usage Specification) is an open standard from the FinOps Foundation that defines a common schema — consistent column names and meanings — for cloud and SaaS billing data. Its purpose is to let cost data from different providers be read and compared with the same queries, instead of hand-mapping each vendor’s format. The current version is 1.4, ratified June 4, 2026.

Do AWS, Azure, and Google Cloud support FOCUS?

Yes — all three ship FOCUS-formatted billing exports, and as of August 2026 all three are at FOCUS version 1.2 in those exports (behind the 1.4 spec, which is normal). AWS delivers it via Data Exports / CUR 2.0 to S3, Azure via a Cost Management export to blob storage, and Google Cloud via a BigQuery export view. Check each provider’s current docs for the exact version and any preview status.

Is FOCUS the same as the AWS CUR?

No. The CUR is AWS’s own detailed billing format, with AWS-specific column names. FOCUS is a cross-provider standard; AWS can emit its data in FOCUS format (through CUR 2.0 / Data Exports) so it lines up with Azure and GCP data under shared column names. Think of the CUR as the native dialect and FOCUS as the shared language AWS can also speak.