FOCUS Specification v1.0-preview

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

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

Document Use License

FinOps Open Cost and Usage Specification is licensed under CC BY 4.0

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.

Contributors

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

  • 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.)
  • Christopher Harris (Datadog)
  • Colin Jack (Snow Software)
  • Deeja Cruz (Datadog)
  • Eleni Rundle (Google)
  • Erik Peterson (CloudZero)
  • Graham Murphy (Australian Retirement Trust)
  • Irena Jurica (Neos)
  • Jacky Liu (Google)
  • Janine Pickard-Green (MagicOrange Group Limited)
  • Jason Kelly (Anglepoint Group Inc)
  • Joe Ferrero (DB Gurus Inc.)
  • John Grubb (Platform.sh)
  • Joshua Kwan (Ternary)
  • Karl Kraft (Walmart)
  • Larry Advey (Twilio)
  • Letian Wang (Atlassian)
  • Luna Bernal (Twilio)
  • Marc Perreaut (amadeus)
  • Marcin Walkow (Nordcloud)
  • Mark Krawczeniuk (NetApp)
  • Matt Ray (Kubecost)
  • Michael Arkoosh (Vega)
  • Michael Flanakin (Microsoft)
  • Mike Fuller (FinOps Foundation)
  • Mike Polson (VMWare)
  • Nick Kotze (Surveil)
  • Nicolas Fonrose (Teevity)
  • Ray Ding (Accenture)
  • Ricardo Triana (Accenture)
  • Peter Marton (OpenMeter.io)
  • Riley Jenkins (Domo)
  • Rodney Joyce (CloudMonitor)
  • Rupa Patel (Google)
  • Sarah McMullin (Google)
  • Sanjna Srivatsa (VMWare)
  • Shawn Alpay (Envisor)
  • Sumaira Nazir (Platform.sh)
  • Tatiana Dubovchenko (Flexera)
  • Trey Morgan (Microsoft)
  • Tim O’Brien (Walmart)
  • Trig Ghosh (Accenture)
  • Udam Dewaraja (FinOps Foundation)
  • Yuriy Prykhodko (Amazon Web Services)
  • Webb Brown (Kubecost)

