Why FOCUS Exists
Read it and work through the exercises — no video required.
~18 min read · Text + interactive
By the end of this lesson, you can…
- Explain what FOCUS standardizes and why the FinOps Foundation built it, in plain terms.
- Name the specific problem FOCUS solves across AWS, Azure, GCP, and OCI billing exports.
- Say which of FOCUS's four datasets a given billing question belongs to, and why the spec's governance model matters as much as its column list.
The Problem: Four Clouds, Four Different Bills
Every major cloud bills in the same rough shape — a pile of line items, each with a service, a quantity, and a cost — but the four providers you're most likely to touch describe that same shape with four incompatible schemas. Same underlying idea, different column names, different units, different definitions of what "cost" even means. Tap each one.
01AWS Cost and Usage Report (CUR / CUR 2.0)
AWS's native export uses snake_case columns like line_item_unblended_cost, product_servicecode, and line_item_usage_type. CUR 2.0 cleaned up the naming versus the original CUR, but the columns are still AWS's own vocabulary, not a shared one.
02Azure Cost Management exports
Azure's usage-details export uses fields like ConsumedService, MeterCategory/MeterSubCategory, and CostInBillingCurrency. It's a coherent schema on its own — just a completely different coherent schema from AWS's or Google's.
03Google Cloud Billing exports
GCP ships detailed billing data straight into BigQuery, with nested fields like service.description, sku.description, and a plain cost column. Nested/structured fields instead of flat columns is itself a structural difference a cross-cloud query has to handle.
04Oracle Cloud Infrastructure (OCI) Cost Reports
OCI's Cost Reports CSV uses its own slash-delimited grouping, like product/service and cost/myCost. A fourth vocabulary for the same four questions: what was it, how much of it, and what did it cost.
None of these four schemas is wrong. Each one is a reasonable design for its own provider. The problem only shows up the moment you try to answer one question — "what's my total compute spend this month?" — across more than one of them. You either write and maintain four separate parsers, or someone builds a shared schema everyone maps onto. FOCUS is that shared schema.
FOCUS: One Open, Vendor-Neutral Spec
FOCUS (the FinOps Open Cost and Usage Specification) is maintained by the FinOps Foundation, a Linux Foundation project — not by any single cloud provider. It standardizes cloud and SaaS cost and usage data into one common schema, so a charge that AWS calls line_item_unblended_cost and Azure calls CostInBillingCurrency both come out the other side as the same FOCUS column: BilledCost.
That "not owned by a vendor" part is the whole point. FOCUS is developed through an open governance process on GitHub: a Steering Committee, appointed by the FinOps Foundation's Governing Board, reviews and ratifies each release, and works alongside a Maintainers group that drives the spec's day-to-day technical development. The current version, FOCUS v1.4, was ratified by the Steering Committee on June 4, 2026.
Why does FOCUS's governance model make that specific failure much less likely to happen to you?
Reveal my answer
Because no single vendor can unilaterally change the FOCUS schema. A change has to go through community proposal, Maintainer review, and Steering Committee ratification before it ships — and FOCUS 1.4 shipped under an explicit "zero incompatible changes" promise: everything valid under 1.3 is still valid under 1.4. That's a structural guarantee a single vendor's own export format has never had to make to you, because they were never accountable to anyone but themselves for it.
This is also why the governance model matters more than any one vendor's roadmap: whoever ships the next feature doesn't get to unilaterally redefine what "cost" means for everyone else building on FOCUS.
FOCUS's Four Datasets
FOCUS isn't one giant table. As of v1.4, it defines four datasets, each answering a different kind of billing question.
- Cost and Usage
- The core dataset — one row per charge, with what it was, how much of it, and what it cost. This is where you'll spend most of your time, starting Week 2.
- Billing Period
- Invoice-issuer-aware period boundaries and status, so you know exactly when a billing period opened, closed, and whether it can still receive corrections. New in FOCUS 1.4.
- Contract Commitment
- The anatomy of a commitment purchase (Reserved Instance, Savings Plan, CUD, and similar) — separate from the day-to-day Cost and Usage rows it discounts. Expanded from 13 to 30 columns in FOCUS 1.4.
- Invoice Detail
- Charges exactly as they appear on the issued invoice — payment currency, terms, due date, PO number — so Accounts Payable can tie usage data back to the physical bill. New in FOCUS 1.4.
Notice that two of these four datasets, Billing Period and Invoice Detail, didn't exist before this June's release. That's the governance model doing its job in real time: the spec grows to cover real reconciliation gaps practitioners raised, on a predictable, versioned, backward-compatible cadence — not on whatever timeline a single vendor decides is convenient.
Native Adoption: Not Just a Recommendation
FOCUS isn't a theoretical schema you'd have to build yourself from raw exports. All four providers now ship FOCUS-conformant data natively.
| Provider | How you get FOCUS-conformant data | Delivery |
|---|---|---|
| AWS | AWS Data Exports, configured with the FOCUS 1.x schema (built on CUR 2.0) | Scheduled export to S3 |
| Azure | Cost Management exports, configured with the FOCUS schema | Scheduled export to Blob Storage |
| Google Cloud | Google's FOCUS SQL template applied over Detailed billing export data in BigQuery | BigQuery view |
| Oracle Cloud (OCI) | Cost Reports exported directly in FOCUS format | Scheduled export to Object Storage |
Worth noticing: AWS, Azure, and OCI hand you a native FOCUS export outright. GCP's route is a SQL view layered on top of its existing billing export — same end result (a FOCUS-conformant row you can query), different mechanism to get there. That distinction alone is a small preview of a theme this whole course keeps coming back to: FOCUS standardizes the destination, not necessarily the plumbing that gets you there.
Quick glossary: FOCUS vocabulary you'll keep seeing
- Conformant
- A billing export that follows the FOCUS specification correctly — the right columns, the right allowed values, for the datasets it claims to provide.
- Column Library
- The FinOps Foundation's public reference (focus.finops.org) defining every FOCUS column, its data type, and whether it's mandatory, conditional, or optional.
- Native export
- A FOCUS-conformant feed the provider generates and delivers directly, versus one you'd have to build yourself from a proprietary export.
- Steering Committee / Maintainers
- The two governing bodies behind FOCUS: the Committee ratifies releases, the Maintainers group does the ongoing technical drafting.
Exercise: Diagnose Your Own Multi-Cloud Bill
This is the deliverable for the week. Below are 10 line items using the real, currently documented column names from each provider's native export — the actual strings you'd see if you opened your own AWS, Azure, GCP, or OCI billing export today (the dollar amounts are illustrative). Before you reveal the mapping, try to guess what a FOCUS-conformant export would call each one.
| # | Provider | Native field | Native value (as billed) |
|---|---|---|---|
| 1 | AWS CUR 2.0 | product_servicecode | AmazonEC2 |
| 2 | AWS CUR 2.0 | line_item_usage_type | USE1-BoxUsage:m5.4xlarge |
| 3 | AWS CUR 2.0 | line_item_unblended_cost | $6,214.30 |
| 4 | AWS CUR 2.0 | product_region_code | us-east-1 |
| 5 | Azure Cost Management | ConsumedService | Microsoft.Compute |
| 6 | Azure Cost Management | MeterCategory / MeterSubCategory | Storage / Blob Storage |
| 7 | Azure Cost Management | CostInBillingCurrency | €1,204.55 |
| 8 | GCP Billing export | service.description / sku.description | Compute Engine / N2 Instance Core running in Americas |
| 9 | GCP Billing export | cost | $2,340.12 |
| 10 | OCI Cost Report | product/service | COMPUTE |
Quick Check: Which Dataset?
Reflection
Think about the cloud bill(s) you actually deal with. Which of the four datasets — Cost and Usage, Billing Period, Contract Commitment, or Invoice Detail — would solve a real reconciliation headache you or your team has today? If you only use one provider, guess which native field of theirs gives you the most trouble mapping to anything else.
Putting it together
Four providers, four schemas, one recurring problem: the same charge, described four different ways. FOCUS exists to collapse that into one open, vendor-governed schema, split across four datasets, and all four major providers now ship it natively rather than leaving you to build the mapping yourself. The diagnostic you just built is that mapping in miniature — the same skill you'll use for real, column by column, starting next week.
Week 2: The Cost and Usage Dataset, Column by Column
ChargeCategory, ServiceCategory & ServiceSubcategory, ChargeClass, and the commitment-discount columns — classifying real charges against the FOCUS v1.4 allowed-value tables.