FinOps Open Cost and Usage

Specification
Version
Publication version 1.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.

1 of 86
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: License CC BY 4.0

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

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.

2 of 86
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.

3 of 86
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)
4 of 86
 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)

5 of 86
Table of Contents

1. Introduction
1.1. Background and History
1.2. Intended Audience
1.3. Scope
1.4. Design Principles
1.5. Design Notes
1.6. Typographic Conventions
1.7. FOCUS Feature level
1.8. Conformance Checkers and Validators

2. Columns
2.1. Availability Zone
2.2. Billed Cost
2.3. Billing Account ID
2.4. Billing Account Name
2.5. Billing Currency
2.6. Billing Period End
2.7. Billing Period Start
2.8. Charge Category
2.9. Charge Class
2.10. Charge Description
2.11. Charge Frequency
2.12. Charge Period End
2.13. Charge Period Start
2.14. Commitment Discount Category
2.15. Commitment Discount ID
2.16. Commitment Discount Name
2.17. Commitment Discount Status
2.18. Commitment Discount Type
2.19. Consumed Quantity
2.20. Consumed Unit
2.21. Contracted Cost
2.22. Contracted Unit Price
2.23. Effective Cost
2.24. Invoice Issuer
2.25. List Cost
2.26. List Unit Price
2.27. Pricing Category
2.28. Pricing Quantity
2.29. Pricing Unit
2.30. Provider
2.31. Publisher
2.32. Region ID
2.33. Region Name
2.34. Resource ID
2.35. Resource Name
2.36. Resource Type
2.37. Service Category
2.38. Service Name
2.39. SKU ID
2.40. SKU Price ID
2.41. Sub Account ID
2.42. Sub Account Name
6 of 86
 2.43. Tags

3. Attributes
3.1. Column Naming and Ordering
3.2. Currency Code Format
3.3. Date/Time Format
3.4. Discount Handling
3.5. Key-Value Format
3.6. Null Handling
3.7. Numeric Format
3.8. String Handling
3.9. Unit Format

4. Metadata
4.1. Data Generator
4.2. Schema

5. Use Case Library

6. Glossary
7. Appendix
7.1. Grouping constructs for resources or services
7.2. Origination of Cost Data

7 of 86
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):
Cloud Service Providers (CSPs)
Software as a Service (SaaS) platforms
Managed Service Providers (MSPs)
Internal infrastructure and service platforms
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

8 of 86
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.
9 of 86
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.

10 of 86
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

11 of 86
 Constraint Value

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

12 of 86
 Constraint Value

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>

13 of 86
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

14 of 86
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
15 of 86
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.

16 of 86
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

17 of 86
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.

18 of 86
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.

19 of 86
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

20 of 86
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- Charges that repeat every time the service is used. Usage-based charges are typically
Based 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.

21 of 86
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

22 of 86
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

23 of 86
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
24 of 86
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.

25 of 86
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

26 of 86
 Constraint Value

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
27 of 86
 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

28 of 86
 Constraint Value

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

29 of 86
 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

30 of 86
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

31 of 86
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

32 of 86
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

33 of 86
 Constraint Value

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>

34 of 86
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.

35 of 86
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.

36 of 86
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

37 of 86
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

38 of 86
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 Any valid decimal

Range 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:

39 of 86
 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.

40 of 86
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

41 of 86
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

42 of 86
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

43 of 86
 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

44 of 86
 Constraint Value

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>

45 of 86
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

46 of 86
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 Artificial Intelligence and Machine Learning related technologies.

Learning

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.

47 of 86
 Service Category Description

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 Management, logging, and observability of a customer's use of cloud.

Governance

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

48 of 86
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
49 of 86
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

50 of 86
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

51 of 86
 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

52 of 86
 Constraint Value

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.

53 of 86
 {
"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.

54 of 86
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

55 of 86
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

56 of 86
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.

57 of 86
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

58 of 86
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.

59 of 86
 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

60 of 86
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

61 of 86
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.

62 of 86
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 Description
Type

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:

Range /
Data
Precision Definition Significant
Type
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 -(2^63 - 1) to

higher (2^63 - 1)

Decimal Single 32-bit binary format IEEE 754-2008 9

floating-point (decimal32)

Decimal Double 64-bit binary format IEEE 754-2008 16

floating-point (decimal64)

Decimal Extended 128-bit binary format IEEE 754-2008 36+

floating-point (decimal128) or higher

3.7.4.1. Examples

This format requires that single numeric values be represented using an integer or decimal format without
63 of 86
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

64 of 86
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 theChargeClass 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

65 of 86
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)