Table of Contents

  • 4. Use Case Library
  • 5. Glossary
  • 6. Appendix
  •  

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

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

     

    1.3. Scope

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

     

    1.4. Design Principles

    The following principles were considered while building the
    specification.

     

    1.4.1. FOCUS is
    an iterative, living specification

    • Incremental iterations of the specification released on a regular
      basis 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
    backwards with ease of adoption

    • Aim to work backwards from essential FinOps capabilities that
      practitioners need to perform to prioritize the dimensions, metrics and
      the 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 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.4. Extensibility

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

     

    1.5. Design Notes

     

    1.5.1. Optimize for data
    analysis

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

     

    1.5.2. Consistency helps
    with clarity

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

     

    1.6. Typographic Conventions

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

    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.7. Conformance
    Checkers and Validators

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

     

    2. Columns

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

     

    2.1. Availability Zone

    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 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 type Dimension
    Column required False
    Allows nulls True
    Data type String
    Value format <not specified>

     

    2.1.5. Introduced (version)

    0.5  

    2.2. Billed Cost

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

    The BilledCost column MUST be present in the billing data and MUST
    NOT be null. This column MUST be of type Decimal, MUST conform to Numeric Format, and be denominated in the
    BillingCurrency. The aggregated BilledCost for a billing period MUST match
    the charge received on the invoice for the same billing
    period
    .

     

    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
    Column required True
    Allows nulls False
    Data type Decimal
    Value format Numeric
    Format
    Number range Any valid decimal value

     

    2.2.5. Introduced (version)

    0.5  

    2.3. Billing Account ID

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

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

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

     

    2.3.1. Column ID

    BillingAccountId

     

    2.3.2. Display name

    Billing Account ID

     

    2.3.3. Description

    The identifier assigned to a billing account by the
    provider.

     

    2.3.4. Content constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls False
    Data type String
    Value format <not specified>

     

    2.3.5. Introduced (version)

    0.5  

    2.4. Billing Account Name

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

    The BillingAccountName column MUST be present in the billing data.
    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 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
    Column required True
    Allows nulls True
    Data type String
    Value format <not specified>

     

    2.4.5. Introduced (version)

    0.5  

    2.5. Billing Currency

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

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

     

    2.5.1. Column ID

    BillingCurrency

     

    2.5.2. Display name

    Billing Currency

     

    2.5.3. Description

    Represents the currency that a charge was billed in.

     

    2.5.4. Content Constraints

    Constraint Value
    Column type Dimension
    Column required True
    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 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 Date/Time Format. 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 end date and time of the billing period.

     

    2.6.4. Content Constraints

    Constraint Value
    Column type Dimension
    Column required True
    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 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 Date/Time Format. The sum of the BilledCost metric for rows in a given billing
    period
    MUST match the sum of the invoices received for that
    billing period for a billing account.

     

    2.7.1. Column ID

    BillingPeriodStart

     

    2.7.2. Display Name

    Billing Period Start

     

    2.7.3. Description

    The beginning date and time of the billing period.

     

    2.7.4. Content Constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls False
    Data type Date/Time
    Value format Date/Time
    Format

     

    2.7.5. Introduced (version)

    0.5  

    2.8. Charge Category

    A Charge Category indicates whether the row represents an upfront or
    recurring fee, cost of usage that already occurred, an after-the-fact adjustment (e.g., credits), or
    taxes. The Charge Category 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 ChargeCategory column MUST be present and MUST NOT be null. This
    column is of type String and MUST be one of the allowed values.

     

    2.8.1. Column ID

    ChargeCategory

     

    2.8.2. Display Name

    Charge Category

     

    2.8.3. Description

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

     

    2.8.4. Content Constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls False
    Data type String
    Value format Allowed values

    Allowed values:

    Value Description
    Adjustment Any adjustments that are applied after the
    original usage or purchase row. 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.8.5. Introduced (version)

    0.5  

    2.9. 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 Charge Description column MUST be present within the dataset,
    MUST be of type String, and SHOULD NOT be null. Providers SHOULD specify
    the length of this column in their publicly available documentation.

     

    2.9.1. Column ID

    ChargeDescription

     

    2.9.2. Display Name

    Charge Description

     

    2.9.3. Description

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

     

    2.9.4. Content Constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls True
    Data type String
    Value format <not specified>

     

    2.9.5. Introduced (version)

    1.0  

    2.10. 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 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. When ChargeCategory is
    “Purchase”, ChargeFrequency MUST NOT be “Usage-Based”.

     

    2.10.1. Column ID

    ChargeFrequency

     

    2.10.2. Display Name

    Charge Frequency

     

    2.10.3. Description

    Indicates how often a charge will occur.

     

    2.10.4. Content Constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls False
    Data type String
    Value format Allowed values

    Allowed values:

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

     

    2.10.5. Introduced (version)

    1.0  

    2.11. Charge Period End

    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 Date/Time Format.

     

    2.11.1. Column ID

    ChargePeriodEnd

     

    2.11.2. Display name

    Charge Period End

     

    2.11.3. Description

    The end date and time of a charge period.

     

    2.11.4. Content constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls False
    Data type Date/Time
    Value format Date/Time
    Format

     

    2.11.5. Introduced (version)

    0.5  

    2.12. Charge Period Start

    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 Date/Time Format.

     

    2.12.1. Column ID

    ChargePeriodStart

     

    2.12.2. Display name

    Charge Period Start

     

    2.12.3. Description

    The beginning date and time of a charge period.

     

    2.12.4. Content constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls False
    Data type Date/Time
    Value format Date/Time
    Format

     

    2.12.5. Introduced (version)

    0.5  

    2.13. Charge Subcategory

    Charge Subcategory indicates what kind of usage or adjustment the row represents. Charge Subcategory is
    a supplemental detail to the Charge
    Category
    . It provides additional context to describe the primary
    category of charge.

    This linkage to the parent Charge Category means that for every entry
    under Charge Category, there can be a corresponding Charge Subcategory
    that further refines the nature of the charge. It’s a nested level of
    detail that allows users to see not just what type of charge was
    incurred. Current sub-categorization currently applies to Charge
    Category values “Usage” and “Adjustment”. Support for others will be
    added as needed.

    When Charge Category is “Usage” and the charge is related to a commitment, the Charge
    Subcategory indicates whether the row represents committed usage or is
    an amortized charge for
    the unused portion of the commitment. Charge Subcategory is
    commonly used for scenarios like calculating commitment
    utilization when Charge Category is “Usage”.

    When Charge Category is “Adjustment”, the Charge Subcategory
    indicates what kind of after-the-fact adjustment the record
    represents and is commonly used to identify changes like credits and
    refunds.

    ChargeSubcategory MUST follow the requirements listed below:

    • The ChargeSubcategory MUST be present in the billing data.
    • ChargeSubcategory is of type String and MUST be one of the allowed
      values.
    • ChargeSubcategory MUST NOT be null when ChargeCategory is “Usage”
      and the charge is covered by a commitment.

      • When a usage charge is covered by a commitment,
        ChargeSubcategory MUST be “Used Commitment”.
      • When a commitment is not used fully used or partially used
        within the committed period, ChargeSubcategory MUST be “Unused
        Commitment” for the unused usage charge.
    • ChargeSubcategory MUST be null when ChargeCategory is “Usage” and is
      not covered by a commitment.
    • ChargeSubcategory MUST NOT be null when ChargeCategory is
      “Adjustment”.

      • When an adjustment applies to a specific item, the
        corresponding FOCUS columns that identify that item MUST NOT be null and
        MUST match the applicable item details the adjustment pertains
        to.
    • ChargeSubcategory MUST be null when ChargeCategory is “Purchase” or
      “Tax”.

     

    2.13.1. Column ID

    ChargeSubcategory

     

    2.13.2. Display Name

    Charge Subcategory

     

    2.13.3. Description

    Indicates what kind of usage or adjustment the row
    represents.

     

    2.13.4. Content Constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls True
    Data type String
    Value format Allowed values

    Allowed values when ChargeCategory is “Usage”:

    Value Description
    On-Demand Usage charges that are not associated with
    a commitment
    Used Commitment Usage charges that are associated with
    consumption of a commitment’s underlying basis.
    Unused Commitment Amortized usage charges for the portion of
    a commitment that has not been used. For example, if an organization has
    a commitment-based discount that is not fully utilized, the unused
    portion falls under this category. It highlights an area where the
    organization is not fully leveraging its commitments, which could be a
    lost cost-saving opportunity.

    Allowed values when ChargeCategory is “Adjustment”:

    Value Description
    Refund Negative charges that were previously
    billed and are being returned by the provider. Providers can have
    multiple types of refunds such as resolving a tax error or for returned
    or exchanged commitment-based discounts.
    Credit Negative charges granted by the provider
    for various scenarios, like negotiated benefits, usage discounts, or
    promotional credits.
    Rounding Error Positive or negative charges that are
    needed to ensure raw billing data aggregations match the total cost on
    the invoice, which may be rounded.
    General Adjustment Positive or negative charges the provider
    applies that do not fall into other adjustment category values.

     

    2.13.5. Introduced (version)

    1.0  

    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. This column MUST be of type String, MUST be null when CommitmentDiscountId is null, and MUST
    NOT be null when CommitmentDiscountId is not null. The
    CommitmentDiscountCategory MUST be one of the allowed values.

     

    2.14.1. Column ID

    CommitmentDiscountCategory

     

    2.14.2. Display name

    Commitment Discount Category

     

    2.14.3. Description

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

     

    2.14.4. Content constraints

    Constraint Value
    Column type Dimension
    Column required True
    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  

    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.
    This column MUST be of type String and MUST NOT contain null values when
    a charge is related to a commitment-based discount. When a
    charge is not associated with a commitment-based discount, the
    column MUST be null. CommitmentDiscountId MUST be unique within the
    provider.

     

    2.15.1. Column ID

    CommitmentDiscountId

     

    2.15.2. Display name

    Commitment Discount ID

     

    2.15.3. Description

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

     

    2.15.4. Content constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls True
    Data type String
    Value format <not specified>

     

    2.15.5. Introduced (version)

    1.0  

    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. This column MUST be of type String. The CommitmentDiscountName
    value MUST be null if the charge is not related to a
    commitment-based discount and MAY be null if a display name
    cannot be assigned to a commitment-based discount.
    CommitmentDiscountName MUST NOT be null if a display name can be
    assigned to a commitment-based discount.

     

    2.16.1. Column ID

    CommitmentDiscountName

     

    2.16.2. Display name

    Commitment Discount Name

     

    2.16.3. Description

    The display name assigned to a commitment-based
    discount
    .

     

    2.16.4. Content constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls True
    Data type String
    Value format <not specified>

     

    2.16.5. Introduced (version)

    1.0  

    2.17. 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. This column MUST be of type String, MUST be null when CommitmentDiscountId is null, and MUST
    NOT be null when CommitmentDiscountId is not null. Providers MUST use a
    consistent value-format and a set of values for CommitmentDiscountType
    values within their billing datasets.

     

    2.17.1. Column ID

    CommitmentDiscountType

     

    2.17.2. Display name

    Commitment Discount Type

     

    2.17.3. Description

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

     

    2.17.4. Content constraints

    Constraint Value
    Column type Dimension
    Column required False
    Allows nulls True
    Data type String
    Value format <not specified>

     

    2.17.5. Introduced (version)

    1.0  

    2.18. Effective Cost

    Effective Cost represents a cost inclusive of the impacts of all
    reduced rates and discounts, augmented with the amortization of relevant
    purchases (one-time or recurring) paid to cover future eligible charges.
    The amortized portion included should be proportional to the Pricing Quantity and the time granularity of
    the data. 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, over the duration of 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, and be denominated in the
    BillingCurrency. 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 SkuPriceId is null, 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. ChargeSubcategory is
      “Credit”).

     

    2.18.1. Column ID

    EffectiveCost

     

    2.18.2. Display name

    Effective Cost

     

    2.18.3. Description

    Cost inclusive of the impacts of all reduced rates and discounts,
    augmented with the amortization of relevant purchases (one-time
    or recurring) paid to cover future eligible charges.

     

    2.18.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.18.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 with 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.18.4. Content constraints

    Constraint Value
    Column type Metric
    Column required True
    Allows nulls False
    Data type Decimal
    Value format Numeric
    Format
    Number range Any valid decimal value

     

    2.18.5. Introduced (version)

    0.5  

    2.19. 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.19.1. Column ID

    InvoiceIssuerName

     

    2.19.2. Display Name

    Invoice Issuer

     

    2.19.3. Description

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

     

    2.19.4. Content Constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls False
    Data type String
    Value format <not specified>

     

    2.19.5. Introduced (version)

    0.5  

    2.20. List Cost

    List Cost represents the cost calculated by multiplying 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 Effective
    Cost
    .

    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, and be denominated in the
    BillingCurrency. When a ListUnitPrice is not null, multiplying the
    ListUnitPrice by PricingQuantity MUST produce the ListCost.

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

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

     

    2.20.1. Column ID

    ListCost

     

    2.20.2. Display name

    List Cost

     

    2.20.3. Description

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

     

    2.20.4. Content Constraints

    Constraint Value
    Column type Metric
    Column required True
    Allows nulls False
    Data type Decimal
    Value format Numeric
    Format
    Number range Any valid decimal value

     

    2.20.5. Introduced (version)

    1.0  

    2.21. 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. This
    column MUST be a Decimal within the range of non-negative decimal
    values, MUST conform to Numeric Format, and
    be denominated in the BillingCurrency. ListUnitPrice MUST NOT be null if
    SkuPriceId is not null and MUST be null if
    SkuPriceId is null. When ListUnitPrice is not null, multiplying
    ListUnitPrice by PricingQuantity MUST
    equal ListCost.

     

    2.21.1. Column ID

    ListUnitPrice

     

    2.21.2. Display name

    List Unit Price

     

    2.21.3. Description

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

     

    2.21.4. Content Constraints

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

     

    2.21.5. Introduced (version)

    1.0  

    2.22. 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 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 and MUST be of
      type String.
    • PricingCategory MUST be null if SkuPriceId
      is null and MUST NOT be null if SkuPriceId is not null.
    • PricingCategory MUST be one of the allowed values.
    • PricingCategory MUST be “On-Demand” when pricing is predetermined at
      the standard rate for the billing
      account
      .
    • PricingCategory MUST be “Commitment-Based” 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 current allowed values apply.

     

    2.22.1. Column ID

    PricingCategory

     

    2.22.2. Display name

    Pricing Category

     

    2.22.3. Description

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

     

    2.22.4. Content constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls True
    Data type String
    Value format Allowed values

    Allowed values:

    Value Description
    On-Demand Charges priced at the standard rate for
    the billing account. 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.
    Commitment-Based 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.22.5. Introduced (version)

    1.0  

    2.23. Pricing Quantity

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

    PricingQuantity MUST be present in the billing data. This column MUST
    be of type Decimal and MUST conform to Numeric
    Format
    . The value MAY be negative in cases where ChargeSubcategory is “Refund”. This column
    MUST NOT be null if SkuPriceId is not null and
    MUST be null if SkuPriceId is null. When unit prices are not null,
    multiplying PricingQuantity by a unit price MUST produce a result equal
    to the corresponding cost metric.

     

    2.23.1. Column ID

    PricingQuantity

     

    2.23.2. Display name

    Pricing Quantity

     

    2.23.3. Description

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

     

    2.23.4. Content constraints

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

     

    2.23.5. Introduced (version)

    1.0  

    2.24. Pricing Unit

    The Pricing Unit represents a provider-specified measurement unit for
    determining unit prices, indicating how a provider rates measured usage
    and purchase quantities considering 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 Usage
    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 if SkuPriceId is not null and MUST be null if
    SkuPriceId is null. Units of measure used in PricingUnit SHOULD adhere
    to the values and format requirements specified in the UnitFormat attribute.

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

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

     

    2.24.1. Column ID

    PricingUnit

     

    2.24.2. Display name

    Pricing Unit

     

    2.24.3. Description

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

     

    2.24.4. Content constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls True
    Data type String
    Value format Unit Format

     

    2.24.5. Introduced (version)

    1.0  

    2.25. Provider

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

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

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

     

    2.25.1. Column ID

    ProviderName

     

    2.25.2. Display Name

    Provider

     

    2.25.3. Description

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

     

    2.25.4. Content Constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls False
    Data type String
    Value format <not specified>

     

    2.25.5. Introduced (version)

    0.5  

    2.26. Publisher

    A Publisher is an entity that produced 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.26.1. Column ID

    PublisherName

     

    2.26.2. Display Name

    Publisher

     

    2.26.3. Description

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

     

    2.26.4. Content Constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls False
    Data type String
    Value format <not specified>

     

    2.26.5. Introduced (version)

    0.5  

    2.27. Region

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

    Region MUST be present in the billing data and MUST be of type
    String. Region MUST NOT be null when a resource or
    service is operated in or managed from a distinct region.
    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.27.1. Column ID

    Region

     

    2.27.2. Display name

    Region

     

    2.27.3. Description

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

     

    2.27.4. Content constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls True
    Data type String
    Value format <not specified>

     

    2.27.5. Introduced (version)

    0.5  

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

     

    2.28.1. Column ID

    ResourceId

     

    2.28.2. Display Name

    Resource ID

     

    2.28.3. Description

    Identifier assigned to a resource by the provider.

     

    2.28.4. Content Constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls True
    Data type String
    Value format <not specified>

     

    2.28.5. Introduced (version)

    0.5  

    2.29. 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.29.1. Column ID

    ResourceName

     

    2.29.2. Display Name

    Resource Name

     

    2.29.3. Description

    Display name assigned to a resource.

     

    2.29.4. Content Constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls True
    Data type String
    Value format <not specified>

     

    2.29.5. Introduced (version)

    0.5  

    2.30. 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 within billing data. 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. Providers MUST use a consistent value-format and a set of values
    for ResourceType values within their billing datasets.

     

    2.30.1. Column ID

    ResourceType

     

    2.30.2. Display Name

    Resource Type

     

    2.30.3. Description

    The kind of resource the charge applies to.

     

    2.30.4. Content Constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls True
    Data type String
    Value format <not specified>

     

    2.30.5. Introduced (version)

    1.0  

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

     

    2.31.1. Column ID

    ServiceCategory

     

    2.31.2. Display Name

    Service Category

     

    2.31.3. Description

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

     

    2.31.4. Content Constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls False
    Data type String
    Value format Allowed Values

    Allowed values:

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

     

    2.31.5. Introduced (version)

    0.5  

    2.32. 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.32.1. Column ID

    ServiceName

     

    2.32.2. Display Name

    Service Name

     

    2.32.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.32.4. Content Constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls False
    Data type String
    Value format <not specified>

     

    2.32.5. Introduced (version)

    0.5  

    2.33. SKU ID

    A SKU ID is an 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. This column
    MUST be of type String. The SkuId MUST NOT be null when SkuPriceId is not null. SkuId MUST equal
    SkuPriceId when a provider does not support an overarching SKU ID
    construct.

     

    2.33.1. Column ID

    SkuId

     

    2.33.2. Display name

    SKU ID

     

    2.33.3. Description

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

     

    2.33.4. Content constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls True
    Data type String
    Value format <not specified>

     

    2.33.5. Introduced (version)

    1.0  

    2.34. 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. 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. The SkuPriceId
    MUST NOT be null when ChargeCategory is
    “Purchase” or “Usage”. SkuPriceId MUST NOT be null when ChargeSubcategory is “Refund” and the
    refund is related to charges with a specific SkuPriceId. A given value
    of SkuPriceId MUST be associated with one and only one SkuId, except in cases of commitment discount
    flexibility.

     

    2.34.1. Column ID

    SkuPriceId

     

    2.34.2. Display name

    SKU Price ID

     

    2.34.3. Description

    Unique identifier that defines the unit price used to calculate the
    charge.

     

    2.34.4. Content constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls True
    Data type String
    Value format <not specified>

     

    2.34.5. Introduced (version)

    1.0  

    2.35. 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. 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](#glossary:billing-account)) or does support a
    sub account construct, but the 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.35.1. Column ID

    SubAccountId

     

    2.35.2. Display name

    Sub Account ID

     

    2.35.3. Description

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

     

    2.35.4. Content constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls True
    Data type String
    Value format <not specified>

     

    2.35.5. Introduced (version)

    0.5  

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

     

    2.36.1. Column ID

    SubAccountName

     

    2.36.2. Display name

    Sub Account Name

     

    2.36.3. Description

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

     

    2.36.4. Content constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls True
    Data type String
    Value format <not specified>

     

    2.36.5. Introduced (version)

    0.5  

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

    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 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 without a specified value MUST have its tag value set to
      null.
    • 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.37.1.
    Provider-Defined vs. User-Defined Tags

    The following is an example of one user-defined tag and one
    provider-defined tag, respectively, with tag key, foo. The
    first tag is user-defined and not prefixed. The second tag is
    provider-defined and prefixed with acme/, which the
    provider has specified as a reserved tag key prefix.

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

     

    2.37.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 a 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.37.3. Column ID

    Tags

     

    2.37.4. Display Name

    Tags

     

    2.37.5. Description

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

     

    2.37.6. Content Constraints

    Constraint Value
    Column type Dimension
    Column required True
    Allows nulls True
    Data type JSON
    Value format Key-Value
    Format

     

    2.37.7. Introduced (version)

    1.0  

    2.38. Usage Quantity

    The Usage Quantity represents the volume of a given resource or service used or purchased based on
    the Usage Unit. Usage 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.

    UsageQuantity MUST be present in the billing data. This column MUST
    be of type Decimal and MUST conform to Numeric
    Format
    . The value MAY be negative in cases where ChargeSubcategory is “Refund”. This column
    MUST NOT contain null values when SkuPriceId
    is not null.

     

    2.38.1. Column ID

    UsageQuantity

     

    2.38.2. Display name

    Usage Quantity

     

    2.38.3. Description

    Volume of a given resource or service used or
    purchased based on the Usage Unit.

     

    2.38.4. Content constraints

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

     

    2.38.5. Introduced (version)

    1.0  

    2.39. Usage Unit

    Usage Unit represents the units of a given resource or service used or purchased in
    combination with Usage Quantity. Usage Unit
    is often listed at a finer granularity or over a different time interval
    when compared to the Pricing Unit
    (complementary to Pricing Quantity), and
    focuses on resource and service consumption, not
    pricing and cost.

    The UsageUnit column MUST be present in the billing data. This column
    MUST be of type String and MUST NOT contain null values when the ChargeCategory is “Usage”. Units of measure
    used in UsageUnit SHOULD adhere to the values and format requirements
    specified in the UnitFormat attribute. The
    UsageUnit column MUST NOT be used as the basis for determining values
    related to any pricing or cost metric.

     

    2.39.1. Column ID

    UsageUnit

     

    2.39.2. Display name

    Usage Unit

     

    2.39.3. Description

    Units of a given resource or service used or
    purchased in combination with Usage
    Quantity
    .

     

    2.39.4. Content constraints

    Constraint Value
    Column type Metric
    Column required True
    Allows nulls True
    Data type String
    Value format Unit Format
    recommended

     

    2.39.5. Introduced (version)

    1.0

     

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

     

    3.1. Column Naming Convention

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

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

     

    3.1.1. Attribute ID

    ColumnNamingConvention

     

    3.1.2. Attribute Name

    Column Naming Convention

     

    3.1.3. Description

    Naming convention for columns appearing in billing data.

     

    3.1.4. Requirements

    • All columns defined by FOCUS MUST follow the following rules:
      • 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 there are no other columns with the same name
        prefix.
    • Custom (e.g., provider-defined) columns SHOULD follow the same rules
      as FOCUS columns listed above.
    • 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.
    • 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.
    • All FOCUS columns SHOULD be first in the provided dataset.
      • Custom columns SHOULD be listed after all FOCUS columns and SHOULD
        NOT be intermixed.
      • Columns MAY be sorted alphabetically but custom columns SHOULD be
        after all FOCUS columns.

     

    3.1.5. Exceptions

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

     

    3.1.6. Introduced (version)

    0.5  

    3.2. Currency Code Format

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

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

     

    3.2.1. Attribute ID

    CurrencyCodeFormat

     

    3.2.2. Attribute name

    Currency Code Format

     

    3.2.3. Description

    Formatting for currency columns appearing in billing data.

     

    3.2.4. Requirements

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

     

    3.2.5. Exceptions

    None

     

    3.2.6. Introduced (version)

    0.5  

    3.3. Date/Time Format

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

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

     

    3.3.1. Attribute ID

    DateTimeFormat

     

    3.3.2. Attribute name

    Date/Time Format

     

    3.3.3. Description

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

     

    3.3.4. Requirements

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

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

     

    3.3.5. Exceptions

    None

     

    3.3.6. Introduced (version)

    0.5  

    3.4. Discount Handling

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

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

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

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

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

     

    3.4.1. Attribute ID

    DiscountHandling

     

    3.4.2. Attribute name

    Discount Handling

     

    3.4.3. Description

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

     

    3.4.4. Requirements

    • All applicable discounts SHOULD be applied to each row they pertain
      to and SHOULD NOT be negated in a separate row.
    • All discounts applied to a row MUST apply to the entire charge.
      • Multiple discounts MAY apply to a row, but they MUST apply to the
        entire charge covered by that row.
      • If a discount only applies to a portion of a charge, then the
        discounted portion of the charge MUST be split into a separate row.
      • Each discount MUST be identifiable using existing FOCUS columns.
        • Rows with a commitment-based discount applied to it 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.
    • ChargeSubCategory MUST NOT be null for rows where ChargeType is
      “Usage” and the row received reduced rates from a discount.
    • Purchased discounts (e.g., commitment-based discounts) MUST be
      amortized.

      • The BilledCost MUST be 0 for any row where the commitment covers the
        entire cost for the charge period.
      • The EffectiveCost MUST include the portion of the amortized purchase
        cost that applies to this row.
      • ChargeSubcategory MUST be “Used Commitment” for rows that received a
        reduced price from that commitment.
      • 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. ChargeSubcategory MUST be “Unused Commitment”.
      • The sum of the EffectiveCost for all “Used Commitment” and “Unused
        Commitment” rows for each CommitmentDiscountId over the entire duration
        of the commitment MUST be the same as the total BilledCost of the
        commitment-based discount.
    • Credits that are applied after the fact MUST use a ChargeType of
      “Adjustment” and ChargeSubcategory of “Credit”.

     

    3.4.5. Exceptions

    None

     

    3.4.6. Introduced (version)

    1.0  

    3.5. Key-Value Format

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

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

     

    3.5.1. Attribute ID

    KeyValueFormat

     

    3.5.2. Attribute Name

    Key-Value Format

     

    3.5.3. Description

    Rules and formatting requirements for columns appearing in billing
    data which 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 one of the following types: number,
      string, true, false, or
      null.
    • Values in a key-value pair MUST NOT be an object nor an array.

     

    3.5.5. Exceptions

    None

     

    3.5.6. Introduced (version)

    1.0  

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

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

     

    3.6.1. Attribute ID

    NullHandling

     

    3.6.2. Attribute Name

    Null Handling

     

    3.6.3. Description

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

     

    3.6.4. Requirements

    • Columns MUST use NULL when there isn’t a value that can be specified
      for a nullable column.
    • Columns MUST NOT use empty strings or placeholder values such as
      “Not Set” or “Not Applicable” in columns, regardless of if 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.
    Provider-generated numeric value capturing columns SHOULD adopt the same
    format requirements over time.

     

    3.7.1. Attribute ID

    NumericFormat

     

    3.7.2. Attribute name

    Numeric Format

     

    3.7.3. Description

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

     

    3.7.4. Requirements

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

      • Allowed values:

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

      • Allowed values:

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

     

    3.7.4.1. Examples

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

    • Values Meeting Numeric Requirements:

      • -100.2
      • -3
      • 4
      • 35.2E-7
      • 1.234
    • Values NOT Meeting Numeric Requirements

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

     

    3.7.5. Exceptions

    None

     

    3.7.6. Introduced (version)

    1.0  

    3.8. 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.8.1. Attribute ID

    UnitFormat

     

    3.8.2. Attribute Name

    Unit Format

     

    3.8.3. Description

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

     

    3.8.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
      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.8.4.1. Data Size Unit Names

    Data size unit names MUST be abbreviated using one of 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 an invalid unit name. Values that exceed
    10^18 MUST use the abbreviation for exabit, exabyte, exbibit, and
    exbibyte, and values smaller than a byte MUST use the abbreviation for
    bit or byte. For example, the abbreviation “YB” for “yottabyte” is not a
    valid data size unit name as it represents a value larger than what is
    listed in the following table.

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

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

     

    3.8.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 unit 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.8.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.8.4.4. Composite Units

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

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

     

    3.8.5. Exceptions

    None

     

    3.8.6. Introduced (version)

    1.0

     

    4. Use Case Library

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

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

    ChargePeriodStart
    ChargePeriodEnd

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

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

     

    5. 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 Usage Unit and Usage Quantity.

    Charge

    A row in a FOCUS compatible cost and usage dataset.

    Charge Period

    The time window in which a charge was incurred, inclusive of the
    start date and exclusive of the 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).

    Commitment

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

    Commitment-Based
    Discount

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

    Cloud Service Provider
    (CSP)

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

    Dimension

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

    Effective Cost

    Cost inclusive of the impacts of all reduced rates and discounts,
    augmented with the amortization of relevant purchases (one-time or
    recurring) paid to cover future eligible charges.

    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.

    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.

    Metric

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

    Managed Service
    Provider (MSP)

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

    On Demand

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

    Practitioner

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

    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 to one
    SKU. SKU Prices are usually referenced from provider’s price list and
    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.

     

    6. Appendix

    This section is non-normative.

     

    6.1. Grouping
    constructs for resources or services

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

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

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

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

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

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

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

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

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

Get Trained and Certified on FOCUS

Learn how FOCUS can accelerate FinOps at your organization.

Introduction to FOCUS

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

Take the Free course

FinOps Certified FOCUS Analyst

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

Learn more