FinOps Open Cost and Usage

Specification
Version
v0.5 Candidate Release

⚡ Warning

This version is a candidate release but not an official

publication

Copyright © 2023 - 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 candidate for release as a publication. This is not a published release of the FinOps Open Cost and Usage
Specification.

This document was published by the FOCUS Working Group as a Working Draft using the Recommendation track.

Publication as a Candidate Release does not imply endorsement by the FOCUS Project and its Members.

This document should be considered a draft document and may be updated, replaced or obsoleted by other
documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Patent Policy. FOCUS maintains a public list of
any patent disclosures made in connection with the deliverables of the group; that page also includes instructions

1 of 33
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 in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 5 February 2004 W3C Patent Policy.

Abstract
FOCUS is an open-source specification for cloud 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.

2 of 33
Contributors
Thanks to the following FOCUS members for their contributions to this work.

Amit Wadhwa (Google)

Chandra Deverajan (CloudTrakr)
Christopher Harris (Datadog)
Eleni Rundle (Google)
Erik Peterson (CloudZero)
Graham Murphy (Australian Retirement Trust)
Irena Jurica (Neos)
Jason Kelly (Anglepoint Group Inc)
Joe Ferrero (DB Gurus Inc.)
John Grubb (platform.sh)
Josh Kwon (Ternary)
Karl Kraft (Walmart)
Mark Krawczeniuk (NetApp)
Michael Arkoosh (Vega)
Michael Flanakin (Microsoft)
Mike Fuller (FinOps Foundation)
Mike Polson (VMWare)
Nicolas Fonrose (Teevity)
Ray Ding (Accenture)
Ricardo Triana (Accenture)
Riley Jenkins (Domo)
Rodney Joyce (CloudMonitor)
Rupa Patel (Google)
Sanjna Srivatsa (VMWare)
Tatiana Dubovchenko (Flexera)
Trey Morgan (Microsoft)
Tim O'Brien (Walmart)
Trig Ghosh (Accenture)
Udam Dewaraja (FinOps Foundation)

3 of 33
Table of Contents

1. Introduction
1.1. Background and History
1.2. Intended Audience
1.3. Scope
1.4. Design Notes
1.5. Typographic Conventions
1.6. Conformance Checkers and Validators

2. Dimensions
2.1. Availability Zone
2.2. Billing Account ID
2.3. Billing Account Name
2.4. Billing Currency
2.5. Billing Period End
2.6. Billing Period Start
2.7. Charge Period End
2.8. Charge Period Start
2.9. Charge Type
2.10. Invoice Issuer
2.11. Provider
2.12. Publisher
2.13. Region
2.14. Resource ID
2.15. Resource Name
2.16. Service Category
2.17. Service Name
2.18. Sub Account ID
2.19. Sub Account Name

3. Metrics
3.1. Amortized Cost
3.2. Billed Cost

4. Attributes
4.1. Column Naming Convention
4.2. Currency Code Format
4.3. Date/Time Format
4.4. Null Handling

5. Glossary
6. Appendix
6.1. Grouping constructs for resources and/or services
6.2. Origination of Cost Data

4 of 33
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. However, 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 in order 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 sponsored 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 Notes

5 of 33
The following principles were considered while building the specification.

1.4.1. Provider-Neutral Approach by Default

While the schema, naming, terminology and attributes of many providers were reviewed during
development, this specification aims to be provider-neutral. In some cases, the approach may closely
resemble one or more provider's implementation, 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 alignment with the FinOps Framework and Capabilities.

1.4.2. Working Backwards

The FOCUS group working on the specification aims to work backwards from essential FinOps capabilities
that practitioners need to perform to prioritize the dimensions, metrics and the attributes of the billing data
that should be defined in the specification to fulfill that capability. Some of the enabled capabilities will be
documented in the Appendix: FinOps Capabilities Enabled by FOCUS (TODO).

1.4.3. Extensibility

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

1.5. 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.

An implementation of this specification is not compliant if it fails to satisfy one or more of the "MUST",
"MUST NOT", "REQUIRED", "SHALL", or "SHALL NOT" requirements defined in the specification. Conversely,
an implementation of the specification is compliant if it satisfies all the "MUST", "MUST NOT", "REQUIRED",
"SHALL", and "SHALL NOT" requirements defined in the specification.

1.6. 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.

6 of 33
2. Dimensions
The FOCUS specification defines a group of columns that provide qualitative values (such as dates,
resource, and provider information). These columns are categorized to as 'dimensions' within the dataset
and are needed to serve many FinOps capabilities. You can use dimensions to categorize, filter, and reveal
details in your data when grouped with 'metrics', which are the quantitative (numeric) values. The
Dimensions are presented in Alphabetical order.

