The FOCUS specification, in plain English

Outcome

By the end of this lesson, you will be able to explain what the FOCUS specification is, why it exists, and identify which cloud providers and tools have adopted it.

1. Concept

FOCUS is an open standard for what a cloud bill should look like as data. The name stands for FinOps Open Cost and Usage Specification, and it is published by the FinOps Foundation.

The problem it solves is dull and expensive. Every provider names things differently. AWS calls the cost column lineItem/UnblendedCost. Google calls it cost. Azure calls it Cost, or sometimes CostInBillingCurrency. Repeat that disagreement across 50 or so columns, three providers and every tool in the market.

The result held the industry back for years. Every tool wrote its own translation layer. Every query only worked on one cloud. Comparing two clouds meant building pipelines to convert one into the other.

FOCUS settles the naming. Once a provider exports in this format, a column means the same thing everywhere.

Why it exists

Three things came together in 2023 and 2024.

1. Most companies now run on more than one cloud. Comparing them became a daily need rather than an annual exercise.
2. Tools disagreed with each other. Each vendor wrote its own conversion, with small differences, so two tools reading the same bill reported different totals. That is fatal to trust.
3. Customers pushed the providers. AWS, Google and Azure agreed to help write one specification rather than each publishing their own.

The FinOps Foundation owns the spec and convenes the working group.

What FOCUS is, in shape

FOCUS is a specification for columns, nothing more. It defines three things:

• The set of columns (about 50 in FOCUS 1.0: BilledCost, EffectiveCost, ServiceName, ResourceId, RegionId, RegionName, ChargePeriodStart, etc.)
• The data types and allowed values
• The semantics of each column (what counts as BilledCost vs EffectiveCost, for instance)

It is not:

• A file format (any format works: Parquet, CSV, JSON; provider’s choice)
• A query engine (you run your own queries over FOCUS-formatted data)
• A required schema for storage (your warehouse can keep extra columns)
• A guarantee of comparable totals (different providers have legitimate rate-card differences; FOCUS normalizes the structure, not the prices)

The core columns to know

The FinOps Foundation publishes the full spec. A short list of the most-used:

COLUMN                    MEANING
─────────────────────────────────────────────────────────────
BilledCost                What the customer is invoiced for the charge
EffectiveCost             The amortized cost (e.g., reservation distributed)
ListCost                  What the cost would have been at public list price
ServiceName               The cloud service (EC2, Compute Engine, Storage)
ResourceId                Cloud-native identifier of the resource
RegionId / RegionName     Cloud-native region id + display name
ChargeCategory            "Usage" / "Tax" / "Credit" / "Adjustment"
ChargePeriodStart / End   The time window the charge covers
SkuId                     The pricing SKU
CommitmentDiscountStatus  "Used" / "Unused" / null

Note BilledCost vs EffectiveCost vs ListCost. These are exactly the three bands from M0.1 L3 and M0.4 L4, normalized into the spec.

Where adoption stands (2026)

• Microsoft Azure ships FOCUS-aligned exports natively, opt-in.
• Oracle Cloud publishes FOCUS-aligned exports.
• Google Cloud offers FOCUS export from BigQuery billing data.
• AWS ships a native FOCUS 1.0 export through Data Exports (generally available since 2024), so no converter is needed.
• Apptio, IBM, Vantage, CloudHealth offer FOCUS-formatted output.
• FinOps tools (including ZopNight) can ingest FOCUS or provider-native and emit FOCUS to a destination warehouse if requested.

Adoption is uneven but accelerating. By 2027 most enterprise FinOps practices will use FOCUS as the canonical schema and treat provider-native as the upstream feed.

Why it matters for the curriculum

A learner who knows FOCUS can:

• Read any cost dataset across providers with the same vocabulary.
• Validate that vendor cost reports use the right column for the question.
• Write portable cost queries that survive a provider switch.
• Understand why a tool’s cost number differs from the cloud console number (typically: BilledCost vs EffectiveCost confusion).

These are everyday FinOps skills. FOCUS is the vocabulary.

2. Demo

The same query, FOCUS-formatted vs. provider-native:

Provider-native (AWS CUR):

SELECT line_item_product_code AS service,
       SUM(line_item_unblended_cost) AS cost
FROM cur.consolidated_2026_05
WHERE bill_payer_account_id = '123456789012'
  AND DATE(line_item_usage_start_date) = '2026-05-19'
GROUP BY 1
ORDER BY cost DESC;

FOCUS:

SELECT ServiceName AS service,
       SUM(BilledCost) AS cost
FROM focus.cost_data
WHERE BillingAccountId = '123456789012'
  AND DATE(ChargePeriodStart) = '2026-05-19'
GROUP BY 1
ORDER BY cost DESC;

The FOCUS version runs unchanged against GCP, Azure, Oracle: wherever the FOCUS data lands. The CUR version is AWS-only.

3. Hands-on (5 min)

If you have access to any of the FOCUS-publishing exports:

1. Open the FOCUS export from Azure Cost Management, GCP BigQuery billing, or Oracle.
2. Locate the BilledCost, EffectiveCost, ListCost, ServiceName, and ChargePeriodStart columns.
3. Pull yesterday’s total spend grouped by ServiceName.
4. Notice how the query reads identically regardless of source.

If you do not have FOCUS access today: read the public schema reference at https://focus.finops.org/, particularly the column list, and identify which of your team’s current cost queries would simplify with FOCUS.

4. Knowledge check

Q1

FOCUS is most accurately described as:

A. A column specification: a schema for cost data that works across providers
B. A file format
C. A FinOps Foundation certification programme for practitioners today
D. A SQL query engine

Q2

The BilledCost column in FOCUS most closely corresponds to:

A. Live rack rate
B. The forecasted spend
C. The lagged daily billing cost (post-discount)
D. The negotiated enterprise discount rate itself

Q3

An organization runs on AWS, GCP, and Azure. The FinOps Analyst writes a cost query in FOCUS schema. The query:

A. Will need to be rewritten per provider
B. Will only work against AWS
C. Will only work against the most recently adopted cloud provider
D. Should run unchanged once each provider’s FOCUS export is wired up

5. Apply

ZopNight reads provider-native billing data today (CUR for AWS, BigQuery billing for GCP, Cost Management amortized for Azure) and stores it in an internal schema that is close to FOCUS but not identical (the internal schema predates FOCUS adoption). The roadmap converges the internal schema toward FOCUS as the spec stabilizes and provider exports mature.

For learners building their own data warehouse or BI layer downstream of ZopNight, the integration recipe is:

1. Export ZopNight cost records via the API or BigQuery sync.
2. Map ZopNight columns to FOCUS columns at the warehouse boundary.
3. Run portable queries against the FOCUS-shaped destination.

A FOCUS-native export option is on the ZopNight roadmap.

Related lessons

• M0.3: Why scheduling beats commitments (next module)
• T0.M0.1.L2: Pick your billing source
• T0.M0.4.L4: The two-source cost model

External references

• FinOps Foundation FOCUS spec: https://focus.finops.org/

Glossary terms touched

FOCUS · BilledCost · EffectiveCost · ListCost · ServiceName