66 of 86
 Data size in bits Data size in bytes

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

67 of 86
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

68 of 86
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.
69 of 86
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
70 of 86
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
71 of 86
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

72 of 86
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

73 of 86
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

74 of 86
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 / Budget As a Business/Product Owner, I need BilledCost

Product Management to compare actual usage costs BillingAccountId
Owner incurred within a time period to the BillingAccountName
amount forecasted. ChargePeriodStart
ChargePeriodEnd
ChargeCategory
Provider

Engineering Budget As an Engineering Manager who BillingPeriodStart

& Operations Management wants to reduce their billed cost for CommitmentDiscountType
Compute for a specific provider, I EffectiveCost
want to understand what is my ProviderName
current rate of Commitment based ServiceName
discount (without negotiated SubAccountId
discounts) per type of commitment, SubAccountName
so that I can strategize further
purchases

Engineering Data As an Engineer, I want to understand ChargeDescription

& Operations Analysis and the costs of the components that ChargePeriodStart
Showback belong to an application EffectiveCost
ResourceId
ResourceName
ResourceType
ServiceCategory
ServiceName
SkuId
Tags

Engineering Data As an Engineer, I want to understand ChargePeriodStart

& Operations Analysis and the costs of the components for a EffectiveCost
Showback specific resource ResourceId
ResourceName
SkuId

Engineering Data As an Engineer, I want to understand ChargePeriodStart

& Operations Analysis and the costs of all components and EffectiveCost
Showback resources within a subaccount ResourceId
ResourceName
SkuId
SubAccountId

75 of 86
Persona Capability Use Case FOCUS Columns

Engineering Data As an Engineering & Operations BilledCost

& Operations Analysis and person I would like to analyze the ProviderName
Showback usage of serverless requests on a ChargePeriodStart
weekly basis to identity potential ChargePeriodEnd
optimization candidates SkuId
ConsumedQuantity
Tags
ConsumedUnit

Engineering Data As an Engineer, I need to extract a ChargePeriodStart

& Operations Analysis and ranked list of the top 10 service cost EffectiveCost
Showback drivers within a sub account from a SubAccountId
time period SubAccountName
ServiceName

Engineering Workload As an Engineer I need to ensure my ProviderName

& Operations Management costs within a region are distributed AvailabilityZone
& across the different availability zones RegionId
Automation in an expected manner. RegionName
BillingPeriodStart
EffectiveCost

Engineering Workload As an Engineering manager, I need ResourceId

& Operations Management to see the cost of each compute ResourceName
& resource in a production SubAccount ChargePeriodStart
Automation I'm responsible for. ChargePeriodEnd
ServiceName
ServiceCategory
PricingQuantity
EffectiveCost

Finance Budget As a person in Finance, I need to BilledCost

Management update cloud budget with actual cost BillingPeriodStart
details within a billing period BillingPeriodEnd
ProviderName

Finance Budget As a person in Finance, I need to BilledCost

Management update budget, by application, with BillingPeriodStart
actual cost details within a billed BillingPeriodEnd
time period ProviderName
Tags

Finance Budget As a person in Finance, I need to BillingPeriodStart

Management track tax costs month over month. BilledCost
ChargeCategory
ProviderName

Finance Budget As a Financial Analyst or member of ChargeFrequency

Management the company's treasury, I would like BillingPeriodStart
to understand what volume of BilledCost
commitment based charges are
going to reoccur in the coming
financial year

76 of 86
Persona Capability Use Case FOCUS Columns

Finance Data As a Finance person of a company ProviderName

Analysis and that sells SaaS services, I need to BillingPeriodStart
Showback determine the resource quantity and SkuId
type used by a customer so that a PricingQuantity
monthly invoice can be issued to the ConsumedQuantity
customer. ConsumedUnit
Tags

Finance Data As a person in Finance, I need a BilledCost

Analysis and report of all cost associated with a BillingCurrency
Showback product from all geographic locations BillingAccountId
for a given month. BillingAccountName
BillingPeriodEnd
ProviderName
Tags

Finance FinOps & As a person in Finance, I need a BillingPeriodStart

Intersecting report of service-level cost within a EffectiveCost
Frameworks specific Sub Account as a part of a ProviderName
private pricing negotiation. ServiceName
SubAccountId
SubAccountName

Finance Forecasting As a person in Finance, I need to BillingPeriodStart

forecast amortized costs on a month ChargeCategory
over month basis, based on historical EffectiveCost
trends PricingUnit
ProviderName
ServiceName
ServiceCategory

