FOCUS, explained

Last reviewed: September 2026

In one sentence: FOCUS is an open specification that standardizes technology billing data so cost and usage information from different providers can be understood using a common language.

What is FOCUS?

FOCUS stands for FinOps Open Cost and Usage Specification. It is an open technical specification that defines a common structure and terminology for technology billing data.

FOCUS addresses a basic problem in technology cost management: different providers can describe similar financial concepts using different schemas, field names, terminology, and calculation methods.

A cloud provider might call something an account while another uses a subscription or project.

Cost fields can have different meanings.

Usage units can be represented differently.

Discounts, commitments, credits, and pricing can follow provider-specific structures.

None of those approaches is necessarily wrong.

But when an organization wants to analyze several providers together, those differences create additional work.

FOCUS establishes a common language that technology providers, FinOps platforms, and practitioners can use to represent cost and usage data consistently.

Why does FOCUS exist?

Consider an organization using:

• AWS

• Microsoft Azure

• Google Cloud

• SaaS platforms

• AI services

• private or data center infrastructure

Each system can produce useful billing and consumption data.

The problem is that those datasets were not necessarily designed to work together.

Before meaningful analysis can begin, organizations often need to understand:

Which field represents the service?

Which field identifies the resource?

Which cost should we use?

How are discounts represented?

What does this usage quantity mean?

Which account, subscription, or project owns the charge?

That translation layer adds complexity to multi-provider FinOps.

FOCUS attempts to move part of that normalization upstream by defining common concepts and requirements for billing datasets.

FOCUS creates a common language, not a common price

FOCUS does not make AWS, Azure, Google Cloud, or other technology services cost the same.

It does not standardize provider prices.

It does not make the underlying products identical.

And it does not remove provider-specific billing models.

Instead, it standardizes how important billing concepts are represented.

Think of it as agreeing on a common vocabulary.

Different providers can still sell fundamentally different products, but concepts such as:

• billed cost

• effective cost

• service

• resource

• billing period

• charge period

• consumed quantity

• pricing quantity

• pricing unit

• region

• tags

can be represented according to shared definitions.

That makes downstream analysis more consistent.

What does a FOCUS dataset contain?

FOCUS organizes billing information into standardized dimensions and metrics.

Dimensions describe the charge.

Examples include:

• service

• resource

• region

• billing account

• sub-account

• charge category

• pricing unit

• tags

• billing period

Metrics provide numerical values that can be aggregated or analyzed.

Examples include:

• Billed Cost

• Effective Cost

• List Cost

• Contracted Cost

• Consumed Quantity

• Pricing Quantity

Together, these fields help answer questions such as:

Who incurred the cost?

What was consumed?

When was it consumed?

Where was the service delivered?

How was it priced?

How much did it cost?

A simple example

Imagine an organization runs a compute workload for one month.

Its provider billing file contains information equivalent to:

• Service: Compute

• Resource: VM-123

• Region: Europe

• Usage: 100 hours

• Billed cost: €80

• Effective cost: €70

The €80 might represent the amount relevant to invoicing.

The €70 might reflect the economic cost after accounting for applicable discounts or prepaid commitments.

In a provider-specific billing export, these concepts may appear under provider-specific field names and structures.

FOCUS gives those concepts standardized definitions.

A simplified FOCUS-style representation could therefore look like:

The important point is not the example values.

It is that another FOCUS-compatible dataset can express equivalent concepts using the same standardized vocabulary.

Billed Cost vs Effective Cost

One of the useful aspects of FOCUS is that it distinguishes different meanings of "cost."

These distinctions matter because one number cannot always answer every financial question.

Billed Cost

Billed Cost represents the charge used as the basis for invoicing after applicable reduced rates and discounts, but without amortizing relevant prepaid purchases across the resources they cover.

It can therefore be useful for questions related to invoicing, cash-based analysis, budgeting, and reconciliation.

Effective Cost

Effective Cost represents the amortized cost after applicable discounts and the relevant portion of prepaid purchases have been attributed to the usage they cover.

This can provide a more useful view of the economic cost of consumption.

For example, suppose an organization pays €12,000 upfront for a one-year commitment.

Looking only at the month in which the €12,000 payment occurred would make that month appear extremely expensive and subsequent months unusually cheap.

