FOCUS Specification v1.0

Copyright © 2024 – FinOps Open Cost and Usage Specification (FOCUS) a
Series of the Joint Development Foundation Projects, LLC. Linux
Foundation trademark,
and document use rules apply.

Status of This Document

This section describes the status of this document at the time of its
publication.

This is a published release of the FinOps Open Cost and Usage
Specification.

This document was produced by a group operating under the Joint
Development Foundation Projects agreement. FOCUS maintains a public list
of any patent disclosures made in connection with the deliverables of
the group; that
page
also includes instructions for disclosing a patent. An
individual who has actual knowledge of a patent which the individual
believes contains Essential Claim(s) must disclose the information.

Document Use License

Copyright (c) Joint Development Foundation Projects, LLC, FinOps Open
Cost and Usage Specification (FOCUS) Series and its contributors. The
materials in this repository are made available under the Creative
Commons Attribution 4.0 International license (CC-BY-4.0), available at
[https://creativecommons.org/licenses/by/4.0/legalcode](https://creativecommons.org/licenses/by/4.0/legalcode).

Shield: CC BY 4.0

This work is made available under: Creative Commons
Attribution 4.0 International License
.

CC BY 4.0

THESE MATERIALS ARE PROVIDED “AS IS.” The parties expressly disclaim
any warranties (express, implied, or otherwise), including implied
warranties of merchantability, non-infringement, fitness for a
particular purpose, or title, related to the materials. The entire risk
as to implementing or otherwise using the materials is assumed by the
implementer and user. IN NO EVENT WILL THE PARTIES BE LIABLE TO ANY
OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL,
INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF
ACTION OF ANY KIND WITH RESPECT TO THIS DELIVERABLE OR ITS GOVERNING
AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING
NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER MEMBER HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

This document is governed by the Patent Policy Option 4: W3C Mode:
See project
charter
.

Abstract

FOCUS is an open-source specification for billing data. It defines a
common schema for billing data, aligns terminology with the FinOps
Framework and defines a minimum set of requirements for billing data.
The specification provides clear guideline for billing data generators
to produce FinOps-serviceable data. The specification enables FinOps
practitioners to perform common FinOps capabilities such as chargeback,
cost allocation, budgeting and forecasting etc. using a generic set of
instructions, regardless of the origin of the FOCUS compatible
dataset.

Working Group

Maintainers

Thanks to the following FOCUS Maintainers for their leadership and
contributions to the FOCUS specification.

  • Christopher Harris (Datadog)
  • Dennis Park-Rodriguez (Amazon Web Services)
  • Erik Peterson (CloudZero)
  • Irena Jurica (Neos)
  • Joaquin Prado (FinOps Foundation)
  • Karl Kraft (Walmart)
  • Larry Advey (Twilio)
  • Michael Flanakin (Microsoft)
  • Mike Fuller (FinOps Foundation)
  • Riley Jenkins (Domo)
  • Rupa Patel (Google)
  • Udam Dewaraja (FinOps Foundation)

Contributors

Thanks to the following FOCUS members for their contributions to the
FOCUS specification.

  • Adam Schwartz (Ernst & Young)
  • Alex Hullah (Goldman Sachs)
  • Amit Wadhwa (Google)
  • Anand Tripathi (Amazon Web Services)
  • Anderson Oliveira (Farfetch.com)
  • Andrew Qu (Everest)
  • Anne Johnston (Capital One)
  • Arun Ramakrishnan (Oracle)
  • Ben Shy (Microsoft)
  • Ben Swoboda (NetApp)
  • Ben Zhou (Apptio)
  • Casey Doran (Apptio)
  • Chandra Devarajan (CloudTrakr)
  • Chew Esmero (Alphaus Inc.)
  • Colin Jack (Snow Software)
  • Deeja Cruz (Datadog)
  • Eleni Rundle (Google)
  • George Parker (Salesforce)
  • Graham Murphy (Australian Retirement Trust)
  • Harish Kumar Munagapat (Kyndryl)
  • Hrishikesh Sardar (Kyndryl)
  • Ilia Semenov (CloudThread)
  • Jacky Liu (Google Cloud)
  • Jacqui Wilson (Old Mutual South Africa)
  • Janine Pickard-Green (MagicOrange Group Limited)
  • Jason Kelly (Anglepoint Group Inc)
  • Joe Ferrero (DB Gurus Inc)
  • John Grubb (Platform.sh)
  • Joshua Kwan (Ternary)
  • Letian Wang (Atlassian)
  • Luna Bernal (Twilio)
  • Marc Perreaut (Amadeus)
  • Marcin Walkow (Nordcloud)
  • Mark Krawczeniuk (NetApp)
  • Matt Ray (Kubecost)
  • Michael Arkoosh (Vega)
  • Mike Polson (VMWare)
  • Nick Kotze (Surveil)
  • Nicolas Fonrose (Teevity)
  • Peter Marton (OpenMeter.io)
  • Ray Ding (Accenture)
  • Ricardo Triana (Accenture)
  • Rodney Joyce (CloudMonitor)
  • Sanjna Srivatsa (VMWare)
  • Shawn Alpay (Envisor)
  • Sireesha Oram (Kyndryl)
  • Sonal Garg (Kyndryl)
  • Sumaira Nazir (Platform.sh)
  • Tatiana Dubovchenko (Flexera)
  • Tim O’Brien (Walmart)
  • Trey Morgan (Microsoft)
  • Trig Ghosh (Accenture)
  • Webb Brown (Kubecost)
  • Yuriy Prykhodko (Amazon Web Services)
  • Zach Erdman (Amazon Web Services)

Steering Committee Members

Thanks to the following FOCUS Steering Committee members for their
leadership on the FOCUS specification.

  • Anne Johnston (Capital One)
  • Michael Flanakin (Microsoft)
  • Mike Fuller (FinOps Foundation)
  • Roy Wolman (Amazon Web Services)
  • Sarah McMullin (Google)
  • Tim O’Brien (Walmart)

Table of Contents

1. Introduction

This section is non-normative.

FOCUS aims to establish a community-driven specification for
consumption-based billing data. Due to the lack of a broadly adopted
specification, infrastructure and services providers have resorted to
proprietary billing schemas and terminology. The lack of conformance
amongst the billing data generators has forced FinOps practitioners to
employ disparate, best-effort schemes which each practitioner
must develop individually for each provider to perform
essential FinOps capabilities such as chargeback, cost allocation,
budgeting and forecasting.

The FOCUS specification’s schema definition and FinOps-aligned
terminology provide a clear guide for producing FinOps-serviceable
billing datasets. Datasets conforming to FOCUS enable FinOps
practitioners to perform common FinOps capabilities, like the ones
mentioned above, using a generic set of instructions, regardless of the
origin of the dataset.

1.1. Background and History

This project is supported by the FinOps Foundation. This work initially
started under the Open Billing working group under the FinOps
Foundation. The decision was made in Jan 2023 to begin to migrate the
work to a newly formed project under the Linux Foundation called the
FinOps Open Cost and Usage Specification (FOCUS) to better support the
creation of a specification.

1.2. Intended Audience

This specification is designed to be used by three major groups:

      • Billing data generators: Infrastructure and services
        providers that bill based on consumption, such as (but not
        limited to):

      • FinOps tool providers: Organizations that provide tools to
        assist with FinOps
      • FinOps practitioners: Organizations and individuals consuming
        billing data for doing FinOps

1.3. Scope

The FOCUS working group will develop an open-source specification for
billing data. The schema will define data dimensions, metrics, a set of attributes about
billing data, and a common lexicon for describing billing data.

1.4. Design Principles

The following principles were considered while building the
specification.

1.4.1. FOCUS is
an iterative, living specification

      • Incremental iterations of the specification released regularly will
        provide higher value to practitioners and allow feedback as the
        specification develops. The goal is not to get to a complete, finished
        specification in one pass.

1.4.2. Working
backward with ease of adoption

      • Aim to work backward from essential FinOps capabilities that
        practitioners need to perform to prioritize the dimensions, metrics and
        attributes of the cost and usage data that should be defined in the
        specification to fulfill that capability.
      • Be FinOps scenario-driven. Define columns that answer scenario
        questions; don’t look for scenarios to fit a column, each column must
        have a use case.
      • Don’t add dimensions or metrics to the specification just because it
        can be added.
      • When defining the specification, consideration should be made to
        existing data already in the major providers’ (AWS, GCP, Azure, OCI)
        datasets.
      • As long as it solves the FinOps use case, there should be a
        preference to align with data that is already present in a majority of
        the major providers.
      • Strive for simplicity. However, prioritize accuracy, clarity, and
        consistency.
      • Strive to build columns that serve a single purpose, with clear and
        concise names and values.
      • The specification should allow data to be presented free from
        jargon, using simple understandable terms, and be approachable.
      • Naming and terms used should be carefully considered to avoid using
        terms for which the definition could be confused by the reader. If a
        term must be used which has either an unclear or multiple definitions,
        it should be clarified in the glossary.
      • The specification should provide all of the data elements necessary
        for the Capabilities.

1.4.3.
Provider-neutral approach by default

      • While the schema, naming, terminology, and attributes of many
        providers are reviewed during development, this specification aims to be
        provider-neutral.
      • Contributors must take care to ensure the specification examines how
        each decision relates to each of the major cloud providers and SaaS
        vendors, not favoring any single one.
      • In some cases, the approach may closely resemble one or more
        provider’s implementations, while in other cases, the approach might be
        new. In all cases, the FOCUS group (community composed of FinOps
        practitioners, Cloud and SaaS providers and FinOps vendors) will attempt
        to prioritize enabling FinOps Capabilities
        and alignment with the FinOps Framework.

1.4.4. Extensibility

      • The initial specification aims to introduce a common schema and
        terminology for billing datasets produced by Cloud Service Providers
        (CSPs).
      • The specification, however, aims to be extensible to SaaS products
        and other types of cost datasets.
      • Future versions of the specification will look to expand the content
        to support a broader set of prioritized FinOps capabilities.

1.5. Design Notes

1.5.1. Optimize for data
analysis

      • Optimize columns for data analysis at scale and avoid the
        requirement of splitting or parsing values.
      • Avoid complex JSON structures when an alternative columnar structure
        is possible.
      • Facilitate the inclusion of data necessary for a system of record
        for cost and usage data to consume.

1.5.2. Consistency helps
with clarity

      • Where possible, use consistent names that will naturally create
        associations between related columns in the specification.
      • Column naming must strictly follow the column naming conventions.
      • Use established standards (e.g., ISO8601 for dates, ISO4217 for
        currency).

1.6. Typographic Conventions

The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and
“OPTIONAL” in this specification are to be interpreted as described in
BCP14 [RFC2119][RFC8174] when, and only
when, they appear in all capitals, as shown here.

1.7. FOCUS Feature level

Under each column defined in the FOCUS specification, there exists a
‘Feature level’ designation that describes the column as ‘Mandatory’,
‘Conditional’, or ‘Optional’. Feature level is designated based on the
following criteria described in the normative requirements in each
column definition:

      • If the existence of a column is described with MUST with no
        conditions of when it applies, then the feature level is designated as
        ‘Mandatory’.
      • If the existence of a column is described as MUST with conditions of
        when it applies, then the feature level is designated as
        ‘Conditional’.
      • If the existence of a column is described as RECOMMENDED, then the
        feature level is designated as ‘Recommended’.
      • If the existence of a column is described as MAY, then the feature
        level is designated as ‘Optional’.

1.8. Conformance
Checkers and Validators

There are no current resources available to test for specification
conformance or validators to run on sample data. When one becomes
available, this section of the specification will be updated with
details.

2. Columns

The FOCUS specification defines a group of columns that provide
qualitative values (such as dates, resource, and provider information)
categorized as “dimensions” and quantitative values (numeric values)
categorized as “metrics” that can be used for performing various FinOps
capabilities
. Metrics are commonly used for aggregations (sum,
multiplication, averaging etc.) and statistical operations within the
dataset. Dimensions are commonly used to categorize, filter, and reveal
details in your data when combined with metrics. The Columns are
presented in Alphabetical order.

2.1. Availability Zone

An availability
zone
is a provider-assigned identifier for a physically
separated and isolated area within a Region that provides high
availability and fault tolerance. Availability Zone is commonly used for
scenarios like analyzing cross-zone data transfer usage and the
corresponding cost based on where resources are deployed.

The AvailabilityZone column is RECOMMENDED to be present in the
billing data when the provider supports deploying resources or services
within an availability zone. This column MUST be of type String
and MAY contain null values when a charge is not specific to an
availability zone.

2.1.1. Column ID

AvailabilityZone

2.1.2. Display Name

Availability Zone

2.1.3. Description

A provider-assigned identifier for a physically separated and
isolated area within a Region that provides high availability and fault
tolerance.

2.1.4. Content constraints

Constraint Value
Column type Dimension
Feature level Recommended
Allows nulls True
Data type String
Value format <not specified>

2.1.5. Introduced (version)

0.5

2.2. Billed Cost

The billed cost
represents a charge serving as the basis for invoicing, inclusive of the
impacts of all reduced rates and discounts while excluding the amortization of relevant
purchases (one-time or recurring) paid to cover future eligible charges.
This cost is denominated in the Billing
Currency
. The Billed Cost is commonly used to perform FinOps
capabilities that require cash-basis accounting such as cost allocation,
budgeting, and invoice reconciliation.

The BilledCost column MUST be present in the billing data and MUST
NOT be null. This column MUST be of type Decimal, MUST conform to Numeric Format, and be denominated in the
BillingCurrency. The sum of the BilledCost for rows in a given billing period MUST match
the sum of the invoices received for that billing period for a
billing account.

2.2.1. Column ID

BilledCost

2.2.2. Display Name

Billed Cost

2.2.3. Description

A charge serving as the basis for invoicing, inclusive of all reduced
rates and discounts while excluding the amortization of upfront
charges (one-time or recurring).

2.2.4. Content constraints

Constraint Value
Column type Metric
Feature level Mandatory
Allows nulls False
Data type Decimal
Value format Numeric
Format
Number range Any valid decimal value

2.2.5. Introduced (version)

0.5

2.3. Billing Account ID

A Billing Account ID is a provider-assigned identifier for a billing account.
Billing accounts are commonly used for scenarios like grouping
based on organizational constructs, invoice reconciliation and cost
allocation strategies.

The BillingAccountId column MUST be present in the billing data. This
column MUST be of type String and MUST NOT contain null values.
BillingAccountId MUST be a globally unique identifier within a
provider.

See Appendix:
Grouping constructs for resources or services
for details and
examples of the different grouping constructs supported by FOCUS.

2.3.1. Column ID

BillingAccountId

2.3.2. Display Name

Billing Account ID

2.3.3. Description

The identifier assigned to a billing account by the
provider.

2.3.4. Content constraints

Constraint Value
Column type Dimension
Feature level Mandatory
Allows nulls False
Data type String
Value format <not specified>

2.3.5. Introduced (version)

0.5

2.4. Billing Account Name

A Billing Account Name is a display name assigned to a billing account.
Billing accounts are commonly used for scenarios like grouping
based on organizational constructs, invoice reconciliation and cost
allocation strategies.

The BillingAccountName column MUST be present in the billing data and
MUST NOT be null when the provider supports assigning a display name for
the billing account. This column MUST be of type String.
BillingAccountName MUST be unique within a customer when a customer has
more than one billing account.

See Appendix:
Grouping constructs for resources or services
for details and
examples of the different grouping constructs supported by FOCUS.

2.4.1. Column ID

BillingAccountName

2.4.2. Display Name

Billing Account Name

2.4.3. Description

The display name assigned to a billing account.

2.4.4. Content constraints

Constraint Value
Column type Dimension
Feature level Mandatory
Allows nulls True
Data type String
Value format <not specified>

2.4.5. Introduced (version)

0.5

2.5. Billing Currency

Billing currency is
an identifier that represents the currency that a charge for resources or services was billed in. Billing
Currency is commonly used in scenarios where costs need to be grouped or
aggregated.

The BillingCurrency column MUST be present in the billing data.
BillingCurrency MUST match the currency used in the invoice generated by
the invoice issuer. This column MUST be of type String and MUST NOT
contain null values. BillingCurrency MUST conform to Currency Code Format requirements.

2.5.1. Column ID

BillingCurrency

2.5.2. Display Name

Billing Currency

2.5.3. Description

Represents the currency that a charge was billed in.

2.5.4. Content Constraints

Constraint Value
Column type Dimension
Feature level Mandatory
Allows nulls False
Data type String
Value format Currency
Code Format

2.5.5. Introduced (version)

0.5

2.6. Billing Period End

Billing Period End represents the exclusive end date and time
of a billing period. For
example, a time period where BillingPeriodStart is
‘2024-01-01T00:00:00Z’ and BillingPeriodEnd is ‘2024-02-01T00:00:00Z’
includes charges for January, since BillingPeriodStart is inclusive, but does not
include charges for February since BillingPeriodEnd is
exclusive.

The BillingPeriodEnd column MUST be present in the billing data. This
column MUST be of type Date/Time Format,
MUST be an exclusive value, and MUST NOT contain null values.
The sum of the BilledCost column for rows in a given billing
period
MUST match the sum of the invoices received for that
billing period for a billing account.

2.6.1. Column ID

BillingPeriodEnd

2.6.2. Display Name

Billing Period End

2.6.3. Description

The exclusive end
date and time of a billing
period
.

2.6.4. Content Constraints

Constraint Value
Column type Dimension
Feature level Mandatory
Allows nulls False
Data type Date/Time
Value format Date/Time
Format

2.6.5. Introduced (version)

0.5

2.7. Billing Period Start

Billing Period Start represents the inclusive start date and
time of a billing
period
. For example, a time period where BillingPeriodStart is
‘2024-01-01T00:00:00Z’ and BillingPeriodEnd is ‘2024-02-01T00:00:00Z’
includes charges for January, since BillingPeriodStart is inclusive, but
does not include charges for February since BillingPeriodEnd is exclusive.

The BillingPeriodStart column MUST be present in the billing data,
MUST be of type Date/Time Format, MUST be
an inclusive value, and MUST NOT contain null values. The sum
of the BilledCost metric for rows in a given billing
period
MUST match the sum of the invoices received for that
billing period for a billing account.

2.7.1. Column ID

BillingPeriodStart

2.7.2. Display Name

Billing Period Start

2.7.3. Description

The inclusive start
date and time of a billing
period
.

2.7.4. Content Constraints

Constraint Value
Column type Dimension
Feature level Mandatory
Allows nulls False
Data type Date/Time
Value format Date/Time
Format

2.7.5. Introduced (version)

0.5

2.8. Charge Category

Charge Category represents the highest-level classification of a
charge based on the nature of how it is billed. Charge Category is
commonly used to identify and distinguish between types of charges that
may require different handling.

The ChargeCategory column MUST be present in the billing data and
MUST NOT be null. This column is of type String and MUST be one of the
allowed values.

2.8.1. Column ID

ChargeCategory

2.8.2. Display Name

Charge Category

2.8.3. Description

Represents the highest-level classification of a charge based on the
nature of how it is billed.

2.8.4. Content Constraints

Constraint Value
Column type Dimension
Feature level Mandatory
Allows nulls False
Data type String
Value format Allowed values

Allowed values:

Value Description
Usage Positive or negative charges based on the
quantity of a service or resource that was consumed over a given period
of time including refunds.
Purchase Positive or negative charges for the
acquisition of a service or resource bought upfront or on a recurring
basis including refunds.
Tax Positive or negative applicable taxes that
are levied by the relevant authorities including refunds. Tax charges
may vary depending on factors such as the location, jurisdiction, and
local or federal regulations.
Credit Positive or negative charges granted by
the provider for various scenarios e.g promotional credits or
corrections to promotional credits.
Adjustment Positive or negative charges the provider
applies that do not fall into other category values.

2.8.5. Introduced (version)

0.5

2.9. Charge Class

Charge Class indicates whether the row represents a correction to one
or more charges invoiced in a
previous billing period. Charge Class is commonly used to differentiate
corrections from regularly incurred charges.

The ChargeClass column MUST be present in the billing data. This
column MUST be of type String and MUST be “Correction” when the row
represents a correction to one or more charges invoiced in a previous
billing period. ChargeClass MUST be null when it is not a correction or
when it is a correction within the current billing period.

2.9.1. Column ID

ChargeClass

2.9.2. Display Name

Charge Class

2.9.3. Description

Indicates whether the row represents a correction to one or more
charges invoiced in a previous billing period.

2.9.4. Content Constraints

Constraint Value
Column type Dimension
Feature level Mandatory
Allows nulls True
Data type String
Value format Allowed values

Allowed values:

Value Description
Correction Correction to one or more charges invoiced
in previous billing periods (e.g., refunds and credit
modifications).

2.9.5. Introduced (version)

1.0

2.10. Charge Description

A Charge Description provides a high-level context of a row without requiring additional
discovery. This column is a self-contained summary of the charge’s
purpose and price. It typically covers a select group of corresponding
details across a billing dataset or provides information not otherwise
available.

The ChargeDescription column MUST be present in the billing data,
MUST be of type String, and SHOULD NOT be null. Providers SHOULD specify
the length of this column in their publicly available documentation.

2.10.1. Column ID

ChargeDescription

2.10.2. Display Name

Charge Description

2.10.3. Description

Self-contained summary of the charge’s purpose and price.

2.10.4. Content Constraints

Constraint Value
Column type Dimension
Feature level Mandatory
Allows nulls True
Data type String
Value format <not specified>

2.10.5. Introduced (version)

1.0-preview

2.11. Charge Frequency

Charge Frequency indicates how often a charge will occur. Along with
the charge period related columns,
the Charge Frequency is commonly used to understand recurrence periods
(e.g., monthly, yearly), forecast upcoming charges, and differentiate
between one-time and recurring fees for purchases.

The ChargeFrequency column is RECOMMENDED be present in the billing
data and MUST NOT be null. This column is of type String and MUST be one
of the allowed values. When ChargeCategory
is “Purchase”, ChargeFrequency MUST NOT be “Usage-Based”.

2.11.1. Column ID

ChargeFrequency

2.11.2. Display Name

Charge Frequency

2.11.3. Description

Indicates how often a charge will occur.

2.11.4. Content Constraints

Constraint Value
Column type Dimension
Feature level Recommended
Allows nulls False
Data type String
Value format Allowed values

Allowed values:

Value Description
One-Time Charges that only happen once and will not
repeat. One-time charges are typically recorded on the hour or day when
the cost was incurred.
Recurring Charges that repeat on a periodic cadence
(e.g., weekly, monthly) regardless of whether the product or service was
used. Recurring charges typically happen on the same day or point within
every period. The charge date does not change based on how or when the
service is used.
Usage-Based Charges that repeat every time the service
is used. Usage-based charges are typically recorded hourly or daily,
based on the granularity of the cost data for the period when the
service was used (referred to as charge period). Usage-based charges are
not recorded when the service is not used.

2.11.5. Introduced (version)

1.0-preview

2.12. Charge Period End

Charge Period End represents the exclusive end date and time
of a charge period. For
example, a time period where ChargePeriodStart is
‘2024-01-01T00:00:00Z’ and ChargePeriodEnd is ‘2024-01-02T00:00:00Z’
includes charges for January 1, since ChargePeriodStart is inclusive, but does not
include charges for January 2 since ChargePeriodEnd is
exclusive.

ChargePeriodEnd MUST be present in the billing data, MUST be of type
Date/Time, MUST be an exclusive value, and MUST NOT contain
null values. ChargePeriodEnd MUST match the ending date and time
boundary of the effective period of the charge.

2.12.1. Column ID

ChargePeriodEnd

2.12.2. Display Name

Charge Period End

2.12.3. Description

The exclusive end
date and time of a charge period.

2.12.4. Content constraints

Constraint Value
Column type Dimension
Feature level Mandatory
Allows nulls False
Data type Date/Time
Value format Date/Time
Format

2.12.5. Introduced (version)

0.5

2.13. Charge Period Start

Charge Period Start represents the inclusive start date and
time within a charge
period
. For example, a time period where ChargePeriodStart is
‘2024-01-01T00:00:00Z’ and ChargePeriodEnd is ‘2024-01-02T00:00:00Z’
includes charges for January 1, since ChargePeriodStart is
inclusive, but does not include charges for January 2 since
ChargePeriodEnd is exclusive.

ChargePeriodStart MUST be present in the billing data, MUST be of
type Date/Time, MUST be an inclusive value, and MUST NOT
contain null values. ChargePeriodStart MUST match the beginning date and
time boundary of the effective period of the charge.

2.13.1. Column ID

ChargePeriodStart

2.13.2. Display Name

Charge Period Start

2.13.3. Description

The inclusive start
date and time within a charge
period
.

2.13.4. Content constraints

Constraint Value
Column type Dimension
Feature level Mandatory
Allows nulls False
Data type Date/Time
Value format Date/Time
Format

2.13.5. Introduced (version)

0.5

2.14. Commitment Discount
Category

Commitment Discount Category indicates whether the commitment-based
discount
identified in the CommitmentDiscountId column is based
on usage quantity or cost (aka “spend”).

The CommitmentDiscountCategory column MUST be present in the billing
data when the provider supports commitment-based discounts.
This column MUST be of type String, MUST be null when CommitmentDiscountId is null, and MUST
NOT be null when CommitmentDiscountId is not null. The
CommitmentDiscountCategory MUST be one of the allowed values.

2.14.1. Column ID

CommitmentDiscountCategory

2.14.2. Display Name

Commitment Discount Category

2.14.3. Description

Indicates whether the commitment-based discount identified
in the CommitmentDiscountId column is based on usage quantity or cost
(aka “spend”).

2.14.4. Content constraints

Constraint Value
Column type Dimension
Feature level Conditional
Allows nulls True
Data type String
Value format Allowed Values

Allowed values:

Value Description
Spend Commitment-based discounts that require a
predetermined amount of spend.
Usage Commitment-based discounts that require a
predetermined amount of usage.

2.14.5. Introduced (version)

1.0-preview

2.15. Commitment Discount ID

A Commitment Discount ID is the identifier assigned to a commitment-based
discount
by the provider. Commitment Discount ID is commonly
used for scenarios like chargeback for commitments and savings
per commitment-based discount.

The CommitmentDiscountId column MUST be present in the billing data
when the provider supports commitment-based discounts. This
column MUST be of type String and MUST NOT contain null values when a
charge is related to a commitment-based discount. When a charge
is not associated with a commitment-based discount, the column
MUST be null. CommitmentDiscountId MUST be unique within the
provider.

2.15.1. Column ID

CommitmentDiscountId

2.15.2. Display Name

Commitment Discount ID

2.15.3. Description

The identifier assigned to a commitment-based discount by
the provider.

2.15.4. Content constraints

Constraint Value
Column type Dimension
Feature level Conditional
Allows nulls True
Data type String
Value format <not specified>

2.15.5. Introduced (version)

1.0-preview

2.16. Commitment Discount
Name

A Commitment Discount Name is the display name assigned to a commitment-based
discount
.

The CommitmentDiscountName column MUST be present in the billing data
when the provider supports commitment-based discounts. This
column MUST be of type String. The CommitmentDiscountName value MUST be
null if the charge is not related to a commitment-based
discount
and MAY be null if a display name cannot be assigned to a
commitment-based discount. CommitmentDiscountName MUST NOT be
null if a display name can be assigned to a commitment-based
discount
.

2.16.1. Column ID

CommitmentDiscountName

2.16.2. Display Name

Commitment Discount Name

2.16.3. Description

The display name assigned to a commitment-based
discount
.

2.16.4. Content constraints

Constraint Value
Column type Dimension
Feature level Conditional
Allows nulls True
Data type String
Value format <not specified>

2.16.5. Introduced (version)

1.0-preview

2.17. Commitment Discount
Status

Commitment Discount Status indicates whether the charge corresponds
with the consumption of the commitment-based
discount
identified in the CommitmentDiscountId column or the
unused portion of the committed amount.

The CommitmentDiscountStatus column MUST be present in the billing
data when the provider supports commitment-based discounts.
This column MUST be of type String, MUST be null when CommitmentDiscountId is null, and MUST
NOT be null when CommitmentDiscountId is not null and Charge Category is “Usage”. The
CommitmentDiscountCategory MUST be one of the allowed values.

2.17.1. Column ID

CommitmentDiscountStatus

2.17.2. Display name

Commitment Discount Status

2.17.3. Description

Indicates whether the charge corresponds with the consumption of a
commitment-based discount or the unused portion of the
committed amount.

2.17.4. Content constraints

Constraint Value
Column type Dimension
Feature level Conditional
Allows nulls True
Data type String
Value format Allowed Values

Allowed values:

Value Description
Used Charges that utilized a specific amount of
a commitment-based discount.
Unused Charges that represent the unused portion
of the commitment-based discount.

2.17.5. Introduced (version)

1.0

2.18. Commitment Discount
Type

Commitment Discount Type is a provider-assigned name to identify the
type of commitment-based
discount
applied to the row.

The CommitmentDiscountType column MUST be present in the billing data
when the provider supports commitment-based discounts. This
column MUST be of type String, MUST be null when CommitmentDiscountId is null, and MUST
NOT be null when CommitmentDiscountId is not null.

2.18.1. Column ID

CommitmentDiscountType

2.18.2. Display Name

Commitment Discount Type

2.18.3. Description

A provider-assigned identifier for the type of commitment-based
discount
applied to the row.

2.18.4. Content constraints

Constraint Value
Column type Dimension
Feature level Conditional
Allows nulls True
Data type String
Value format <not specified>

2.18.5. Introduced (version)

1.0-preview

2.19. Consumed Quantity

The Consumed Quantity represents the volume of a given SKU associated
with a resource or service used, based on the Consumed Unit. Consumed Quantity is often
derived at a finer granularity or over a different time interval when
compared to the Pricing Quantity
(complementary to Pricing Unit) and focuses
on resource and service consumption, not pricing and
cost.

ConsumedQuantity column MUST be present in the billing data when the
provider supports the measurement of usage. This column MUST NOT be null
if ChargeCategory is “Usage” and ChargeClass is not “Correction”. This column
MUST be null for other ChargeCategory values. This column MUST be of
type Decimal and MUST conform to Numeric
Format
requirements. The value MAY be negative in cases where ChargeClass is “Correction”.

2.19.1. Column ID

ConsumedQuantity

2.19.2. Display Name

Consumed Quantity

2.19.3. Description

The volume of a given SKU associated with a resource or
service used, based on the Consumed Unit.

2.19.4. Content constraints

Constraint Value
Column type Metric
Feature level Conditional
Allows nulls True
Data type Decimal
Value format Numeric
Format
Number range Any valid decimal value

2.19.5. Introduced (version)

1.0

2.20. Consumed Unit

The Consumed Unit represents a provider-specified measurement unit
indicating how a provider measures usage of a given SKU associated with
a resource or service. Consumed Unit complements
the Consumed Quantity metric. It is
often listed at a finer granularity or over a different time interval
when compared to Pricing Unit (complementary
to Pricing Quantity), and focuses on
resource and service consumption, not pricing and
cost.

The ConsumedUnit column MUST be present in the billing data when the
provider supports the measurement of usage. This column MUST be of type
String. ConsumedUnit MUST NOT be null if ChargeCategory is “Usage” and ChargeClass is not “Correction”. This column
MUST be null for other ChargeCategory values. Units of measure used in
ConsumedUnit SHOULD adhere to the values and format requirements
specified in the UnitFormat attribute. The
ConsumedUnit column MUST NOT be used to determine values related to any
pricing or cost metrics.

2.20.1. Column ID

ConsumedUnit

2.20.2. Display Name

Consumed Unit

2.20.3. Description

Provider-specified measurement unit indicating how a provider
measures usage of a given SKU associated with a resource or
service.

2.20.4. Content constraints

Constraint Value
Column type Metric
Feature level Conditional
Allows nulls True
Data type String
Value format Unit Format
recommended

2.20.5. Introduced (version)

1.0

2.21. Contracted Cost

Contracted Cost represents the cost calculated by multiplying contracted unit
price
and the corresponding Pricing
Quantity
. Contracted Cost is denominated in the Billing Currency and is commonly used for
calculating savings based on negotiation activities, by comparing it
with List Cost. If negotiated discounts are not
applicable, the Contracted Cost defaults to the List Cost.

Important: When aggregating Contracted Cost for
savings calculations, it’s important to exclude either one-time or
recurring charges (Charge Category
“Purchase”) that are paid to cover future eligible charges (e.g., Commitment-Based
Discount
) or the covered charges themselves. This exclusion helps
prevent double counting of these charges in the aggregation. Which set
of charges to exclude depends on whether cost are aggregated on a billed
basis (exclude covered charges) or accrual basis (exclude Purchases for
future charges). For instance, charges categorized as Charge Category “Purchase” and their related
Charge Category “Tax” charges for a
Commitment-Based Discount might be excluded from an accrual basis cost
aggregation of Contracted Cost. This is because the “Usage” and “Tax”
charge records provided during the term of the commitment discount
already specify the Contracted Cost. Purchase charges that cover future
eligible charges can be identified by filtering for Charge Category “Purchase” records with a Billed Cost greater than 0 and an Effective Cost equal to 0.

The ContractedCost column MUST be present in the billing data and
MUST NOT be null. This column MUST be of type Decimal, MUST conform to
Numeric Format requirements, and be
denominated in the BillingCurrency. When ContractedUnitPrice is present and not
null, multiplying the ContractedUnitPrice by PricingQuantity MUST
produce the ContractedCost, except in cases of ChargeClass “Correction”, which may address
PricingQuantity or any cost discrepancies independently.

In cases where the ContractedUnitPrice is present and null, the
following applies:

      • The ContractedCost of a charge calculated based on other charges
        (e.g., when the ChargeCategory is “Tax”)
        MUST be calculated based on the ContractedCost of those related
        charges.
      • The ContractedCost of a charge unrelated to other charges (e.g.,
        when the ChargeCategory is “Credit”) MUST
        match the BilledCost.

2.21.1. Column ID

ContractedCost

2.21.2. Display Name

Contracted Cost

2.21.3. Description

Cost calculated by multiplying contracted unit price and the
corresponding Pricing Quantity.

2.21.4. Content Constraints

Constraint Value
Column type Metric
Feature level Mandatory
Allows nulls False
Data type Decimal
Value format Numeric
Format
Number range Any valid decimal value

2.21.5. Introduced (version)

1.0

2.22. Contracted Unit Price

The Contracted Unit Price represents the agreed-upon unit price for a
single Pricing Unit of the associated SKU,
inclusive of negotiated discounts, if present, while excluding
negotiated commitment-based discounts or any other discounts. This price
is denominated in the Billing Currency.
The Contracted Unit Price is commonly used for calculating savings based
on negotiation activities. If negotiated discounts are not applicable,
the Contracted Unit Price defaults to the List
Unit Price
.

The ContractedUnitPrice column MUST be present in the billing data
when the provider supports negotiated pricing concept. This column MUST
be a Decimal within the range of non-negative decimal values, MUST
conform to Numeric Format requirements, and
be denominated in the BillingCurrency. It MUST NOT be null when ChargeClass is not “Correction” and ChargeCategory is “Usage” or “Purchase”, MUST
be null when ChargeCategory is “Tax”, and MAY be null for all other
combinations of ChargeClass and ChargeCategory. When ContractedUnitPrice
is present and not null, multiplying ContractedUnitPrice by PricingQuantity MUST equal ContractedCost, except in cases of
ChargeClass “Correction”, which may address PricingQuantity or any cost
discrepancies independently.

2.22.1. Column ID

ContractedUnitPrice

2.22.2. Display Name

Contracted Unit Price

2.22.3. Description

The agreed-upon unit price for a single Pricing Unit of the
associated SKU, inclusive of negotiated discounts, if present, while
excluding negotiated commitment-based discounts or any other
discounts.

2.22.4. Content Constraints

Constraint Value
Column type Metric
Feature level Conditional
Allows nulls True
Data type Decimal
Value format Numeric
Format
Number range Any valid non-negative decimal value

2.22.5. Introduced (version)

1.0

2.23. Effective Cost

Effective Cost represents the amortized cost of the charge after applying all reduced
rates, discounts, and the applicable portion of relevant, prepaid
purchases (one-time or recurring) that covered this charge. The
amortized portion included should be proportional to the Pricing Quantity and the time granularity of
the data. Since amortization breaks down and spreads the cost of a
prepaid purchase, to subsequent eligible charges, the Effective Cost of
the original prepaid charge is set to 0. Effective Cost does not mix or
“blend” costs across multiple charges of the same service. This cost is
denominated in the Billing Currency. The
Effective Cost is commonly utilized to track and analyze spending
trends.

This column resolves two challenges that are faced by
practitioners:

      1. Practitioners need to amortize relevant purchases, such as
        upfront fees, throughout the commitment and distribute them to
        the appropriate reporting groups (e.g. tags, resources).
      2. Many commitment-based
        discount
        constructs include a recurring expense for the
        commitment for every billing period and must
        distribute this cost to the resources using the
        commitment. This forces reconciliation between the initial
        commitment row per period
        and the actual usage rows.

The EffectiveCost column MUST be present in the billing data and MUST
NOT be null. This column MUST be of type Decimal, MUST conform to Numeric Format requirements, and be
denominated in the BillingCurrency. EffectiveCost MUST be 0 when
ChargeCategory is “Purchase” and the purchase is intended to cover
future eligible charges. The aggregated EffectiveCost for a billing
period may not match the charge received on the invoice for the same
billing period.

In cases where the ChargeCategory is
not “Usage” or “Purchase”, the following applies:

      • The EffectiveCost MUST be calculated based on the EffectiveCost of
        the related charges if the charge is calculated based on other charges
        (e.g. ChargeCategory is “Tax”).
      • The EffectiveCost MUST match the BilledCost if the charge is unrelated to other
        charges (e.g. ChargeCategory is
        “Credit”).

2.23.1. Column ID

EffectiveCost

2.23.2. Display Name

Effective Cost

2.23.3. Description

The amortized cost of the charge after applying all
reduced rates, discounts, and the applicable portion of relevant,
prepaid purchases (one-time or recurring) that covered this charge.

2.23.3.1.
Concerning Granularity and Distribution of Recurring Fee

Providers should distribute the commitment purchase amount
instead of including a row at the beginning of a period so
practitioners do not need to manually distribute the fee themselves.

2.23.3.2. Concerning
Amortization Approaches

Eligible purchases should be amortized using a methodology
determined by the provider that reflects the needs of their customer
base and is proportional to the Pricing Quantity and the time
granularity of the row. Should a practitioner desire to
amortize relevant purchases using a different approach, the
practitioner can do so using the Billed Cost
for the line item representing the initial purchase.

2.23.4. Content constraints

Constraint Value
Column type Metric
Feature level Mandatory
Allows nulls False
Data type Decimal
Value format Numeric
Format
Number range Any valid decimal value

2.23.5. Introduced (version)

0.5

2.24. Invoice Issuer

An Invoice Issuer is an entity responsible for invoicing for the resources or services consumed. It is commonly
used for cost analysis and reporting scenarios.

The InvoiceIssuer column MUST be present in the billing data. This
column MUST be of type String and MUST NOT contain null values.

See Appendix: Origination of cost
data
section for examples of Provider, Publisher and Invoice Issuer values that can be
used for various purchasing scenarios.

2.24.1. Column ID

InvoiceIssuerName

2.24.2. Display Name

Invoice Issuer

2.24.3. Description

The name of the entity responsible for invoicing for the
resources or services consumed.

2.24.4. Content Constraints

Constraint Value
Column type Dimension
Feature level Mandatory
Allows nulls False
Data type String
Value format <not specified>

2.24.5. Introduced (version)

0.5

2.25. List Cost

List Cost represents the cost calculated by multiplying the list unit price and the
corresponding Pricing Quantity. List Cost
is denominated in the Billing Currency
and is commonly used for calculating savings based on various rate
optimization activities, by comparing it with Contracted Cost, Billed
Cost
and Effective Cost.

Important: When aggregating List Cost for savings
calculations, it’s important to exclude either one-time or recurring
charges (Charge Category “Purchase”) that
are paid to cover future eligible charges (e.g., Commitment-Based
Discount
) or the covered charges themselves. This exclusion helps
prevent double counting of these charges in the aggregation. Which set
of charges to exclude depends on whether cost are aggregated on a billed
basis (exclude covered charges) or accrual basis (exclude Purchases for
future charges). For instance, charges categorized as Charge Category “Purchase” and their related
Charge Category “Tax” charges for a
Commitment-Based Discount might be excluded from an accrual basis cost
aggregation of List Cost. This is because the “Usage” and “Tax” charge
records provided during the term of the commitment discount already
specify the List Cost. Purchase charges that cover future eligible
charges can be identified by filtering for Charge Category “Purchase” records with a Billed Cost greater than 0 and an Effective Cost equal to 0.

The ListCost column MUST be present in the billing data and MUST NOT
be null. This column MUST be of type Decimal, MUST conform to Numeric Format requirements, and be
denominated in the BillingCurrency. When ListUnitPrice is present and not null,
multiplying the ListUnitPrice by PricingQuantity MUST produce the
ListCost, except in cases of ChargeClass
“Correction”, which may address PricingQuantity or any cost
discrepancies independently.

In cases where the ListUnitPrice is present and is null, the
following applies:

      • The ListCost of a charge calculated based on other charges (e.g.,
        when the ChargeCategory is “Tax”) MUST be
        calculated based on the ListCost of those related charges.
      • The ListCost of a charge unrelated to other charges (e.g., when the
        ChargeCategory is “Credit”) MUST match the
        BilledCost.

2.25.1. Column ID

ListCost

2.25.2. Display Name

List Cost

2.25.3. Description

Cost calculated by multiplying List Unit Price and the corresponding
Pricing Quantity.

2.25.4. Content Constraints

Constraint Value
Column type Metric
Feature level Mandatory
Allows nulls False
Data type Decimal
Value format Numeric
Format
Number range Any valid decimal value

2.25.5. Introduced (version)

1.0-preview

2.26. List Unit Price

The List Unit Price represents the suggested provider-published unit
price for a single Pricing Unit of the
associated SKU, exclusive of any discounts. This price is denominated in
the Billing Currency. The List Unit Price
is commonly used for calculating savings based on various rate
optimization activities.

The ListUnitPrice column MUST be present in the billing data when the
provider publishes unit prices exclusive of discounts. This column MUST
be a Decimal within the range of non-negative decimal values, MUST
conform to Numeric Format requirements, and
be denominated in the BillingCurrency. It MUST NOT be null when ChargeClass is not “Correction” and ChargeCategory is “Usage” or “Purchase”, MUST
be null when ChargeCategory is “Tax”, and MAY be null for all other
combinations of ChargeClass and ChargeCategory. When ListUnitPrice is
present and is not null, multiplying ListUnitPrice by PricingQuantity MUST equal ListCost, except in cases of ChargeClass
“Correction”, which may address PricingQuantity or any cost
discrepancies independently.

2.26.1. Column ID

ListUnitPrice

2.26.2. Display Name

List Unit Price

2.26.3. Description

The suggested provider-published unit price for a single Pricing Unit
of the associated SKU, exclusive of any discounts.

2.26.4. Content Constraints

Constraint Value
Column type Metric
Feature level Conditional
Allows nulls True
Data type Decimal
Value format Numeric
Format
Number range Any valid non-negative decimal value

2.26.5. Introduced (version)

1.0-preview

2.27. Pricing Category

Pricing Category describes the pricing model used for a charge at the
time of use or purchase. It can be useful for distinguishing between
charges incurred at the list
unit price
or a reduced price and exposing optimization
opportunities, like increasing commitment-based discount
coverage.

The PricingCategory column adheres to the following requirements:

      • PricingCategory MUST be present in the billing data when the
        provider supports more than one pricing category across all SKUs and
        MUST be of type String.
      • PricingCategory MUST NOT be null when ChargeClass is not “Correction” and ChargeCategory is “Usage” or “Purchase”, MUST
        be null when ChargeCategory is “Tax”, and MAY be null for all other
        combinations of ChargeClass and ChargeCategory.
      • PricingCategory MUST be one of the allowed values.
      • PricingCategory MUST be “Standard” when pricing is predetermined at
        the agreed upon rate for the billing
        account
        .
      • PricingCategory MUST be “Committed” when CommitmentDiscountId is not null.
      • PricingCategory MUST be “Dynamic” when pricing is determined by the
        provider and may change over time, regardless of predetermined agreement
        pricing.
      • PricingCategory MUST be “Other” when there is a pricing model but
        none of the allowed values apply.

2.27.1. Column ID

PricingCategory

2.27.2. Display Name

Pricing Category

2.27.3. Description

Describes the pricing model used for a charge at the time of use or
purchase.

2.27.4. Content constraints

Constraint Value
Column type Dimension
Feature level Conditional
Allows nulls True
Data type String
Value format Allowed values

Allowed values:

Value Description
Standard Charges priced at the agreed upon rate for
the billing account, including negotiated discounts. This includes any
flat rate and volume/tiered pricing but does not include dynamic or
commitment-based discount pricing.
Dynamic Charges priced at a variable rate
determined by the provider. This includes any product or service with a
unit price the provider can change without notice, like interruptible or
low priority resources.
Committed Charges with reduced prices due to a
commitment-based discount specified by the Commitment Discount ID.
Other Charges priced in a way not covered by
another pricing category.

2.27.5. Introduced (version)

1.0-preview

2.28. Pricing Quantity

The Pricing Quantity represents the volume of a given SKU associated
with a resource or service used or purchased, based
on the Pricing Unit. Distinct from Consumed Quantity (complementary to Consumed Unit), it focuses on pricing and cost,
not resource and service consumption.

The PricingQuantity column MUST be present in the billing data. This
column MUST be of type Decimal and MUST conform to Numeric Format requirements. The value MAY be
negative in cases where ChargeClass is
“Correction”. This column MUST NOT be null when ChargeClass is not “Correction” and ChargeCategory is “Usage” or “Purchase”, MUST
be null when ChargeCategory is “Tax”, and MAY be null for all other
combinations of ChargeClass and ChargeCategory. When unit prices are not
null, multiplying PricingQuantity by a unit price MUST produce a result
equal to the corresponding cost metric, except in cases of ChargeClass
“Correction”, which may address PricingQuantity or any cost
discrepancies independently.

2.28.1. Column ID

PricingQuantity

2.28.2. Display Name

Pricing Quantity

2.28.3. Description

The volume of a given SKU associated with a resource or
service used or purchased, based on the Pricing Unit.

2.28.4. Content constraints

Constraint Value
Column type Metric
Feature level Mandatory
Allows nulls True
Data type Decimal
Value format Numeric
Format
Number Range Any valid decimal value

2.28.5. Introduced (version)

1.0-preview

2.29. Pricing Unit

The Pricing Unit represents a provider-specified measurement unit for
determining unit prices, indicating how the provider rates measured
usage and purchase quantities after applying pricing rules like block pricing. Common
examples include the number of hours for compute appliance runtime (e.g.
Hours), gigabyte-hours for a storage appliance (e.g.,
GB-Hours), or an accumulated count of requests for a
network appliance or API service (e.g., 1000 Requests).
Pricing Unit complements the Pricing
Quantity
metric. Distinct from the Consumed
Unit
, it focuses on pricing and cost, not resource and service consumption, often at a
coarser granularity.

The PricingUnit column MUST be present in the billing data. This
column MUST be of type String. It MUST NOT be null when ChargeClass is not “Correction” and ChargeCategory is “Usage” or “Purchase”, MUST
be null when ChargeCategory is “Tax”, and MAY be null for all other
combinations of ChargeClass and ChargeCategory. Units of measure used in
PricingUnit SHOULD adhere to the values and format requirements
specified in the UnitFormat attribute.

The PricingUnit value MUST be semantically equal to the corresponding
pricing measurement unit value provided in:

      • The provider-published price
        list
      • The invoice, when the invoice includes a pricing measurement
        unit

2.29.1. Column ID

PricingUnit

2.29.2. Display Name

Pricing Unit

2.29.3. Description

Provider-specified measurement unit for determining unit prices,
indicating how the provider rates measured usage and purchase quantities
after applying pricing rules like block pricing.

2.29.4. Content constraints

Constraint Value
Column type Dimension
Feature level Mandatory
Allows nulls True
Data type String
Value format Unit Format

2.29.5. Introduced (version)

1.0-preview

2.30. Provider

A Provider is an entity that makes the resources or services available for purchase.
It is commonly used for cost analysis and reporting scenarios.

The Provider column MUST be present in the billing data. This column
MUST be of type String and MUST NOT contain null values.

See Appendix: Origination of cost
data
section for examples of Provider, Publisher and Invoice Issuer
values that can be used for various purchasing scenarios.

2.30.1. Column ID

ProviderName

2.30.2. Display Name

Provider

2.30.3. Description

The name of the entity that made the resources or
services available for purchase.

2.30.4. Content Constraints

Constraint Value
Column type Dimension
Feature level Mandatory
Allows nulls False
Data type String
Value format <not specified>

2.30.5. Introduced (version)

0.5

2.31. Publisher

A Publisher is an entity that produces the resources or services that were purchased. It
is commonly used for cost analysis and reporting scenarios.

The Publisher column MUST be present in the billing data. This column
MUST be of type String and MUST NOT contain null values.

See Appendix: Origination of cost
data
section for examples of Provider,
Publisher and Invoice Issuer values that
can be used for various purchasing scenarios.

2.31.1. Column ID

PublisherName

2.31.2. Display Name

Publisher

2.31.3. Description

The name of the entity that produced the resources or
services that were purchased.

2.31.4. Content Constraints

Constraint Value
Column type Dimension
Feature level Mandatory
Allows nulls False
Data type String
Value format <not specified>

2.31.5. Introduced (version)

0.5

2.32. Region ID

A Region ID is a provider-assigned identifier for an isolated
geographic area where a resource is provisioned or a service is provided. The region is
commonly used for scenarios like analyzing cost and unit prices based on
where resources are deployed.

The RegionId column MUST be present in the billing data when the
provider supports deploying resources or services within a
region and MUST be of type String. RegionId MUST NOT be null
when a resource or service is operated in or managed
from a distinct region by the Provider and MAY contain null values when
a resource or service is not restricted to an isolated
geographic area.

2.32.1. Column ID

RegionId

2.32.2. Display Name

Region ID

2.32.3. Description

Provider-assigned identifier for an isolated geographic area where a
resource is provisioned or a service is provided.

2.32.4. Content constraints

Constraint Value
Column type Dimension
Feature level Conditional
Allows nulls True
Data type String
Value format <not specified>

2.32.5. Introduced (version)

1.0

2.33. Region Name

Region Name is a provider-assigned display name for an isolated
geographic area where a resource is provisioned or a service is provided. Region Name
is commonly used for scenarios like analyzing cost and unit prices based
on where resources are deployed.

The RegionName column MUST be present in the billing data when the
provider supports deploying resources or services within a
region and MUST be of type String. RegionName MUST NOT be null
when a resource or service is operated in or managed
from a distinct region by the Provider and MAY contain null values when
a resource or service is not restricted to an isolated
geographic area.

2.33.1. Column ID

RegionName

2.33.2. Display Name

Region Name

2.33.3. Description

The name of an isolated geographic area where a resource is
provisioned or a service is provided.

2.33.4. Content constraints

Constraint Value
Column type Dimension
Feature level Conditional
Allows nulls True
Data type String
Value format <not specified>

2.33.5. Introduced (version)

1.0

2.34. Resource ID

A Resource ID is an identifier assigned to a resource by the provider. The
Resource ID is commonly used for cost reporting, analysis, and
allocation scenarios.

The ResourceId column MUST be present in the billing data when the
provider supports billing based on provisioned resources. This column
MUST be of type String. The ResourceId value MAY be a nullable column as
some cost data rows may not be
associated with a resource. ResourceId MUST appear in the cost
data if an identifier is assigned to a resource by the
provider. ResourceId SHOULD be a fully-qualified identifier that ensures
global uniqueness within the provider.

2.34.1. Column ID

ResourceId

2.34.2. Display Name

Resource ID

2.34.3. Description

Identifier assigned to a resource by the provider.

2.34.4. Content Constraints

Constraint Value
Column type Dimension
Feature level Conditional
Allows nulls True
Data type String
Value format <not specified>

2.34.5. Introduced (version)

0.5

2.35. Resource Name

The Resource Name is a display name assigned to a resource. It is commonly used for
cost analysis, reporting, and allocation scenarios.

The ResourceName column MUST be present in the billing data when the
provider supports billing based on provisioned resources. This column
MUST be of type String. The ResourceName value MAY be a nullable column
as some cost data rows may not be
associated with a resource or because a display name cannot be
assigned to a resource. ResourceName MUST NOT be null if a
display name can be assigned to a resource. Resources
not provisioned interactively or only have a system-generated ResourceId MUST NOT duplicate the same value as
the ResourceName.

2.35.1. Column ID

ResourceName

2.35.2. Display Name

Resource Name

2.35.3. Description

Display name assigned to a resource.

2.35.4. Content Constraints

Constraint Value
Column type Dimension
Feature level Conditional
Allows nulls True
Data type String
Value format <not specified>

2.35.5. Introduced (version)

0.5

2.36. Resource Type

Resource Type describes the kind of resource the charge applies to. A
Resource Type is commonly used for scenarios like identifying cost
changes in groups of similar resources and may include values
like Virtual Machine, Data Warehouse, and Load Balancer.

The ResourceType column MUST be present in the billing data when the
provider supports billing based on provisioned resources and supports
assigning a type for resources. This column MUST be of type String and
MUST NOT be null when a corresponding ResourceId is not null. When a corresponding
ResourceId value is null, the ResourceType column value MUST also be
null.

2.36.1. Column ID

ResourceType

2.36.2. Display Name

Resource Type

2.36.3. Description

The kind of resource the charge applies to.

2.36.4. Content Constraints

Constraint Value
Column type Dimension
Feature level Conditional
Allows nulls True
Data type String
Value format <not specified>

2.36.5. Introduced (version)

1.0-preview

2.37. Service Category

The Service Category is the highest-level classification of a service based on the core function
of the service. Each service should have one and only
one category that best aligns with its primary purpose. The Service
Category is commonly used for scenarios like analyzing costs across
providers and tracking the migration of workloads across fundamentally
different architectures.

The ServiceCategory column MUST be present and MUST NOT be null. This
column is of type String and MUST be one of the allowed values.

2.37.1. Column ID

ServiceCategory

2.37.2. Display Name

Service Category

2.37.3. Description

Highest-level classification of a service based on the core
function of the service.

2.37.4. Content Constraints

Constraint Value
Column type Dimension
Feature level Mandatory
Allows nulls False
Data type String
Value format Allowed Values

Allowed values:

Service Category Description
AI and Machine Learning Artificial Intelligence and Machine
Learning related technologies.
Analytics Data processing, analytics, and
visualization capabilities.
Business Applications Business and productivity applications and
services.
Compute Virtual, containerized, serverless, or
high-performance computing infrastructure and services.
Databases Database platforms and services that allow
for storage and querying of data.
Developer Tools Software development and delivery tools
and services.
Multicloud Support for interworking of multiple cloud
and/or on-premises environments.
Identity Identity and access management
services.
Integration Services that allow applications to
interact with one another.
Internet of Things Development and management of IoT devices
and networks.
Management and Governance Management, logging, and observability of
a customer’s use of cloud.
Media Media and entertainment streaming and
processing services.
Migration Moving applications and data to the
cloud.
Mobile Services enabling cloud applications to
interact via mobile technologies.
Networking Network connectivity and management.
Security Security monitoring and compliance
services.
Storage Storage services for structured or
unstructured data.
Web Services enabling cloud applications to
interact via the Internet.
Other New or emerging services that do not align
with an existing category.

2.37.5. Introduced (version)

0.5

2.38. Service Name

A service represents an
offering that can be purchased from a provider (e.g., cloud virtual
machine, SaaS database, professional services from a systems
integrator). A service offering can include various types of
usage or other charges. For example, a cloud database service
may include compute, storage, and networking charges.

The Service Name is a display name for the offering that was
purchased. The Service Name is commonly used for scenarios like
analyzing aggregate cost trends over time and filtering data to
investigate anomalies.

The ServiceName column MUST be present in the cost data. This column
MUST be of type String and MUST NOT contain null values.

2.38.1. Column ID

ServiceName

2.38.2. Display Name

Service Name

2.38.3. Description

An offering that can be purchased from a provider (e.g., cloud
virtual machine, SaaS database, professional services from a
systems integrator).

2.38.4. Content Constraints

Constraint Value
Column type Dimension
Feature level Mandatory
Allows nulls False
Data type String
Value format <not specified>

2.38.5. Introduced (version)

0.5

2.39. SKU ID

A SKU ID is a unique identifier that defines a provider-supported
construct for organizing properties that are common across one or more
SKU Prices. SKU ID can be
referenced on a catalog or price
list
published by a provider to look up detailed information
about the SKU. The composition of the properties associated with the SKU
ID may differ across providers. Some providers may not support the SKU construct and instead associate
all such properties directly with the SKU Price. SKU ID is
commonly used for analyzing cost based on SKU-related
properties above the pricing constructs.

The SkuId column MUST be present in the billing data when the
provider publishes a SKU list. This column MUST be of type String. It
MUST NOT be null when ChargeClass is not
“Correction” and ChargeCategory is “Usage”
or “Purchase”, MUST be null when ChargeCategory is “Tax”, and MAY be
null for all other combinations of ChargeClass and ChargeCategory. SkuId
MUST equal SkuPriceId when a provider does not support an overarching
SKU ID construct.

2.39.1. Column ID

SkuId

2.39.2. Display Name

SKU ID

2.39.3. Description

A unique identifier that defines a provider-supported construct for
organizing properties that are common across one or more SKU
Prices
.

2.39.4. Content constraints

Constraint Value
Column type Dimension
Feature level Conditional
Allows nulls True
Data type String
Value format <not specified>

2.39.5. Introduced (version)

1.0-preview

2.40. SKU Price ID

A SKU Price ID is a unique identifier that defines the unit price
used to calculate the charge. SKU Price ID can be referenced on a price list published by a
provider to look up detailed information, including a corresponding list
unit price. The composition of the properties associated with the SKU
Price ID may differ across providers. SKU Price ID is commonly used for
analyzing cost based on pricing properties such as Terms and Tiers.

The SkuPriceId column MUST be present in the billing data when the
provider publishes a SKU price list. This column MUST be of type String.
SkuPriceId MUST define a single unit price used for calculating the
charge. The ListUnitPrice MUST be
associated with the SkuPriceId in the provider published price
list
. This column MUST NOT be null when ChargeClass is not “Correction” and ChargeCategory is “Usage” or “Purchase”, MUST
be null when ChargeCategory is “Tax”, and MAY be null for all other
combinations of ChargeClass and ChargeCategory. A given value of
SkuPriceId MUST be associated with one and only one SkuId, except in cases of commitment discount
flexibility.

2.40.1. Column ID

SkuPriceId

2.40.2. Display Name

SKU Price ID

2.40.3. Description

A unique identifier that defines the unit price used to calculate the
charge.

2.40.4. Content constraints

Constraint Value
Column type Dimension
Feature level Conditional
Allows nulls True
Data type String
Value format <not specified>

2.40.5. Introduced (version)

1.0-preview

2.41. Sub Account ID

A Sub Account ID is a provider-assigned identifier assigned to a sub account. Sub Account ID is
commonly used for scenarios like grouping based on organizational
constructs, access management needs, and cost allocation strategies.

The SubAccountId column MUST be present in the billing data when the
provider supports a sub account construct. This column MUST be
of type String. If a charge does not apply to a sub account,
the SubAccountId column MUST be null.

See Appendix:
Grouping constructs for resources or services
for details and
examples of the different grouping constructs supported by FOCUS.

2.41.1. Column ID

SubAccountId

2.41.2. Display Name

Sub Account ID

2.41.3. Description

An ID assigned to a grouping of resources or services, often used to manage
access and/or cost.

2.41.4. Content constraints

Constraint Value
Column type Dimension
Feature level Conditional
Allows nulls True
Data type String
Value format <not specified>

2.41.5. Introduced (version)

0.5

2.42. Sub Account Name

A Sub Account Name is a display name assigned to a sub account. Sub account Name
is commonly used for scenarios like grouping based on organizational
constructs, access management needs, and cost allocation strategies.

The SubAccountName column MUST be present in the billing data when
the provider supports a sub account construct. This column MUST
be of type String. If a charge does not apply to a sub account,
the SubAccountName column MUST be null.

See Appendix:
Grouping constructs for resources or services
for details and
examples of the different grouping constructs supported by FOCUS.

2.42.1. Column ID

SubAccountName

2.42.2. Display Name

Sub Account Name

2.42.3. Description

A name assigned to a grouping of resources or services, often used to manage
access and/or cost.

2.42.4. Content constraints

Constraint Value
Column type Dimension
Feature level Conditional
Allows nulls True
Data type String
Value format <not specified>

2.42.5. Introduced (version)

0.5

2.43. Tags

The Tags column represents the set of tags assigned to tag sources that also account
for potential provider-defined or user-defined tag evaluations. Tags are
commonly used for scenarios like adding business context to billing data
to identify and accurately allocate charges. Tags may also be referred
to by providers using other terms such as labels.

A tag becomes finalized when a single
value is selected from a set of possible tag values assigned to the tag
key. When supported by a provider, this can occur when a tag value is
set by provider-defined or user-defined rules.

The Tags column adheres to the following requirements:

      • The Tags column MUST be present in the billing data when the
        provider supports setting user or provider-defined tags.
      • The Tags column MUST contain user-defined and provider-defined
        tags.
      • The Tags column MUST only contain finalized tags.
      • The Tags column MUST be in Key-Value
        Format
        .
      • A Tag key with a non-null value for a given resource SHOULD be
        included in the tags column.
      • A Tag key with a null value for a given resource MAY be included in
        the tags column depending on the provider’s tag finalization
        process.
      • A Tag key that does not support a corresponding value, MUST
        have a corresponding true (boolean) value set.
      • If Tag finalization is supported, providers MUST publish tag
        finalization methods and semantics within their respective
        documentation.
      • Providers MUST NOT alter user-defined Tag keys or values.

Provider-defined Tags additionally adhere to the following
requirements:

      • Provider-defined tags MUST be prefixed with a provider-specified tag
        key prefix.
      • Providers SHOULD publish all provider-specified tag key prefixes
        within their respective documentation.

2.43.1.
Provider-Defined vs. User-Defined Tags

This example illustrates three different tagging scenarios. The first
two illustrate when the provider supports both keys and values, while
the third is for supporting keys only. The first tag is user-defined and
doesn’t have a provider prefix. The second tag is provider-defined and
has a prefix of acme/, which is reserved by the provider.
The third tag has a tag key of baz and its value is
assigned the boolean value true since the tag doesn’t
support a value.

    {
        "foo": "bar",
        "acme/foo": "bar",
        "baz": true,
    }

2.43.2. Finalized Tags

Within a provider, tag keys may be associated with multiple values,
and potentially defined at different levels within the provider, such as
accounts, folders, resource
and other resource grouping constructs. When finalizing,
providers must reduce these multiple levels of definition to a
single value where each key is associated with exactly one value. The
method by which this is done and the semantics are up to each provider
but must be documented within their respective documentation.

As an example, let’s assume 1 sub
account
exists with 1 virtual machine with the following
details, and tag inheritance favors Resources over Sub
Accounts
.

      • Sub Account
        • id: my-sub-account
        • user-defined tags: team:ops, env:prod
      • Virtual Machine
        • id: my-vm
        • user-defined tags: team:web

The table below represents a finalized billing dataset with these
resources. It also shows the finalized state after all
resource-oriented, tag inheritance rules are processed.

ResourceType ResourceId Tags
Sub Account my-sub-account { “team”: “ops”, “env”: “prod” }
Virtual Machine my-vm { “team”: “web”, “env”: “prod”
}

Because the the Virtual Machine Resource did not have an
env tag, it inherited tag, env:prod
(italicized), from its parent sub account. Conversely, because
the Virtual Machine Resource already has a team tag
(team:web), it did not inherit team:ops from
its parent sub account.

2.43.3. Column ID

Tags

2.43.4. Display Name

Tags

2.43.5. Description

The set of tags assigned to tag sources that account for
potential provider-defined or user-defined tag evaluations.

2.43.6. Content Constraints

Constraint Value
Column type Dimension
Feature level Conditional
Allows nulls True
Data type JSON
Value format Key-Value
Format

2.43.7. Introduced (version)

1.0-preview

3. Attributes

Attributes are requirements that apply across a billing dataset
instead of an individual column level. Requirements on data content can
include naming conventions, data types, formatting standardizations,
etc. Attributes may introduce high-level requirements for data
granularity, recency, frequency, etc. Requirements defined in attributes
are necessary for servicing FinOps
capabilities
accurately using a standard set of instructions
regardless of the origin of the data.

3.1. Column Naming and
Ordering

Column IDs provided in cost data following a consistent naming and
ordering convention reduce friction for FinOps practitioners who consume
the data for analysis, reporting, and other use cases.

All columns defined in the FOCUS specification MUST follow the naming
and ordering requirements listed below.

3.1.1. Attribute ID

ColumnNamingAndOrdering

3.1.2. Attribute Name

Column Naming and Ordering

3.1.3. Description

Naming and ordering convention for columns appearing in billing
data.

3.1.4. Requirements

3.1.4.1. Column Names
      • All columns defined by FOCUS MUST follow the following rules:
        • Column IDs MUST use Pascal case.
        • Column IDs MUST NOT use abbreviations.
        • Column IDs MUST be alphanumeric with no special characters.
        • Columns that have an ID and a Name MUST have the Id or
          Name suffix in the Column ID. Display Name for a Column MAY
          avoid the Name suffix if there are no other columns with the same name
          prefix.
        • Column IDs SHOULD NOT use acronyms.
        • Column IDs SHOULD NOT exceed 50 characters to accommodate column
          length restrictions of various data repositories.
      • All custom columns MUST be prefixed with a consistent
        x_ prefix to identify them as external, custom columns and
        distinguish them from FOCUS columns to avoid conflicts in future
        releases.
      • Columns that have an ID and a Name MUST have the Id or
        Name suffix in the Column ID. Display Name for a Column MAY
        avoid the Name suffix if it is considered superfluous.
      • Columns with the Category suffix MUST be
        normalized.
      • Custom (e.g., provider-defined) columns SHOULD follow the same rules
        listed above for FOCUS columns.

3.1.4.2. Column Order
      • All FOCUS columns SHOULD be first in the provided dataset.
      • Custom columns SHOULD be listed after all FOCUS columns and SHOULD
        NOT be intermixed.
      • Columns MAY be sorted alphabetically, but custom columns SHOULD be
        after all FOCUS columns.

3.1.5. Exceptions

      • Identifiers will use the “Id” abbreviation since this is a standard
        pattern across the industry.
      • Product offerings that incur charges will use the “Sku” abbreviation
        because it is a well-understood term both within and outside the
        industry.

3.1.6. Introduced (version)

0.5

3.2. Currency Code Format

Columns that contain currency information in cost data following a
consistent format reduce friction for FinOps practitioners who consume
the data for analysis, reporting, and other use cases.

All columns capturing a currency value, defined in the FOCUS
specification, MUST follow the requirements listed below. Custom
currency-related columns SHOULD also follow the same formatting
requirements.

3.2.1. Attribute ID

CurrencyCodeFormat

3.2.2. Attribute Name

Currency Code Format

3.2.3. Description

Formatting for currency columns appearing in billing data.

3.2.4. Requirements

Currency-related columns MUST be represented as a three-letter
alphabetic code as dictated in the governing document ISO 4217:2015.

3.2.5. Exceptions

None

3.2.6. Introduced (version)

0.5

3.3. Date/Time Format

Columns that provide date and time information conforming to
specified rules and formatting requirements ensure clarity, accuracy,
and ease of interpretation for both humans and systems.

All columns capturing a date/time value, defined in the FOCUS
specification, MUST follow the formatting requirements listed below.
Custom date/time-related columns SHOULD also follow the same formatting
requirements.

3.3.1. Attribute ID

DateTimeFormat

3.3.2. Attribute Name

Date/Time Format

3.3.3. Description

Rules and formatting requirements for date/time-related columns
appearing in billing data.

3.3.4. Requirements

      • Date/time values MUST be in UTC (Coordinated Universal Time) to
        avoid ambiguity and ensure consistency across different time zones.
      • Date/time values format MUST be aligned with ISO 8601 standard,
        which provides a globally recognized format for representing dates and
        times (see ISO
        8601-1:2019
        governing document for details).
      • Values providing information about a specific moment in time MUST be
        represented in the extended ISO 8601 format with UTC offset
        (‘YYYY-MM-DDTHH:mm:ssZ’) and conform to the following guidelines:

        • Include the date and time components, separated with the letter
          ‘T’
        • Use two-digit hours (HH), minutes (mm), and seconds (ss).
        • End with the ‘Z’ indicator to denote UTC (Coordinated Universal
          Time)

3.3.5. Exceptions

None

3.3.6. Introduced (version)

0.5

3.4. Discount Handling

A discount is a pricing construct where providers offer a reduced
price for services. Providers
may have many types of discounts, including but not limited to
commercially negotiated discounts, commitment-based discounts when you
agree to a certain amount of usage or spend, and bundled discounts where
you receive free or discounted usage of one product or service
based on the usage of another. Discount Handling is commonly used in
scenarios like verifying discounts were applied and calculating cost
savings.

Some discount offers can be purchased from a provider to get reduced
prices. The most common example is a commitment-based discount, where
you “purchase” a commitment to use or spend a specific amount within a
period. When a commitment isn’t fully utilized, the unused amount
reduces the potential savings from the discount and can even result in
paying higher costs than without the discount. Due to this risk, unused
commitment amounts need to be clearly identifiable at a granular level.
To facilitate this, unused commitments are recorded with a separate row
for each charge period where the commitment was not fully utilized. In
order to show the impact of purchased discounts on each discounted row,
discount purchases need the purchase amount the be amortized over the
term the discount is applied to (e.g., 1 year) with each charge period
split and applied to each row that received the discount.

Amortization is a process used to break down and spread purchase
costs over a period of time or term of use. When a purchase is
applicable to resources, like commitment-based discounts, the amortized
cost of a resource takes the initial payment and term into account and
distributes it out based on the resource’s usage, attributing the
prorated cost for each unit of billing. Amortization enables users of
billing data to distribute purchase charges to the appropriate audience
in support of cost allocation efforts. Discount Handling for purchased
commitments is commonly used for scenarios like calculating utilization
and implementing chargeback for the purchase amount.

While providers may use different terms to describe discounts, FOCUS
identifies a discount as being a reduced price applied directly to a
row. Any price or cost reductions that are awarded after the fact are
identified as a “Credit” Charge Subcategory. One example might be when a
provider offers a reduced rate after passing a certain threshold of
usage or spend.

All rows defined in FOCUS MUST follow the discount handling
requirements listed below.

3.4.1. Attribute ID

DiscountHandling

3.4.2. Attribute Name

Discount Handling

3.4.3. Description

Indicates how to include and apply discounts to usage charges or
rows.

3.4.4. Requirements

      • All applicable discounts SHOULD be applied to each row they pertain
        to and SHOULD NOT be negated in a separate row.
      • All discounts applied to a row MUST apply to the entire charge.
        • Multiple discounts MAY apply to a row, but they MUST apply to the
          entire charge covered by that row.
        • If a discount only applies to a portion of a charge, then the
          discounted portion of the charge MUST be split into a separate row.
        • Each discount MUST be identifiable using existing FOCUS columns.
          • Rows with a commitment-based discount applied to them MUST include a
            CommitmentDiscountId.
          • If a provider applies a discount that cannot be represented by a
            FOCUS column, they SHOULD include additional columns to identify the
            source of the discount.
      • Purchased discounts (e.g., commitment-based discounts) MUST be
        amortized.

        • The BilledCost MUST be 0 for any row where the commitment covers the
          entire cost for the charge period.
        • The EffectiveCost MUST include the portion of the amortized purchase
          cost that applies to this row.
        • The sum of the EffectiveCost for all rows where
          CommitmentDiscountStatus is “Used” or “Unused” for each
          CommitmentDiscountId over the entire duration of the commitment MUST be
          the same as the total BilledCost of the commitment-based discount.
        • The CommitmentDiscountId and ResourceId MUST be set to the ID
          assigned to the commitment-based discount. ChargeCategory MUST be set to
          “Purchase” on rows that represent a purchase of a commitment-based
          discount.
        • CommitmentDiscountStatus MUST be “Used” for ChargeCategory “Usage”
          rows that received a reduced price from a commitment.
          CommitmentDiscountId MUST be set to the ID assigned to the discount.
          ResourceId MUST be set to the ID of the resource that received the
          discount.
        • If a commitment is not fully utilized, the provider MUST include a
          row that represents the unused portion of the commitment for that charge
          period. These rows MUST be represented with CommitmentDiscountStatus set
          to “Unused” and ChargeCategory set to “Usage”. Such rows MUST have their
          CommitmentDiscountId and ResourceId set to the ID assigned to the
          commitment-based discount.
      • Credits that are applied after the fact MUST use a ChargeCategory of
        “Credit”.

3.4.5. Exceptions

None

3.4.6. Introduced (version)

1.0-preview

3.5. Key-Value Format

Columns that provide Key-Value information are often used in place of
separate columns for enumerating data which would be inherently sparse
and/or without predetermined keys. This consolidates related information
and provides more consistency in the schema. Key-value pairs are also
referred to as name-value pairs, attribute-value pairs, or field-value
pairs.

All key-value related columns defined in the FOCUS specification MUST
follow the key-value formatting requirements listed below.

3.5.1. Attribute ID

KeyValueFormat

3.5.2. Attribute Name

Key-Value Format

3.5.3. Description

Rules and formatting requirements for columns appearing in billing
data that convey data as key-value pairs.

3.5.4. Requirements

      • Key-Value Format columns MUST contain a serialized JSON string,
        consistent with the ECMA
        404
        definition of an object.
      • Keys in a key-value pair MUST be unique within an object.
      • Values in a key-value pair MUST be one of the following types:
        number, string, true, false, or
        null.
      • Values in a key-value pair MUST NOT be an object or an array.

3.5.5. Exceptions

None

3.5.6. Introduced (version)

1.0-preview

3.6. Null Handling

Cost data rows that don’t have a
value that can be presented for a column must be handled in a consistent
way to reduce friction for FinOps practitioners who consume the data for
analysis, reporting, and other use cases.

All columns defined in the FOCUS specification MUST follow the null
handling requirements listed below. Custom columns SHOULD also follow
the same formatting requirements.

3.6.1. Attribute ID

NullHandling

3.6.2. Attribute Name

Null Handling

3.6.3. Description

Indicates how to handle columns that don’t have a value.

3.6.4. Requirements

      • Columns MUST use NULL when there isn’t a value that can be specified
        for a nullable column.
      • Columns MUST NOT use empty strings or placeholder values such as 0
        for numeric columns or “Not Applicable” for string columns to represent
        a null or not having a value, regardless of whether the column allows
        nulls or not.

3.6.5. Exceptions

None

3.6.6. Introduced (version)

0.5

3.7. Numeric Format

Columns that provide numeric values conforming to specified rules and
formatting requirements ensure clarity, accuracy, and ease of
interpretation for humans and systems. The FOCUS specification does not
require a specific level of precision for numeric values. The level of
precision required for a given column is determined by the provider and
should be part of a data definition published by the provider.

All columns capturing a numeric value, defined in the FOCUS
specification, MUST follow the formatting requirements listed below.
Custom numeric value capturing columns SHOULD adopt the same format
requirements over time.

3.7.1. Attribute ID

NumericFormat

3.7.2. Attribute Name

Numeric Format

3.7.3. Description

Rules and formatting requirements for numeric columns appearing in
billing data.

3.7.4. Requirements

      • Columns with a Numeric value format MUST contain a single numeric
        value.
      • Numeric values MUST be expressed as an integer value, a decimal
        value, or a value expressed in scientific notation. Fractional notation
        MUST NOT be used.
      • Numeric values expressed using scientific notation MUST be expressed
        using E notation “mEn” with a real number m and an integer n indicating
        a value of “m x 10^n”. The sign of the exponent MUST only be expressed
        as part of the exponent value if n is negative.
      • Numeric values MUST NOT be expressed with mathematical symbols,
        functions, or operators.
      • Numeric values MUST NOT contain qualifiers or additional characters
        (e.g., currency symbols, units of measure, etc.).
      • Numeric values MUST NOT contain commas or punctuation marks except
        for a single decimal point (“.”) if required to express a decimal
        value.
      • Numeric values MUST NOT include a character to represent a sign for
        a positive value. A negative sign (-) MUST indicate a negative
        value.
      • Columns with a Numeric value format MUST present one of the
        following values as the “Data type” in the column definition.

        • Allowed values:
          Data Type Type Description
          Integer Specifies a numeric value represented by a
          whole number or by zero. Integer number formats correspond to standard
          data types defined by ISO/IEC 9899:2018
          Decimal Specifies a numeric value represented by a
          decimal number. Decimal formats correspond to ISO/IEC/IEEE 60559:2011
          and IEEE 754-2008 definitions.
      • Providers SHOULD define precision and scale for Numeric Format
        columns using one of the following precision values in a data definition
        document that providers publish.

        • Allowed values:
          Data Type Precision Definition Range / Significant Digits
          Integer Short 16-bit signed short int ISO/IEC
          9899:2018
          -32,767 to +32,767
          Integer Long 32-bit signed long int ISO/IEC
          9899:2018
          -2,147,483,647 to +2,147,483,647
          Integer Extended 64-bit signed two’s complement integer
          or higher
          -(2^63 – 1) to (2^63 – 1)
          Decimal Single 32-bit binary format IEEE 754-2008
          floating-point (decimal32)
          9
          Decimal Double 64-bit binary format IEEE 754-2008
          floating-point (decimal64)
          16
          Decimal Extended 128-bit binary format IEEE 754-2008
          floating-point (decimal128) or higher
          36+

3.7.4.1. Examples

This format requires that single numeric values be represented using
an integer or decimal format without additional characters or
qualifiers. The following lists provide examples of values that meet the
requirements and those that do not.

      • Values Meeting Numeric Requirements:
        • -100.2
        • -3
        • 4
        • 35.2E-7
        • 1.234
      • Values NOT Meeting Numeric Requirements
        • 1 1/2 – contains fractional notation
        • 35.2E+7 – contains a positive exponent with a sign
        • 35.24 x 10^7 – contains an invalid format for scientific
          notation
        • [3,5,8] – contains an array
        • [4:5] – contains a range
        • 5i + 4 – contains a complex number
        • sqrt(2) – contains a mathematical symbol or operation
        • 2.3^3 – contains an exponent
        • 32 GiB – contains a unit of measure
        • $32 – contains a currency symbol
        • 3,432,342 – contains a comma
        • +333 – contains a positive sign

3.7.5. Exceptions

None

3.7.6. Introduced (version)

1.0-preview

3.8. String Handling

Columns that capture string values conforming to specified
requirements foster data integrity, interoperability, and consistency,
improve data analysis and reporting, and support reliable data-driven
decision-making.

All columns capturing a string value, defined in the FOCUS
specification, MUST follow the requirements listed below. Custom string
value capturing columns SHOULD adopt the same requirements over
time.

3.8.1. Attribute ID

StringHandling

3.8.2. Attribute Name

String Handling

3.8.3. Description

Requirements for string-capturing columns appearing in billing
data.

3.8.4. Requirements

      • String values MUST maintain the original casing, spacing, and other
        relevant consistency factors as specified by providers and
        end-users.
      • Charges to mutable entities
        (e.g., resource names) MUST be accurately reflected in corresponding
        charges incurred after the change and MUST NOT alter
        charges incurred before the change, preserving data integrity
        and auditability for all charge records.
      • Immutable string values that refer to the same entity (e.g.,
        resource identifiers, region identifiers, etc.) MUST remain consistent
        and unchanged across all billing
        periods
        .
      • Empty strings and strings consisting solely of spaces SHOULD NOT be
        used in not-nullable string columns.

3.8.5. Exceptions

      • When a record is provided after a change to a mutable string value
        and the ChargeClass is “Correction”, the
        record MAY contain the altered value.

3.8.6. Introduced (version)

1.0

3.9. Unit Format

Billing data frequently captures data measured in units related to
data size, count, time, and other dimensions. The Unit Format
attribute provides a standard for expressing units of measure in columns
appearing in billing data.

All columns defined in FOCUS specifying Unit Format as a value format
MUST follow the requirements listed below.

3.9.1. Attribute ID

UnitFormat

3.9.2. Attribute Name

Unit Format

3.9.3. Description

Indicates standards for expressing measurement units in columns
appearing in billing data.

3.9.4. Requirements

      • Units SHOULD be expressed as a single unit of measure adhering to
        one of the following three formats.

        • <plural-units> – “GB”, “Seconds”
        • <singular-unit>-<plural-time-units>
          “GB-Hours”, “MB-Days”
        • <plural-units>/<singular-time-unit>
          “GB/Hour”, “PB/Day”
      • Units MAY be expressed with a unit quantity or time interval. If a
        unit quantity or time interval is used, the unit quantity or time
        interval MUST be expressed as a whole number. The following formats are
        valid:

        • <quantity> <plural-units> – “1000 Tokens”,
          “1000 Characters”
        • <plural-units>/<interval> <plural-time-units>
          – “Units/3 Months”
      • Unit values and components of columns using the Unit Format MUST use
        a capitalization scheme that is consistent with the capitalization
        scheme used in this attribute if that term is listed in this section.
        For example, a value of “gigabyte-seconds” would not be compliant with
        this specification as the terms “gigabyte” and “second” are listed in
        this section with the appropriate capitalization. If the unit is not
        listed in the table, it is to be used over a functional equivalent with
        a similar meaning with the same capitalization scheme.
      • Units SHOULD be composed of the list of recommended units listed in
        this section unless the unit value covers a dimension not
        listed in the recommended unit set, or if the unit covers a count-based
        unit distinct from recommended values in the count dimension
        listed in this section.

3.9.4.1. Data Size Unit Names

Data size unit names MUST be abbreviated using one of the
abbreviations in the following table. For example, a unit name of “TB”
is a valid unit name, and a unit name of “terabyte” is an invalid unit
name. Data size abbreviations can be considered both the singular and
plural form of the unit. For example, “GB” is both the singular and
plural form of the unit “gigabyte”, and “GBs” would be an invalid unit
name. Values that exceed 10^18 MUST use the abbreviation for exabit,
exabyte, exbibit, and exbibyte, and values smaller than a byte MUST use
the abbreviation for bit or byte. For example, the abbreviation “YB” for
“yottabyte” is not a valid data size unit name as it represents a value
larger than what is listed in the following table.

The following table lists the valid abbreviations for data size units
from a single bit or byte to 10^18 bits or bytes.

Data size in bits Data size in bytes
b (bit) = 10^1 B (byte = 10^1)
Kb (kilobit = 10^3) KB (kilobyte = 10^3)
Mb (megabit = 10^6) MB (megabyte = 10^6)
Gb (gigabit = 10^9) GB (gigabyte = 10^9)
Tb (terabit = 10^12) TB (terabyte = 10^12)
Pb (petabit = 10^15) PB (petabyte = 10^15)
Eb (exabit = 10^18) EB (exabyte = 10^18)
Kib (kibibit = 2^10) KiB (kibibyte = 2^10)
Mib (mebibit = 2^20) MiB (mebibyte = 2^20)
Gib (gibibit = 2^30) GiB (gibibyte = 2^30)
Tib (tebibit = 2^40) TiB (tebibyte = 2^40)
Pib (pebibit = 2^50) PiB (pebibyte = 2^50)
Eib (exbibit = 2^60) EiB (exbibyte = 2^60)

3.9.4.2. Count-based Unit
Names

A count-based unit is a noun that represents a discrete number of
items, events, or actions. For example, a count-based unit can be used
to represent the number of requests, instances, tokens, or
connections.

If the following list of recommended values does not cover a
count-based unit, a provider MAY introduce a new noun representing a
count-based unit. All nouns appearing in units that are not listed in
the recommended values table will be considered count-based units. A new
count-based unit value MUST be capitalized.

Count
Count
Unit
Request
Token
Connection
Certificate
Domain
Core

3.9.4.3. Time-based Unit Names

A time-based unit is a noun that represents a time interval.
Time-based units can be used to measure consumption over a time interval
or in combination with another unit to capture a rate of consumption.
Time-based units MUST match one of the values listed in the following
table.

Time
Year
Month
Day
Hour
Minute
Second

3.9.4.4. Composite Units

If the unit value is a composite value made from combinations of one
or more units, each component MUST also align with the set of
recommended values.

Instead of “per” or “-” to denote a Composite Unit, slash (“/”) and
space(” “) MUST be used as a common convention.  Count-based units like
requests, instances, and tokens SHOULD be expressed using a value listed
in the count dimension.  For example, if a usage unit is
measured as a rate of requests or instances over a period of time, the
unit SHOULD be listed as “Requests/Day” to signify the number of
requests per day.

3.9.5. Exceptions

None

3.9.6. Introduced (version)

1.0-preview

4. Metadata

The FOCUS specification defines a metadata structure that is to be
supplied by data providers to facilitate practitioners use of FOCUS
data. This meta data includes general information about the data
generator and the schema of the FOCUS dataset. FOCUS Metadata SHOULD be
provided in a format that is accessible programmatically, such as: a
file, website, api, table.

4.1. Data Generator

The FOCUS metadata about the generator of the FOCUS data.

4.1.1. Data Generator

Human readable name of the entity that is generating the data.

The DataGenerator MUST be provided in the metadata. DataGenerator
MUST be of type String and MUST NOT contain null values. The
DataGenerator SHOULD be easily associated with the provider who
generated the FOCUS dataset.

4.1.1.1. Metadata ID

DataGenerator

4.1.1.2. Metadata Name

Data Generator

4.1.1.3. Introduced (version)

1.0

4.2. Schema

Each FOCUS dataset must have a metadata about the schema associated
with it. The schema metadata provides information about the structure of
the data provided.

4.2.1. Schema ID

The Schema ID provides the reference item to associate which Schema
was used for the generation of a FOCUS Dataset.

The SchemaId MUST be present in the metadata. The SchemaId MUST be of
String. It is RECOMMENDED for SchemaId to be a Universally Unique
Identifier (UUID) or SemVer
version.

4.2.1.1. Metadata ID

SchemaId

4.2.1.2. Metadata Name

Schema ID

4.2.1.3. Introduced (version)

1.0

4.2.2. Creation Date

Date the schema was created.

The CreationDate MUST be present in the metadata. This MUST be of
type Date/Time and MUST NOT contain null values. CreationDate MUST
conform to Date/Time Format.

4.2.2.1. Metadata ID

CreationDate

4.2.2.2. Metadata Name

Creation Date

4.2.2.3. Introduced (version)

1.0

4.2.3. FOCUS Version

The version of FOCUS utilized for building the dataset.

The FocusVersion MUST be provided in the metadata. FocusVersion MUST
be of type String and MUST NOT contain null values. FOCUSVersion MUST
match one of the published versions of the FOCUS specification.
FocusVersion MUST match the version of the FOCUS specification that the
FOCUS dataset conforms to.

4.2.3.1. Metadata ID

FocusVersion

4.2.3.2. Metadata Name

FOCUS Version

4.2.3.3. Introduced (version)

1.0

4.2.4. Column Definition

The FOCUS metadata schema column definition provides a list of the
columns present in the FOCUS dataset along with metadata about the
columns.

4.2.4.1. Column Name

The name of the column provided in the FOCUS dataset.

The ColumnName MUST be provided in the FOCUS Metadata schema.
ColumnName MUST be of type String and MUST NOT contain null values.

4.2.4.1.1. Metadata ID

ColumnName

4.2.4.1.2. Metadata Name

Column Name

4.2.4.1.3. Introduced (version)

1.0

4.2.4.2. Data Type

The data type of the column provided in the FOCUS dataset.

The DataType MUST be provided in the FOCUS Metadata schema. DataType
MUST be of type String and MUST NOT contain null values.

4.2.4.2.1. Metadata ID

DataType

4.2.4.2.2. Metadata Name

Data Type

4.2.4.2.3. Introduced (version)

1.0

4.2.4.3. Numeric Precision

Numeric Precision is the maximum number of digits for the values in
the column.

NumericPrecision SHOULD be provided in the FOCUS Metadata schema for
Numeric Format columns. NumericPrecision MUST be of type Integer and
MUST NOT contain null values.

4.2.4.3.1. Metadata ID

NumericPrecision

4.2.4.3.2. Metadata Name

Numeric Precision

4.2.4.3.3. Introduced (version)

1.0

4.2.4.4. Number Scale

The number scale of the data provides the maximum number of digits
after the decimal point in decimal numbers.

NumberScale SHOULD be provided in the FOCUS Metadata schema for
Decimal columns. NumberScale MUST be of type Integer and MUST NOT
contain null values.

4.2.4.4.1. Metadata ID

NumberScale

4.2.4.4.2. Metadata Name

Number Scale

4.2.4.4.3. Introduced (version)

1.0

4.2.4.5. Provider Tag Prefixes

The Provider Tag Prefixes defines the list of prefixes used in the
tag name of provider-defined tags. This metadata is
useful for the consumer to identify which tags are provider-defined vs
user-defined.

The ProviderTagPrefixes MUST be provided when ColumnName is equal to
Tags. The ProviderTagPrefix MUST be of type Array of Strings. The
ProviderTagPrefixes SHOULD be easily associated with the provider who
generated the FOCUS dataset.

4.2.4.5.1. Metadata ID

ProviderTagPrefixes

4.2.4.5.2. Metadata Name

Provider Tag Prefixes

4.2.4.5.3. Introduced (version)

1.0

4.2.4.6. String Encoding

The string encoding scheme of the column provided in the FOCUS
dataset.

StringEncoding SHOULD be provided in the FOCUS Metadata schema when
it is required to know this information in order to successfully read
the data. StringEncoding MUST be of type String and MUST NOT contain
null values.

4.2.4.6.1. Metadata ID

StringEncoding

4.2.4.6.2. Metadata Name

StringEncoding

4.2.4.6.3. Introduced (version)

1.0

4.2.4.7. String Max Length

The string max length of the data that can be stored in the
column.

StringMaxLength SHOULD be provided in the FOCUS Metadata schema for
String columns. StringMaxLength MUST be of type Integer and MUST NOT
contain null values.

4.2.4.7.1. Metadata ID

StringMaxLength

4.2.4.7.2. Metadata Name

String Max Length

4.2.4.7.3. Introduced (version)

1.0

5. Use Case Library

The following table contains a set of commonly performed FinOps
scenarios that were used as a basis for developing this specification.
These use cases were developed by FinOps practitioners.

Persona Capability Use Case FOCUS Columns
Business / Product Owner Budget Management As a Business/Product Owner, I need to
compare actual usage costs incurred within a time period to the amount
forecasted.
BilledCost
BillingAccountId
BillingAccountName
ChargePeriodStart
ChargePeriodEnd
ChargeCategory
Provider
Engineering & Operations Budget Management As an Engineering Manager who wants to
reduce their billed cost for Compute for a specific provider, I want to
understand what is my current rate of Commitment based discount (without
negotiated discounts) per type of commitment, so that I can strategize
further purchases
BillingPeriodStart
CommitmentDiscountType
EffectiveCost
ProviderName
ServiceName
SubAccountId
SubAccountName
Engineering & Operations Data Analysis and Showback As an Engineer, I want to understand the
costs of the components that belong to an application
ChargeDescription
ChargePeriodStart
EffectiveCost
ResourceId
ResourceName
ResourceType
ServiceCategory
ServiceName
SkuId
Tags
Engineering & Operations Data Analysis and Showback As an Engineer, I want to understand the
costs of the components for a specific resource
ChargePeriodStart
EffectiveCost
ResourceId
ResourceName
SkuId
Engineering & Operations Data Analysis and Showback As an Engineer, I want to understand the
costs of all components and resources within a subaccount
ChargePeriodStart
EffectiveCost
ResourceId
ResourceName
SkuId
SubAccountId
Engineering & Operations Data Analysis and Showback As an Engineering & Operations person
I would like to analyze the usage of serverless requests on a weekly
basis to identity potential optimization candidates
BilledCost
ProviderName
ChargePeriodStart

ChargePeriodEnd

SkuId
ConsumedQuantity
Tags
ConsumedUnit

Engineering & Operations Data Analysis and Showback As an Engineer, I need to extract a ranked
list of the top 10 service cost drivers within a sub account from a time
period
ChargePeriodStart
EffectiveCost
SubAccountId
SubAccountName
ServiceName
Engineering & Operations Workload Management & Automation As an Engineer I need to ensure my costs
within a region are distributed across the different availability zones
in an expected manner.
ProviderName
AvailabilityZone
RegionId
RegionName
BillingPeriodStart
EffectiveCost
Engineering & Operations Workload Management & Automation As an Engineering manager, I need to see
the cost of each compute resource in a production SubAccount I’m
responsible for.
ResourceId
ResourceName
ChargePeriodStart
ChargePeriodEnd
ServiceName
ServiceCategory
PricingQuantity
EffectiveCost
Finance Budget Management As a person in Finance, I need to update
cloud budget with actual cost details within a billing period
BilledCost
BillingPeriodStart
BillingPeriodEnd
ProviderName
Finance Budget Management As a person in Finance, I need to update
budget, by application, with actual cost details within a billed time
period
BilledCost
BillingPeriodStart
BillingPeriodEnd
ProviderName
Tags
Finance Budget Management As a person in Finance, I need to track
tax costs month over month.
BillingPeriodStart
BilledCost
ChargeCategory
ProviderName
Finance Budget Management As a Financial Analyst or member of the
company’s treasury, I would like to understand what volume of commitment
based charges are going to reoccur in the coming financial year
ChargeFrequency
BillingPeriodStart
BilledCost
Finance Data Analysis and Showback As a Finance person of a company that
sells SaaS services, I need to determine the resource quantity and type
used by a customer so that a monthly invoice can be issued to the
customer.
ProviderName
BillingPeriodStart

SkuId
PricingQuantity
ConsumedQuantity
ConsumedUnit
Tags

Finance Data Analysis and Showback As a person in Finance, I need a report of
all cost associated with a product from all geographic locations for a
given month.
BilledCost
BillingCurrency
BillingAccountId
BillingAccountName
BillingPeriodEnd
ProviderName
Tags
Finance FinOps & Intersecting Frameworks As a person in Finance, I need a report of
service-level cost within a specific Sub Account as a part of a private
pricing negotiation.
BillingPeriodStart
EffectiveCost
ProviderName
ServiceName
SubAccountId
SubAccountName
Finance Forecasting As a person in Finance, I need to forecast
amortized costs on a month over month basis, based on historical
trends
BillingPeriodStart
ChargeCategory
EffectiveCost
PricingUnit
ProviderName
ServiceName
ServiceCategory
Finance Forecasting As a person in Finance, I need to forecast
cashflow on a month over month basis, based on historical trends
BillingPeriodStart
ChargeCategory
ChargeDescription
BilledCost
BillingCurrency
ProviderName
ServiceName
ServiceCategory
FinOps Practitioner Data Analysis and Showback As a FinOps practitioner, I need to
analyze service costs month over month, over a time period
EffectiveCost
BillingPeriodStart
ProviderName
ServiceName
FinOps Practitioner Data Analysis and Showback As a FinOps practitioner, I need to
analyze service costs, by region, over a time period
EffectiveCost
BillingPeriodStart
ProviderName
RegionId
RegionName
ServiceName
FinOps Practitioner Data Analysis and Showback As a FinOps practitioner, I need to
analyze Compute Engine service costs month over month for a period of
time to identify accounts spending the most money on Compute Engine
BilledCost
BillingPeriodStart
ProviderName
ResourceId
ResourceName
ServiceName
SubAccountId
SubAccountName
FinOps Practitioner Data Analysis and Showback As a FinOps practitioner, I want to
monitor how much we are spending on a specific SaaS product purchased
via the cloud service provider’s marketplace.
ChargePeriodStart
ChargePeriodEnd
EffectiveCost
InvoiceIssuer
ProviderName
Publisher
FinOps Practitioner Data Analysis and Showback As a FinOps Practitioner, I need to
understand what we are spending across providers, billing periods, and
service categories
ProviderName
BillingPeriodStart
BilledCost
BillingCurrency
ServiceCategory
FinOps Practitioner FinOps & Intersecting Frameworks As a FinOps Practitioner, I need to verify
the accuracy of the cloud service provider invoices
ProviderName
BillingAccountId
BillingAccountName
BillingPeriodStart
BilledCost
BillingCurrency
FinOps Practitioner FinOps & Intersecting Frameworks As a FinOps Practitioner, I need to verify
the accuracy of the cloud service provider invoices and the underlying
services
ProviderName
BillingAccountId
BillingAccountName
BillingPeriodStart
BilledCost
BillingCurrency
ServiceName
FinOps Practitioner FinOps & Intersecting Frameworks As a FinOps Practitioner, I need to
reconcile discounts on the cloud service provider invoices and the
underlying services
ProviderName
BillingAccountId
BillingAccountName
BillingPeriodStart
BilledCost
BillingCurrency
EffectiveCost
ListCost
ServiceName
FinOps Practitioner FinOps & Intersecting Frameworks As a FinOps Practitioner, I need to
analyze usage data of resources
ChargePeriodStart
ChargeCategory
EffectiveCost
ProviderName
PricingQuantity
ConsumedQuantity
ResourceId
ServiceName
SkuId
ConsumedUnit
FinOps Practitioner Forecasting As a FinOps Practitioner, I need to
forecast costs, based on historical usage trends and rates
BillingPeriodStart
ChargeCategory
ChargeDescription
EffectiveCost
ProviderName
PricingQuantity
ConsumedQuantity
RegionId
ServiceCategory
ServiceName
SkuId
ConsumedUnit
FinOps Practitioner Managing Anomalies As a FinOps Practitioner, I need to see
the daily costs across all cloud providers, billing accounts, and sub
accounts
BillingAccountId
SubAccountId
ChargePeriodStart
ChargePeriodEnd
ProviderName
EffectiveCost
FinOps Practitioner Managing Anomalies As a FinOps Practitioner, I need to see
the daily costs across all cloud providers, billing accounts, sub
accounts, and region
BillingAccountId
SubAccountId
ChargePeriodStart
ChargePeriodEnd
EffectiveCost
ProviderName
RegionId
RegionName
FinOps Practitioner Managing Anomalies As a FinOps practitioner, I need to see
the daily costs across all cloud providers, billing accounts, sub
accounts, and service
BillingAccountId
SubAccountId
ChargePeriodStart
ChargePeriodEnd
EffectiveCost
ProviderName
ServiceName
FinOps Practitioner Managing Commitment Based Discounts As a FinOps Practitioner, I want to track
all commitment based discounts purchased for a time period
ProviderName
BillingAccountId
CommitmentDiscountId
CommitmentDiscountType
BilledCost
ChargePeriodStart
ChargeCategory
FinOps Practitioner Managing Commitment Based Discounts As a FinOps Practitioner, I want to track
unused commitment charges in any given time period so that I consider
them in my future commitment planning or remedy them
CommitmentDiscountStatus
(filter)
CommitmentDiscountId
BilledCost
ChargePeriodStart
FinOps Practitioner Resource Utilization & Efficiency As a FinOps Practitioner, I need to
analyze the fleet diversity in order to run a campaign to standardize
application architecture.
ChargeCategory
ChargeDescription
ChargePeriodStart
ProviderName
ResourceType
SubAccountId
ServiceName
FinOps Practitioner Resource Utilization & Efficiency As a FinOps Practitioner, I need to
analyze the fleet diversity in order to run a campaign to standardize
application architecture within a specific service
ChargeCategory
ChargeDescription
ChargePeriodStart
ProviderName
ResourceType
SubAccountId
ServiceName
FinOps Practitioner Resource Utilization & Efficiency As a FinOps Practitioner, I need to
identify total refunds within a billing period.
ProviderName
BillingAccountId
ServiceCategory
BilledCost
BillingPeriodStart
ChargeCategory
ChargeClass
FinOps Practitioner Resource Utilization & Efficiency As a FinOps Practitioner, I need to
identify refunds across sub accounts within a billing period.
ProviderName
BillingAccountId
ServiceCategory
BilledCost
BillingPeriodStart
ChargeCategory
ChargeClass
SubAccountId
FinOps Practitioner Workload Management & Automation As a FinOps Practitioner, I need to do an
analysis on compliance to data residency requirements across all
regions
ChargePeriodStart
ProviderName
RegionId
RegionName
SubAccountId
Procurement Data Analysis and Showback As a person in Procurement, I need to
understand what we are spending, across billing periods, across service
categories to focus negotiations toward highest costing items
ProviderName
BillingAccountId
BillingAccountName
BillingCurrency
BilledCost
BillingPeriodStart
ServiceCategory
ServiceName
Procurement, Finance, FinOps
Practitioner
FinOps & Intersecting Frameworks Multiple personas in an organization need
to know the top SKU Codes based on spend, so that they can achieve
multiple goals such as contract negotiation, SKU based forecasting, or
high unit cost cleanup activities.
ChargePeriodStart
ChargePeriodEnd
ListCost
PricingUnit
ListUnitPrice
PricingQuantity
SkuId
SkuPriceId
ProviderName

6. Glossary

Adjustment

A charge representing a modification to billing data to account for
certain events or circumstances not previously captured, or captured
incorrectly. Examples include billing errors, service disruptions, or
pricing changes.

Amortization

The distribution of upfront costs over time to accurately reflect the
consumption or benefit derived from the associated resources or
services. Amortization is valuable when the commitment period (time
duration of the cost) extends beyond the granularity of the source
report.

Availability Zone

A collection of geographically separated locations containing a data
center or cluster of data centers. Each availability zone (AZ) should
have its own power, cooling, and networking, to provide redundancy and
fault tolerance.

Billed Cost

A charge that serves as the basis for invoicing. It includes the
total amount of fees and discounts, signifying a monetary obligation.
Valuable when reconciling cash outlay with incurred expenses is
required, such as cost allocation, budgeting, and invoice
reconciliation.

Billing Account

A container for resources and/or services that are billed together in
an invoice. A billing account may have sub accounts, all of whose costs
are consolidated and invoiced to the billing account.

Billing Currency

An identifier that represents the currency that a charge for
resources and/or services was billed in.

Billing Period

The time window that an organization receives an invoice for,
inclusive of the start date and exclusive of the end date. It is
independent of the time of usage and consumption of resources and
services.

Block Pricing

A pricing approach where the cost of a particular resource or service
is determined based on predefined quantities or tiers of usage. In these
scenarios, the Pricing Unit and the corresponding Pricing Quantity can
be different from the Consumed Unit and Consumed Quantity.

Charge

A row in a FOCUS-compatible cost and usage dataset.

Charge Period

The time window for which a charge is effective, inclusive of the
start date and exclusive of the end date. The charge period for
continuous usage should match the time granularity of the dataset (e.g.,
1 hour for hourly, 1 day for daily). The charge period for a non-usage
charge with time boundaries should match the duration of
eligibility.

Commitment

A customer’s agreement to consume a specific quantity of a service or
resource over a defined period, usually also creating a financial
commitment throughout the entirety of the commitment period. Some
commitments also hold Providers to certain assurance levels of resource
availability.

Commitment-Based
Discount

Also known as Commitment Discount, this is a commitment for an amount
of usage or spend throughout a specified term, in exchange for
discounted unit pricing on that amount. The commitment may be based on
quantities of resource units or monetary value, with various payment
options and time frames.

Cloud Service Provider
(CSP)

A company or organization that provides remote access to computing
resources, infrastructure, or applications for a fee.

Dimension

A specification-defined categorical attribute that provides context
or categorization to billing data.

Effective Cost

The amortized cost of the charge after applying all reduced rates,
discounts, and the applicable portion of relevant, prepaid purchases
(one-time or recurring) that covered this charge.

Exclusive Bound

A Date/Time Format value that is not contained within the ending
bound of a time period.

Finalized Tag

A tag with one tag value chosen from a set of possible tag values
after being processed by a set of provider-defined or user-defined
rules.

FinOps Cost
and Usage Specification (FOCUS)

An open-source specification that defines requirements for billing
data.

Inclusive Bound

A Date/Time Format value that is contained within the beginning bound
of a time period.

Interruptible

A category of compute resources that can be paused or terminated by
the CSP within certain criteria, often advertised at reduced unit
pricing when compared to the equivalent non-interruptible resource.

List Unit Price

The suggested provider-published unit price for a single Pricing Unit of the associated SKU, exclusive of any discounts. This price is
denominated in the Billing
Currency
.

Contracted Unit
Price

The agreed-upon unit price for a single Pricing Unit of the associated SKU, inclusive of
negotiated discounts, if present, and exclusive of any other discounts.
This price is denominated in the Billing Currency.

Metric

A FOCUS-defined column that provides numeric values, allowing for
aggregation operations such as arithmetic operations (sum,
multiplication, averaging etc.) and statistical operations.

Managed Service
Provider (MSP)

A company or organization that provides outsourced management and
support of a range of IT services, such as network infrastructure,
cybersecurity, cloud computing, and more.

On-Demand

A term that describes a service that is available and provided
immediately or as needed, without requiring a pre-scheduled appointment
or prior arrangement. In cloud computing, virtual machines can be
created and terminated as needed, i.e. on demand.

Practitioner

An individual who performs FinOps within an organization to maximize
the business value of using cloud and cloud-like services.

Potato

A long and often painful conversation had by the FOCUS contributors.
Sometimes the name of a thing that we could not yet name. No starchy
root vegetables were harmed during the production of this specification.
We thank potato for its contribution in the creation of this
specification.

Provider

An entity that made internal or 3rd party resources and/or services
available for purchase.

Price List

A comprehensive list of prices offered by a provider.

Resource

A unique component that incurs a charge.

Row

A row in a FOCUS-compatible cost and usage dataset.

Service

An offering that can be purchased from a provider, and can include
many types of usage or other charges; eg., a cloud database service may
include compute, storage, and networking charges.

SKU

A construct composed of the common properties of a product offering
associated with one or many SKU Prices.

SKU Price

The unit price used to calculate a charge that is associated with one
SKU. SKU Prices are usually referenced from the provider’s price list
and are unique to various providers.

Sub Account

A sub account is an optional provider-supported construct for
organizing resources and/or services connected to a billing account. Sub
accounts must be associated with a billing account as they do not
receive invoices.

Tag

A metadata label assigned to a resource to provide information about
it or to categorize it for organizational and management purposes.

Tag Source

A Resource or Provider-defined construct for grouping resources
and/or other Provider-defined construct that a Tag can be assigned
to.

7. Appendix

This section is non-normative.

7.1. Grouping
constructs for resources or services

Providers natively support various constructs for grouping resources
or services. These grouping constructs are often used to mimic
organizational structures, technical architectures, cost
attribution/allocation and access management boundaries, or other
customer-specific structures based on requirements.

Providers may support multiple levels of resource or service grouping
mechanisms. FOCUS supports two distinct levels of groupings that are
commonly needed for FinOps capabilities like chargeback, invoice
reconciliation and cost allocation.

      • Billing account: A mandatory container for resources or services
        that are billed together in an invoice. Billing accounts are commonly
        used for scenarios like grouping based on organizational constructs,
        invoice reconciliation and cost allocation strategies.
      • Sub account: An optional provider-supported construct for organizing
        resources and services connected to a billing account. Sub accounts are
        commonly used for scenarios like grouping based on organizational
        constructs, access management needs and cost allocation strategies. Sub
        accounts must be associated with a billing account as they do not
        receive invoices.

The table below highlights key properties of the two grouping
constructs supported by FOCUS.

Property Billing account Sub account
Requirement level Mandatory Optional
Receives an invoice? Yes No
Invoiced at Self Associated billing account
Examples AWS: Management
Account*
GCP: Billing Account
Azure MCA: Billing
Profile
Snowflake: Organizational Account
AWS: Member Account
GCP:
Project
Azure MCA: Subscription
Snowflake: Account

* For organizations that have multiple AWS Member Accounts
within an AWS Organization, consolidated billing is enabled by default
and invoices are received at Management Account level. A Member Account
can be removed from AWS consolidated billing whereby the removed account
receives independent invoices and is responsible for payments.

7.2. Origination of Cost Data

Cost data presented in the billing datasets originates from various
sources depending on the purchasing mechanism. There are at least 3
different pieces of information that are important for understanding
where cost originated from.

      • Provider: The entity that made the resources or services available
        for purchase.
      • Publisher: The entity that produced the resources or services that
        were purchased.
      • Invoice Issuer: The entity responsible for invoicing for the
        resources or services consumed.

The value for each of these may be different depending on the various
purchasing scenarios for resources or services. Use cases for purchasing
direct, via a Managed Service Provider (MSP), via a cloud marketplace,
and from internal service offerings were considered. The table below
presents a few scenarios to show how the value for each dimension may
change based on the purchasing scenario.

# Scenario Provider Publisher Invoice Issuer
1.1 Purchasing cloud services directly from
cloud provider
Cloud service provider Cloud service provider Cloud service provider
1.2 Purchasing cloud services from the cloud
provider where the cloud region is operated by a 3rd party
Cloud service provider Cloud service provider Entity operating the region for the cloud
service provider
2.1 Purchasing cloud services via MSP Managed Service Provider Cloud service provider Managed Service Provider
2.2 Purchasing cloud-agnostic resources or
services built/sold by an MSP
Managed Service Provider Managed Service Provider Managed Service Provider
2.3 Purchasing labor services from managed
service provider
Managed Service Provider Managed Service Provider Managed Service Provider
3.1 Purchasing a cloud marketplace offering
that runs on the cloud provider
Cloud service provider Company building the software or services
(Cloud service provider OR third-party software or services
company)
Cloud service provider
3.2 Purchasing a cloud marketplace offering
that is not running directly on your cloud infrastructure (e.g,. SaaS
product, Professional Services)
Cloud service provider Company producing the SaaS or services
product
Cloud service provider
3.3 Purchasing a SaaS product that is not
directly running on your cloud infrastructure from a 3rd party reseller
managed cloud marketplace
Cloud service provider SaaS provider Reseller
4.1 Purchasing SaaS software directly from
provider
SaaS provider SaaS provider SaaS provider
4.2 Purchasing SaaS software that additionally
runs on your cloud resources (in addition to #4.1)
Cloud service provider Cloud service provider Cloud service provider
5.1 Purchasing internal infrastructure or
services offerings running on-premise
Internal product name Internal product name Internal product name
5.2 Purchasing internal infrastructure or
services offerings running on cloud
Internal product name Internal product name Internal product name
5.3 Associated software license cost for use
on an on-premise infrastructure platform (Where license cost is
presented separately in cost data)
Internal product name Company producing the software Internal product name

Get Trained and Certified on FOCUS

Learn how FOCUS can accelerate FinOps at your organization.

Introduction to FOCUS

Explore the goals of FOCUS, view sample use cases, and learn about gathering FOCUS conformed datasets.

Take the Free course

FinOps Certified FOCUS Analyst

An in-depth understanding of the FOCUS Specification, learn how to use FOCUS datasets to answer real-world business questions.

Learn more