Finance Forecasting As a person in Finance, I need to BillingPeriodStart

forecast cashflow on a month over ChargeCategory
month basis, based on historical ChargeDescription
trends BilledCost
BillingCurrency
ProviderName
ServiceName
ServiceCategory

FinOps Data As a FinOps practitioner, I need to EffectiveCost

Practitioner Analysis and analyze service costs month over BillingPeriodStart
Showback month, over a time period ProviderName
ServiceName

FinOps Data As a FinOps practitioner, I need to EffectiveCost

Practitioner Analysis and analyze service costs, by region, BillingPeriodStart
Showback over a time period ProviderName
RegionId
RegionName
ServiceName

77 of 86
Persona Capability Use Case FOCUS Columns

FinOps Data As a FinOps practitioner, I need to BilledCost

Practitioner Analysis and analyze Compute Engine service BillingPeriodStart
Showback costs month over month for a period ProviderName
of time to identify accounts spending ResourceId
the most money on Compute Engine ResourceName
ServiceName
SubAccountId
SubAccountName

FinOps Data As a FinOps practitioner, I want to ChargePeriodStart

Practitioner Analysis and monitor how much we are spending ChargePeriodEnd
Showback on a specific SaaS product purchased EffectiveCost
via the cloud service provider's InvoiceIssuer
marketplace. ProviderName
Publisher

FinOps Data As a FinOps Practitioner, I need to ProviderName

Practitioner Analysis and understand what we are spending BillingPeriodStart
Showback across providers, billing periods, and BilledCost
service categories BillingCurrency
ServiceCategory

FinOps FinOps & As a FinOps Practitioner, I need to ProviderName

Practitioner Intersecting verify the accuracy of the cloud BillingAccountId
Frameworks service provider invoices BillingAccountName
BillingPeriodStart
BilledCost
BillingCurrency

FinOps FinOps & As a FinOps Practitioner, I need to ProviderName

Practitioner Intersecting verify the accuracy of the cloud BillingAccountId
Frameworks service provider invoices and the BillingAccountName
underlying services BillingPeriodStart
BilledCost
BillingCurrency
ServiceName

FinOps FinOps & As a FinOps Practitioner, I need to ProviderName

Practitioner Intersecting reconcile discounts on the cloud BillingAccountId
Frameworks service provider invoices and the BillingAccountName
underlying services BillingPeriodStart
BilledCost
BillingCurrency
EffectiveCost
ListCost
ServiceName

FinOps FinOps & As a FinOps Practitioner, I need to ChargePeriodStart

Practitioner Intersecting analyze usage data of resources ChargeCategory
Frameworks EffectiveCost
ProviderName
PricingQuantity
ConsumedQuantity
ResourceId
ServiceName
SkuId
ConsumedUnit

78 of 86
Persona Capability Use Case FOCUS Columns

FinOps Forecasting As a FinOps Practitioner, I need to BillingPeriodStart

Practitioner forecast costs, based on historical ChargeCategory
usage trends and rates ChargeDescription
EffectiveCost
ProviderName
PricingQuantity
ConsumedQuantity
RegionId
ServiceCategory
ServiceName
SkuId
ConsumedUnit

FinOps Managing As a FinOps Practitioner, I need to BillingAccountId

Practitioner Anomalies see the daily costs across all cloud SubAccountId
providers, billing accounts, and sub ChargePeriodStart
accounts ChargePeriodEnd
ProviderName
EffectiveCost

FinOps Managing As a FinOps Practitioner, I need to BillingAccountId

Practitioner Anomalies see the daily costs across all cloud SubAccountId
providers, billing accounts, sub ChargePeriodStart
accounts, and region ChargePeriodEnd
EffectiveCost
ProviderName
RegionId
RegionName

FinOps Managing As a FinOps practitioner, I need to BillingAccountId

Practitioner Anomalies see the daily costs across all cloud SubAccountId
providers, billing accounts, sub ChargePeriodStart
accounts, and service ChargePeriodEnd
EffectiveCost
ProviderName
ServiceName

FinOps Managing As a FinOps Practitioner, I want to ProviderName

Practitioner Commitment track all commitment based BillingAccountId
Based discounts purchased for a time CommitmentDiscountId
Discounts period CommitmentDiscountType
BilledCost
ChargePeriodStart
ChargeCategory

FinOps Managing As a FinOps Practitioner, I want to CommitmentDiscountStatus