2.1. Availability Zone

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 cost and usage based on where resources are deployed.

The AvailabilityZone column SHOULD be present in the billing data. This column MUST be of type String and
MAY contain null values.

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 required False

Data type String

Allows nulls True

Value format <not specified>

2.1.5. Introduced (version)

0.5
7 of 33
2.2. Billing Account ID

A billing account is a container for resources and/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.

A Billing Account ID is a provider assigned identifier for a billing account.

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 and/or services for details and examples of the different
grouping constructs supported by FOCUS.

2.2.1. Column ID

BillingAccountId

2.2.2. Display name

Billing Account ID

2.2.3. Description

The identifier assigned to a billing account by the provider.

2.2.4. Content constraints

Constraint Value

Column required True

Data type String

Allows nulls False

Value format <not specified>

2.2.5. Introduced (version)

0.5

2.3. Billing Account Name

A billing account is a container for resources and/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.

8 of 33
A Billing Account Name is a display name assigned to a billing account.

The BillingAccountName column MUST be present in the billing data. This column MUST be of type String.
The BillingAccountName MUST NOT be null if a display name can be assigned to a billing account.
BillingAccountName MUST be unique within a customer when a customer has more than one billing account.

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

2.3.1. Column ID

BillingAccountName

2.3.2. Display name

Billing Account Name

2.3.3. Description

The display name assigned to a billing account.

2.3.4. Content constraints

Constraint Value

Column required True

Data type String

Allows nulls True

Value format <not specified>

2.3.5. Introduced (version)

0.5

2.4. Billing Currency

Billing Currency is an identifier that represents the currency that a charge for resources and/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 FOCUS Currency Code Format requirements.

9 of 33
2.4.1. Column ID

BillingCurrency

2.4.2. Display name

Billing Currency

2.4.3. Description

Represents the currency that a charge was billed in.

2.4.4. Content Constraints

Constraint Value

Column required True

Data type String

Allows nulls False

Value format list-of-values

Allowed Values Meets FOCUS Currency Code Format

requirements

2.4.5. Introduced (version)

0.5

2.5. Billing Period End

Billing period represents the time window for which an organization has or will receive an invoice for. The
time window is inclusive of the start date and exclusive of the end date.

Billing Period End represents the end date and time of the billing period.

The BillingPeriodEnd column MUST be present in the billing data. This column MUST be of type Date/Time
and MUST NOT contain null values. BillingPeriodEnd column MUST conform to FOCUS Date/Time Format. The
sum of the Billed Cost metric for line items in a given billing period MUST match the sum of the invoices
received for that billing period for a billing account.

2.5.1. Column ID

BillingPeriodEnd

10 of 33
2.5.2. Display Name

Billing Period End

2.5.3. Description

The end date and time of the billing period.

2.5.4. Content Constraints

Constraint Value

Column Required True

Data type Date/Time

Allows nulls False

Value format Meets FOCUS Date/Time Format

requirements

2.5.5. Introduced (version)

0.5

2.6. Billing Period Start

Billing period represents the time window for which an organization has or will receive an invoice for. The
time window is inclusive of the start date and exclusive of the end date.

Billing Period Start represents the start date and time of the billing period.

The BillingPeriodStart column MUST be present in the billing data. This column MUST be of type Date/Time
and MUST NOT contain null values. BillingPeriodStart column MUST conform to FOCUS Date/Time Format.
The sum of the Billed Cost metric for line items 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

BillingPeriodStart

2.6.2. Display Name

Billing Period Start

11 of 33
2.6.3. Description

The beginning date and time of the billing period.

2.6.4. Content Constraints

Constraint Value

Column Required True

Data type Date/Time

Allows nulls False

Value format Meets FOCUS Date/Time Format

requirements

2.6.5. Introduced (version)

0.5

2.7. Charge Period End

Charge period represents the time window in which a charge was incurred. The time window is inclusive of
the charge period start date and exclusive of the charge period end date. A charge can start and/or end at
any time within a charge period window. The charge period for continuous usage should match the time
granularity of the dataset (e.g., 1 hour for hourly, 1 day for daily).

Charge Period End represents the end date and time of the charge period.

The ChargePeriodEnd column MUST be present in the billing data. This column MUST be of type Date/Time
and MUST NOT contain null values. ChargePeriodEnd column MUST conform to FOCUS Date/Time Format.

2.7.1. Column ID