An amortized view can instead distribute the relevant economic cost across the period or usage that benefits from the commitment.

The distinction allows practitioners to choose the cost metric appropriate to the question they are asking.

Consumed Quantity vs Pricing Quantity

FOCUS also distinguishes between how something is consumed and how it is priced.

These are not always the same thing.

Suppose a service processes:

12,500 requests

That could be its consumed quantity.

But the provider might price the service in blocks of:

1,000 requests

The pricing quantity could therefore represent:

12.5 units of 1,000 requests

This distinction is important because provider pricing models do not always correspond directly to the underlying technical consumption unit.

A standardized schema needs to preserve both concepts.

The same charge across different providers

This is where FOCUS becomes particularly useful.

Imagine an organization has comparable compute workloads running across AWS, Azure, and Google Cloud.

Without normalization, the provider datasets might expose equivalent concepts through different native structures.

Conceptually, the organization needs to translate something like this:

FOCUS creates a standardized destination:

The provider-native data has not become identical.

It has been mapped into a common semantic model.

That distinction is important.

A worked multi-cloud example

Suppose three equivalent workloads generate these monthly effective costs:

AWS workload: €420

Azure workload: €390

Google Cloud workload: €450

Once the relevant data is represented consistently, the organization can perform straightforward cross-provider analysis.

Total effective compute cost:

€420 + €390 + €450 = €1,260

Provider share:

AWS:

€420 ÷ €1,260 = 33.3%

Azure:

€390 ÷ €1,260 ≈ 31.0%

Google Cloud:

€450 ÷ €1,260 ≈ 35.7%

The arithmetic itself is trivial.

The difficult part is ensuring that the three values being compared actually represent the same financial concept.

That is the problem standardization helps address.

Why standardized semantics matter

Imagine one dataset reports gross list price.

Another reports the amount after negotiated discounts.

A third includes amortized commitment costs.

All three columns might casually be described as "cost."

Adding them together would produce a number.

But the number would not necessarily mean anything useful.

FOCUS attempts to prevent this ambiguity by defining what each standardized metric represents.

That is why FOCUS is more than a column-renaming exercise.

A useful standard needs consistent semantics, not just consistent labels.

FOCUS does not eliminate provider-specific data

Standardization inevitably raises another question:

What happens to information that is unique to one provider?

FOCUS allows data generators to provide supplemental columns in addition to the standardized FOCUS structure.

That matters because provider-specific details can still be valuable.

A common schema should make cross-provider analysis easier without preventing deeper analysis of a particular platform.

The practical model can therefore become:

FOCUS columns for standardized analysis

plus

provider-specific fields where additional detail is useful

This preserves both portability and depth.

FOCUS and cost allocation

FOCUS standardizes billing data.

It does not decide who should ultimately own a cost inside your organization.

Suppose a FOCUS dataset tells you:

• the service

• the resource

• the consumed quantity

• the effective cost

• the tags

You may still need to determine whether that resource belongs to:

• Product A

• Team B

• Customer C

• a shared platform

• an unallocated category

That is a business allocation decision.

FOCUS can provide standardized inputs that make those decisions easier to apply consistently, but it does not replace the organization's allocation methodology.

This distinction is important:

FOCUS standardizes the cost data. Cost allocation determines accountability for that cost.

See Cost allocation for a detailed explanation of allocation methods and unallocated spend.

FOCUS and chargeback

The same principle applies to chargeback and showback.

FOCUS can provide standardized information about what was consumed and what it cost.

An organization still needs to determine:

• who owns the consumption

• which cost basis should be used

• whether markups or internal rates apply

• how shared costs should be treated

• whether the result is shown or financially charged

FOCUS provides a common data foundation.

The organization's financial model sits on top of it.

FOCUS and unit economics

FOCUS can also provide part of the numerator for unit economics.

For example, standardized cost data might establish that Product A has €50,000 of technology cost.

But calculating:

Cost per customer

requires another dataset containing customer information.

Calculating:

Cost per successful transaction

requires outcome data.

Calculating:

Cost per AI workflow

may require telemetry from AI or observability systems.

FOCUS makes technology cost data easier to standardize.

It does not automatically supply every piece of business context required to understand value.