Practitioner Commitment track unused commitment charges in (filter)
Based any given time period so that I CommitmentDiscountId
Discounts consider them in my future BilledCost
commitment planning or remedy ChargePeriodStart
them

79 of 86
Persona Capability Use Case FOCUS Columns

FinOps Resource As a FinOps Practitioner, I need to ChargeCategory

Practitioner Utilization & analyze the fleet diversity in order to ChargeDescription
Efficiency run a campaign to standardize ChargePeriodStart
application architecture. ProviderName
ResourceType
SubAccountId
ServiceName

FinOps Resource As a FinOps Practitioner, I need to ChargeCategory

Practitioner Utilization & analyze the fleet diversity in order to ChargeDescription
Efficiency run a campaign to standardize ChargePeriodStart
application architecture within a ProviderName
specific service ResourceType
SubAccountId
ServiceName

FinOps Resource As a FinOps Practitioner, I need to ProviderName

Practitioner Utilization & identify total refunds within a billing BillingAccountId
Efficiency period. ServiceCategory
BilledCost
BillingPeriodStart
ChargeCategory
ChargeClass

FinOps Resource As a FinOps Practitioner, I need to ProviderName

Practitioner Utilization & identify refunds across sub accounts BillingAccountId
Efficiency within a billing period. ServiceCategory
BilledCost
BillingPeriodStart
ChargeCategory
ChargeClass
SubAccountId

FinOps Workload As a FinOps Practitioner, I need to do ChargePeriodStart

Practitioner Management an analysis on compliance to data ProviderName
& residency requirements across all RegionId
Automation regions RegionName
SubAccountId

Procurement Data As a person in Procurement, I need ProviderName

Analysis and to understand what we are spending, BillingAccountId
Showback across billing periods, across service BillingAccountName
categories to focus negotiations BillingCurrency
toward highest costing items BilledCost
BillingPeriodStart
ServiceCategory
ServiceName

Procurement, FinOps & Multiple personas in an organization ChargePeriodStart

Finance, Intersecting need to know the top SKU Codes ChargePeriodEnd
FinOps Frameworks based on spend, so that they can ListCost
Practitioner achieve multiple goals such as PricingUnit
contract negotiation, SKU based ListUnitPrice
forecasting, or high unit cost cleanup PricingQuantity
activities. SkuId
SkuPriceId
ProviderName

80 of 86
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,

81 of 86
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

82 of 86
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.

83 of 86
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* AWS: Member Account

GCP: Billing Account GCP: Project
Azure MCA: Billing Profile Azure MCA: Subscription
Snowflake: Organizational Account 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,
84 of 86
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.

Invoice
# Scenario Provider Publisher
Issuer

1.1 Purchasing cloud services directly Cloud Cloud service provider Cloud
from cloud provider service service
provider provider

1.2 Purchasing cloud services from the Cloud Cloud service provider Entity
cloud provider where the cloud service operating
region is operated by a 3rd party provider the region
for the
cloud
service
provider

2.1 Purchasing cloud services via MSP Managed Cloud service provider Managed
Service Service
Provider Provider

2.2 Purchasing cloud-agnostic resources Managed Managed Service Provider Managed

or services built/sold by an MSP Service Service
Provider Provider

2.3 Purchasing labor services from Managed Managed Service Provider Managed
managed service provider Service Service
Provider Provider

3.1 Purchasing a cloud marketplace Cloud Company building the Cloud

offering that runs on the cloud service software or services service
provider provider (Cloud service provider provider
OR third-party software or
services company)

3.2 Purchasing a cloud marketplace Cloud Company producing the Cloud

offering that is not running directly service SaaS or services product service
on your cloud infrastructure (e.g,. provider provider
SaaS product, Professional Services)

3.3 Purchasing a SaaS product that is Cloud SaaS provider Reseller

not directly running on your cloud service
infrastructure from a 3rd party provider
reseller managed cloud marketplace

4.1 Purchasing SaaS software directly SaaS SaaS provider SaaS

from provider provider provider

4.2 Purchasing SaaS software that Cloud Cloud service provider Cloud
additionally runs on your cloud service service
resources (in addition to #4.1) provider provider

5.1 Purchasing internal infrastructure or Internal Internal product name Internal

services offerings running on- product product
premise name name

5.2 Purchasing internal infrastructure or Internal Internal product name Internal

services offerings running on cloud product product
name name

85 of 86
 Invoice
# Scenario Provider Publisher
Issuer

5.3 Associated software license cost for Internal Company producing the Internal
use on an on-premise infrastructure product software product
platform (Where license cost is name name
presented separately in cost data)

86 of 86