ChargePeriodEnd

2.7.2. Display name

Charge Period End

2.7.3. Description

The end date and time of a charge period.

12 of 33
2.7.4. Content constraints

Constraint Value

Column Required True

Data type Date/Time

Allows nulls False

Value format Meets FOCUS Date/Time Format

requirements

2.7.5. Introduced (version)

0.5

2.8. Charge Period Start

Charge period represents the time window in which a charge was incurred. The time window is inclusive of
the charge period start date and exclusive of the charge period end date. A charge can start and/or end at
any time within a charge period window. The charge period for continuous usage should match the time
granularity of the dataset (e.g., 1 hour for hourly, 1 day for daily).

Charge Period Start represents the starting date and time of the charge period.

The ChargePeriodStart column MUST be present in the billing data. This column MUST be of type Date/Time
and MUST NOT contain null values. ChargePeriodStart column MUST conform to FOCUS Date/Time Format.

2.8.1. Column ID

ChargePeriodStart

2.8.2. Display name

Charge Period Start

2.8.3. Description

The beginning date and time of a charge period.

2.8.4. Content constraints

Constraint Value

Column Required True

Data type Date/Time

13 of 33
 Constraint Value

Allows nulls False

Value format Meets FOCUS Date/Time Format

requirements

2.8.5. Introduced (version)

0.5

2.9. Charge Type

A Charge Type indicates whether the record represents an upfront or recurring fee, cost of usage that
already occurred, an after-the-fact adjustment (e.g., credits), or taxes. The Charge Type is commonly used
to identify prepaid purchases separately from usage-based charges, to separate taxes that may require
special handling, or to apply finer-grained allocation logic to purchases or adjustments.

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

See Appendix: Charge Type for details about allowed values and governance criteria for this dimension.

2.9.1. Column ID

ChargeType

2.9.2. Display Name

Charge Type

2.9.3. Description

Indicates whether the record represents an upfront or recurring fee, cost of usage that already occurred, an
after-the-fact adjustment (e.g., credits), or taxes.

2.9.4. Content Constraints

Constraint Value

Column required True

Data type String

Allows nulls False

14 of 33
 Constraint Value

Value format list-of-values

Allowed values:

Value Description

Adjustment Any adjustments that are applied after the original usage or purchase record.
Adjustments may be related to multiple charges.

Purchase Charges for the acquisition of a service or resource bought upfront or on a recurring
basis.

Tax Applicable taxes that are levied by the relevant authorities. Tax charges may vary
depending on factors such as the location, jurisdiction, and local or federal regulations.

Usage Charges based on the quantity of a service or resource that was consumed over a given
period of time.

2.9.5. Introduced (version)

0.5

2.10. Invoice Issuer

An Invoice Issuer is an entity responsible for invoicing for the resources and/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.10.1. Column ID

InvoiceIssuerName

2.10.2. Display Name

Invoice Issuer

2.10.3. Description

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

2.10.4. Content Constraints

15 of 33
 Constraint Value

Column required True

Data type String

Allows nulls False

Value format <not specified>

2.10.5. Introduced (version)

0.5

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

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

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

2.11.1. Column ID

ProviderName

2.11.2. Display Name

Provider

2.11.3. Description

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

2.11.4. Content Constraints

Constraint Value

Column required True

Data type String

Allows nulls False

Value format <not specified>

16 of 33
2.11.5. Introduced (version)

0.5

2.12. Publisher

A Publisher is an entity that produced the resources and/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.12.1. Column ID

PublisherName

2.12.2. Display Name

Publisher

2.12.3. Description

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

2.12.4. Content Constraints

Constraint Value

Column required True

Data type String

Allows nulls False

Value format <not specified>

2.12.5. Introduced (version)

0.5

2.13. Region
17 of 33
A Region is a provider assigned identifier for an isolated geographic area where a resource is provisioned in
and/or a service is provided from. Region is commonly used for scenarios like analyzing cost and prices
based on where resources are deployed.

The Region column MUST be present in the billing data. This column MUST be of type String and MUST NOT
contain null values. Region values MUST be consistent within the provider and MUST be the same values
used to indicate the region when provisioning or purchasing the resource or service.

2.13.1. Column ID

Region

2.13.2. Display name

Region

2.13.3. Description

Isolated geographic area where a resource is provisioned in and/or a service is provided from.

2.13.4. Content constraints

Constraint Value

Column required True

Data type String

Allows nulls False

Value format <not specified>

2.13.5. Introduced (version)

0.5

2.14. 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. 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.