That is why standardized billing data should be viewed as a foundation rather than the final FinOps model.

FOCUS is expanding beyond public cloud

FOCUS began in a world where inconsistent cloud billing data was an obvious problem.

Its scope is now broader.

The specification is intended for technology billing data generators including cloud providers, SaaS platforms, managed service providers, and internal infrastructure or service platforms.

The broader FOCUS ecosystem now includes data generators across cloud, SaaS, AI, data center, and other technology categories.

That direction matters because modern technology environments rarely consist of one public cloud provider.

An organization's cost model may need to represent:

public cloud + SaaS + private infrastructure + data platforms + AI services + internal technology

A common cost and usage language becomes more valuable as the number and variety of those sources increases.

What FOCUS does not solve

FOCUS is powerful precisely because its scope is specific.

It should not be treated as a complete FinOps solution.

FOCUS does not decide:

Who should own a shared cost.

That requires cost allocation.

Whether a team should be charged.

That requires a chargeback or showback model.

Whether spending created enough business value.

That requires unit economics and business context.

Which resource should be optimized.

That requires operational analysis and decision-making.

Whether a particular architecture is appropriate.

That requires technical context.

What your internal service should cost.

That may require custom rates, infrastructure economics, and business rules.

FOCUS standardizes the financial and usage language used by these processes.

It does not replace the processes themselves.

FOCUS versions

FOCUS is a living specification and continues to evolve.

As of September 2026, FOCUS 1.4 is the latest ratified version.
Exivity supports all released FOCUS versions, including FOCUS 1.4.

New versions expand the specification as technology cost management develops.

For example, the specification has progressively added support for areas such as capacity reservations, invoice reconciliation, allocation metadata, contract commitments, and more detailed financial structures.

Organizations should therefore record which FOCUS version a dataset conforms to rather than treating "FOCUS" as a single permanent schema.

This is particularly important when combining datasets produced by different providers.

Native FOCUS data vs normalized FOCUS data

There are two useful ways an organization might encounter FOCUS.

Provider-generated FOCUS data

A technology provider can make billing data available directly in a FOCUS-compatible format.

Several major technology providers now make FOCUS-formatted datasets available.

This reduces the amount of downstream transformation required.

Data normalized into FOCUS

Existing provider-specific billing data can also be transformed into the FOCUS schema.

This is useful where the source does not produce the required FOCUS dataset directly or where an organization needs to standardize historical or custom billing information.

The result may look similar downstream.

But understanding how the dataset was generated remains important for data governance and validation.

How Exivity works with FOCUS

Exivity supports all released versions of the FOCUS specification, including FOCUS 1.4, the latest released version as of September 2026.

This allows organizations to work with FOCUS-structured cost and usage data alongside other technology consumption and billing data within the same environment.

Technology cost data may originate as provider-native billing data, FOCUS-structured data, private infrastructure consumption, SaaS data, AI consumption, or another custom source. Exivity can bring these different datasets together and enrich them with the business context required for financial management.

FOCUS provides the standardized cost and usage foundation. Exivity can then connect that data with dimensions that may exist outside the original billing dataset, such as:

• customers

• departments

• products

• services

• contracts

• custom business structures

From there, organizations can apply their own financial logic for cost allocation, showback, chargeback, billing, reporting, and unit economics.

Reading all FOCUS versions is also important when organizations receive datasets conforming to different versions of the specification. Rather than requiring every source to use the same FOCUS release, Exivity can work with FOCUS data across versions, including the current FOCUS 1.4 specification.

This makes FOCUS part of a broader financial model rather than an isolated billing format: standardized technology cost data can be combined with other consumption and business information to understand not only what something cost, but who consumed it, who should be accountable for it, and what business activity that cost supported.

Standardization is the beginning, not the end

The value of FOCUS is easy to misunderstand.

The goal is not simply to make billing files look cleaner.

The larger benefit is that teams can spend less effort translating provider-specific billing terminology and more effort answering the questions that matter:

Who owns this cost?

Why did it change?

What are we getting for the money?

How should shared costs be allocated?

What should be charged back?

What does this service cost per customer or outcome?

FOCUS helps establish a common financial language. FinOps practices turn that language into decisions.

Related: Cost allocation · Chargeback vs showback · Unit economics · AI token economics