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. They are the three costs from M0.4, normalized into the spec: ListCost is the rack rate from L1, BilledCost the billing cost from L2, and EffectiveCost the amortized cost from L3.

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.
• Vantage offers FOCUS-format exports; CloudHealth by Broadcom offers a FOCUS dataset and report.
• IBM Cloudability can ingest FOCUS-format data from other providers.
• ZopNight reads provider-native billing data and serves a FOCUS 1.4 billing API, with its gaps declared in each response (see Apply).

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 (Cost Explorer for AWS, or your CUR 2.0 export if you opt in, BigQuery billing for GCP, Cost Management amortized for Azure) and serves it two ways:

• A FOCUS 1.4 billing API (GET /orgs/{orgID}/billing/focus). It emits FOCUS 1.4 columns plus x_-prefixed vendor extensions, the spec’s own mechanism for extra fields.
• The reporting API behind the dashboards. It keeps its own field names (costUsd, savingsUsd, unattributedCostUsd and so on) by decision, because FOCUS models billing line items and has no column for savings, unattributed or untagged cost.

The FOCUS API declares its gaps rather than filling them with guesses. Each response says:

• Which columns are omitted, and why. ContractedCost, ContractedUnitPrice and PricingQuantity are always omitted, because the capture does not store a rate or priced quantity they can be derived from honestly. ListCost is also omitted when a capture source in the window cannot supply it.
• Which rows were excluded, and how much cost they carried. A row that cannot fill a Mandatory column is dropped and counted, never zero-filled.
• Caveats for the window. For example, BilledCost and EffectiveCost may be overstated when a payer export and a member account’s own capture record the same charge, so reconcile against the payer invoice.

It also refuses (HTTP 409) for an organization reading cost on rack rate, since there are no billed charges to serve.

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

1. Pull cost records from the FOCUS 1.4 billing API.
2. Read the omitted columns, excluded rows and caveats, and decide how your warehouse treats each one.
3. Run portable queries against the FOCUS-shaped destination.

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 · Rack rate