18 of 33
2.14.1. Column ID

ResourceId

2.14.2. Display Name

Resource ID

2.14.3. Description

Identifier assigned to a resource by the provider.

2.14.4. Content Constraints

Constraint Value

Column required True

Data type String

Allows nulls True

Value format <not specified>

2.14.5. Introduced (version)

0.5

2.15. 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. 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.15.1. Column ID

ResourceName

2.15.2. Display Name

19 of 33
Resource Name

2.15.3. Description

Display name assigned to a resource.

2.15.4. Content Constraints

Constraint Value

Column required True

Data type String

Allows nulls True

Value format <not specified>

2.15.5. Introduced (version)

0.5

2.16. 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 to 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 or empty. This column is of type String
and MUST be one of the allowed values.

2.16.1. Column ID

ServiceCategory

2.16.2. Display Name

Service Category

2.16.3. Description

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

20 of 33
2.16.4. Content Constraints

Constraint Value

Column required True

Data type String

Allows nulls False

Value format List of 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.

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.16.5. Introduced (version)

0.5

2.17. 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.
21 of 33
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.17.1. Column ID

ServiceName

2.17.2. Display Name

Service Name

2.17.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.17.4. Content Constraints

Constraint Value

Column required True

Data type String

Allows nulls False

Value format <not specified>

2.17.5. Introduced (version)

0.5

2.18. Sub Account ID

A sub account is an optional provider-supported construct for organizing resources and/or 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.

A sub account ID is a provider assigned identifier assigned to a sub account.

The SubAccountId column MUST be present in the billing data. This column MUST be of type String. If a
provider supports a sub account construct, that value MUST appear in this column. If a provider does not
support a sub account construct (only has a billing account) or does support a sub account construct, but the

22 of 33
charge does not apply to a sub account, the SubAccountId column MUST be null.

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

2.18.1. Column ID

SubAccountId

2.18.2. Display name

Sub Account ID

2.18.3. Description

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

2.18.4. Content constraints

Constraint Value

Column required True

Data type String

Allows nulls True

Value format <not specified>

2.18.5. Introduced (version)

0.5

2.19. Sub Account Name

A sub account is an optional provider-supported construct for organizing resources and/or 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.

A sub account name is a display name assigned to a sub account.

The SubAccountName column MUST be present in the billing data. This column MUST be of type String. If a
provider supports setting a display name for sub accounts, that value MUST appear in this column. If a
provider does not support a sub account construct (only has a billing account) or does support a sub account
construct, but the charge does not apply to a sub account, the SubAccountName column MUST be null.

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

2.19.1. Column ID

SubAccountName

2.19.2. Display name

Sub Account Name

2.19.3. Description

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

2.19.4. Content constraints

Constraint Value

Column required True

Data type String

Allows nulls True

Value format <not specified>

2.19.5. Introduced (version)

0.5

3. Metrics
The FOCUS specification defines a group of columns that provide numeric values. These columns are
categorized to as 'metrics' within the dataset and are needed to serve many FinOps capabilities. Metric
columns in the dataset allow for aggregation operations such as arithmetic operations (sum, multiplication,
averaging etc.) and statistical operations. When combined with dimensions (which are qualitative value
columns), metrics reveal details in your data.

3.1. Amortized Cost

Amortized cost represents the sum of the amortized upfront fees, amortized recurring fees, and the usage
cost of the line item. This column is often used to show spending trends that include on demand rates,
24 of 33
effective commitment-based discount rates, recurring commitments, as well as amortization of upfront fees.
The fee and upfront amortization portion of this column's value should be proportional to the number of
units for the line item and the time granularity of the data. The currency for the value specified in Amortized
Cost can be found in the Billing Currency column. The aggregated Amortized Cost for a billing period may
not match the charge received on the invoice for the same billing period.

Practitioners are faced with two main challenges with respect to this metric:

1. Practitioners need to amortize upfront fees over the duration of the commitment and distribute those
fees 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 line item per period and the actual usage line items.

The AmortizedCost column MUST be present in the billing data. This column MUST be a numeric value of
type Decimal and MUST NOT contain null values.

3.1.1. Column ID

AmortizedCost

3.1.2. Display name

Amortized Cost

3.1.3. Description

The cost inclusive of amortized upfront fees, amortized recurring fees, and the usage cost of the line item.

3.1.3.1. Concerning Granularity and Distribution of Recurring Fee

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

3.1.3.2. Concerning Amortization Approaches

The amortization of the upfront charge should be amortized using a methodology determined by the
provider that reflects the needs of their customer base and is proportional with usage quantity and the time
granularity of the line item. Should a practitioner desire to amortize upfront fees using a different approach,
the practitioner can do so using the Billed Cost for the line item representing the initial purchase.

3.1.4. Content constraints

Constraint Value

25 of 33
 Constraint Value

Column required True

Data type Decimal

Allows nulls False

Value format Numeric

value

3.1.5. Introduced (version)

0.5

3.2. Billed Cost

The Billed Cost represents a charge inclusive of negotiated discounts that a consumer would be charged for
each billing period. Billed Cost does not amortize upfront charges (one-time or recurring). The currency for
the value specified in Billed Cost can be found in the Billing Currency column. Billed Cost is often 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. This column MUST be a numeric value of type
Decimal and MUST NOT contain null values. The aggregated BilledCost for a billing period MUST match the
charge received on the invoice for the same billing period.

3.2.1. Column ID

BilledCost

3.2.2. Display name

Billed Cost

3.2.3. Description

A charge inclusive of negotiated discounts that a consumer would be charged for each billing period.

3.2.4. Content constraints

Constraint Value

Column required True

Data type Decimal

Allows nulls False

26 of 33
 Constraint Value

Value format Numeric

value

3.2.5. Introduced (version)

0.5

4. Attributes
Attributes are requirements that apply to the billing datasets. 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.

4.1. Column Naming Convention

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

All columns defined in FOCUS MUST follow the naming requirements listed below. Provider generated
columns SHOULD adopt these same naming requirements over time.

4.1.1. Attribute ID

ColumnNamingConvention

4.1.2. Attribute Name

Column Naming Convention

4.1.3. Description

Naming convention for columns appearing in billing data.

4.1.4. Requirements
27 of 33
 Column IDs MUST use Pascal case.
Column IDs MUST NOT use abbreviations.
Column IDs SHOULD NOT use acronyms.
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 it is considered superfluous

4.1.5. Exceptions

Identifiers will use the "Id" abbreviation since this is a standard pattern across the industry.

4.1.6. Introduced (version)

0.5

4.2. Currency Code Format

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

All currency related columns defined in the FOCUS schema MUST follow the currency formatting
requirements listed below. Provider generated currency-related columns SHOULD adopt the same format
requirements over time.

4.2.1. Attribute ID

CurrencyCodeFormat

4.2.2. Attribute name

Currency Code Format

4.2.3. Description

Formatting for currency columns appearing in billing data.

4.2.4. Requirements

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

28 of 33
4.2.5. Exceptions

None

4.2.6. Introduced (version)

0.5

4.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 date/time related columns, defined in the FOCUS specification, MUST be represented in UTC and follow
the ISO 8601 aligned formatting requirements listed below. Provider generated date/time related columns
SHOULD also be represented in UTC and conform to the ISO 8601 standard.

4.3.1. Attribute ID

DateTimeFormat

4.3.2. Attribute name

Date/Time Format

4.3.3. Description

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

4.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)

29 of 33
4.3.5. Exceptions

None

4.3.6. Introduced (version)

0.5

4.4. 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 that consume the data for analysis, reporting, and other use
cases.

All columns defined in FOCUS MUST follow the null handling requirements listed below. Provider generated
columns SHOULD adopt these same null handling requirements over time.

4.4.1. Attribute ID

NullHandling

4.4.2. Attribute Name

Null Handling

4.4.3. Description

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

4.4.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 'Not Set' or 'Not Applicable' in
columns, regardless of if the column allows nulls or not.

4.4.5. Exceptions

None

4.4.6. Introduced (version)

30 of 33
0.5

5. Glossary
This section is non-normative.

TODO Needs to be completed and linked

Resource:

Add definition

Service:

Add definition

6. Appendix
This section is non-normative.

6.1. Grouping constructs for resources and/or services

Providers natively support various constructs for grouping resources and/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 and/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 and/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

31 of 33
* 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.

6.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 and/or services available for purchase.
Publisher: The entity that produced the resources and/or services that were purchased.
Invoice Issuer: The entity responsible for invoicing for the resources and/or services consumed.

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

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 Managed Managed Service Provider Managed

resources and/or services built/sold Service Service
by an MSP 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 and/or services service
provider provider (Cloud service provider OR provider
third-party software and/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)

32 of 33
 Invoice
# Scenario Provider Publisher
Issuer

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 Internal Internal product name Internal

and/or services offerings running product product
on-premise name name

5.2 Purchasing internal infrastructure Internal Internal product name Internal

and/or services offerings running on product product
cloud name name

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)

33 of 33