Copyright © 2023-2025 – FinOps Open Cost and Usage Specification
(FOCUS) a Series of the Joint Development Foundation Projects, LLC.
Joint Development Foundation trademark,
and document use rules apply.
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.
Copyright (c) Joint Development Foundation Projects, LLC, FinOps Open
Cost and Usage Specification (FOCUS) Series and its contributors. The
materials in this repository are made available under the Creative
Commons Attribution 4.0 International license (CC-BY-4.0), available at
https://creativecommons.org/licenses/by/4.0/legalcode.
Shield: 
This work is made available under: Creative Commons
Attribution 4.0 International License.
THESE MATERIALS ARE PROVIDED “AS IS.” The parties expressly disclaim
any warranties (express, implied, or otherwise), including implied
warranties of merchantability, non-infringement, fitness for a
particular purpose, or title, related to the materials. The entire risk
as to implementing or otherwise using the materials is assumed by the
implementer and user. IN NO EVENT WILL THE PARTIES BE LIABLE TO ANY
OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL,
INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF
ACTION OF ANY KIND WITH RESPECT TO THIS DELIVERABLE OR ITS GOVERNING
AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING
NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER MEMBER HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This document is governed by the Patent Policy Option 4: W3C Mode:
See project
charter.
FOCUS is an open specification for billing data. It defines a common
schema for billing data, aligns terminology with the FinOps Framework
and defines a minimum set of requirements for billing data. The
specification provides clear guidelines 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.
Thanks to the following FOCUS Maintainers for their leadership and
contributions to the FOCUS Release v1.3
specification.
Thanks to the following FOCUS members for their contributions to the
FOCUS Release v1.3 specification.
Thanks to the following FOCUS Steering Committee members for their
leadership on the FOCUS specification.
This section is non-normative.
FOCUS is a standards development organization (SDO) formed to
establish an open, consensus-driven standard for billing data. In the
absence of a broadly adopted standard, infrastructure and service
[service providers](#glossary:service provider) have relied on
proprietary billing schemas and inconsistent terminology, making cost
data difficult to normalize and act upon across environments. This lack
of conformance has forced FinOps practitioners to develop
best-effort custom normalization schemes for each provider, in order to
perform essential FinOps capabilities such as chargeback, cost
allocation, budgeting and forecasting.
The FOCUS Specification, developed by a global community of
practitioners and vendors, defines a consistent, vendor-neutral approach
to billing data. It is designed to improve interoperability between
service providers, reduce operational complexity, and enable greater
transparency in cloud and SaaS cost management.
This project is supported by the FinOps Foundation. This work initially
started under the Open Billing working group under the FinOps
Foundation. The decision was made in Jan 2023 to begin to migrate the
work to a newly formed project under the Linux Foundation called the
FinOps Open Cost and Usage Specification (FOCUS) to better support the
creation of a specification.
This specification is designed to be used by three major groups:
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.
The following principles were considered while building the
specification.
The FOCUS Specification is designed to support evolving FinOps needs
across diverse billing models and service provider types.
While the initial focus was on billing data from Cloud Service
Providers (CSPs), version 1.2 introduces foundational support for
Software as a Service (SaaS) platforms, including normative columns for
pricing currencies, effective cost, and contracted pricing in
non-monetary units such as credits or tokens.
The specification supports extensibility through structured naming
conventions (e.g., x_ custom columns), conditional requirements, and a
version-aware schema approach.
Future versions of FOCUS will consider including additional FinOps
capabilities such as forecasting, exchange rate modeling, and anomaly
detection, while continuing to support a broader range of billing and
cost datasets — including internal infrastructure platforms and
marketplace offerings.
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.
Under each column defined in the FOCUS specification, there exists a
‘Feature level’ designation that describes the column as ‘Mandatory’,
‘Conditional’, or ‘Optional’. Feature level is designated based on the
following criteria described in the normative requirements in each
column definition:
Validation tools may be employed to determine conformance of data and
implementations per this specification.
The FinOps Foundation maintains a validator called the FOCUS
Validator which it uses for its own conformance assessments and
serves as a reference implementation to support validation
activities.
Other validation tools may be developed and made available by third
parties. The FOCUS specification does not mandate the use of any
particular tool, nor does it maintain a registry of available
validators.
The FOCUS specification is designed to meet the needs of FinOps
practitioners in numerous scenarios. The following section contains
features supported by the FOCUS specification. This list does not
represent all possible combinations or use of FOCUS data but does
represent core capabilities that the FOCUS specification supports.
Different service providers have different account constructs that
FinOps practitioners use for allocation, reporting, and more.
Organizations may have one or many accounts within one or more service
providers and FinOps practitioners may need to review the cost broken
down by each account. FOCUS has two types of accounts: a billing account
and a sub account.
A billing account is the account where invoices are generated. Each
billing account can have one or more sub accounts, which can be used for
deploying and managing resources and services. Billing and sub accounts
are often used to facilitate allocation strategies and FinOps
practitioners must be able to break costs down by billing and sub
account to facilitate FinOps scenarios like chargeback and
budgeting.
SELECT
BillingAccountId,
BillingAccountName,
BillingAccountType,
SubAccountId,
SubAccountName,
SubAccountType,
SUM(BilledCost)
FROM focus_data_table
WHERE BillingPeriodStart >= ? AND BillingPeriodEnd < ?
GROUP BY
BillingAccountId,
SubAccountId
FOCUS data should be consistent with the costs indicated on payable
invoices. This is relevant to the total cost of the invoice, as well as
the period of time the invoice covers.
SELECT
BillingPeriodStart,
BillingPeriodEnd,
InvoiceId,
SUM(BilledCost)
FROM focus_data_table
GROUP BY
BillingPeriodStart,
BillingPeriodEnd,
InvoiceId
FOCUS supports the categorization of charges including purchases,
usage, tax, credits and adjustments. It includes classification on
frequency. It includes classification on correction vs normal
entries.
SELECT
MIN(ChargePeriodStart) AS ChargePeriodStart,
MAX(ChargePeriodEnd) AS ChargePeriodEnd,
ServiceProviderName,
BillingAccountId,
CommitmentDiscountId,
CommitmentDiscountType,
CommitmentDiscountUnit,
CommitmentDiscountQuantity,
ChargeFrequency,
SUM(BilledCost) AS TotalBilledCost
FROM focus_data_table
WHERE ChargePeriodStart >= ? AND ChargePeriodEnd < ?
AND ChargeCategory = 'Purchase'
AND CommitmentDiscountId IS NOT NULL
GROUP BY
ServiceProviderName,
BillingAccountId,
CommitmentDiscountId,
CommitmentDiscountType,
CommitmentDiscountUnit,
CommitmentDiscountQuantity,
ChargeFrequency
SELECT
ServiceProviderName,
BillingAccountId,
ChargeCategory,
ServiceCategory,
ServiceName,
SUM(BilledCost) AS TotalBilledCost
FROM focus_data_table
WHERE BillingPeriodStart >= ? AND BillingPeriodEnd < ?
AND ChargeClass = 'Correction'
GROUP BY
ServiceProviderName,
BillingAccountId,
ChargeCategory,
ServiceCategory,
ServiceName
SELECT
BillingPeriodStart,
CommitmentDiscountId,
CommitmentDiscountName,
CommitmentDiscountType,
ChargeFrequency,
SUM(BilledCost) AS TotalBilledCost
FROM focus_data_table
WHERE BillingPeriodStart >= ? AND BillingPeriodStart < ?
AND ChargeFrequency = 'Recurring'
AND CommitmentDiscountId IS NOT NULL
GROUP BY
BillingPeriodStart,
CommitmentDiscountId,
CommitmentDiscountName,
CommitmentDiscountType,
ChargeFrequency
FOCUS supports the tracking of commitment discounts usage and under
usage, which can come in the form of commitment discounts or capacity
reservations.
SELECT
ServiceProviderName,
BillingAccountId,
CommitmentDiscountId,
CommitmentDiscountType,
CommitmentDiscountStatus,
SUM(BilledCost) AS TotalBilledCost,
SUM(EffectiveCost) AS TotalEffectiveCost
FROM focus_data_table
WHERE ChargePeriodStart >= ? AND ChargePeriodEnd < ?
AND CommitmentDiscountStatus = 'Unused'
GROUP BY
ServiceProviderName,
BillingAccountId,
CommitmentDiscountId,
CommitmentDiscountType
SELECT
ServiceProviderName,
BillingAccountId,
CapacityReservationId,
CapacityReservationStatus,
SUM(BilledCost) AS TotalBilledCost,
SUM(EffectiveCost) AS TotalEffectiveCost
FROM focus_data_table
WHERE ChargePeriodStart >= ? AND ChargePeriodEnd < ?
AND CapacityReservationStatus = 'Unused'
GROUP BY
ServiceProviderName,
BillingAccountId,
CapacityReservationId,
CapacityReservationStatus
FOCUS supports the tracking of commitments made via contractual
agreements between a service provider and a customer. Each row in the
Cost and Usage dataset is associated with one or more unique identifiers
representing those contracts and contract commitments, stored in a JSON
column called Contract Applied. A richer amount of detail that describes
those commitments is carried in a separate Contract Commitment dataset,
which can be joined to the Cost and Usage dataset to facilitate various
queries involving filtering and aggregation.
The Contract Applied column contains several FOCUS-defined
properties. For more information, see the definition of Contract Applied
here.
The FOCUS specification implements the application of contract
commitments to cost and usage via the ContractApplied column, which is
defined in JSON object
format.
Because ANSI SQL does not inherently support the parsing of JSON, the
following queries leverage the JSON functions found in BigQuery Standard
SQL in order to demonstrate this feature's functionality. Similar JSON
functions are available in all major SQL engines; thus, the below
examples can be slightly modified to accommodate any particular database
instance.
This query takes inputs of a time range via ChargePeriodStart and
ChargePeriodEnd, then presents the aggregation of initial contract
commitments from the CostAndUsage dataset per ServiceProviderName and
ContractCommitmentID by filtering on the specified time range, along
with ChargeCategory of Purchase.
SELECT
MIN(CU.ChargePeriodStart) AS ChargePeriodStart,
MAX(CU.ChargePeriodEnd) AS ChargePeriodEnd,
CU.ServiceProviderName,
JSON_VALUE(CA, '$.ContractCommitmentID') AS ContractCommitmentId,
SUM(CAST(JSON_VALUE(CA, '$.ContractCommitmentAppliedCost') AS FLOAT64)) AS ContractCommitmentAppliedCost
FROM CostAndUsage CU
CROSS JOIN
UNNEST(JSON_EXTRACT_ARRAY(CU.ContractApplied, '$.Elements')) AS CA
WHERE JSON_VALUE(CA, '$.ContractCommitmentAppliedCost') IS NOT NULL
AND ChargePeriodStart >= ? AND ChargePeriodEnd < ?
AND ChargeCategory = 'Purchase'
GROUP BY ServiceProviderName, ContractCommitmentId
ORDER BY ServiceProviderName, ContractCommitmentId
This query takes inputs of a time range via ChargePeriodStart and
ChargePeriodEnd, then presents the aggregation of the application of
contract commitments from the CostAndUsage dataset per
ServiceProviderName and ContractCommitmentID by filtering on the
specified time range, along with ChargeCategory of
Usage.
SELECT
MIN(CU.ChargePeriodStart) AS ChargePeriodStart,
MAX(CU.ChargePeriodEnd) AS ChargePeriodEnd,
CU.ServiceProviderName,
JSON_VALUE(CA, '$.ContractCommitmentID') AS ContractCommitmentId,
SUM(CAST(JSON_VALUE(CA, '$.ContractCommitmentAppliedCost') AS FLOAT64)) AS ContractCommitmentAppliedCost
FROM CostAndUsage CU
CROSS JOIN
UNNEST(JSON_EXTRACT_ARRAY(CU.ContractApplied, '$.Elements')) AS CA
WHERE JSON_VALUE(CA, '$.ContractCommitmentAppliedCost') IS NOT NULL
AND ChargePeriodStart >= ? AND ChargePeriodEnd < ?
AND ChargeCategory = 'Usage'
GROUP BY ServiceProviderName, ContractCommitmentId
ORDER BY ServiceProviderName, ContractCommitmentId
This query takes inputs of a time range via ChargePeriodStart and
ChargePeriodEnd, then presents the aggregation of the application of
contract commitments from the CostAndUsage dataset per
ServiceProviderName and ContractCommitmentID by filtering on the
specified time range, along with ChargeCategory of Usage.
It also joins in the ContractCommitment dataset to provide further
information about each contract commitment (in this case, the start and
end date/time).
SELECT
MIN(CU.ChargePeriodStart) AS ChargePeriodStart,
MAX(CU.ChargePeriodEnd) AS ChargePeriodEnd,
CU.ServiceProviderName,
JSON_VALUE(CA, '$.ContractCommitmentID') AS ContractCommitmentId,
CC.ContractCommitmentPeriodStart,
CC.ContractCommitmentPeriodEnd,
SUM(CAST(JSON_VALUE(CA, '$.ContractCommitmentAppliedCost') AS FLOAT64)) AS ContractCommitmentAppliedCost
FROM CostAndUsage CU
CROSS JOIN
UNNEST(JSON_EXTRACT_ARRAY(CU.ContractApplied, '$.Elements')) AS CA
INNER JOIN
ContractCommitment CC
ON
JSON_VALUE(CA, '$.ContractCommitmentID') = CC.ContractCommitmentID
WHERE JSON_VALUE(CA, '$.ContractCommitmentAppliedCost') IS NOT NULL
AND ChargePeriodStart >= ? AND ChargePeriodEnd < ?
AND ChargeCategory = 'Usage'
GROUP BY ServiceProviderName, ContractCommitmentId, ContractCommitmentPeriodStart, ContractCommitmentPeriodEnd
ORDER BY ServiceProviderName, ContractCommitmentId, ContractCommitmentPeriodStart, ContractCommitmentPeriodEnd
Many service providers have features that allow FinOps practitioners
to enrich cost and usage data with metadata that is in addition to
service provider defined data, in order to analyze FinOps data using
organizational, deployment, or other structures. These features may take
the form of directly applied metadata or inherited metadata. FOCUS
facilitates the inclusion of this metadata at a row level.
SELECT
tags,
ConsumedUnit,
SUM(BilledCost),
SUM(EffectiveCost),
SUM(ConsumedQuantity)
FROM focus_data_table
WHERE BillingPeriodStart >= ? AND BillingPeriodEnd < ?
GROUP BY
tags,
ConsumedUnit
FOCUS supports the comparison of cost columns in order to identify
savings, amortization, or other constructs.
WITH AggregatedData AS (
SELECT
ServiceProviderName,
BillingAccountId,
BillingAccountName,
BillingCurrency,
ServiceName,
SUM(EffectiveCost) AS TotalEffectiveCost,
SUM(BilledCost) AS TotalBilledCost,
SUM(CASE
WHEN ChargeCategory = 'Usage' AND BilledCost = 0 AND EffectiveCost != 0
THEN 0
ELSE ContractedCost
END) AS TotalContractedCost,
SUM(CASE
WHEN ChargeCategory = 'Usage' AND BilledCost = 0 AND EffectiveCost != 0
THEN 0
ELSE ListCost
END) AS TotalListCost
FROM focus_data_table
WHERE BillingPeriodStart >= ?
AND BillingPeriodEnd < ?
AND ChargeClass IS NULL
GROUP BY
ServiceProviderName,
BillingAccountId,
BillingAccountName,
BillingCurrency,
ServiceName
)
SELECT ServiceProviderName,
BillingAccountId,
BillingAccountName,
BillingCurrency,
ServiceName,
TotalEffectiveCost,
TotalBilledCost,
TotalListCost,
1 - (TotalContractedCost / NULLIF(TotalListCost, 0)) * 100 AS ContractedDiscount,
1 - (TotalEffectiveCost / NULLIF(TotalListCost, 0)) * 100 AS EffectiveDiscount
FROM AggregatedData
FOCUS supports the inclusion of custom columns to facilitate
reporting capability that is not covered by the columns included in the
specification.
SELECT
BillingPeriodStart,
x_CustomColumn,
SUM(BilledCost) AS TotalBilledCost,
FROM focus_data_table
WHERE ServiceName = ?
AND BillingPeriodStart >= ? AND BillingPeriodStart < ?
GROUP BY
BillingPeriodStart,
x_CustomColumn
ORDER BY MonthlyCost DESC
FOCUS enables tracking of resources split by some internal
consumption metrics. This is most common for resources supporting shared
usage like compute nodes in a shared cluster (Kubernetes, databases) or
storage engines that can share capacity between workloads.
SELECT
DISTINCT ResourceId
FROM focus_data_table
WHERE ChargeCategory='Usage'
AND ChargePeriodStart >= ? AND ChargePeriodEnd <= ?
AND AllocatedMethodId IS NOT NULL
SELECT
ResourceId,
SUM(EffectiveCost) AS TotalEffectiveCost
FROM focus_data_table
WHERE ChargeCategory='Usage'
AND ChargePeriodStart >= ? AND ChargePeriodEnd <= ?
AND AllocatedMethodId IS NOT NULL
GROUP BY
ResourceId
SELECT
AllocatedResourceId,
SUM(EffectiveCost) AS TotalEffectiveCost
FROM focus_data_table
WHERE ChargeCategory='Usage'
AND ChargePeriodStart >= ? AND ChargePeriodEnd <= ?
AND AllocatedMethodId IS NOT NULL
GROUP BY
AllocatedResourceId
SELECT
ResourceId,
SUM(EffectiveCost) AS TotalEffectiveCost
FROM focus_data_table
WHERE ChargeCategory='Usage'
AND ChargePeriodStart >= ? AND ChargePeriodEnd <= ?
AND AllocatedMethodId IS NOT NULL AND AllocatedResourceId IS NULL
GROUP BY
ResourceId
SELECT
ResourceId,
COALESCE(AllocatedResourceId, 'Unallocated') AS AllocatedResourceId,
SUM(EffectiveCost) AS TotalEffectiveCost
FROM focus_data_table
WHERE ChargeCategory='Usage'
AND ChargePeriodStart >= ? AND ChargePeriodEnd <= ?
AND AllocatedResourceId = ?
GROUP BY
ResourceId,
COALESCE(AllocatedResourceId, 'Unallocated')
SELECT
resource_id,
elements.allocated_ratio,
elements.usage_unit,
elements.usage_quantity
FROM
focus_data_table,
JSON_TABLE(
AllocatedMethodDetails,
'$.Elements[*]' COLUMNS (
allocated_ratio DECIMAL(10, 2) PATH '$.AllocatedRatio',
usage_unit VARCHAR(50) PATH '$.UsageUnit',
usage_quantity DECIMAL(10, 2) PATH '$.UsageQuantity'
)
) AS elements
FOCUS supports multiple levels of cost and usage data granularity.
This includes the ability to report on a daily, hourly, or other time
period basis. FOCUS also supports the ability for cost and usage data to
be provided for high granularity scenarios, such as down to the
individual resources. It also supports high level granularity cost and
usage data, such as account level, or service level charges.
SELECT
ChargePeriodStart,
ChargePeriodEnd,
ResourceId,
SUM(EffectiveCost)
FROM focus_data_table
Group by
ChargePeriodStart,
ChargePeriodEnd,
ResourceId
FOCUS supports the ability for data generators to provide metadata
that describes information about the dataset artifacts they
provide. This includes properties such as the name of the dataset instance, the
unique identifier of the dataset instance, and the FOCUS dataset that it aligns
with. This metadata can be used by consumers to understand the context
of the data they are receiving, and to ensure that they are working with
the correct dataset instance to execute their particular FinOps use
cases.
FOCUS enables practitioners to analyze costs without having to
distribute upfront fees and discounts, taking discounts and the
amortization of upfront fees paid for services into account. The
EffectiveCost column represents cost after negotiated discounts,
commitment discounts, and the applicable portion of relevant, prepaid
purchases (one-time or recurring) that covered this charge.
EffectiveCost is commonly utilized to track and analyze spending
trends.
SELECT
ServiceProviderName,
BillingPeriodStart,
BillingPeriodEnd,
ServiceCategory,
ServiceName,
RegionId,
RegionName,
PricingUnit,
SUM(EffectiveCost) AS TotalEffectiveCost,
SUM(PricingQuantity) AS TotalPricingQuantity
FROM focus_data_table
WHERE BillingPeriodStart >= ? AND BillingPeriodEnd <= ?
GROUP BY
ServiceProviderName,
BillingPeriodStart,
BillingPeriodEnd,
ServiceCategory,
ServiceName,
RegionId,
RegionName,
PricingUnit
FOCUS provides structured location data through region and
availability zone information. By documenting geographic deployment
locations, practitioners can organize and analyze costs based on where
resources and services are deployed. This standardized location data
helps practitioners understand the geographical distribution of
infrastructure across host providers.
SELECT
RegionId,
RegionName,
AvailabilityZone,
SUM(BilledCost) AS TotalBilledCost
FROM focus_data_table
WHERE ChargePeriodStart >= ? AND ChargePeriodEnd <= ?
GROUP BY
RegionId,
RegionName,
AvailabilityZoneFOCUS supports the analysis of cost and usage data for marketplace
purchases and their associated costs. It also supports the reporting of
EffectiveCost for usage from the service provider.
SELECT
ServiceProviderName,
InvoiceIssuerName,
BillingPeriodStart,
BillingPeriodEnd,
SUM(BilledCost) AS TotalBilledCost
FROM focus_data_table
WHERE ServiceProviderName = ''
AND InvoiceIssuerName = ''
GROUP BY
ServiceProviderName,
InvoiceIssuerName,
BillingPeriodStart,
BillingPeriodEnd
SELECT
ChargePeriodStart,
ChargePeriodEnd,
ResourceId,
SUM(EffectiveCost) AS TotalEffectiveCost
FROM focus_data_table
WHERE InvoiceIssuerName = ''
GROUP BY
ChargePeriodStart,
ChargePeriodEnd,
ResourceId
FOCUS supports the ability for data generators to provide metadata
indicating 1) what portion of a FOCUS dataset artifact is complete
(either in total, or per time sector), and 2) how recently it has been
updated. This metadata allows practitioners to understand whether a
given subset of FOCUS data is subject to further change, which informs
when and whether they can perform various FinOps functions such as
chargeback.
FOCUS enables tracking of resource consumption by providing
information about which resources were used, in what quantities, and
with what units of measure.
SELECT
ServiceProviderName,
ServiceName,
ResourceId,
SkuId,
ConsumedUnit,
SUM(ConsumedQuantity) AS TotalQuantity
FROM focus_data_table
WHERE ChargeCategory='Usage'
AND ChargePeriodStart >= ? AND ChargePeriodEnd <= ?
GROUP BY
ServiceProviderName,
ServiceName,
ResourceId,
SkuId,
ConsumedUnit
FOCUS' schema metadata supports communication of important attributes
about the data, facilitating notifications about changing structure and
database table creation between data generator and consumer. This
includes column names, data types, and any other relevant information
about the data schema. It also includes information as to the version of
FOCUS and Data Generator versioning that the data uses.
FOCUS supports service providers specifying the services and product
offerings that they provide their customers that align with the names
practitioners are familiar with. This empowers practitioners to analyze
cost by service, report service costs by subaccount, forecast based on
historical trends by service, and verify accuracy of services charged
across service providers.
SELECT
BillingPeriodStart,
ServiceProviderName,
SubAccountId,
SubAccountName,
ServiceName,
SUM(BilledCost) AS TotalBilledCost,
SUM(EffectiveCost) AS TotalEffectiveCost
FROM focus_data_table
WHERE ServiceName = ?
AND BillingPeriodStart >= ? AND BillingPeriodStart < ?
GROUP BY
BillingPeriodStart,
ServiceProviderName,
SubAccountId,
SubAccountName,
ServiceName
ORDER BY MonthlyCost DESC
FOCUS provides a structure for categorizing services based on their
core functions. By classifying services into high-level categories and
more granular subcategories, practitioners can organize costs according
to functional areas. This standardized categorization provides data that
practitioners can use in their cost management processes and decision
making.
SELECT
BillingPeriodStart,
BillingPeriodEnd,
ServiceProviderName,
ServiceCategory,
ServiceSubcategory,
ServiceName,
BillingCurrency,
SUM(BilledCost) AS TotalBilledCost
FROM focus_data_table
WHERE BillingPeriodStart >= ? and BillingPeriodEnd < ?
GROUP BY
BillingPeriodStart,
BillingPeriodEnd,
ServiceProviderName,
ServiceCategory,
ServiceSubcategory,
ServiceName,
BillingCurrency
FOCUS allows practitioners to identify the several participating
entities involved in resource or service hosting, invoicing, and data
generation. The FOCUS Specification includes multiple columns to
identify key participating entities, including Service Provider Name,
Invoice Issuer Name, Host Provider Name, and Data Generator.
SELECT
BillingPeriodStart,
BillingPeriodEnd,
ServiceProviderName,
InvoiceIssuerName,
HostProviderName,
ServiceName,
BillingCurrency,
SUM(BilledCost) AS TotalBilledCost
FROM focus_data_table
WHERE BillingPeriodStart >= ? and BillingPeriodEnd < ?
GROUP BY
BillingPeriodStart,
BillingPeriodEnd,
ServiceProviderName,
InvoiceIssuerName,
HostProviderName,
ServiceName,
BillingCurrency
1.1
When a service provider supports unit pricing concepts, FOCUS allows
practitioners to:
SELECT DISTINCT
SkuId,
SkuPriceId,
SkuPriceDetails,
BillingPeriodId,
ChargePeriodStart,
ChargePeriodEnd,
BillingCurrency,
ListUnitPrice,
ContractedUnitPrice
FROM focus_data_table
WHERE
SkuPriceId = ?
AND ChargePeriodStart >= ?
AND ChargePeriodEnd < ?
1.0
FOCUS defines many individual datasets made up of a selected set of
columns which abide by the attributes outlined in this FOCUS
Specification.
The Cost and Usage dataset is the primary dataset for FOCUS cost and
usage data.
The specification for the Cost and Usage dataset defines a group of
columns that provide qualitative values (such as dates, resource, and
service 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.
| Column | Column Type | Feature Level | Allows Nulls | Data Type |
|---|---|---|---|---|
| Allocated Method Details | Dimension | Recommended | True | JSON |
| Allocated Method ID | Dimension | Conditional | True | String |
| Allocated Resource ID | Dimension | Conditional | True | String |
| Allocated Resource Name | Dimension | Conditional | True | String |
| Allocated Tags | Dimension | Conditional | True | JSON |
| Availability Zone | Dimension | Recommended | True | String |
| Billed Cost | Metric | Mandatory | False | Decimal |
| Billing Account ID | Dimension | Mandatory | False | String |
| Billing Account Name | Dimension | Mandatory | True | String |
| Billing Account Type | Dimension | Conditional | False | String |
| Billing Currency | Dimension | Mandatory | False | String |
| Billing Period End | Dimension | Mandatory | False | Date/Time |
| Billing Period Start | Dimension | Mandatory | False | Date/Time |
| Capacity Reservation ID | Dimension | Conditional | True | String |
| Capacity Reservation Status |
Dimension | Conditional | True | String |
| Charge Category | Dimension | Mandatory | False | String |
| Charge Class | Dimension | Mandatory | True | String |
| Charge Description | Dimension | Mandatory | True | String |
| Charge Frequency | Dimension | Recommended | False | String |
| Charge Period End | Dimension | Mandatory | False | Date/Time |
| Charge Period Start | Dimension | Mandatory | False | Date/Time |
| Commitment Discount Category |
Dimension | Conditional | True | String |
| Commitment Discount ID | Dimension | Conditional | True | String |
| Commitment Discount Name | Dimension | Conditional | True | String |
| Commitment Discount Quantity |
Metric | Conditional | True | Decimal |
| Commitment Discount Status |
Dimension | Conditional | True | String |
| Commitment Discount Type | Dimension | Conditional | True | String |
| Commitment Discount Unit | Dimension | Conditional | True | String |
| Consumed Quantity | Metric | Conditional | True | Decimal |
| Consumed Unit | Dimension | Conditional | True | String |
| Contract Applied | Dimension / Metric | Conditional | True | JSON |
| Contracted Cost | Metric | Mandatory | False | Decimal |
| Contracted Unit Price | Metric | Conditional | True | Decimal |
| Effective Cost | Metric | Mandatory | False | Decimal |
| Host Provider Name | Dimension | Mandatory | False | String |
| Invoice ID | Dimension | Recommended | True | String |
| Invoice Issuer Name | Dimension | Mandatory | False | String |
| List Cost | Metric | Mandatory | False | Decimal |
| List Unit Price | Metric | Conditional | True | Decimal |
| Pricing Category | Dimension | Conditional | True | String |
| Pricing Currency | Dimension | Conditional | True | String |
| Pricing Currency Contracted Unit Price |
Metric | Conditional | True | Decimal |
| Pricing Currency Effective Cost |
Metric | Conditional | True | Decimal |
| Pricing Currency List Unit Price |
Metric | Conditional | True | Decimal |
| Pricing Quantity | Metric | Mandatory | True | Decimal |
| Pricing Unit | Dimension | Mandatory | True | String |
| Provider - DEPRECATED | Dimension | Mandatory | False | String |
| Publisher - DEPRECATED | Dimension | Mandatory | False | String |
| Region ID | Dimension | Conditional | True | String |
| Region Name | Dimension | Conditional | True | String |
| Resource ID | Dimension | Conditional | True | String |
| Resource Name | Dimension | Conditional | True | String |
| Resource Type | Dimension | Conditional | True | String |
| Service Category | Dimension | Mandatory | False | String |
| Service Name | Dimension | Mandatory | False | String |
| Service Provider Name | Dimension | Mandatory | False | String |
| Service Subcategory | Dimension | Recommended | False | String |
| SKU ID | Dimension | Conditional | True | String |
| SKU Meter | Dimension | Conditional | True | String |
| SKU Price Details | Dimension | Conditional | True | JSON |
| SKU Price ID | Dimension | Conditional | True | String |
| Sub Account ID | Dimension | Conditional | True | String |
| Sub Account Name | Dimension | Conditional | True | String |
| Sub Account Type | Dimension | Conditional | True | String |
| Tags | Dimension | Conditional | True | JSON |
The Cost and Usage dataset can be joined to the Contract Commitment
dataset through the use of the Contract Commitment ID.
| Dataset A | Dataset A Column | Dataset B | Dataset B Column |
|---|---|---|---|
| Cost and Usage | Contract Applied | Contract Commitment | Contract Commitment ID |
CostAndUsage adheres to the following requirements:
CostAndUsage
Cost and Usage
Describes the cost and usage incurred through using or purchasing a
service provider's resources
or services.
Allocated Method ID is the unique identifier for the allocated method defined by the
service provider which was used for the Data
Generator-Calculated Split Cost Allocation. This unique identifier
can be used to find how the allocated charge was calculated in
the provider's documentation.
AllocatedMethodId adheres to the following requirements:
AllocatedMethodId
Allocated Method ID
A unique identifier defining the method of data generator-calculated
split cost allocation.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
Allocated Method Details provides information about how resources are
allocated when usage records are split to support cost allocation
requirements.
Allocated Method Details consists of a valid JSON object which
contains an array consisting of key-value objects describing the one or
more factors that determined the split cost allocation. Each object
consists of FOCUS-defined keys but can be extended to provide additional
details about the allocation.
The FOCUS-defined properties are:
Allocated Ratio: The ratio of a charge that this allocationUsage Unit: Unit being measured used to calculate thisUsage Quantity: The quantity of units used denominatedIn addition to these, a data generator may include one or more custom
properties, also denoted as key-value pairs.
The AllocatedMethodDetails column adheres to the following
requirements:
Allocated Method Details consists of a valid JSON object which
contains an array of key-value objects describing the one or more
factors (allocation properties) that determined the split cost
allocation. Each object consists of FOCUS-defined keys but can be
extended to provide additional details about the allocation.
When AllocatedMethodDetails is not null, the JsonObjectFormat for
AllocatedMethodDetails adheres to the following requirements:
The following keys are used for allocation properties to facilitate
querying data across allocations and across data generators.
Focus-defined keys will appear in the list below and data
generator-defined keys will be prefixed with "x_" to make them easy to
identify as well as prevent collisions.
Allocated Ratio
Allocated Ratio communicates the percentage of the Origin Charge that this Allocated Charge derived
from the corresponding Allocated Method
Id and Usage Unit property.
The "AllocatedRatio" property adheres to the following
requirements:
Usage Unit
Usage Unit communicates the aspect of the documented Allocation
Method Id being used to calculate the Allocated Ratio property and what
is being measured by Usage Quantity property.
The "UsageUnit" property adheres to the following requirements:
Usage Quantity
Usage Quantity communicates the volume that was consumed or used,
denominated in the Usage Unit property value.
The "UsageQuantity" property adheres to the following
requirements:
The parent array is called Elements and contains one or
more objects which communicate information about how an allocated record
was calculated.
| Key | ValueType | Required | Description |
|---|---|---|---|
| Elements | Array | True | The parent array containing one or more objects which communicate information about how an allocated record was calculated. |
The Elements array contains one or more objects, each of
which contains the following entries:
| Key | ValueType | Required | Description |
|---|---|---|---|
| AllocatedRatio | Numeric | True | Percentage of overall cost derived from corresponding method and metric. |
| UsageUnit | String | Conditional | Unit being measured used to calculate allocation. |
| UsageQuantity | Numeric | False | Volume of UsageUnit consumed or used. |
{
"Elements" : [ {
"AllocatedRatio" : 0.05,
"UsageUnit" : "CPU",
"UsageQuantity" : 0.5
}, {
"AllocatedRatio" : 0.1,
"UsageUnit" : "Memory",
"UsageQuantity" : 4
} ]
}{
"properties": {
"Elements": {
"elements": {
"properties": {
"AllocatedRatio": { "type": "float64" }
},
"optionalProperties": {
"UsageUnit": { "type": "string" },
"UsageQuantity": { "type": "float64" }
},
"additionalProperties": true
}
}
},
"additionalProperties": true
}NOTE: The above JSON Type Definition (JTD) is an approximation of the
expected contents of this column, but it should not be considered
normative because it cannot accurately describe the normative
requirements (above) for AllocatedMethodDetails. Where there are
discrepancies, deference will be given to the normative requirements.
For example, NumericFormat allows for
multiple numeric data types and precisions, but JTD requires both to be
specified; other numeric data types and precisions allowable under
NumericFormat are considered valid.
The JSON samples in the scenarios below each represent a single
allocated record out of the multiple records derived from an origin
record for that scenario. The sum AllocatedRatio will add up to 1 (100%)
across all allocated records for an origin record, with the
AllocatedRatio (or sum of AllocatedRatio) representing the allocated
record's portion of the overall origin record.
<a class="toc-anchor"
name="scenario1:single"usageunit"valueusedforallocation">
When only a single "UsageUnit" is used to calculate the
allocation.
{
"Elements" : [ {
"AllocatedRatio" : 0.1,
"UsageUnit" : "Hours",
"UsageQuantity" : 300
}
]
}<a class="toc-anchor"
name="scenario2:multiple"usageunit"valuesusedforallocation">
When multiple "UsageUnit" values are used to calculate the
allocation, another object is added to the "Elements" collection.
{
"Elements": [
{
"AllocatedRatio": 0.05,
"UsageUnit": "CPU",
"UsageQuantity": 0.5
},
{
"AllocatedRatio": 0.1,
"UsageUnit": "Memory",
"UsageQuantity": 4
}
]
}This data generator does not wish to supply the "UsageUnit" or
"UsageQuantity" keys but still provides cost allocation with some
additional allocation method details. In this case, "UsageUnit" and
"UsageQuantity" are omitted, and only the "AllocatedRatio" is
supplied.
{
"Elements" : [ {
"AllocatedRatio" : 0.45
}
]
}A data generator can add additional properties if they feel more
context is helpful or necessary to the practitioner. In this scenario,
the data generator is supplying additional context that shows only 0.5
of a unit was used. However, since 1 unit was requested by the service
this allocation represents, the allocation is being charged at 1
regardless.
{
"Elements": [
{
"AllocatedRatio": 0.6,
"UsageUnit": "vCPU",
"UsageQuantity": 1,
"x_ReservedVCPU": 1,
"x_UsedVCPU": 0.5,
"x_AllocatedVCPU": 1
}
]
}AllocatedMethodDetails
Allocated Method Details
A set of properties describing how resources are allocated in data
generator-defined split cost allocation.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Recommended |
| Allows nulls | True |
| Data type | JSON |
| Value format | JSON Object Format |
An Allocated Resource ID is an identifier assigned by the data
generator which cost is being allocated to in a Data
Generator-Calculated Split Cost Allocation. The Allocated Resource
ID is used to understand what the cost is being allocated to in charges where the data generator is
allocating costs to something other than the charge's ResourceID, as is the case for allocated charges.
AllocatedResourceId adheres to the following requirements:
AllocatedResourceId
Allocated Resource ID
The identifier of the object to which cost is allocated in data
generator-calculated split cost allocation.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
The Allocated Resource Name is a display name which cost is being
allocated to in a Data
Generator-Calculated Split Cost Allocation. The Allocated Resource
Name is used to understand what the cost is being allocated to in charges where the service provider
is allocating costs to something other than the charge's ResourceID, as is the case for allocated charges.
AllocatedResourceName adheres to the following requirements:
AllocatedResourceName
Allocated Resource Name
The display name of the object to which cost is allocated in data
generator-calculated split cost allocation.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
The Allocated Tags column represents the set of tags assigned to tag sources which are
specifically applicable to allocated charges
resulting from a data generator-calculated split cost allocation.
AllocatedTags adheres to the following requirements:
This example illustrates various tags produced from multiple
user-defined and data generator-defined tag schemes. The first two tags
illustrate examples from two different, user-defined tag schemes. The
second tag is produced from a valueless, user-defined tag scheme, so the
data generator also applies true as its default value.
The last two tags illustrate examples from two different, data
generator-defined tag schemes.
{
"userDefinedTagScheme1/foo": "bar",
"userDefinedTagScheme2/foo": true,
"providerDefinedTagScheme1/foo": "bar",
"providerDefinedTagScheme2/foo": "bar"
}AllocatedTags
Allocated Tags
A set of tags assigned to tag sources that are applicable to
allocated charges in data generator-calculated split cost
allocation.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | JSON |
| Value format | Key-Value Format |
An availability
zone is a host-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.
AvailabilityZone adheres to the following requirements:
AvailabilityZone
Availability Zone
A host-provider-assigned identifier for a physically separated and
isolated area within a Region that provides high availability and fault
tolerance.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Recommended |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
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.
BilledCost adheres to the following requirements:
BilledCost
Billed Cost
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).
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Decimal |
| Value format | Numeric Format |
| Number range | Any valid decimal value |
A Billing Account ID is an invoice-issuer-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.
BillingAccountId adheres to the following requirements:
See Appendix:
Grouping constructs for resources or services for details and
examples of the different grouping constructs supported by FOCUS.
BillingAccountId
Billing Account ID
The identifier assigned to a billing account by the invoice
issuer.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
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.
BillingAccountName adheres to the following requirements:
See Appendix:
Grouping constructs for resources or services for details and
examples of the different grouping constructs supported by FOCUS.
BillingAccountName
Billing Account Name
The display name assigned to a billing account.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
Billing Account Type is an invoice-issuer-assigned name to identify
the type of billing
account. Billing Account Type is a readable display name and
not a code. Billing Account Type is commonly used for scenarios like
mapping FOCUS and provider constructs, summarizing costs across
providers, or invoicing and chargeback.
BillingAccountType adheres to the following requirements:
BillingAccountType
Billing Account Type
An invoice-issuer-assigned name to identify the type of billing
account.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
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.
BillingCurrency adheres to the following requirements:
BillingCurrency
Billing Currency
Represents the currency that a charge was billed in.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | Currency Format |
Billing Period End represents the exclusive end bound of a
billing period. For
example, a time period where Billing
Period Start is '2024-01-01T00:00:00Z' and Billing Period End is
'2024-02-01T00:00:00Z' includes charges for January since Billing
Period Start represents the inclusive start bound,
but does not include charges for February since Billing Period
End represents the exclusive end bound.
BillingPeriodEnd adheres to the following requirements:
BillingPeriodEnd
Billing Period End
The exclusive end bound of a billing period.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Date/Time |
| Value format | Date/Time Format |
Billing Period Start represents the inclusive start bound
of a billing period. For
example, a time period where Billing Period Start is
'2024-01-01T00:00:00Z' and Billing Period
End is '2024-02-01T00:00:00Z' includes charges for January since Billing
Period Start represents the inclusive start bound, but does not
include charges for February since BillingPeriodEnd represents
the exclusive end
bound.
BillingPeriodStart adheres to the following requirements:
BillingPeriodStart
Billing Period Start
The inclusive start bound of a billing period.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Date/Time |
| Value format | Date/Time Format |
A Capacity Reservation ID is the identifier assigned to a capacity reservation
by the service provider. Capacity Reservation ID is commonly used for
scenarios to allocate charges
for capacity reservation usage.
CapacityReservationId adheres to the following requirements:
CapacityReservationId
Capacity Reservation ID
The identifier assigned to a capacity reservation by the
service provider.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
Capacity Reservation Status indicates whether the charge represents either the
consumption of the capacity
reservation identified in the CapacityReservationId column or
when the capacity reservation is unused.
CapacityReservationStatus adheres to the following requirements:
CapacityReservationStatus
Capacity Reservation Status
Indicates whether the charge represents either the
consumption of a capacity reservation or when a capacity
reservation is unused.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | Allowed Values |
Allowed values:
| Value | Description |
|---|---|
| Used | Charges that utilized a specific amount of a capacity reservation. |
| Unused | Charges that represent the unused portion of a capacity reservation. |
Charge Category represents the highest-level classification of a charge based on the nature of how
it is billed. Charge Category is commonly used to identify and
distinguish between types of charges that may require different
handling.
ChargeCategory adheres to the following requirements:
ChargeCategory
Charge Category
Represents the highest-level classification of a charge
based on the nature of how it is billed.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | Allowed values |
Allowed values:
| Value | Description |
|---|---|
| Usage | Positive or negative charges based on the quantity of a service or resource that was consumed over a given period of time including refunds. |
| Purchase | Positive or negative charges for the acquisition of a service or resource bought upfront or on a recurring basis including refunds. |
| Tax | Positive or negative applicable taxes that are levied by the relevant authorities including refunds. Tax charges may vary depending on factors such as the location, jurisdiction, and local or federal regulations. |
| Credit | Positive or negative charges granted by the service provider for various scenarios e.g promotional credits or corrections to promotional credits. |
| Adjustment | Positive or negative charges the service provider applies that do not fall into other category values. |
Charge Class indicates whether the row represents a correction to a
previously invoiced billing
period. Charge Class is commonly used to differentiate corrections from regularly
incurred charges.
ChargeClass adheres to the following requirements:
ChargeClass
Charge Class
Indicates whether the row represents a correction to a
previously invoiced billing period.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | True |
| Data type | String |
| Value format | Allowed values |
Allowed values:
| Value | Description |
|---|---|
| Correction | Correction to a previously invoiced billing period (e.g., refunds and credit modifications). |
1.0
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.
ChargeDescription adheres to the following requirements:
ChargeDescription
Charge Description
Self-contained summary of the charge's purpose and
price.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
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.
ChargeFrequency adheres to the following requirements:
ChargeFrequency
Charge Frequency
Indicates how often a charge will occur.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Recommended |
| Allows nulls | False |
| Data type | String |
| Value format | Allowed values |
Allowed values:
| Value | Description |
|---|---|
| One-Time | Charges that only happen once and will not repeat. One-time charges are typically recorded on the hour or day when the cost was incurred. |
| Recurring | Charges that repeat on a periodic cadence (e.g., weekly, monthly) regardless of whether the product or service was used. Recurring charges typically happen on the same day or point within every period. The charge date does not change based on how or when the service is used. |
| Usage-Based | Charges that repeat every time the service is used. Usage-based charges are typically recorded hourly or daily, based on the granularity of the cost data for the period when the service was used (referred to as charge period). Usage-based charges are not recorded when the service is not used. |
Charge Period End represents the exclusive end bound of a
charge period. For
example, a time period where Charge Period
Start is '2024-01-01T00:00:00Z' and Charge Period End is
'2024-01-02T00:00:00Z' includes charges for January 1 since Charge
Period Start represents the inclusive start bound,
but does not include charges for January 2 since Charge Period
End represents the exclusive end bound.
ChargePeriodEnd adheres to the following requirements:
ChargePeriodEnd
Charge Period End
The exclusive end bound of a charge period.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Date/Time |
| Value format | Date/Time Format |
Charge Period Start represents the inclusive start bound
of a charge period. For
example, a time period where Charge Period Start is
'2024-01-01T00:00:00Z' and Charge Period
End is '2024-01-02T00:00:00Z' includes charges for January 1 since Charge
Period Start represents the inclusive start bound, but does not
include charges for January 2 since Charge Period End
represents the exclusive end
bound.
ChargePeriodStart adheres to the following requirements:
ChargePeriodStart
Charge Period Start
The inclusive start bound of a charge period.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Date/Time |
| Value format | Date/Time Format |
Commitment Discount Category indicates whether the commitment discount
identified in the CommitmentDiscountId column is based on usage quantity
or cost (aka "spend"). The CommitmentDiscountCategory column is only
applicable to commitment discounts and not negotiated
discounts.
CommitmentDiscountCategory adheres to the following requirements:
CommitmentDiscountCategory
Commitment Discount Category
Indicates whether the commitment discount identified in the
CommitmentDiscountId column is based on usage quantity or cost (aka
"spend").
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | Allowed Values |
Allowed values:
| Value | Description |
|---|---|
| Spend | Commitment discounts that require a predetermined amount of spend. |
| Usage | Commitment discounts that require a predetermined amount of usage. |
A Commitment Discount ID is the identifier assigned to a commitment discount by
the service provider. Commitment Discount ID is commonly used for
scenarios like chargeback for commitments and savings per
commitment discount. The CommitmentDiscountId column is only
applicable to commitment discounts and not negotiated
discounts.
CommitmentDiscountId adheres to the following requirements:
CommitmentDiscountId
Commitment Discount ID
The identifier assigned to a commitment discount by the
service provider.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
A Commitment Discount Name is the display name assigned to a commitment discount.
The CommitmentDiscountName column is only applicable to commitment
discounts and not negotiated
discounts.
CommitmentDiscountName adheres to the following requirements:
CommitmentDiscountName
Commitment Discount Name
The display name assigned to a commitment discount.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
Commitment Discount Quantity is the amount of a commitment discount
purchased or accounted for in commitment discount related rows that is denominated in Commitment Discount Units. The
aggregated Commitment Discount Quantity across purchase records,
pertaining to a particular Commitment
Discount ID during its commitment period, represents the total
Commitment Discount Units acquired with that commitment discount. For
committed usage, the Commitment Discount Quantity is either the number
of Commitment Discount Units consumed by a row that is covered
by a commitment discount or is the unused portion of a
commitment discount over a charge period. Commitment
Discount Quantity is commonly used in commitment discount
analysis and optimization use cases and only applies to commitment
discounts, not negotiated
discounts.
When CommitmentDiscountCategory is
"Usage" (usage-based commitment discounts), the Commitment
Discount Quantity reflects the predefined amount of usage purchased or
consumed. If commitment discount
flexibility is applicable, this value may be further
transformed based on additional, service-provider-specific requirements.
When CommitmentDiscountCategory is "Spend" (spend-based commitment
discounts), the Commitment Discount Quantity reflects the
predefined amount of spend purchased or consumed. See Appendix: Commitment Discount
Flexibility for more details around commitment discount
flexibility.
CommitmentDiscountQuantity adheres to the following requirements:
CommitmentDiscountQuantity
Commitment Discount Quantity
The amount of a commitment discount purchased or accounted
for in commitment discount related rows that is
denominated in Commitment Discount Units.
Aggregation: When aggregating Commitment Discount
Quantity for commitment utilization calculations, it's important to
exclude commitment
discount purchases (i.e. when Charge Category is "Purchase")
that are paid to cover future eligible charges (e.g., commitment
discount). Otherwise, when accounting for all upfront or accrued
purchases, it's important to exclude commitment discount usage
(i.e. when Charge Category is "Usage"). This exclusion helps prevent
double counting of these quantities in the aggregation.
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | Decimal |
| Value format | Numeric Format |
| Number range | Any valid decimal value |
Commitment Discount Status indicates whether the charge corresponds with the
consumption of a commitment
discount identified in the CommitmentDiscountId column or the
unused portion of the committed amount. The CommitmentDiscountStatus
column is only applicable to commitment discounts and not negotiated
discounts.
CommitmentDiscountStatus adheres to the following requirements:
CommitmentDiscountStatus
Commitment Discount Status
Indicates whether the charge corresponds with the
consumption of a commitment discount or the unused portion of
the committed amount.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | Allowed Values |
Allowed values:
| Value | Description |
|---|---|
| Used | Charges that utilized a specific amount of a commitment discount. |
| Unused | Charges that represent the unused portion of the commitment discount. |
Commitment Discount Type is a service-provider-assigned name to
identify the type of commitment discount
applied to the row. The
CommitmentDiscountType column is only applicable to commitment
discounts and not negotiated
discounts.
CommitmentDiscountType adheres to the following requirements:
CommitmentDiscountType
Commitment Discount Type
A service-provider-assigned identifier for the type of commitment
discount applied to the row.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
Commitment Discount Unit represents the service-provider-specified
measurement unit indicating how a service provider measures the Commitment Discount Quantity of a
commitment
discount. The CommitmentDiscountUnit column is only applicable
to commitment discounts and not negotiated
discounts.
CommitmentDiscountUnit adheres to the following requirements:
See Examples: Commitment
Discount Flexibility for more details around commitment discount
flexibility.
CommitmentDiscountUnit
Commitment Discount Unit
The service-provider-specified measurement unit indicating how a
service provider measures the Commitment Discount Quantity of a
commitment discount.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | Unit Format |
The Consumed Quantity represents the volume of a metered SKU
associated with a resource or
service used, based on the Consumed Unit. Consumed Quantity is often
derived at a finer granularity or over a different time interval when
compared to the Pricing Quantity
(complementary to Pricing Unit) and focuses
on resource and service consumption, not pricing and
cost.
ConsumedQuantity adheres to the following requirements:
ConsumedQuantity
Consumed Quantity
The volume of a metered SKU associated with a resource or
service used, based on the Consumed Unit.
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | Decimal |
| Value format | Numeric Format |
| Number range | Any valid decimal value |
The Consumed Unit represents a service-provider-specified measurement
unit indicating how a service provider measures usage of a metered SKU
associated with a resource or
service. Consumed Unit
complements the Consumed Quantity
metric. It is often listed at a finer granularity or over a different
time interval when compared to Pricing Unit
(complementary to Pricing Quantity), and
focuses on resource and service consumption, not
pricing and cost.
ConsumedUnit adheres to the following requirements:
ConsumedUnit
Consumed Unit
Service-provider-specified measurement unit indicating how a service
provider measures usage of a metered SKU associated with a
resource or service.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | Unit Format recommended |
Contract Applied is a set of properties that associate a charge with
one or more contract
commitments, denoted as key-value pairs in a JSON object.
Contract Applied allows the practitioner to track the progress of the
commitments to which they have agreed with a service provider.
The FOCUS-defined properties are:
Contract ID: The unique identifier representing aContract Commitment ID: The unique identifierContract Commitment Applied Cost: The value of theContract Commitment Applied Quantity: The usage of theContract Commitment Applied Unit: The unit of measureIn addition to these, a data generator may include one or more custom
properties, also denoted as key-value pairs.
The ContractApplied column adheres to the following requirements:
Contract Applied consists of a valid JSON object which contains an
array of key-value objects describing the one or more contract
commitments applied to the charge. Each object consists of FOCUS-defined
keys but can be extended to provide additional details about the
contract application.
x_ prefix to identify them asThe following keys are used for contract application properties to
facilitate querying data across allocations and across service
providers. FOCUS-defined keys will appear in the list below, and custom
keys will be prefixed with "x_" to make them easy to identify as well as
prevent collisions.
Contract ID
Contract ID is a service-provider-assigned identifier for a contract
describing the agreed terms between a service provider and a customer.
Contracts can include commitment to a certain amount of spend or usage
over an agreed period of time.
The "ContractId" property adheres to the following requirements:
Contract Commitment ID
A Contract Commitment ID is a service-provider-assigned identifier
describing an agreement agreed between a service provider and a
customer. Contracts can include commitment to a certain amount of spend
or usage over an agreed period of time.
The "ContractCommitmentID" property adheres to the following
requirements:
Contract Commitment Applied Cost
Contract Commitment Applied Cost represents the cost of the charge
applied to the contract line item. Contract Commitment Applied Cost is
associated with the contract line item via Contract Commitment ID.
Contract Commitment Applied Cost is commonly used for monitoring the
progress towards fulfilling contractual commitments that may facilitate
discounts for resources or services as agreed between a
service provider and a customer.
The "ContractCommitmentAppliedCost" property adheres to the following
requirements:
Contract Commitment Applied Quantity
Contract Commitment Applied Quantity represents the quantity of the
charge applied to the contract line item. Contract Commitment Applied
Quantity is associated with the contract line item via Contract
Commitment ID. Contract Commitment Applied Quantity is commonly used for
monitoring the progress towards fulfilling contractual commitments that
may facilitate discounts for resources or services as agreed between a
service provider and a customer.
The "ContractCommitmentAppliedQuantity" property adheres to the
following requirements:
Contract Commitment Applied Unit
The Contract Commitment Applied Unit represents a
service-provider-specified measurement unit for the usage declared in
Contract Commitment Applied Quantity. Contract Commitment Applied Unit
complements the Contract Commitment Applied Quantity metric.
The "ContractCommitmentAppliedUnit" property adheres to the following
requirements:
The parent array is called Elements and contains one or
more objects which communicate information about how an allocated record
was calculated.
| Key | ValueType | Required | Description |
|---|---|---|---|
| Elements | Array | True | The parent array containing one or more objects which communicate information about how contract commitments were applied to the charge. |
The Elements array contains one or more objects, each of
which contains the following entries:
| Key | Key Type | Feature Level | Allows Nulls | Data Type |
|---|---|---|---|---|
| ContractID | Dimension | Conditional | False | String |
| ContractCommitmentID | Dimension | Conditional | False | String |
| ContractCommitmentAppliedCost | Dimension | Conditional | True | Numeric |
| ContractCommitmentAppliedQuantity | Dimension | Conditional | True | Numeric |
| ContractCommitmentAppliedUnit | Dimension | Conditional | True | String |
{
"Elements" : [ {
"ContractID" : "12345",
"ContractCommitmentID" : "23456",
"ContractCommitmentAppliedCost" : 500000.00
}, {
"ContractID" : "12345",
"ContractCommitmentID" : "34567",
"ContractCommitmentAppliedQuantity" : 10000.00,
"ContractCommitmentAppliedUnit" : "compute_hours"
} ]
}{
"properties": {
"Elements": {
"elements": {
"properties": {
"ContractID": { "type": "string" },
"ContractCommitmentID": { "type": "string" }
},
"optionalProperties": {
"ContractCommitmentAppliedCost": { "type": "float64" },
"ContractCommitmentAppliedQuantity": { "type": "float64" },
"ContractCommitmentAppliedUnit": { "type": "float64" }
},
"additionalProperties": true
}
}
},
"additionalProperties": true
}NOTE: The above JSON Type Definition (JTD) is an approximation of the
expected contents of this column, but it should not be considered
normative because it cannot accurately describe the normative
requirements (above) for ContractApplied. Where there are discrepancies,
deference will be given to the normative requirements. For example, NumericFormat allows for multiple numeric data
types and precisions, but JTD requires both to be specified; other
numeric data types and precisions allowable under NumericFormat are
considered valid.
A single Cost and Usage charge represents the values stated on a
contract and its three contract commitments agreed between a service
provider and a customer:
The Charge Category is denoted as Purchase, and the Contract ID,
Resource ID, and Contract Commitment ID are all denoted as 12345.
{
"ResourceID": "12345",
"ChargeCategory": "Purchase",
"BilledCost": 500000.00,
"EffectiveCost": 0.00,
"ContractApplied":
{
"Elements": [ {
"ContractID": "12345",
"ContractCommitmentID": "12345",
"ContractCommitmentAppliedCost": 500000.00
}, {
"ContractID": "12345",
"ContractCommitmentID": "23456",
"ContractCommitmentAppliedCost": 25000.00
}, {
"ContractID": "12345",
"ContractCommitmentID": "34567",
"ContractCommitmentAppliedQuantity": 100000.00,
"ContractCommitmentAppliedUnit": "compute_hours"
} ]
}Assume the contract commitment as described in Scenario 1. Assume
that only 50% of cost and usage gets applied to the contract
commitments, per the contract terms.
A single Cost and Usage charge for myResource1 carries
Effective Cost of 30 (denominated in USD) and Consumed Quantity of 1
(denominated in compute hours). The Charge Category is denoted as
Usage.
This applies to the contract commitments in the following manner:
{
"ResourceID": "myResource1",
"ChargeCategory": "Usage",
"BilledCost": 0.00,
"EffectiveCost": 30.00,
"ConsumedQuantity": 1,
"ContractApplied":
{
"Elements": [ {
"ContractID": "12345",
"ContractCommitmentID": "12345",
"ContractCommitmentAppliedCost": 15.00
}, {
"ContractID": "12345",
"ContractCommitmentID": "23456",
"ContractCommitmentAppliedCost": 15.00
}, {
"ContractID": "12345",
"ContractCommitmentID": "34567",
"ContractCommitmentAppliedQuantity": 0.50,
"ContractCommitmentAppliedUnit": "compute_hours"
} ]
}The same as Scenario 2, except a custom key-value pair
x_ContractCommitmentCostBalance is provided by the data
generator. This datapoint represents the value remaining on a given
contract commitment.
{
"ResourceID": "myResource1",
"ChargeCategory": "Usage",
"BilledCost": 0.00,
"EffectiveCost": 30.00,
"ConsumedQuantity": 1,
"ContractApplied":
{
"Elements": [ {
"ContractID": "12345",
"ContractCommitmentID": "12345",
"ContractCommitmentAppliedCost": 15.00,
"x_ContractCommitmentCostBalance": 499985.00
}, {
"ContractID": "12345",
"ContractCommitmentID": "23456",
"ContractCommitmentAppliedCost": 15.00,
"x_ContractCommitmentCostBalance": 24985.00
}, {
"ContractID": "12345",
"ContractCommitmentID": "34567",
"ContractCommitmentAppliedQuantity": 0.50,
"ContractCommitmentAppliedUnit": "compute_hours"
} ]
}ContractApplied
Contract Applied
A set of properties that associate a charge with one or more contract
commitments.
| Constraint | Value |
|---|---|
| Column type | Dimension and Metric |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | JSON |
| Value format | JSON Object Format |
Contracted Cost represents the cost calculated by multiplying contracted unit
price and the corresponding Pricing
Quantity. Contracted Cost is denominated in the Billing Currency and is commonly used for
calculating savings based on negotiation activities, by comparing it
with List Cost. If negotiated discounts
are not applicable, the Contracted Cost defaults to the List Cost.
ContractedCost adheres to the following requirements:
ContractedCost
Contracted Cost
Cost calculated by multiplying contracted unit price and the
corresponding Pricing Quantity.
Aggregation: When aggregating Contracted Cost for
savings calculations, it's important to exclude either Charge Category "Purchase" charges
(one-time and recurring) that are paid to cover future eligible
charges (e.g., commitment discount) or the
covered Charge Category "Usage"
charges themselves. This exclusion helps prevent double
counting of these charges in the aggregation. Which set of
charges to exclude depends on whether cost are aggregated on a
billed basis (exclude covered charges) or accrual basis
(exclude Purchases for future charges). For instance,
charges categorized as Charge
Category "Purchase" and their related Charge Category "Tax" charges for a
Commitment Discount might be excluded from an accrual basis cost
aggregation of Contracted Cost. This is because the "Usage" and "Tax"
charge records provided during the commitment period already specify the
Contracted Cost. Purchase charges that cover future eligible
charges can be identified by filtering for Charge Category "Purchase" records with a Billed Cost greater than 0 and an Effective Cost equal to 0.
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Decimal |
| Value format | Numeric Format |
| Number range | Any valid decimal value |
The Contracted Unit Price represents the agreed-upon unit price for a
single Pricing Unit of the associated SKU,
inclusive of negotiated
discounts, if present, while excluding negotiated commitment discounts
or any other discounts. This price is denominated in the Billing Currency. The Contracted Unit Price
is commonly used for calculating savings based on negotiation
activities. If negotiated discounts are not applicable, the Contracted
Unit Price defaults to the List Unit
Price.
ContractedUnitPrice adheres to the following requirements:
ContractedUnitPrice
Contracted Unit Price
The agreed-upon unit price for a single Pricing Unit of the
associated SKU, inclusive of negotiated discounts, if present, while
excluding negotiated commitment discounts or any other discounts.
Aggregation: Column values should only be viewed in
the context of their row and not aggregated to produce a total.
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | Decimal |
| Value format | Numeric Format |
| Number range | Any valid non-negative decimal value |
Effective Cost represents the amortized cost of the charge after applying all reduced
rates, discounts, and the applicable portion of relevant, prepaid
purchases (one-time or recurring) that covered this charge. The
amortized portion included should be proportional to the Pricing Quantity and the time granularity of
the data. Since amortization breaks down and spreads the cost of a
prepaid purchase, to subsequent eligible charges, the Effective
Cost of the original prepaid charge is set to 0. Effective Cost
does not mix or "blend" costs across multiple charges of the
same service. This cost is
denominated in the Billing Currency. The
Effective Cost is commonly utilized to track and analyze spending
trends.
This column resolves two challenges that are faced by
practitioners:
EffectiveCost adheres to the following requirements:
EffectiveCost
Effective Cost
The amortized cost of the charge after applying all
reduced rates, discounts, and the applicable portion of relevant,
prepaid purchases (one-time or recurring) that covered this
charge.
Service 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.
Eligible purchases should be amortized using a methodology
determined by the service provider that reflects the needs of their
customer base and is proportional to the Pricing Quantity and the time
granularity of the row. Should a practitioner desire to
amortize relevant purchases using a different approach, the
practitioner can do so using the Billed Cost
for the line item representing the initial purchase.
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Decimal |
| Value format | Numeric Format |
| Number range | Any valid decimal value |
Host Provider Name is the name of the entity that provides the
underlying infrastructure on which the resources or services of the Service Provider are deployed.
In some instances, the host provider and the service provider are the
same entity: the provider hosts their own services. In other instances,
the host provider and the service provider are separate entities, though
the service provider may or may not expose the host provider and/or
allow the customer to select the host provider.
HostProviderName adheres to the following requirements:
See Appendix:
Participating Entity Identification Examples section for examples of
Host Provider values across various use case scenarios.
HostProviderName
Host Provider Name
The name of the entity whose resources are used by the
Service Provider to make their resources or services available.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
An Invoice ID is an invoice-issuer-assigned identifier for an invoice
encapsulating charges in the
corresponding billing
period for a given billing account. Invoices
are commonly used for scenarios like tracking billing transactions,
facilitating payment processes and for performing invoice reconciliation
between charges and billing periods.
InvoiceId adheres to the following requirements:
See Appendix:
Grouping constructs for resources or services for details and
examples of the different grouping constructs supported by FOCUS.
InvoiceId
Invoice ID
The invoice-issuer-assigned identifier for an invoice encapsulating
charges in the corresponding billing period for a given billing
account.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Recommended |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
Invoice Issuer Name is the name of the entity responsible for issuing
payable invoices for the resources or services consumed. It is commonly
used for cost analysis and reporting scenarios.
InvoiceIssuerName adheres to the following requirements:
See Appendix:
Participating Entity Identification Examples section for examples of
Invoice Issuer Name values across various use case scenarios.
InvoiceIssuerName
Invoice Issuer Name
The name of the entity responsible for invoicing for the
resources or services consumed.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
List Cost represents the cost calculated by multiplying the list unit price and the
corresponding Pricing Quantity. List Cost
is denominated in the Billing Currency
and is commonly used for calculating savings based on various rate
optimization activities by comparing it with Contracted Cost, Billed
Cost and Effective Cost.
ListCost adheres to the following requirements:
ListCost
List Cost
Cost calculated by multiplying List Unit Price and the corresponding
Pricing Quantity.
Aggregation: When aggregating List Cost for savings
calculations, it's important to exclude either Charge Category "Purchase" charges
(one-time and recurring) that are paid to cover future eligible
charges (e.g., commitment discount) or the
covered Charge Category "Usage"
charges themselves. This exclusion helps prevent double
counting of these charges in the aggregation. Which set of
charges to exclude depends on whether cost are aggregated on a
billed basis (exclude covered charges) or accrual basis
(exclude Purchases for future charges). For instance,
charges categorized as Charge
Category "Purchase" and their related Charge Category "Tax" charges for a
Commitment Discount might be excluded from an accrual basis cost
aggregation of List Cost. This is because the "Usage" and "Tax" charge
records provided during the term of the commitment discount already
specify the List Cost. Purchase charges that cover future
eligible charges can be identified by filtering for Charge Category "Purchase" records with a Billed Cost greater than 0 and an Effective Cost equal to 0.
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Decimal |
| Value format | Numeric Format |
| Number range | Any valid decimal value |
The List Unit Price represents the suggested
service-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.
ListUnitPrice adheres to the following requirements:
ListUnitPrice
List Unit Price
The suggested service-provider-published unit price for a single
Pricing Unit of the associated SKU, exclusive of any discounts.
Aggregation: Column values should only be viewed in
the context of their row and not aggregated to produce a total.
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | Decimal |
| Value format | Numeric Format |
| Number range | Any valid non-negative decimal value |
Pricing Category describes the pricing model used for a charge at the time of use or
purchase. It can be useful for distinguishing between charges
incurred at the list unit
price or a reduced price and exposing optimization
opportunities, like increasing commitment discount
coverage.
PricingCategory adheres to the following requirements:
PricingCategory
Pricing Category
Describes the pricing model used for a charge at the time of
use or purchase.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | Allowed values |
Allowed values:
| Value | Description |
|---|---|
| Standard | Charges priced at the agreed upon rate for the billing account, including negotiated discounts. This pricing includes any flat rate and volume/tiered pricing but does not include dynamic pricing or reduced pricing due to the application of a commitment discount. This does include the purchase of a commitment discount at agreed upon rates. |
| Dynamic | Charges priced at a variable rate determined by the service provider. This includes any product or service with a unit price the service provider can change without notice, like interruptible or low priority resources. |
| Committed | Charges with reduced pricing due to the application of the commitment discount specified by the Commitment Discount ID. |
| Other | Charges priced in a way not covered by another pricing category. |
Pricing Currency is
the national or virtual currency denomination that a resource or service was priced in. Pricing
Currency is commonly used in scenarios where different currencies are
used for pricing and billing.
PricingCurrency adheres to the following requirements:
PricingCurrency
Pricing Currency
The national or virtual currency denomination that a
resource or service was priced in.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | Currency Format |
The Pricing Currency Contracted Unit Price represents the agreed-upon
unit price for a single Pricing Unit of the
associated SKU, inclusive of negotiated discounts,
if present, while excluding negotiated commitment discounts
or any other discounts. This price is denominated in the Pricing Currency. When negotiated discounts
do not apply to unit prices and instead are applied to exchange rates,
the Pricing Currency Contracted Unit Price defaults to the Pricing Currency List Unit
Price. The Pricing Currency Contracted Unit Price is commonly used
to calculate savings based on negotiation activities.
PricingCurrencyContractedUnitPrice adheres to the following
requirements:
PricingCurrencyContractedUnitPrice
Pricing Currency Contracted Unit Price
The agreed-upon unit price for a single Pricing Unit of the
associated SKU, inclusive of negotiated discounts, if present,
while excluding negotiated commitment discounts or any other
discounts, and expressed in Pricing Currency.
Aggregation: Column values should only be viewed in
the context of their row and not aggregated to produce a total.
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | Decimal |
| Value format | Numeric Format |
| Number range | Any valid non-negative decimal value |
The Pricing Currency Effective Cost represents the cost of the charge after applying all reduced
rates, discounts, and the applicable portion of relevant, prepaid
purchases (one-time or recurring) that covered this charge, as
denominated in Pricing Currency. This
allows the practitioner to perform a conversion from either 1) a national currency to a virtual currency (e.g.,
tokens to USD), or 2) one national currency to another (e.g., EUR to
USD).
PricingCurrencyEffectiveCost adheres to the following
requirements:
PricingCurrencyEffectiveCost
Pricing Currency Effective Cost
The cost of the charge after applying all reduced rates,
discounts, and the applicable portion of relevant, prepaid purchases
(one-time or recurring) that covered this charge, as
denominated in Pricing Currency.
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | Decimal |
| Value format | Numeric Format |
| Number range | Any valid decimal value |
The Pricing Currency List Unit Price represents the suggested
service-provider-published unit price for a single Pricing Unit of the associated SKU, exclusive of any discounts. This
price is denominated in the Pricing
Currency. The Pricing Currency List Unit Price is commonly used for
calculating savings based on various rate optimization activities.
PricingCurrencyListUnitPrice adheres to the following
requirements:
PricingCurrencyListUnitPrice
Pricing Currency List Unit Price
The suggested service-provider-published unit price for a single
Pricing Unit of the associated SKU, exclusive of any discounts
and expressed in Pricing Currency.
Aggregation: Column values should only be viewed in
the context of their row and not aggregated to produce a total.
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | Decimal |
| Value format | Numeric Format |
| Number range | Any valid non-negative decimal value |
The Pricing Quantity represents the volume of a given SKU associated with a resource or service used or purchased, based
on the Pricing Unit. Distinct from Consumed Quantity (complementary to Consumed Unit), it focuses on pricing and cost,
not resource and service consumption.
PricingQuantity adheres to the following requirements:
PricingQuantity
Pricing Quantity
The volume of a given SKU associated with a
resource or service used or purchased, based on the
Pricing Unit.
Aggregation: When aggregating Pricing Quantity for
commitment utilization calculations, it's important to exclude commitment discount
purchases (i.e. when Charge Category is "Purchase") that are paid to
cover future eligible charges
(e.g., commitment discount). Otherwise, when accounting for all
upfront or accrued purchases, it's important to exclude commitment
discount usage (i.e. when Charge Category is "Usage"). This
exclusion helps prevent double counting of these quantities in the
aggregation.
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Mandatory |
| Allows nulls | True |
| Data type | Decimal |
| Value format | Numeric Format |
| Number Range | Any valid decimal value |
The Pricing Unit represents a service-provider-specified measurement
unit for determining unit prices, indicating how the service provider
rates measured usage and purchase quantities after applying pricing
rules like block pricing.
Common examples include the number of hours for compute appliance
runtime (e.g., Hours), gigabyte-hours for a storage
appliance (e.g., GB-Hours), or an accumulated count of
requests for a network appliance or API service (e.g.,
1000 Requests). Pricing Unit complements the Pricing Quantity metric. Distinct from the
Consumed Unit, it focuses on pricing and
cost, not resource and service consumption, often at a
coarser granularity.
PricingUnit adheres to the following requirements:
PricingUnit
Pricing Unit
Service-provider-specified measurement unit for determining unit
prices, indicating how the service provider rates measured usage and
purchase quantities after applying pricing rules like block
pricing.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | True |
| Data type | String |
| Value format | Unit Format |
Provider is the name of the entity that makes the resources or services available for purchase.
It is commonly used for cost analysis and reporting scenarios.
ProviderName adheres to the following requirements:
See Appendix:
Participating Entity Identification Examples section for examples of
Service Provider Name, Host Provider Name and Invoice Issuer Name values across various
use case scenarios. For entity identification examples that include the
deprecated Provider column, please see here
(external GitHub link to FOCUS v1.2).
ProviderName
Provider Name
The name of the entity that made the resources or
services available for purchase.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
0.5
1.3 Replaced by ServiceProviderName
Publisher is the name of the entity that produces the resources or services that were purchased. It
is commonly used for cost analysis and reporting scenarios.
PublisherName adheres to the following requirements:
See Appendix:
Participating Entity Identification Examples section for examples of
Service Provider Name, Host Provider Name and Invoice Issuer Name values across various
use case scenarios. For entity identification examples that include the
deprecated Publisher column, please see here
(external GitHub link to FOCUS v1.2).
PublisherName
Publisher Name
The name of the entity that produced the resources or
services that were purchased.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
0.5
A Region ID is a host-provider-assigned identifier for an isolated
geographic area where a resource is provisioned or a service is provided. The region is
commonly used for scenarios like analyzing cost and unit prices based on
where resources are deployed.
RegionId adheres to the following requirements:
RegionId
Region ID
Host-provider-assigned identifier for an isolated geographic area
where a resource is provisioned or a service is
provided.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
Region Name is a host-provider-assigned display name for an isolated
geographic area where a resource is provisioned or a service is provided. Region Name
is commonly used for scenarios like analyzing cost and unit prices based
on where resources are deployed.
RegionName adheres to the following requirements:
RegionName
Region Name
The name of an isolated geographic area where a resource is
provisioned or a service is provided.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
A Resource ID is an identifier assigned to a resource by the service provider.
The Resource ID is commonly used for cost reporting, analysis, and
allocation scenarios.
ResourceId adheres to the following requirements:
ResourceId
Resource ID
Identifier assigned to a resource by the service
provider.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
The Resource Name is a display name assigned to a resource. It is commonly used for
cost analysis, reporting, and allocation scenarios.
ResourceName adheres to the following requirements:
ResourceName
Resource Name
Display name assigned to a resource.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
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.
ResourceType adheres to the following requirements:
ResourceType
Resource Type
The kind of resource the charge applies to.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
Service Provider Name is the name of the entity that provides the resources or services available for usage or
purchase. These services can be built on top of infrastructure provided
by a Host Provider, offered as fully
integrated solutions, or include complementary offerings such as
support, licensing, or consulting. It is commonly used for cost analysis
and reporting scenarios.
Notes:
ServiceProviderName adheres to the following requirements:
See Appendix:
Participating Entity Identification Examples section for examples of
Service Provider Name values across various use case scenarios.
ServiceProviderName
Service Provider Name
The name of the entity that made the resources or
services available for purchase or consumption.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
1.3 Introduced as a replacement for ProviderName
The Service Category is the highest-level classification of a service based on the core function
of the service. Each service should have one and only
one category that best aligns with its primary purpose. The Service
Category is commonly used for scenarios like analyzing costs across
service providers and tracking the migration of workloads across
fundamentally different architectures.
ServiceCategory adheres to the following requirements:
ServiceCategory
Service Category
Highest-level classification of a service based on the core
function of the service.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | Allowed Values |
Allowed values:
| Service Category | Description |
|---|---|
| AI and Machine Learning | Artificial Intelligence and Machine Learning related technologies. |
| Analytics | Data processing, analytics, and visualization capabilities. |
| Business Applications | Business and productivity applications and services. |
| Compute | Virtual, containerized, serverless, or high-performance computing infrastructure and services. |
| Databases | Database platforms and services that allow for storage and querying of data. |
| Developer Tools | Software development and delivery tools and services. |
| Multicloud | Support for interworking of multiple cloud and/or on-premises environments. |
| Identity | Identity and access management services. |
| Integration | Services that allow applications to interact with one another. |
| Internet of Things | Development and management of IoT devices and networks. |
| Management and Governance | Management, logging, and observability of a customer's use of cloud. |
| Media | Media and entertainment streaming and processing services. |
| Migration | Moving applications and data to the cloud. |
| Mobile | Services enabling cloud applications to interact via mobile technologies. |
| Networking | Network connectivity and management. |
| Security | Security monitoring and compliance services. |
| Storage | Storage services for structured or unstructured data. |
| Web | Services enabling cloud applications to interact via the Internet. |
| Other | New or emerging services that do not align with an existing category. |
A service represents an
offering that can be purchased from a service 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.
ServiceName adheres to the following requirements:
ServiceName
Service Name
An offering that can be purchased from a service provider (e.g.,
cloud virtual machine, SaaS database, professional services
from a systems integrator).
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
The Service Subcategory is a secondary classification of the Service Category for a service based on its core
function. The Service Subcategory (in conjunction with the Service
Category) is commonly used for scenarios like analyzing spend and usage
for specific workload types across service providers and tracking the
migration of workloads across fundamentally different architectures.
ServiceSubcategory adheres to the following requirements:
ServiceSubcategory
Service Subcategory
Secondary classification of the Service Category for a
service based on its core function.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Recommended |
| Allows nulls | False |
| Data type | String |
| Value format | Allowed Values |
Allowed values:
| Service Category | Service Subcategory | Service Subcategory Description |
|---|---|---|
| AI and Machine Learning | AI Platforms | Unified solution that combines artificial intelligence and machine learning technologies. |
| AI and Machine Learning | Bots | Automated performance of tasks such as customer service, data collection, and content moderation. |
| AI and Machine Learning | Generative AI | Creation of content like text, images, and music by learning patterns from existing data. |
| AI and Machine Learning | Machine Learning | Creation, training, and deployment of statistical algorithms that learn from and perform tasks based on data. |
| AI and Machine Learning | Natural Language Processing | Generation of human language, handling tasks like translation, sentiment analysis, and text summarization. |
| AI and Machine Learning | Other (AI and Machine Learning) | AI and Machine Learning services that do not fall into one of the defined subcategories. |
| Analytics | Analytics Platforms | Unified solution that combines technologies across the entire analytics lifecycle. |
| Analytics | Business Intelligence | Semantic models, dashboards, reports, and data visualizations to track performance and identify trends. |
| Analytics | Data Processing | Integration and transformation tasks to prepare data for analysis. |
| Analytics | Search | Discovery of information by indexing and retrieving data from various sources. |
| Analytics | Streaming Analytics | Real-time data stream processes to detect patterns, trends, and anomalies as they occur. |
| Analytics | Other (Analytics) | Analytics services that do not fall into one of the defined subcategories. |
| Business Applications | Productivity and Collaboration | Tools that facilitate individuals managing tasks and working together. |
| Business Applications | Other (Business Applications) | Business Applications services that do not fall into one of the defined subcategories. |
| Compute | Containers | Management and orchestration of containerized compute platforms. |
| Compute | End User Computing | Virtualized desktop infrastructure and device / endpoint management. |
| Compute | Quantum Compute | Resources and simulators that leverage the principles of quantum mechanics. |
| Compute | Serverless Compute | Enablement of compute capabilities without provisioning or managing servers. |
| Compute | Virtual Machines | Computing environments ranging from hosts with abstracted operating systems to bare-metal servers. |
| Compute | Other (Compute) | Compute services that do not fall into one of the defined subcategories. |
| Databases | Caching | Low-latency and high-throughput access to frequently accessed data. |
| Databases | Data Warehouses | Big data storage and querying capabilities. |
| Databases | Ledger Databases | Immutable and transparent databases to record tamper-proof and cryptographically secure transactions. |
| Databases | NoSQL Databases | Unstructured or semi-structured data storage and querying capabilities. |
| Databases | Relational Databases | Structured data storage and querying capabilities. |
| Databases | Time Series Databases | Time-stamped data storage and querying capabilities. |
| Databases | Other (Databases) | Database services that do not fall into one of the defined subcategories. |
| Developer Tools | Developer Platforms | Unified solution that combines technologies across multiple areas of the software development lifecycle. |
| Developer Tools | Continuous Integration and Deployment | CI/CD tools and services that support building and deploying code for software and systems. |
| Developer Tools | Development Environments | Tools and services that support authoring code for software and systems. |
| Developer Tools | Source Code Management | Tools and services that support version control of code for software and systems. |
| Developer Tools | Quality Assurance | Tools and services that support testing code for software and systems. |
| Developer Tools | Other (Developer Tools) | Developer Tools services that do not fall into one of the defined subcategories. |
| Identity | Identity and Access Management | Technologies that ensure users have appropriate access to resources. |
| Identity | Other (Identity) | Identity services that do not fall into one of the defined subcategories. |
| Integration | API Management | Creation, publishing, and management of application programming interfaces. |
| Integration | Messaging | Asynchronous communication between distributed applications. |
| Integration | Workflow Orchestration | Design, execution, and management of business processes and workflows. |
| Integration | Other (Integration) | Integration services that do not fall into one of the defined subcategories. |
| Internet of Things | IoT Analytics | Examination of data collected from IoT devices. |
| Internet of Things | IoT Platforms | Unified solution that combines IoT data collection, processing, visualization, and device management. |
| Internet of Things | Other (Internet of Things) | Internet of Things (IoT) services that do not fall into one of the defined subcategories. |
| Management and Governance | Architecture | Planning, design, and construction of software systems. |
| Management and Governance | Compliance | Adherance to regulatory standards and industry best practices. |
| Management and Governance | Cost Management | Monitoring and controlling expenses of systems and services. |
| Management and Governance | Data Governance | Management of the availability, usability, integrity, and security of data. |
| Management and Governance | Disaster Recovery | Plans and procedures that ensure systems and services can recover from disruptions. |
| Management and Governance | Endpoint Management | Tools that configure and secure access to devices. |
| Management and Governance | Observability | Monitoring, logging, and tracing of data to track the performance and health of systems. |
| Management and Governance | Support | Assistance and expertise supplied by service providers. |
| Management and Governance | Other (Management and Governance) | Management and governance services that do not fall into one of the defined subcategories. |
| Media | Content Creation | Production of media content. |
| Media | Gaming | Development and delivery of gaming services. |
| Media | Media Streaming | Multimedia delivered and rendered in real-time on devices. |
| Media | Mixed Reality | Technologies that blend real-world and computer-generated environments. |
| Media | Other (Media) | Media services that do not fall into one of the defined subcategories. |
| Migration | Data Migration | Movement of stored data from one location to another. |
| Migration | Resource Migration | Movement of resources from one location to another. |
| Migration | Other (Migration) | Migration services that do not fall into one of the defined subcategories. |
| Mobile | Other (Mobile) | All Mobile services. |
| Multicloud | Multicloud Integration | Environments that facilitate consumption of services from multiple cloud service providers. |
| Multicloud | Other (Multicloud) | Multicloud services that do not fall into one of the defined subcategories. |
| Networking | Application Networking | Distribution of incoming network traffic across application-based workloads. |
| Networking | Content Delivery | Distribution of digital content using a network of servers (CDNs). |
| Networking | Network Connectivity | Facilitates communication between networks or network segments. |
| Networking | Network Infrastructure | Configuration, monitoring, and troubleshooting of network devices. |
| Networking | Network Routing | Services that select paths for traffic within or across networks. |
| Networking | Network Security | Protection from unauthorized network access and cyber threats using firewalls and anti-malware tools. |
| Networking | Other (Networking) | Networking services that do not fall into one of the defined subcategories. |
| Security | Secret Management | Information used to authenticate users and systems, including secrets, certificates, tokens, and other keys. |
| Security | Security Posture Management | Tools that help organizations configure, monitor, and improve system security. |
| Security | Threat Detection and Response | Collect and analyze security data to identify and respond to potential security threats and vulnerabilities. |
| Security | Other (Security) | Security services that do not fall into one of the defined subcategories. |
| Storage | Backup Storage | Secondary storage to protect against data loss. |
| Storage | Block Storage | High performance, low latency storage that provides random access. |
| Storage | File Storage | Scalable, sharable storage for file-based data. |
| Storage | Object Storage | Highly available, durable storage for unstructured data. |
| Storage | Storage Platforms | Unified solution that supports multiple storage types. |
| Storage | Other (Storage) | Storage services that do not fall into one of the defined subcategories. |
| Web | Application Platforms | Integrated environments that run web applications. |
| Web | Other (Web) | Web services that do not fall into one of the defined subcategories. |
| Other | Other (Other) | Services that do not fall into one of the defined categories. |
A SKU ID is a service-provider-specified unique identifier that
represents a specific SKU.
SKUs are quantifiable goods or service offerings in a Cost and
Usage FOCUS dataset that
represent specific functionality and technical specifications. Examples
of SKUs include but are not limited to:
Each SKU ID represents a unique set of features that can be sold at
different price points or SKU
Prices. SKU ID is consistent across all pricing variations,
which may differ based on multiple factors beyond the common
functionality and technical specifications. Examples include but are not
limited to:
SKU ID should be consistent across pricing variations of a good or
service to facilitate price comparisons for the same functionality, like
where the functionality is provided or how it's paid for. SKU ID can be
referenced on a catalog or price
list published by a service provider to look up detailed
information about the SKU. The composition of the properties
associated with the SKU ID may differ across service providers. SKU ID
is commonly used for analyzing and comparing costs for the same SKU
across different price details (e.g., period, tier,
location).
SkuId adheres to the following requirements:
SkuId
SKU ID
Service-provider-specified unique identifier that represents a
specific SKU (e.g., a quantifiable good or service
offering).
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
SKU Meter describes the functionality being metered or measured by a
particular SKU in a charge.
Service providers often have billing models in which multiple SKUs
exist for a given service to describe and bill for different
functionalities for that service. For example, an object storage service
may have separate SKUs for functionalities such as object storage, API
requests, data transfer, encryption, and object management. This field
helps practitioners understand which functionalities are being metered
by the different SKUs that appear in a Cost and Usage FOCUS dataset.
SkuMeter adheres to the following requirements:
Compute Usage, Block Volume Usage, Data Transfer, API Requests
SkuMeter
SKU Meter
Describes the functionality being metered or measured by a particular
SKU in a charge.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
SKU Price Details represent a list of SKU Price properties (key-value
pairs) associated with a specific SKU Price
ID. These properties include qualitative and quantitative properties
of a SKUs (e.g., functionality and
technical specifications), along with core stable pricing properties
(e.g., pricing periods, tiers,
etc.), excluding dynamic or negotiable pricing elements such as unit
price amounts, currency (and related exchange rates), temporal validity
(e.g., effective dates), and contract- or negotiation-specific factors
(e.g., contract or account identifiers, and negotiable discounts).
The composition of properties associated with a specific SKU
Price may differ across service providers and across SKUs
within the same service provider. However, the exclusion of dynamic or
negotiable pricing properties should ensure that all charges with the same SKU Price ID
share the same SKU Price Details, i.e., that SKU Price Details remains
consistent across different billing periods and billing accounts within a
service provider.
SKU Price Details helps practitioners understand and distinguish
SKU Prices, each identified by a SKU Price ID and associated
with a used or purchased resource or service. It can also help
determine the quantity of units for a property when it holds a numeric
value (e.g., CoreCount), even when its unit differs from the one in
which the SKU is priced and charged, thus supporting FinOps
capabilities such as unit economics. Additionally, the SKU Price Details
may be used to analyze costs based on pricing properties such as
periods and tiers.
SkuPriceDetails adheres to the following requirements:
{
"StorageClass": "Archive",
"CoreCount": 4,
"x_PremiumProcessing": true
}SkuPriceDetails
SKU Price Details
A set of properties of a SKU Price ID which are meaningful and common
to all instances of that SKU Price ID.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | JSON |
| Value format | Key-Value Format |
The following keys should be used when applicable to facilitate
cross-SKU and cross-service-provider queries for the same conceptual
property. FOCUS-defined keys will appear in the list below and custom
(e.g., service-provider-defined) keys will be prefixed with "x_" to make
them easy to identify as well as prevent collisions.
| Key | Description | Data Type | Unit of Measure (numeric) or example values (string) |
|---|---|---|---|
| CoreCount | Number of physical or virtual CPUs available1 |
Numeric | Measure: Quantity of Cores |
| DiskMaxIops | Storage maximum sustained input/output operations per second1 |
Numeric | Measure: Input/Output Operations per Second (IOPS) |
| DiskSpace | Storage capacity available | Numeric | Measure: Gibibytes (GiB) |
| DiskType | Kind of disk used | String | Examples: "SSD", "HDD", "NVMe" |
| GpuCount | Number of GPUs available | Numeric | Measure: Quantity of GPUs |
| InstanceType | Common name of the instance including size, shape, series, etc. |
String | Examples: "m5d.2xlarge", "NC24rs_v3", "P50" |
| InstanceSeries | Common name for the series and/or generation of the instance |
String | Examples: "M5", "Dadv5", "N2D" |
| MemorySize | RAM allocated for processing | Numeric | Measure: Gibibytes (GiB2) |
| NetworkMaxIops | Network maximum sustained input/output operations per second1 |
Numeric | Measure: Input/Output Operations per Second (IOPS) |
| NetworkMaxThroughput | Network maximum sustained throughput for data transfer1 |
Numeric | Measure: Megabits per second (Mbps) |
| OperatingSystem | Operating system family3 | String | Examples: "Linux", "MacOS", "Windows" |
| Redundancy | Level of redundancy offered by the SKU |
String | Examples: "Local", "Zonal", "Global" |
| StorageClass | Class or tier of storage provided | String | Examples: "Hot", "Archive", "Nearline" |
Notes
1 In the case of "burstable" SKUs offering
variable levels of performance, the baseline or guaranteed value should
be used.
2 Memory manufacturers still commonly uses "GB"
to refer to 230 bytes, which is known as GiB in other
contexts.
3 This is the operating system family of the
SKU, if it's included with the SKU or the SKU only supports one type of
operating system.
SKU Price ID is a service-provider-specified unique identifier that
represents a specific SKU
Price associated with a resource or service used or purchased. It
serves as a key reference for a SKU Price in a price list published by a
service provider, allowing practitioners to look up detailed information
about the SKU Price.
The composition of properties associated with the SKU Price ID may
differ across service providers and across SKUs within the same
service provider. However, the exclusion of dynamic or negotiable
pricing properties, such as unit price amount, currency (and related
exchange rates), temporal validity (e.g., effective dates), and
contract- or negotiation-specific elements (e.g., contract or account
identifiers, and negotiable discounts), ensures that the SKU Price ID
remains consistent across different billing periods and billing accounts
within a service provider. This consistency enables efficient filtering
of charges to track price
fluctuations (e.g., changes in unit price amounts) over time and across
billing accounts, for both list and contracted unit prices.
Additionally, the SKU Price ID is commonly used to analyze costs based
on pricing properties such as periods and tiers.
SkuPriceId adheres to the following requirements:
See Examples: Commitment
Discount Flexibility for more details around commitment discount
flexibility.
SkuPriceId
SKU Price ID
A service-provider-specified unique identifier that represents a
specific SKU Price associated with a resource or
service used or purchased.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
A Sub Account ID is a service-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.
SubAccountId adheres to the following requirements:
See Appendix:
Grouping constructs for resources or services for details and
examples of the different grouping constructs supported by FOCUS.
SubAccountId
Sub Account ID
An ID assigned to a grouping of resources or services, often used to manage
access and/or cost.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
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.
SubAccountName adheres to the following requirements:
See Appendix:
Grouping constructs for resources or services for details and
examples of the different grouping constructs supported by FOCUS.
SubAccountName
Sub Account Name
A name assigned to a grouping of resources or services, often used to manage
access and/or cost.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
Sub Account Type is a service-provider-assigned name to identify the
type of sub account. Sub
Account Type is a readable display name and not a code. Sub Account Type
is commonly used for scenarios like mapping FOCUS and service provider
constructs, summarizing costs across service providers, or invoicing and
chargeback.
SubAccountType adheres to the following requirements:
SubAccountType
Sub Account Type
A service-provider-assigned name to identify the type of sub
account.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
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 cost and
usage data to identify and accurately allocate charges. Tags may also be referred
to by data generators using other terms such as labels.
A tag becomes finalized when a single
value is selected from a set of possible tag values assigned to the tag
key. When supported by a data generator, this can occur when a tag value
is set by provider-defined or user-defined rules.
Tags adheres to the following requirements:
This example illustrates various tags produced from multiple
user-defined and provider-defined tag schemes. The first three tags
illustrate examples from three different, user-defined tag schemes. The
data generator predetermined that 1 user-defined tag scheme (i.e.,
"foo": "bar") does not have a prepended prefix, but the
remaining two user-defined tag schemes (i.e.,
"userDefinedTagScheme2/foo": "bar",
"userDefinedTagScheme3/foo": true) do have provider-defined
and reserved prefixes. Additionally, the third tag is produced from a
valueless, user-defined tag scheme, so the data generator also applies
true as its default value.
The last two tags illustrate examples from two different,
provider-defined tag schemes. Since all provider-defined tag schemes
require a prefix, the data generator has prepended predefined and
reserved prefixes (providerDefinedTagScheme1/,
providerDefinedTagScheme2/) to each tag.
{
"foo": "bar",
"userDefinedTagScheme2/foo": "bar",
"userDefinedTagScheme3/foo": true,
"providerDefinedTagScheme1/foo": "bar",
"providerDefinedTagScheme2/foo": "bar"
}Within a data generator, tag keys may be associated with multiple
values, and potentially defined at different levels within the data
generator, such as accounts, folders, resource and other
resource grouping constructs. When finalizing, data
generator 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 data
generator but must be documented within their respective
documentation.
As an example, let's assume 1 sub
account exists with 1 virtual machine with the following
details, and tag inheritance favors Resources over Sub
Accounts.
The table below represents a finalized 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 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.
Tags
Tags
The set of tags assigned to tag sources that account for
potential provider-defined or user-defined tag evaluations.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Conditional |
| Allows nulls | True |
| Data type | JSON |
| Value format | Key-Value Format |
The Contract Commitment dataset is a supporting dataset that
describes the terms of contracts agreed between a service provider and a
customer.
| Column | Column Type | Feature Level | Allows Nulls | Data Type |
|---|---|---|---|---|
| Billing Currency | Dimension | Mandatory | True | String |
| Contract Commitment Category |
Dimension | Mandatory | False | String |
| Contract Commitment Cost | Metric | Mandatory | True | Numeric |
| Contract Commitment Description |
Dimension | Mandatory | True | String |
| Contract Commitment ID | Dimension | Mandatory | False | String |
| Contract Commitment Period End |
Dimension | Mandatory | False | Date/Time |
| Contract Commitment Period Start |
Dimension | Mandatory | False | Date/Time |
| Contract Commitment Quantity |
Metric | Mandatory | True | Numeric |
| Contract Commitment Type | Dimension | Mandatory | False | String |
| Contract Commitment Unit | Dimension | Mandatory | True | String |
| Contract ID | Dimension | Mandatory | False | String |
| Contract Period End | Dimension | Mandatory | False | Date/Time |
| Contract Period Start | Dimension | Mandatory | False | Date/Time |
The Contract Commitment dataset can be joined to the Cost and Usage
dataset through the use of Contract Commitment ID.
| Dataset A | Dataset A Column | Dataset B | Dataset B Column |
|---|---|---|---|
| Contract Commitment | Contract Commitment ID | Cost and Usage | Contract Applied |
ContractCommitment adheres to the following requirements:
ContractCommitment
Contract Commitment
Describes the terms of contracts agreed between a service provider
and a customer.
Billing currency is
an identifier that represents the currency of a contract
commitment.
BillingCurrency adheres to the following requirements:
BillingCurrency
Billing Currency
Represents the currency of a contract commitment.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | True |
| Data type | String |
| Value format | Currency Format |
Contract Commitment Cost represents the monetary value of the contract commitment.
Contract Commitment Cost is commonly used for monitoring the progress
towards fulfilling contractual commitments that may facilitate discounts
for resources or services as agreed between a
service provider and a customer.
ContractCommitmentCost adheres to the following requirements:
ContractCommitmentCost
Contract Commitment Cost
The monetary value of the contract commitment.
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Mandatory |
| Allows nulls | True |
| Data type | Decimal |
| Value format | Numeric Format |
| Number range | Any valid decimal value |
Contract Commitment ID is a service-provider-assigned identifier
describing a single contract term agreed between a provider and a
customer. Contracts can include commitments to a certain amount of spend
or usage over an agreed period of time.
ContractCommitmentId adheres to the following requirements:
ContractCommitmentId
Contract Commitment ID
A service-provider-assigned identifier describing a single contract
term agreed between a service provider and a customer.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
Contract Commitment Category represents the highest-level
classification of a contract
commitment based on the nature of how it is applied to a
charge. Contract Commitment Category is commonly used to identify and
distinguish between categories of contract commitments that may require
different handling.
ContractCommitmentCategory adheres to the following requirements:
ContractCommitmentCategory
Contract Commitment Category
Represents the highest-level classification of a contract
commitment based on the nature of how it is applied to a
charge.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | Allowed values |
Allowed values:
| Value | Description |
|---|---|
| Spend | Contract commitments that require a predetermined amount of spend. |
| Usage | Contract commitments that require a predetermined amount of usage. |
Contract Commitment Description provides a high-level context of a contract commitment
without requiring additional discovery. Contract Commitment Description
is a self-contained summary of the contract commitment's terms, which
may not be sufficiently described by the other columns of the Contract
Commitment dataset.
ContractCommitmentDescription adheres to the following
requirements:
ContractCommitmentDescription
Contract Commitment Description
The self-contained summary of the contract commitment's
terms.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
Contract Commitment Period End represents the exclusive end bound of a
contract commitment
period. For example, a time period where Contract Commitment Period Start is
'2024-01-01T00:00:00Z' and Contract Commitment Period End is
'2024-01-02T00:00:00Z' includes January 1 2024 since Contract Commitment
Period Start represents the inclusive start bound,
but does not include January 1 2025 since Contract Commitment Period End
represents the exclusive end bound.
ContractCommitmentPeriodEnd adheres to the following
requirements:
ContractCommitmentPeriodEnd
Contract Commitment Period End
The exclusive end bound of a contract commitment
period.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Date/Time |
| Value format | Date/Time Format |
Contract Commitment Period Start represents the inclusive start bound
of a contract
commitment period. For example, a time period where Contract
Commitment Period Start is '2024-01-01T00:00:00Z' and Contract Commitment End is
'2025-01-01T00:00:00Z' includes January 1 2024 since Contract Commitment
Period Start represents the inclusive start bound, but does not
include charges for January 2 2025 since Contract Commitment
Period End represents the exclusive end bound.
ContractCommitmentPeriodStart adheres to the following
requirements:
ContractCommitmentPeriodStart
Contract Commitment Period Start
The inclusive start bound of a contract commitment
period.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Date/Time |
| Value format | Date/Time Format |
Contract Commitment Quantity represents the amount associated with
the contract
commitment, denominated in a service-provider-defined Contract Commitment Unit. Contract
Commitment Quantity is commonly used for monitoring the progress towards
fulfilling contractual commitments that may facilitate discounts for resources or services as agreed between a
provider and a customer.
ContractCommitmentQuantity adheres to the following requirements:
ContractCommitmentQuantity
Contract Commitment Quantity
The amount associated with the contract commitment.
| Constraint | Value |
|---|---|
| Column type | Metric |
| Feature level | Mandatory |
| Allows nulls | True |
| Data type | Decimal |
| Value format | Numeric Format |
| Number range | Any valid decimal value |
Contract Commitment Type is a service-provider-assigned name to
identify the type of contract commitment.
Contract Commitment Type is a readable display name and not a code.
Contract Commitment Type is commonly used for displaying and aggregating
the types of commitments the practitioner has made, stated in
service-provider-specific terms.
ContractCommitmentType adheres to the following requirements:
ContractCommitmentType
Contract Commitment Type
A service-provider-assigned name to identify the type of contract
commitment.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
The Contract Commitment Unit represents a service-provider-specified
measurement unit for the amount declared in Contract Commitment
Quantity. Contract Commitment Unit complements the Contract Commitment
Quantity metric.
ContractCommitmentUnit adheres to the following requirements:
ContractCommitmentUnit
Contract Commitment Unit
A service-provider-specified measurement unit for the amount declared
in Contract Commitment Quantity.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | True |
| Data type | String |
| Value format | Unit Format recommended |
Contract ID is a service-provider-assigned identifier for a contract
describing the agreed terms between a service provider and a customer.
Contracts can include commitment to a certain amount of spend or usage
over an agreed period of time.
ContractId adheres to the following requirements:
ContractId
Contract ID
A service-provider-assigned identifier for a contract describing the
agreed terms between a service provider and a customer.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | True |
| Data type | String |
| Value format | <not specified> |
Contract Period End represents the exclusive end bound of a
contract period. For
example, a time period where Contract
Period Start is '2024-01-01T00:00:00Z' and Contract Period End is
'2024-01-02T00:00:00Z' includes January 1 2024 since Contract Period
Start represents the inclusive start bound,
but does not include January 1 2025 since Contract Period End represents
the exclusive end bound.
ContractPeriodEnd adheres to the following requirements:
ContractPeriodEnd
Contract Period End
The exclusive end bound of a contract period.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Date/Time |
| Value format | Date/Time Format |
Contract Period Start represents the inclusive start bound
of a contract period.
For example, a time period where Contract Period Start is
'2024-01-01T00:00:00Z' and Contract Period
End is '2025-01-01T00:00:00Z' includes January 1 2024 since Contract
Period Start represents the inclusive start bound, but does not
include January 2 2025 since Contract Period End represents the exclusive end bound.
ContractPeriodStart adheres to the following requirements:
ContractPeriodStart
Contract Period Start
The inclusive start bound of a contract period.
| Constraint | Value |
|---|---|
| Column type | Dimension |
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Date/Time |
| Value format | Date/Time Format |
1.3
Attributes are requirements that apply either across a FOCUS dataset or an
individual column level. An attribute is associated with a dataset or
column in their respective Requirements sections. 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.
A FOCUS dataset
consists of a set of columns that convey information about the charges
incurred with a service provider. Each column describes an aspect of the
charge, including but not limited to:
While FOCUS establishes the core structure and standardizes columns
for consistent reporting of cost and usage data, the diverse and
evolving landscape of service providers and service offerings may
require service providers and data generators to include supplemental
columns in the FOCUS dataset. These additional columns may enable deeper
analysis and provide more detailed descriptions of usage that may not be
fully captured by standard FOCUS dataset columns.
In such cases, service providers and data generators are responsible
for ensuring that their usage and cost data is accurately and
comprehensively represented by including necessary supplemental columns
without duplicating data in FOCUS columns. Rows in a FOCUS dataset may
be aggregated or split differently than non-FOCUS datasets to align with
FOCUS requirements (e.g., Discount Handling), while enriching the
dataset, providers and data generators must maintain the integrity of
FOCUS-defined dimensions and metrics. When performing these
transformations, providers and data generators must ensure the accuracy
of all dimensions and metrics, particularly summable values such as
costs and quantities.
Columns within FOCUS include an ID and a display name. Column IDs are
used in files and database tables and display names can be used in
report output and other descriptive content, like documentation. Column
IDs provided in a FOCUS dataset follow consistent naming and
ordering conventions for FinOps practitioners who consume the data for
analysis, reporting, and other use cases.
All columns defined in the FOCUS specification MUST follow the naming
and ordering requirements listed below.
ColumnHandling
Column Handling
Naming and ordering convention for columns appearing in a FOCUS
dataset.
Id orName suffix in the Column ID.Category suffix MUST bex_Columns that contain currency information in cost data following a
consistent format reduce friction for FinOps practitioners who consume
the data for analysis, reporting, and other use cases.
A currency may be one of the following currency types:
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.
CurrencyFormat
Currency Format
Formatting for currency columns appearing in a FOCUS dataset.
None
The data generator-calculated split cost allocation for data
generator-defined services is a capability that can be offered by data
generators which allocates (or in some cases provides more granular
detail about) a charge to a more granular level. This is accomplished by
taking a charge record present in a FOCUS dataset (origin charge) and
splitting it into multiple charge records (allocated charges) to reflect
the more granular detail, while ensuring the origin charge can be
derived from the combination of allocated charges. This feature is used
by practitioners to conduct chargebacks and better understand the usage
of resources.
DataGeneratorCalculatedSplitCostAllocationHandling
Data Generator-Calculated Split Cost Allocation Handling
An attribute that allows data generators to offer more detailed cost
and usage information based on a method defined and documented by the
data generator, including support for allocating costs in cases where
the usage of a resource might not match the units the resource is
measured in.
None
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.
DateTimeFormat
Date/Time Format
Rules and formatting requirements for date/time-related columns
appearing in a FOCUS
dataset.
None
A discount is a pricing construct where service providers offer a
reduced price for services.
Service providers may have many types of discounts, including but not
limited to commercially negotiated discounts,
commitment
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 service provider to get
reduced prices. The most common example is a commitment
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. To show the impact of purchased discounts on each
discounted row, discount purchases need the purchase amount to be
amortized over the period 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. When a purchase is applicable to
resources, like commitment discounts, the amortized cost of a
resource takes the initial payment and period 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 service 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 Category. One example might
be when a service 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.
DiscountHandling
Discount Handling
Indicates how to include and apply discounts to usage charges or rows
in a FOCUS dataset.
None
JSON Objects extend the Key-Value
Format to add support for complex data types like arrays and nested
key-value pairs. This format is used when the Key-Value Format is
insufficient to represent the complexity, such as when multiple sets of
key-value pairs apply to the same charge record. JSON Objects are also
referred to as maps, trees, or hashtables.
All complex JSON Object columns defined in the FOCUS specification
MUST follow the object formatting requirements listed below.
JsonObjectFormat
JSON Object Format
Rules and formatting requirements for columns appearing in a FOCUS dataset that convey
data as complex, hierarchical objects.
true, false, array, object, ornull.None
FinOps practitioners must be able to reconcile FOCUS datasets with
the corresponding invoices and usage statements they receive from Invoice Issuers. In
practice, this means ensuring that all monetary charges that appear on an invoice
or usage statement — including those not tied to metered usage — are
represented in the FOCUS
dataset. Without this alignment, it becomes difficult to
perform accurate invoice reconciliation, financial reporting, and
chargeback.
This attribute introduces requirements for how charges such as usage,
taxes, credits, refunds, etc, inclusive of support, training, and
marketplace transactions, and any other type of charge should be
captured and categorized. It also defines expectations around the
completeness and consistency of invoice-level totals within the dataset,
enabling FOCUS datasets to be used in a system of record for all
invoiced costs.
InvoiceHandling
Invoice Handling
Indicates how invoice-level charges, including those not
directly tied to usage, should be represented in a FOCUS Cost and Usage
dataset.
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.
KeyValueFormat
Key-Value Format
Rules and formatting requirements for columns appearing in a FOCUS dataset that convey
data as key-value pairs.
true, false, ornull.None
Cost data rows that don't have a
value that can be presented for a column must be handled in a consistent
way to reduce friction for FinOps practitioners who consume the data for
analysis, reporting, and other use cases.
All columns defined in the FOCUS specification MUST follow the null
handling requirements listed below. Custom columns SHOULD also follow
the same formatting requirements.
NullHandling
Null Handling
Indicates how to handle columns that don't have a value.
None
Columns that provide numeric values conforming to specified rules and
formatting requirements ensure clarity, accuracy, and ease of
interpretation for humans and systems. The FOCUS specification does not
require a specific level of precision for numeric values. The level of
precision required for a given column is determined by the provider and
should be part of a data definition published by the provider.
All columns capturing a numeric value, defined in the FOCUS
specification, MUST follow the formatting requirements listed below.
Custom numeric value capturing columns SHOULD adopt the same format
requirements over time.
NumericFormat
Numeric Format
Rules and formatting requirements for numeric columns appearing in a
FOCUS dataset.
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. |
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+ |
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:
Values NOT Meeting Numeric Requirements
None
Columns that capture string values conforming to specified
requirements foster data integrity, interoperability, and consistency,
improve data analysis and reporting, and support reliable data-driven
decision-making.
All columns capturing a string value, defined in the FOCUS
specification, MUST follow the requirements listed below. Custom string
value capturing columns SHOULD adopt the same requirements over
time.
StringHandling
String Handling
Requirements for string-capturing columns appearing in a FOCUS dataset.
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 a FOCUS
dataset.
All columns defined in FOCUS specifying Unit Format as a value format
MUST follow the requirements listed below.
UnitFormat
Unit Format
Indicates standards for expressing measurement units in columns
appearing in a FOCUS dataset.
<plural-units> - "GB", "Seconds"<singular-unit>-<plural-time-units> -<plural-units>/<singular-time-unit> -<quantity> <plural-units> - "1000 Tokens",<plural-units>/<interval> <plural-time-units>Data size unit names MUST be abbreviated using one of the
abbreviations in the following table. For example, a unit name of "TB"
is a valid unit name, and a unit name of "terabyte" is an invalid unit
name. Data size abbreviations can be considered both the singular and
plural form of the unit. For example, "GB" is both the singular and
plural form of the unit "gigabyte", and "GBs" would be an invalid unit
name. Values that exceed 10^18 MUST use the abbreviation for exabit,
exabyte, exbibit, and exbibyte, and values smaller than a byte MUST use
the abbreviation for bit or byte. For example, the abbreviation "YB" for
"yottabyte" is not a valid data size unit name as it represents a value
larger than what is listed in the following table.
The following table lists the valid abbreviations for data size units
from a single bit or byte to 10^18 bits or bytes.
| Data size in bits | Data size in bytes |
|---|---|
| b (bit) = 10^1 | B (byte = 10^1) |
| Kb (kilobit = 10^3) | KB (kilobyte = 10^3) |
| Mb (megabit = 10^6) | MB (megabyte = 10^6) |
| Gb (gigabit = 10^9) | GB (gigabyte = 10^9) |
| Tb (terabit = 10^12) | TB (terabyte = 10^12) |
| Pb (petabit = 10^15) | PB (petabyte = 10^15) |
| Eb (exabit = 10^18) | EB (exabyte = 10^18) |
| Kib (kibibit = 2^10) | KiB (kibibyte = 2^10) |
| Mib (mebibit = 2^20) | MiB (mebibyte = 2^20) |
| Gib (gibibit = 2^30) | GiB (gibibyte = 2^30) |
| Tib (tebibit = 2^40) | TiB (tebibyte = 2^40) |
| Pib (pebibit = 2^50) | PiB (pebibyte = 2^50) |
| Eib (exbibit = 2^60) | EiB (exbibyte = 2^60) |
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 service provider/data generator MAY introduce a new
noun representing a count-based unit. All nouns appearing in units that
are not listed in the recommended values table will be considered
count-based units. A new count-based unit value MUST be capitalized.
| Count |
|---|
| Count |
| Unit |
| Request |
| Token |
| Connection |
| Certificate |
| Domain |
| Core |
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 |
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.
None
1.0-preview
The FOCUS specification defines a metadata structure to be supplied
by data providers to facilitate practitioners' use of FOCUS data. This
metadata includes general information about the dataset artifact.
The metadata includes the following sections:
| Metadata Section | Description |
|---|---|
| Data Generator | Describes the entity delivering the dataset artifact. |
| Dataset Instance | Describes the nature of the dataset artifact. |
| Recency | Describes the recency and completeness of data within the artifact. |
| Schema | Describes the schema of data within the artifact. |
Metadata adheres to the following requirements:
Metadata
Metadata
The FOCUS metadata about the generator of the FOCUS data.
DataGenerator adheres to the following requirements:
DataGenerator
Data Generator
For an example of the FOCUS Data Generator metadata please refer to:
Data Generator Example.
Human-readable name of the entity that generated the dataset
instance. The Data Generator ensures the technical accuracy and delivery
of the data.
DataGenerator property adheres to the following requirements:
DataGenerator
Data Generator
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
The Dataset Instance metadata object provides information about the
dataset instance and
its content. Dataset Instance is a data generator-delivered instance of
a FOCUS Dataset. For example, a Data Generator may provide multiple
datasets utilizing the FOCUS specification, including multiple instances
of the FOCUS Cost and Usage dataset, each representing a different time
granularity.
DatasetInstance adheres to the following requirements:
DatasetInstance
Dataset Instance
For an example of the FOCUS dataset instance metadata, please refer
to: Dataset Instance Metadata
Example.
The Dataset Instance ID is a data generator-specified unique
identifier that represents a specific FOCUS dataset instance provided by
the data generator.
DatasetInstanceId adheres to the following requirements:
DatasetInstanceId
Dataset Instance ID
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | GUID (recommended) |
The human-readable name of the dataset instance as provided by the
data generator.
DatasetInstanceName adheres to the following requirements:
DatasetInstanceName
Dataset Instance Name
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
The identifier of the FOCUS dataset for which the schema and its data
conform to. This indicates which FOCUS dataset the data artifact aligns
with, such as "FOCUS Cost and Usage" or "FOCUS Contract."
The FocusDatasetId property adheres to the following
requirements:
FocusDatasetId
FOCUS Dataset ID
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
The recency metadata object and its contents provide information
about how up-to-date FOCUS datasets are and when they have been
updated.
Recency adheres to the following requirements:
Recency
Recency
Example scenarios include but are not limited to:
For an example of the FOCUS recency metadata, please refer to: Recency Metadata Example.
The Dataset Instance ID provides the reference item to associate
which Dataset Instance the recency metadata is for.
DatasetInstanceId adheres to the following requirements:
DatasetInstanceId
Dataset Instance ID
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | GUID (recommended) |
Dataset Instance Complete provides a boolean value to indicate that
the dataset instance is considered complete by the Data Generator. The
definition of complete is determined by the Data Generator and should be
provided in documentation provided by the Data Generator. For Datasets
that are time series, the Complete value indicates that the time sector
is complete and therefore is located in as key value in a time sector.
For datasets that are not time series, a value of "true" indicates that
the dataset is complete and therefore is a property of the recency
object.
DatasetInstanceComplete adheres to the following requirements:
DatasetInstanceComplete
Dataset Instance Complete
| Constraint | Value |
|---|---|
| Feature level | Conditional |
| Allows nulls | False |
| Data type | Boolean |
| Value format | <not specified> |
Datetime when the data present in the Dataset Instance was
updated.
DatasetInstanceLastUpdated adheres to the following requirements:
DatasetInstanceLastUpdated
Dataset Instance Last Updated
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Date/Time |
| Value format | Date/Time Format |
Datetime the recency metadata object was updated.
RecencyLastUpdated adheres to the following requirements:
RecencyLastUpdated
Recency Last Updated
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Date/Time |
| Value format | Date/Time Format |
The FOCUS recency metadata's Time Sectors provide a list of time
periods and metadata about them. Time Sectors are used when the
associated FOCUS dataset
is defined as a time series dataset (i.e., its dataset artifacts
represent data distributed over time). Each time sector represents a
single time period and the completeness of that time period as it
pertains to the dataset artifact. Time sectors do not represent start
and end dates of the dataset artifact but rather periods of time
relative to the datasets Charge Period Start and Charge Period End.
Length of time sectors can be determined by the Data Generator, though
it is suggested to align time sector periods to the reports time
granularity (Hourly cost reports = hourly time sectors).
TimeSectors adheres to the following requirements:
TimeSectors
Time Sectors
Time Sector Complete provides a boolean value to indicate that the
time sector is considered complete by the DataGenerator. The definition
of complete is determined by the DataGenerator and should be provided in
documentation provided by the DataGenerator.
TimeSectorComplete adheres to the following requirements:
TimeSectorComplete
Time Sector Complete
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Boolean |
| Value format | <not specified> |
Datetime the data in the time sector was last updated.
TimeSectorLastUpdated adheres to the following requirements:
TimeSectorLastUpdated
Time Sector Last Updated
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Date/Time |
| Value format | Date/Time Format |
The Time Sector Start is the datetime of the start of the time
sector.
TimeSectorStart adheres to the following requirements:
TimeSectorStart
Time Sector Start
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Date/Time |
| Value format | Date/Time Format |
The Time Sector End is the datetime of the end of the time sector.
The EndTime MUST be later than the StartTime.
TimeSectorEnd adheres to the following requirements:
TimeSectorEnd
Time Sector End
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Date/Time |
| Value format | Date/Time Format |
The schema metadata object and its content provide information about
the structure of the data provided.
Schema adheres to the following requirements:
There are many scenarios that would result in an update to the Schema
metadata. These scenarios include but are not limited to:
For an example of the FOCUS schema metadata, please refer to: Schema Metadata Example.
Schema
Schema
The Schema ID provides the reference item to associate which Schema
was used for the generation of a FOCUS dataset.
SchemaId adheres to the following requirements:
SchemaId
Schema ID
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | GUID (recommended) |
Date the schema was created.
CreationDate adheres to the following requirements:
CreationDate
Creation Date
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | Date/Time |
| Value format | Date/Time Format |
The version of FOCUS utilized for building the dataset.
FocusVersion adheres to the following requirements:
FocusVersion
FOCUS Version
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
The DataGeneratorVersion may be supplied to declare the version of
logic by which the dataset instance
artifact was generated and is separate from FOCUS Version.
DataGeneratorVersion allows for the provider to specify changes that may
not result in a structural change in the data. It is suggested that the
DataGeneratorVersion use a versioning approach such as SemVer version.
DataGeneratorVersion adheres to the following requirements:
DataGeneratorVersion
Data Generator Version
| Constraint | Value |
|---|---|
| Feature level | Optional |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
The Dataset Instance ID is a unique identifier for the specific
dataset instance provided by the data generator. It identifies the
dataset instance that this schema and the corresponding dataset
artifacts are aligned with.
DatasetInstanceId adheres to the following requirements:
DatasetInstanceId
Dataset Instance ID
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | GUID (recommended) |
The FOCUS metadata schema column definition provides a list of the
columns present in the dataset instance
artifact along with metadata about the columns.
ColumnDefinition adheres to the following requirements:
ColumnDefinition
Column Definition
The name of the column provided in the FOCUS dataset.
ColumnName adheres to the following requirements:
ColumnName
Column Name
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
The data type of the column provided in the FOCUS dataset.
DataType adheres to the following requirements:
DataType
Data Type
| Constraint | Value |
|---|---|
| Feature level | Mandatory |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
The deprecation status of a column in a Dataset Instance.
Deprecated adheres to the following requirements:
Deprecated
Deprecated
| Constraint | Value |
|---|---|
| Feature level | Conditional |
| Allows nulls | False |
| Data type | Boolean |
| Value format | <not specified> |
Numeric Precision is the maximum number of digits for the values in
the column.
NumericPrecision adheres to the following requirements:
NumericPrecision
Numeric Precision
| Constraint | Value |
|---|---|
| Feature level | Recommended |
| Allows nulls | False |
| Data type | Integer |
| Value format | Numeric Format |
The number scale of the data provides the maximum number of digits
after the decimal point in decimal numbers.
NumberScale adheres to the following requirements:
NumberScale
Number Scale
| Constraint | Value |
|---|---|
| Feature level | Recommended |
| Allows nulls | False |
| Data type | Integer |
| Value format | Numeric Format |
The PreviousColumnName field indicates that on that schema the column
where the key is included was renamed.
PreviousColumnName adheres to the following requirements:
PreviousColumnName
Previous Column Name
| Constraint | Value |
|---|---|
| Feature level | Conditional |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
The Provider Tag Prefixes define the list of prefixes used in the tag
name of provider-defined tags. This metadata is
useful for the consumer to identify which tags are provider-defined vs
user-defined.
ProviderTagPrefixes adheres to the following requirements:
ProviderTagPrefixes
Provider Tag Prefixes
| Constraint | Value |
|---|---|
| Feature level | Conditional |
| Allows nulls | False |
| Data type | Collection of Strings |
| Value format | <not specified> |
The string encoding scheme of the column provided in the FOCUS dataset.
StringEncoding adheres to the following requirements:
StringEncoding
StringEncoding
| Constraint | Value |
|---|---|
| Feature level | Conditional |
| Allows nulls | False |
| Data type | String |
| Value format | <not specified> |
The string max length of the data that can be stored in the
column.
StringMaxLength adheres to the following requirements:
StringMaxLength
String Max Length
| Constraint | Value |
|---|---|
| Feature level | Recommended |
| Allows nulls | False |
| Data type | Integer |
| Value format | Numeric Format |
1.0
This specification is based on a set of common FinOps use cases,
which are publicly available at https://focus.finops.org/use-cases/.
Developed by FinOps practitioners, these use cases are organized by
persona and capability, making it easy to find relevant scenarios. Each
use case includes sample SQL queries to help you get started with
implementation.
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.
The charge that was created as the
result of an allocation operation. This is used in the context of Data
Generator-Calculated Split Cost Allocation to identify the charges
that were created from the origin
charge resulting from the application of Data Generator-Calculated
Split Cost Allocation.
The process or formula by which cost is being allocated from an origin charge to produce allocated charges. This is used in
the context of Data
Generator-Calculated Split Cost Allocation which requires
documentation of the method to be provided for any and all allocated
methods used. May also be colloquially referred to as allocation
method.
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 extends beyond the
granularity of the source report.
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.
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.
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.
An identifier that represents the currency that a charge for
resources and/or services was billed in.
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.
A pricing approach where the cost of a particular resource or service
is determined based on predefined quantities or tiers of usage. In these
scenarios, the Pricing Unit and the corresponding Pricing Quantity can
be different from the Consumed Unit and Consumed Quantity.
A capacity reservation is an agreement that secures a dedicated
amount of resources or services for a specified period. This ensures the
reserved capacity is always available and accessible, even if it's not
fully utilized. Customers are typically charged for the reserved
capacity, regardless of actual consumption.
A row in a FOCUS-compatible cost and usage dataset.
The time window for which a charge is effective, inclusive of the
start date and exclusive of the end date. The charge period for
continuous usage should match the time granularity of the dataset (e.g.,
1 hour for hourly, 1 day for daily). The charge period for a non-usage
charge with time boundaries should match the period of eligibility.
A company or organization that provides remote access to computing
resources, infrastructure, or applications for a fee.
A customer's agreement to either spend a defined monetary amount or
consume a specific quantity of resources or services over a specified period.
A billing discount model that offers reduced rates on preselected
SKUs in exchange for an obligated usage or spend amount over a specified
period. Commitment discount
purchases, made upfront and/or with recurring monthly payments are
amortized evenly across predefined charge periods (i.e., hourly), and
unused amounts cannot be carried over to subsequent charge periods.
Commitment discounts are publicly available to customers without special
contract arrangements.
Commitment
Discount Flexibility
A feature of commitment
discounts that may further transform the predetermined amount
of usage purchased or consumed based on additional,
service-provider-specific requirements.
A collection of agreed terms between a service provider and a
customer.
A specific term within a contract that defines a
measurable obligation agreed upon by a provider and a customer, such as
a minimum spend or usage over an agreed period of time.
The agreed-upon unit price for a single Pricing Unit of the associated SKU, inclusive of
negotiated discounts, if present, and exclusive of any other discounts.
This price is denominated in the Billing Currency.
A charge to correct cost or usage data in a previously invoiced billing period.
A financial incentive or allowance granted by a service provider
unrelated to other past/current/future charges.
An abbreviated term for dataset instance
artifact.
A specific implementation of a FOCUS dataset provided by a
data generator. A Data Generator may
provide multiple dataset instances of the same FOCUS dataset,
each with different properties such as time granularity or differing
custom column inclusions. For example, the same 'FOCUS Cost and Usage'
FOCUS dataset may be provided at an hourly or daily time
granularity by a Data Generator. Each would be a distinct Dataset
Instance.
A physical representation of a specific dataset instance
delivered by a data generator.
A specification-defined categorical attribute that provides context
or categorization to billing data.
The amortized cost of the charge after applying all reduced rates,
discounts, and the applicable portion of relevant, prepaid purchases
(one-time or recurring) that covered this charge.
A Date/Time Format value that is not contained within the ending
bound of a time period.
A tag with one tag value chosen from a set of possible tag values
after being processed by a set of service-provider-defined or
user-defined rules.
FinOps Cost
and Usage Specification (FOCUS)
An open-source specification that defines requirements for billing
data.
A structured collection of columns that conforms to the BCP14
criteria established by FOCUS. All columns included must be defined in
the FOCUS Columns section of the specification.
In addition to these standardized columns, data generators may include custom columns
(prefixed with x_) where additional context is needed
beyond what is captured in the defined FOCUS columns. If custom columns
introduce record-splitting (i.e., a single original charge results in
multiple rows), the data generator is responsible for ensuring that all
cost and quantity metrics still meet the aggregation and consistency
rules required by the specification.
The collection of datasets are designed to provide billing insight,
additional context, metadata, mapping, or enrichment information that
enhances the interpretability or completeness.
A Date/Time Format value that is contained within the beginning bound
of a time period.
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.
A common acronym for JavaScript Object Notation, a data format
codified in ECMA-404
as a standard for human-readable, serializable data objects. This data
format is used in FOCUS to communicate multiple pieces of information
about a charge (tags, properties, etc.) in a single column.
The suggested service-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.
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.
A FOCUS-defined column that provides numeric values, allowing for
aggregation operations such as arithmetic operations (sum,
multiplication, averaging etc.) and statistical operations.
A government-issued currency (e.g., US dollars, Euros).
A contractual agreement where a customer commits to specific spend or
usage goals over a specified period in exchange for discounted
rates across varying SKUs. Unlike commitment discounts,
negotiated discounts are typically more customized to customer's
accounts, can be utilized at varying frequencies, and may overlap with
commitment discounts.
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.
The charge that existed prior to an
operation. This is used in the context of Data
Generator-Calculated Split Cost Allocation to identify the charge
that existed prior to the application of Data Generator-Calculated Split
Cost Allocation to produce allocated charges.
Pascal Case (PascalCase, also known as UpperCamelCase) is a format
for identifiers which contain one or more words meaning the words are
concatenated together with no delimiter and the first letter of each
word is capitalized.
A time window, with a specifically defined start and end
date/time.
A long and often painful conversation had by the FOCUS contributors.
Sometimes the name of a thing that we could not yet name. No starchy
root vegetables were harmed during the production of this specification.
We thank potato for its contribution in the creation of this
specification.
An individual who performs FinOps within an organization to maximize
the business value of using cloud and cloud-like services.
A comprehensive list of prices offered by a service provider.
An entity that provides the resources or services available for usage or
purchase.
A return of funds that have previously been charged.
A unique component that incurs a charge.
A row in a FOCUS-compatible cost and usage dataset.
An offering that can be purchased from a service provider, and can
include many types of usage or other charges; eg., a cloud database
service may include compute, storage, and networking charges.
A construct composed of the common properties of a product offering
associated with one or many SKU Prices.
A pricing construct that encompasses SKU properties (e.g.,
functionality and technical specifications), along with core stable
pricing details for a particular SKU, while excluding dynamic or
negotiable pricing elements such as unit price amounts, currency (and
related exchange rates), temporal validity (e.g., effective dates), and
contract- or negotiation-specific factors (e.g., contract or account
identifiers, and negotiable discounts).
A sub account is an optional service-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.
A metadata label assigned to a resource to provide information about
it or to categorize it for organizational and management purposes.
A Resource or Service-Provider-defined construct for grouping
resources and/or other Service-Provider-defined construct that a Tag can
be assigned to.
An agreement specified on a contract.
A proprietary currency (e.g., credits, tokens) issued by service
providers and independent of government regulation.
This section is non-normative.
A commitment
discount is a billing discount model that offers reduced rates
on preselected SKUs in exchange for
an obligated usage or spend amount over a specified period. Commitment
discounts typically consist of purchase and usage records within
cost and usage datasets.
Usage-based commitment discounts obligate a customer to a
predetermined amount of usage over a specified period. In some cases, usage-based
commitment discounts also feature commitment discount
flexibility which may expand the types of resources that a commitment
discount can cover. It is important to note when mixing
commitment discounts with and without commitment discount
flexibility, the CommitmentDiscountUnit should reflect
this difference.
Spend-based commitment discounts obligate a customer to a
predetermined amount of spend over a specified period. In the usage examples
below, each row measures the
monetary amount of the hourly commit consumed by the commitment
discount, so the CommitmentDiscountUnit chosen is "USD", or the billing currency.
While customers are bound to the period of a commitment
discount, service providers offer some or all of the following
payment options before and/or during the period:
For example, if a customer buys a 1-year, spend-based commitment
discount with a $1.00 hourly commit and pays with the partial
option, the commitment discount's payment consists of a
one-time purchase in the beginning of the period and
monthly recurring purchases with the following totals:
24 hours * 365 days * $1.00 * 0.5)24 hours * 365 days * $1.00 / 12 months)Commitment discounts follow a "use-it-or-lose-it" model where the amortization of a
commitment discount's purchase applies evenly to eligible
resources over each charge period of the
period.
For example, if a customer buys a spend-based commitment
discount with a $1.00 hourly commit in January (31 days), only
$1.00 is eligible for consumption for each hourly charge
period. If a customer has eligible resources running
during this charge period, an amount of up to $1.00 will be
allocated to these resources. Conversely, if a customer does
not have eligible resources running that fully take advantage
of this $1.00 during this charge period, then some or all of
this amount will go to waste.
Within the FOCUS specification, the following examples demonstrate
how a commitment discount appears across various payment and
usage scenarios.
All commitment discount purchases appear with a positive BilledCost, PricingCategory as "Standard", and with the
commitment discount's id populating both the ResourceId and CommitmentDiscountId value. One-time
purchases appear as a single record with ChargeCategory as "Purchase", ChargeFrequency as "One-Time", and the total
quantity and units for commitment discount's period
reflected as CommitmentDiscountQuantity and
CommitmentDiscountUnit, respectively.
Recurring purchases are allocated across all corresponding charge
periods of the period when ChargeCategory is "Purchase",
ChargeFrequency is "Recurring", and CommitmentDiscountQuantity and
CommitmentDiscountUnit are reflected only for that charge
period.
Using the same commitment discount example as above with a
one-year, spend-based commitment discount with a $1.00 hourly
commit purchased on Jan 1, 2023, various purchase options are
available:
The entire commitment discount is billed once
during the first charge period of the period for
$8,670 (derived as
24 hours * 365 days * $1.00).
The commitment discount is billed across all 8,760
(24 hours * 365 days) charge periods of the
period with $1.00 allocated to each charge period over
the period.
This example shows the first three hourly rows of 8,760 total rows
that are all the same except for the incrementing monthly and hourly
timeframes denoted in the Billing Period and Charge Period columns,
respectively.
With a 50/50 split, half of the commitment is billed once
during the first charge period of the period for
$4,380 (derived as
24 hours * 182.5 days * $1.00), and the other
half is billed across each charge period over the commitment
period, derived as
($1.00 * 8,760 hours * 0.5). Amortized costs
incur half of the amount (i.e., $0.50) from the one-time purchase and
the other half from the recurring purchase.
This example shows the first three hourly rows of 8,760 total rows
that are all the same except for the incrementing monthly and hourly
timeframes denoted in the Billing Period and Charge Period columns,
respectively.
Amortization of commitment discounts occur
similarly regardless of how commitment discount purchases are
made. The same usage-based or spend-based amount is applied evenly
across all charge periods and potentially allocated to eligible
resources. Continuing with the same commitment
discount example, a one-year, spend-based commitment
discount with a $1.00 hourly commit and 1 resource (for
simplicity) yields 4 types of scenarios that can occur during a
charge period:
In this scenario, one eligible resource runs for the full
hour and consumes $1.00, so one row allocated to the
resource is produced.
In this situation, the full eligible, $1.00 amount remained
unutilized and results in 1 unused row. In this scenario, it is
important to note that while CommitmentDiscountQuantity is not because
$1 was still drawn down by the commitment discount even though,
no resource was allocated, so ConsumedQuantity and ConsumedUnit are null.
In this scenario, one eligible resource runs for the full
hour and consumes $0.75 of the $1.00 allocation. One row shows
$0.75 to a resource, and the other row shows that
$0.25 was unused.
In this scenario, one eligible resource runs for the full
hour and is charged $1.50. One row shows that $1.00 was
amortized from the commitment discount, and the other
shows that $0.50 was charged as standard, on-demand spend.
A usage-based commitment
discount obligates a customer to a usage amount for one or more
related SKUs in return for reduced rates. For example, when a
usage-based commitment discount is purchased to cover a
specific database SKU, this commitment will cover every hour over the
period where at least one instance of this SKU is running. The
usage-based commitment can cover 1 resource over the hour, or in the
case of commitment
discount flexibility, it can cover a portion of 1 resource or
multiple resources at a time.
When mixing usage-based commitment discounts with and without
commitment discount flexibility and CommitmentDiscountQuantity
measured by time, it is important to differentiate the CommitmentDiscountUnit for
each type of commitment discount. In each scenario below,
commitment discounts without commitment discount
flexibility applied use "Hour" as the
CommitmentDiscountUnit, and conversely commitment discounts
with commitment discount flexibility applied use
"Normalized Hour" as the CommitmentDiscountUnit.
For more details on exactly how commitment discounts
purchase and usage rows appear with and without commitment discount
flexibility, see the following scenarios:
For this example, fictitious service provider, TinyCloud,
offers the following SKU catalog which is used in the scenario
below.
| Service | Sku Id | Sku Price Id | Sku Price Unit Price | Normalization Factor |
|---|---|---|---|---|
| Compute | VM_SMALL | VM_SMALL_COMMITTED_PURCHASE_NO_UPFRONT | $0.50 | 1 |
| Compute | VM_MEDIUM | VM_MEDIUM_COMMITTED_PURCHASE_NO_UPFRONT | $1.00 | 2 |
| Compute | VM_LARGE | VM_LARGE_COMMITTED_PURCHASE_NO_UPFRONT | $1.50 | 3 |
| Compute | VM_XLARGE | VM_XLARGE_COMMITTED_PURCHASE_NO_UPFRONT | $2.00 | 4 |
| Compute | VM_SMALL | VM_SMALL_COMMITTED_HOUR | $0.50 | 1 |
| Compute | VM_MEDIUM | VM_MEDIUM_COMMITTED_HOUR | $1.00 | 2 |
| Compute | VM_LARGE | VM_LARGE_COMMITTED_HOUR | $1.50 | 3 |
| Compute | VM_XLARGE | VM_XLARGE_COMMITTED_HOUR | $2.00 | 4 |
| Compute | VM_SMALL | VM_SMALL_ON_DEMAND_HOUR | $1.00 | 1 |
| Compute | VM_MEDIUM | VM_MEDIUM_ON_DEMAND_HOUR | $2.00 | 2 |
| Compute | VM_LARGE | VM_LARGE_ON_DEMAND_HOUR | $3.00 | 3 |
| Compute | VM_XLARGE | VM_XLARGE_ON_DEMAND_HOUR | $4.00 | 4 |
The above SKU Catalog shows that this service provider only has 1
service that offers 4 virtual machine SKUs at various list rates, commitment discount
rates, and normalization factors. Each SKU's normalization factor
classifies its relative size to its commitment discount rate.
Usage-based commitment discounts with commitment discount
flexibility can fully cover any combination of 1 or more SKUs
where the sum of their normalization factor is less than or equal to the
normalization factor of the commitment discount.
For this example, fictitious service provider, TinyCloud,
offers the following SKU catalog which is used in the scenario
below.
| Service | Sku Id | Sku Price Id | Sku Price Unit Price | Normalization Factor |
|---|---|---|---|---|
| Compute | VM_SMALL | VM_SMALL_COMMITTED_PURCHASE_NO_UPFRONT | $0.50 | 1 |
| Compute | VM_MEDIUM | VM_MEDIUM_COMMITTED_PURCHASE_NO_UPFRONT | $1.00 | 2 |
| Compute | VM_LARGE | VM_LARGE_COMMITTED_PURCHASE_NO_UPFRONT | $1.50 | 3 |
| Compute | VM_XLARGE | VM_XLARGE_COMMITTED_PURCHASE_NO_UPFRONT | $2.00 | 4 |
| Compute | VM_SMALL | VM_SMALL_COMMITTED_HOUR | $0.50 | 1 |
| Compute | VM_MEDIUM | VM_MEDIUM_COMMITTED_HOUR | $1.00 | 2 |
| Compute | VM_LARGE | VM_LARGE_COMMITTED_HOUR | $1.50 | 3 |
| Compute | VM_XLARGE | VM_XLARGE_COMMITTED_HOUR | $2.00 | 4 |
| Compute | VM_SMALL | VM_SMALL_ON_DEMAND_HOUR | $1.00 | 1 |
| Compute | VM_MEDIUM | VM_MEDIUM_ON_DEMAND_HOUR | $2.00 | 2 |
| Compute | VM_LARGE | VM_LARGE_ON_DEMAND_HOUR | $3.00 | 3 |
| Compute | VM_XLARGE | VM_XLARGE_ON_DEMAND_HOUR | $4.00 | 4 |
The above SKU Catalog shows that this service provider only has 1
service that offers 4 virtual machine SKUs at various list unit prices,
commitment discount
unit prices, and normalization factors. Each SKU's normalization factor
classifies its relative size to its commitment discount unit
price. Usage-based commitment discounts with commitment discount
flexibility can fully cover any combination of 1 or more SKUs
where the sum of their normalization factor is less than or equal to the
normalization factor of the commitment discount.
For this example, fictitious service provider, TinyCloud,
offers the following SKU catalog which is used in the scenario
below.
| Service | Sku Id | Sku Price Id | Sku Price Unit Price | Normalization Factor |
|---|---|---|---|---|
| Compute | VM_SMALL | VM_SMALL_COMMITTED_PURCHASE_NO_UPFRONT | $0.50 | 1 |
| Compute | VM_MEDIUM | VM_MEDIUM_COMMITTED_PURCHASE_NO_UPFRONT | $1.00 | 2 |
| Compute | VM_LARGE | VM_LARGE_COMMITTED_PURCHASE_NO_UPFRONT | $1.50 | 3 |
| Compute | VM_XLARGE | VM_XLARGE_COMMITTED_PURCHASE_NO_UPFRONT | $2.00 | 4 |
| Compute | VM_SMALL | VM_SMALL_COMMITTED_HOUR | $0.50 | 1 |
| Compute | VM_MEDIUM | VM_MEDIUM_COMMITTED_HOUR | $1.00 | 2 |
| Compute | VM_LARGE | VM_LARGE_COMMITTED_HOUR | $1.50 | 3 |
| Compute | VM_XLARGE | VM_XLARGE_COMMITTED_HOUR | $2.00 | 4 |
| Compute | VM_SMALL | VM_SMALL_ON_DEMAND_HOUR | $1.00 | 1 |
| Compute | VM_MEDIUM | VM_MEDIUM_ON_DEMAND_HOUR | $2.00 | 2 |
| Compute | VM_LARGE | VM_LARGE_ON_DEMAND_HOUR | $3.00 | 3 |
| Compute | VM_XLARGE | VM_XLARGE_ON_DEMAND_HOUR | $4.00 | 4 |
The above SKU catalog shows that this service provider only has 1
service that offers 4 virtual machine SKUs at various list rates,
commitment discount rates, and normalization factors. Each
SKU's normalization factor classifies its relative size to its
commitment discount rate. Usage-based commitment discounts
with commitment discount
flexibility can fully cover any combination of 1 or more SKUs
where the sum of their normalization factor is less than or equal to the
normalization factor of the commitment discount.
For this example, fictitious service provider, TinyCloud,
offers the following SKU catalog which is used in the scenario
below.
| Service | Sku Id | Sku Price Id | Sku Price Unit Price | Normalization Factor |
|---|---|---|---|---|
| Compute | VM_SMALL | VM_SMALL_COMMITTED_PURCHASE_NO_UPFRONT | $0.50 | 1 |
| Compute | VM_MEDIUM | VM_MEDIUM_COMMITTED_PURCHASE_NO_UPFRONT | $1.00 | 2 |
| Compute | VM_LARGE | VM_LARGE_COMMITTED_PURCHASE_NO_UPFRONT | $1.50 | 3 |
| Compute | VM_XLARGE | VM_XLARGE_COMMITTED_PURCHASE_NO_UPFRONT | $2.00 | 4 |
| Compute | VM_SMALL | VM_SMALL_COMMITTED_HOUR | $0.50 | 1 |
| Compute | VM_MEDIUM | VM_MEDIUM_COMMITTED_HOUR | $1.00 | 2 |
| Compute | VM_LARGE | VM_LARGE_COMMITTED_HOUR | $1.50 | 3 |
| Compute | VM_XLARGE | VM_XLARGE_COMMITTED_HOUR | $2.00 | 4 |
| Compute | VM_SMALL | VM_SMALL_ON_DEMAND_HOUR | $1.00 | 1 |
| Compute | VM_MEDIUM | VM_MEDIUM_ON_DEMAND_HOUR | $2.00 | 2 |
| Compute | VM_LARGE | VM_LARGE_ON_DEMAND_HOUR | $3.00 | 3 |
| Compute | VM_XLARGE | VM_XLARGE_ON_DEMAND_HOUR | $4.00 | 4 |
The above SKU Catalog shows that this service provider only has 1
service that offers 4 virtual machine SKUs at various list rates,
commitment discount rates, and normalization factors. Each
SKU's normalization factor classifies its relative size to its
commitment discount rate. Usage-based commitment discounts
with commitment discount
flexibility can fully cover any combination of 1 or more SKUs
where the sum of their normalization factor is less than or equal to the
normalization factor of the commitment discount.
The following sections contain examples of metadata provided by a
hypothetical FOCUS data generator called ACME to supply the required
reference between the FOCUS dataset
artifacts and the Metadata. Data
Generator implementations will vary on how the metadata is disseminated;
however, the data generator's chosen metadata delivery approach should
be able to support the structure represented in this example.
In this example, the data generator supports delivery of FOCUS data
via file export to a data storage system. It uses JSON as the format for
providing the metadata. The data generator delivers data every 12 hours
into a path structure described below:
| Type of data | Path |
|---|---|
| Export location | /FOCUS |
| Metadata location | /FOCUS/metadata |
| Cost data location | /FOCUS/data |
Here are some metadata examples for various scenarios:
Acme provides metadata about the data generator as a part of their
FOCUS data export. They provide the relevant data via the Data Generator schema object.
Metadata can be provided at a location such as
/FOCUS/metadata/data_generator.json.
The updated Data Generator-related metadata could look like this:
{
"DataGenerator": "Acme"
}ACME provides two FOCUS datasets: Cost and Usage and Contract. Each
Schema metadata object includes the Dataset metadata to indicate which FOCUS Dataset the
Schema conforms to.
Metadata can be provided at a location such as
/FOCUS/metadata/schemas/schema-1234-abcde-12345-abcde-12345.json.
The schema for the data artifact conforming to the dataset FOCUS Cost
and Usage.
{
"SchemaId": "1234-abcde-12345-abcde-12345",
"FocusVersion": "1.0",
"CreationDate": "2024-01-01T12:01:03.083z",
"DatasetInstanceId": "178151-dbad145e-178151-dbad145e-178151",
"ColumnDefinition": [
{
"ColumnName": "BillingAccountId",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "BillingAccountName",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "ChargePeriodStart",
"DataType": "DATETIME"
},
{
"ColumnName": "ChargePeriodEnd",
"DataType": "DATETIME"
},
{
"ColumnName": "BilledCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "EffectiveCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "Tags",
"DataType": "JSON",
"ProviderTagPrefixes": ["acme", "ac"]
}
]
}The schema for the data artifact conforming to the dataset FOCUS
Contracts.
{
"SchemaId": "1234-abcde-12345-abcde-12345",
"FocusVersion": "1.0",
"CreationDate": "2024-01-01T12:01:03.083z",
"DatasetInstanceId": "178151-dbad145e-178151-dbad145e-246811",
"ColumnDefinition": [
{
"ColumnName": "ContractId",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "OverColumnName",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
}
]
}ACME has decided to deprecate columns prior to removal from their
FOCUS data export. The column for deprecation is x_awesome_column3. The
data generator creates a new Schema object to
represent the new schema, with a unique SchemaId.
Metadata can be provided at a location such as
/FOCUS/metadata/schemas/schema-34567-abcde-34567-abcde-34567.json.
The updated schema-related metadata could look like this:
{
"SchemaId": "34567-abcde-34567-abcde-34567",
"FocusVersion": "1.0",
"CreationDate": "2024-03-02T12:01:03.083z",
"DatasetInstanceId": "178151-dbad145e-178151-dbad145e-178151",
"ColumnDefinition": [
{
"ColumnName": "BillingAccountId",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "BillingAccountName",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "ChargePeriodStart",
"DataType": "DATETIME"
},
{
"ColumnName": "ChargePeriodEnd",
"DataType": "DATETIME"
},
{
"ColumnName": "BilledCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "EffectiveCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "Tags",
"DataType": "JSON",
"ProviderTagPrefixes": ["acme", "ac"]
},
{
"ColumnName": "x_awesome_column1",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "x_awesome_column2",
"DataType": "DATETIME"
},
{
"ColumnName": "x_awesome_column3",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8",
"Deprecated": true
}
]
}For an example of how ACME ensures the schema metadata reference
requirement is met see: Schema Metadata to FOCUS Data
Reference
ACME has decided to rename a column in their FOCUS data export. The
column for rename is x_awesome_column1 and will be renamed to
x_awesome_column_one. The data generator creates a new Schema object to represent the new schema, with a
unique SchemaId. After this schema definition is
created if the data generator creates another schema, the
PreviousColumnName is removed.
Metadata can be provided at a location such as
/FOCUS/metadata/schemas/schema-34567-abcde-34567-abcde-34567.json.
The updated schema related metadata for the schema where the rename
took place could look like this:
{
"SchemaId": "34567-abcde-34567-abcde-34567",
"FocusVersion": "1.0",
"CreationDate": "2024-03-02T12:01:03.083z",
"DatasetInstanceId": "178151-dbad145e-178151-dbad145e-178151",
"ColumnDefinition": [
{
"ColumnName": "BillingAccountId",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "BillingAccountName",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "ChargePeriodStart",
"DataType": "DATETIME"
},
{
"ColumnName": "ChargePeriodEnd",
"DataType": "DATETIME"
},
{
"ColumnName": "BilledCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "EffectiveCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "Tags",
"DataType": "JSON",
"ProviderTagPrefixes": ["acme", "ac"]
},
{
"ColumnName": "x_awesome_column_one",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8",
"PreviousColumnName": "x_awesome_column1"
},
{
"ColumnName": "x_awesome_column2",
"DataType": "DATETIME"
},
{
"ColumnName": "x_awesome_column3",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8",
"Deprecated": true
}
]
}The subsequent new schema metadata after the rename could look like
this:
{
"SchemaId": "34567-abcde-34567-abcde-34567",
"FocusVersion": "1.0",
"CreationDate": "2024-03-02T12:01:03.083z",
"ColumnDefinition": [
{
"ColumnName": "BillingAccountId",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "BillingAccountName",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "ChargePeriodStart",
"DataType": "DATETIME"
},
{
"ColumnName": "ChargePeriodEnd",
"DataType": "DATETIME"
},
{
"ColumnName": "BilledCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "EffectiveCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "Tags",
"DataType": "JSON",
"ProviderTagPrefixes": ["acme", "ac"]
},
{
"ColumnName": "x_awesome_column_one",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "x_awesome_column2",
"DataType": "DATETIME"
},
{
"ColumnName": "x_awesome_column3",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8",
"Deprecated": true
}
]
}For an example of how ACME ensures the schema metadata reference
requirement is met see: Schema Metadata to FOCUS Data
Reference
ACME has only provided one Schema for their
FOCUS data export. ACME provides a directory of schemas and each schema
is a single file. Acme provides a file representing the schema for the
data they provide.
Metadata can be provided at a location such as
/FOCUS/metadata/schemas/schema-1234-abcde-12345-abcde-12345.json.
The updated schema-related metadata could look like this:
{
"SchemaId": "1234-abcde-12345-abcde-12345",
"FocusVersion": "1.0",
"CreationDate": "2024-01-01T12:01:03.083z",
"DatasetInstanceId": "178151-dbad145e-178151-dbad145e-178151",
"ColumnDefinition": [
{
"ColumnName": "BillingAccountId",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "BillingAccountName",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "ChargePeriodStart",
"DataType": "DATETIME"
},
{
"ColumnName": "ChargePeriodEnd",
"DataType": "DATETIME"
},
{
"ColumnName": "BilledCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "EffectiveCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "Tags",
"DataType": "JSON",
"ProviderTagPrefixes": ["acme", "ac"]
}
]
}ACME makes a change to the Schema of their data
exports. For each FOCUS data export, ACME includes a metadata reference
to the schema object. Because multiple files are provided in each
export, Acme has elected to include a metadata file in each export
folder that includes the FOCUS schema reference that applies to the data
export files within that folder. When the schema changes, they include
the new Schema ID in their export metadata file
of the new folder.
Metadata can be provided at a location such as
/FOCUS/data/export1-metadata.json
The export metadata could look like this:
{
"SchemaId":"1234-abcde-12345-abcde-12345",
"data_location":
[
{
"filepath": "/FOCUS/data/export1/export1-part1.csv",
"total_bytes": 9010387,
"total_rows": 4450
},
{
"filepath": "/FOCUS/data/export1/export1-part2.csv",
"total_bytes": 9010387,
"total_rows": 4450
},
{
"filepath": "/FOCUS/data/export1/export1-part3.csv",
"total_bytes": 9010387,
"total_rows": 4450
},
{
"filepath": "/FOCUS/data/export1/export1-part4.csv",
"total_bytes": 9010387,
"total_rows": 4450
}
]
}New metadata can be provided at a location such as
/FOCUS/data/export2-metadata.json.
The new export metadata could look like this:
{
"SchemaId":"23456-abcde-23456-abcde-23456",
"data_location":
[
{
"filepath": "/FOCUS/data/export2/export2-part1.csv",
"total_bytes": 9010387,
"total_rows": 4450
},
{
"filepath": "/FOCUS/data/export2/export2-part2.csv",
"total_bytes": 9010387,
"total_rows": 4450
},
{
"filepath": "/FOCUS/data/export2/export2-part3.csv",
"total_bytes": 9010387,
"total_rows": 4450
},
{
"filepath": "/FOCUS/data/export2/export2-part4.csv",
"total_bytes": 9010387,
"total_rows": 4450
}
]
}ACME specifies the optional metadata property Data Generator Version in their Schema object. They made a change to the Cost and
Usage FOCUS dataset they
produce that does not adopt a new FOCUS Version, nor does it make a
change to the included columns, but does impact values in the data. This
example illustrates that Data Generator Version changes are independent
of column changes, however data generator version changes may include
column changes.
The data generator creates a new schema object to represent the new
schema. The data generator includes both the FOCUS Version and Data
Generator Version in the schema object.
Metadata can be provided at a location such as
/FOCUS/metadata/schemas/schema-56789-abcde-56789-abcde-56789.json.
The updated schema-related metadata could look like this:
{
"SchemaId": "56789-abcde-56789-abcde-56789",
"FocusVersion": "1.1",
"DataGeneratorVersion": "2.4",
"CreationDate": "2024-05-02T12:01:03.083z",
"DatasetInstanceId": "178151-dbad145e-178151-dbad145e-178151",
"ColumnDefinition": [
{
"ColumnName": "BillingAccountId",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "BillingAccountName",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "ChargePeriodStart",
"DataType": "DATETIME"
},
{
"ColumnName": "ChargePeriodEnd",
"DataType": "DATETIME"
},
{
"ColumnName": "BilledCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "EffectiveCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "Tags",
"DataType": "JSON",
"DataGeneratorTagPrefixes": ["acme", "ac"]
},
{
"ColumnName": "x_awesome_column1",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "x_awesome_column2",
"DataType": "DATETIME"
}
]
}For an example of how ACME ensures the schema metadata reference
requirement is met see: Schema Metadata to FOCUS Data
Reference
ACME has decided to add additional columns to their FOCUS data
export. The new columns are x_awesome_column1, x_awesome_column2, and
x_awesome_column3. The data generator creates a new Schema object to represent the new schema, this
schema object has a unique SchemaId. The
subsequent data exports that use the new schema include the new schema's
id as a reference to their corresponding schema object.
Metadata can be provided at a location such as
/FOCUS/metadata/schemas/schema-23456-abcde-23456-abcde-23456.json.
The updated schema-related metadata could look like this:
{
"SchemaId": "23456-abcde-23456-abcde-23456",
"FocusVersion": "1.0",
"CreationDate": "2024-02-02T12:01:03.083z",
"DatasetInstanceId": "178151-dbad145e-178151-dbad145e-178151",
"ColumnDefinition": [
{
"ColumnName": "BillingAccountId",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "BillingAccountName",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "ChargePeriodStart",
"DataType": "DATETIME"
},
{
"ColumnName": "ChargePeriodEnd",
"DataType": "DATETIME"
},
{
"ColumnName": "BilledCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "EffectiveCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "Tags",
"DataType": "JSON",
"ProviderTagPrefixes": ["awecorp", "ac"]
},
{
"ColumnName": "x_awesome_column1",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "x_awesome_column2",
"DataType": "DATETIME"
},
{
"ColumnName": "x_awesome_column3",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
}
]
}For an example of how ACME ensures the schema metadata reference
requirement is met see: Schema Metadata to FOCUS Data
Reference
ACME has decided to remove columns from their FOCUS data export. The
column removed is x_awesome_column3. The data generator creates a new Schema object to represent the new schema, with a
unique SchemaId.
Metadata can be provided at a location such as
/FOCUS/metadata/schemas/schema-34567-abcde-34567-abcde-34567.json.
The updated schema related metadata could look like this:
{
"SchemaId": "34567-abcde-34567-abcde-34567",
"FocusVersion": "1.0",
"CreationDate": "2024-03-02T12:01:03.083z",
"DatasetInstanceId": "178151-dbad145e-178151-dbad145e-178151",
"ColumnDefinition": [
{
"ColumnName": "BillingAccountId",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "BillingAccountName",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "ChargePeriodStart",
"DataType": "DATETIME"
},
{
"ColumnName": "ChargePeriodEnd",
"DataType": "DATETIME"
},
{
"ColumnName": "BilledCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "EffectiveCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "Tags",
"DataType": "JSON",
"ProviderTagPrefixes": ["acme", "ac"]
},
{
"ColumnName": "x_awesome_column1",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "x_awesome_column2",
"DataType": "DATETIME"
}
]
}For an example of how ACME ensures the schema metadata reference
requirement is met see: Schema Metadata to FOCUS Data
Reference
ACME has decided to change the datatype of column x_awesome_column1
from a string to a number. ACME creates a new Schema object with the modification to
x_awesome_column2.
Metadata can be provided at a location such as
/FOCUS/metadata/schemas/schema-67891-abcde-67891-abcde-67891.json.
The updated schema-related metadata could look like this:
{
"SchemaId": "67891-abcde-67891-abcde-67891",
"FocusVersion": "1.0",
"CreationDate": "2024-06-02T12:01:03.083z",
"DatasetInstanceId": "178151-dbad145e-178151-dbad145e-178151",
"ColumnDefinition": [
{
"ColumnName": "BillingAccountId",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "BillingAccountName",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "ChargePeriodStart",
"DataType": "DATETIME"
},
{
"ColumnName": "ChargePeriodEnd",
"DataType": "DATETIME"
},
{
"ColumnName": "BilledCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "EffectiveCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "Tags",
"DataType": "JSON",
"ProviderTagPrefixes": ["acme", "ac"]
},
{
"ColumnName": "x_awesome_column1",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "x_awesome_column2",
"DataType": "DATETIME"
}
]
}For an example of how ACME ensures the schema metadata reference
requirement is met see: Schema Metadata to FOCUS Data
Reference
ACME has discovered that while their export includes the column
x_awesome_column3, the Schema metadata does not
include this column. In this case, the data generator fixes the metadata
in the existing schema object and does not need to create a new schema
object. Reference metadata remains the same.
Metadata can be provided at a location such as
/FOCUS/metadata/schemas/schema-34567-abcde-34567-abcde-34567.json.
The updated schema-related metadata could look like this:
{
"SchemaId": "34567-abcde-34567-abcde-34567",
"FocusVersion": "1.0",
"CreationDate": "2024-03-02T12:01:03.083z",
"DatasetInstanceId": "178151-dbad145e-178151-dbad145e-178151",
"ColumnDefinition": [
{
"ColumnName": "BillingAccountId",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "BillingAccountName",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "ChargePeriodStart",
"DataType": "DATETIME"
},
{
"ColumnName": "ChargePeriodEnd",
"DataType": "DATETIME"
},
{
"ColumnName": "BilledCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "EffectiveCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "Tags",
"DataType": "JSON",
"ProviderTagPrefixes": ["acme", "ac"]
},
{
"ColumnName": "x_awesome_column1",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "x_awesome_column2",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
}
]
}ACME's previous exports used FOCUS version 1.0. They are now going to
adopt FOCUS version 1.1. It is required that they create a new schema
metadata object which specifies the new FOCUS version via the FOCUS Version property—regardless of schema
changes. In this example, the new FOCUS version adoption doesn't include
columns changes. This is to illustrate that FOCUS version changes are
independent of column changes, however, this scenario is unlikely.
Metadata can be provided at a location such as
/FOCUS/metadata/schemas/schema-45678-abcde-45678-abcde-45678.json.
The updated schema-related metadata could look like this:
{
"SchemaId": "45678-abcde-45678-abcde-45678",
"FocusVersion": "1.1",
"CreationDate": "2024-04-02T12:01:03.083z",
"DatasetInstanceId": "178151-dbad145e-178151-dbad145e-178151",
"ColumnDefinition": [
{
"ColumnName": "BillingAccountId",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "BillingAccountName",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "ChargePeriodStart",
"DataType": "DATETIME"
},
{
"ColumnName": "ChargePeriodEnd",
"DataType": "DATETIME"
},
{
"ColumnName": "BilledCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "EffectiveCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "Tags",
"DataType": "JSON",
"ProviderTagPrefixes": ["acme", "ac"]
},
{
"ColumnName": "x_awesome_column1",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "x_awesome_column2",
"DataType": "DATETIME"
}
]
}For an example of how ACME ensures the schema metadata reference
requirement is met see: Schema Metadata to FOCUS Data
Reference
ACME specifies the optional metadata property Data Generator Version in their Schema object. Their data generator version 2.2
supported FOCUS version 1.0. They are now going to adopt FOCUS Version
1.1 which requires that they update their Data Generator Version when
updating the FOCUS Version. They create a new schema object designating
that both properties have changed. In this example, the adoption of the
new FOCUS version doesn't include additional columns. This is to
illustrate that Data Generator Version can change independent of column
changes; however, this scenario is unlikely.
The data generator creates a new schema object to represent the new
schema. The data generator includes both the new FOCUS Version and Data
Generator Version in the schema object.
Metadata can be provided at a location such as
/FOCUS/metadata/schemas/schema-45678-abcde-45678-abcde-45678.json.
The updated schema-related metadata could look like this:
{
"SchemaId": "45678-abcde-45678-abcde-45678",
"FocusVersion": "1.1",
"DataGeneratorVersion": "2.3",
"name": "New Columns",
"CreationDate": "2024-04-02T12:01:03.083z",
"DatasetInstanceId": "178151-dbad145e-178151-dbad145e-178151",
"ColumnDefinition": [
{
"ColumnName": "BillingAccountId",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "BillingAccountName",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "ChargePeriodStart",
"DataType": "DATETIME"
},
{
"ColumnName": "ChargePeriodEnd",
"DataType": "DATETIME"
},
{
"ColumnName": "BilledCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "EffectiveCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "Tags",
"DataType": "JSON",
"ProviderTagPrefixes": ["acme", "ac"]
},
{
"ColumnName": "x_awesome_column1",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "x_awesome_column2",
"DataType": "DATETIME"
}
]
}For reference, the prior schema object looked like this:
{
"SchemaId": "34567-abcde-34567-abcde-34567",
"FocusVersion": "1.0",
"DataGeneratorVersion": "2.2",
"CreationDate": "2024-04-02T12:01:03.083z",
"Dataset": "FOCUS Cost and Usage",
"ColumnDefinition": [
{
"ColumnName": "BillingAccountId",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "BillingAccountName",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "ChargePeriodStart",
"DataType": "DATETIME"
},
{
"ColumnName": "ChargePeriodEnd",
"DataType": "DATETIME"
},
{
"ColumnName": "BilledCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "EffectiveCost",
"DataType": "DECIMAL",
"NumericPrecision": 20,
"NumberScale": 10
},
{
"ColumnName": "Tags",
"DataType": "JSON",
"ProviderTagPrefixes": ["acme", "ac"]
},
{
"ColumnName": "x_awesome_column1",
"DataType": "STRING",
"StringMaxLength": 64,
"StringEncoding": "UTF-8"
},
{
"ColumnName": "x_awesome_column2",
"DataType": "DATETIME"
}
]
}For an example of how ACME ensures the schema metadata reference
requirement is met see: Schema Metadata to FOCUS Data
Reference
ACME provides three dataset instances: "Cost and Usage Daily," "Cost
and Usage Hourly," and "Contract Commitments," corresponding to the
FOCUS datasets Cost and Usage and Contract Commitment. ACME also
provides a metadata directory containing a single file with metadata for
each dataset instance.
Metadata can be provided at a location such as
/FOCUS/metadata/dataset_instances.json.
The updated schema-related metadata could look like this:
[
{
"DatasetInstanceId": "178151-dbad145e-178151-dbad145e-246811",
"DatasetInstanceName": "Contract Commitments Report",
"FocusDatasetId": "ContractCommitment"
},
{
"DatasetInstanceId": "178151-dbad145e-178151-dbad145e-178151",
"DatasetInstanceName": "Cost and Usage Daily",
"FocusDatasetId": "CostAndUsage"
},
{
"DatasetInstanceId": "178151-ja23h1287-387151-dbad145e-134657",
"DatasetInstanceName": "Cost and Usage Hourly",
"FocusDatasetId": "CostAndUsage"
}
]ACME has elected to add recency metadata to its FOCUS data export.
ACME provides a directory of recency metadata for each dataset they
provide and each recency object is a single file.
Metadata can be provided at a location such as
/FOCUS/metadata/recency/recency-1234-abcde-12345-abcde-12345.json.
The provided recency metadata for a time series dataset could look
like this:
{
"DatasetInstanceId": "1234-abcde-12345-abcde-12345",
"RecencyLastUpdateDate": "2025-01-291T12:01:03.083z",
"TimeSectors": [
{
"TimeSectorStart": "2025-01-27T0:00:00z",
"TimeSectorEnd" : "2025-01-27T1:00:00z",
"TimeSectorComplete" : true,
"TimeSectorLastUpdated" : "2025-01-29T04:00:00z"
},
{
"TimeSectorStart": "2025-01-27T1:00:00z",
"TimeSectorEnd" : "2025-01-27T2:00:00z",
"TimeSectorComplete" : true,
"TimeSectorLastUpdated" : "2025-01-29T04:00:00z"
},
{
"TimeSectorStart": "2025-01-27T2:00:00z",
"TimeSectorEnd" : "2025-01-27T3:00:00z",
"TimeSectorComplete" : true,
"TimeSectorLastUpdated" : "2025-01-29T04:00:00z"
},
{
"TimeSectorStart": "2025-01-27T3:00:00z",
"TimeSectorEnd" : "2025-01-27T4:00:00z",
"TimeSectorComplete" : true,
"TimeSectorLastUpdated" : "2025-01-29T04:00:00z"
},
{
"TimeSectorStart": "2025-01-27T4:00:00z",
"TimeSectorEnd" : "2025-01-27T5:00:00z",
"TimeSectorComplete" : true,
"TimeSectorLastUpdated" : "2025-01-29T04:00:00z"
},
{
"TimeSectorStart": "2025-01-27T5:00:00z",
"TimeSectorEnd" : "2025-01-27T6:00:00z",
"TimeSectorComplete" : false,
"TimeSectorLastUpdated" : "2025-01-29T04:00:00z"
},
{
"TimeSectorStart": "2025-01-27T6:00:00z",
"TimeSectorEnd" : "2025-01-27T7:00:00z",
"TimeSectorComplete" : false,
"TimeSectorLastUpdated" : "2025-01-29T04:00:00z"
}
]
}The provided recency metadata for non-time series dataset could look
like this:
{
"DatasetInstanceId": "54321-abcde-12345-abcde-12345",
"RecencyLastUpdateDate": "2025-01-291T12:01:03.083z",
"DatasetInstanceLastUpdated" : "2025-01-29T04:00:00z",
"DatasetInstanceComplete" : true
}ACME provides recency metadata to accompany their FOCUS data export.
ACME updates their FOCUS Contracts dataset, a non time-series dataset,
every day. In this case, the most recent update to the recency data
indicates the dataset and associated data artifact has been updated and
is considered complete.
Metadata can be provided at a location such as
/FOCUS/metadata/recency/recency-54321-abcde-12345-abcde-12345.json.
The provided recency metadata for non-time series dataset could look
like this:
{
"DatasetInstanceId": "54321-abcde-12345-abcde-12345",
"RecencyLastUpdate": "2025-01-291T15:01:03.083z",
"DatasetInstanceLastUpdated" : "2025-01-29T010:00:00z",
"DatasetInstanceComplete" : true
}ACME provides recency metadata to accompany its FOCUS data export.
ACME updates its FOCUS Cost and Usage dataset (time series) every hour;
however, the data lags by two days. Here, the most recent update to the
recency data indicates the previous time sectors are now
TimeSectorComplete. It also indicates that previous time sectors have
been updated in the dataset. New time sectors have also been added.
Metadata can be provided at a location such as
/FOCUS/metadata/recency/recency-1234-abcde-12345-abcde-12345.json.
The provided recency metadata for time series dataset could look like
this:
{
"DatasetInstanceId": "1234-abcde-12345-abcde-12345",
"RecencyLastUpdateDate": "2025-01-291T12:01:03.083z",
"TimeSectors": [
{
"TimeSectorStart": "2025-01-27T0:00:00z",
"TimeSectorEnd" : "2025-01-27T1:00:00z",
"TimeSectorComplete" : true,
"TimeSectorLastUpdated" : "2025-01-29T04:00:00z"
},
{
"TimeSectorStart": "2025-01-27T1:00:00z",
"TimeSectorEnd" : "2025-01-27T2:00:00z",
"TimeSectorComplete" : true,
"TimeSectorLastUpdated" : "2025-01-29T04:00:00z"
},
{
"TimeSectorStart": "2025-01-27T2:00:00z",
"TimeSectorEnd" : "2025-01-27T3:00:00z",
"TimeSectorComplete" : true,
"TimeSectorLastUpdated" : "2025-01-29T04:00:00z"
},
{
"TimeSectorStart": "2025-01-27T3:00:00z",
"TimeSectorEnd" : "2025-01-27T4:00:00z",
"TimeSectorComplete" : true,
"TimeSectorLastUpdated" : "2025-01-29T04:00:00z"
},
{
"TimeSectorStart": "2025-01-27T4:00:00z",
"TimeSectorEnd" : "2025-01-27T5:00:00z",
"TimeSectorComplete" : true,
"TimeSectorLastUpdated" : "2025-01-29T04:00:00z"
},
{
"TimeSectorStart": "2025-01-27T5:00:00z",
"TimeSectorEnd" : "2025-01-27T6:00:00z",
"TimeSectorComplete" : true,
"TimeSectorLastUpdated" : "2025-01-29T04:00:00z"
},
{
"TimeSectorStart": "2025-01-27T6:00:00z",
"TimeSectorEnd" : "2025-01-27T7:00:00z",
"TimeSectorComplete" : true,
"TimeSectorLastUpdated" : "2025-01-29T11:15:24z"
},
{
"TimeSectorStart": "2025-01-27T7:00:00z",
"TimeSectorEnd" : "2025-01-27T8:00:00z",
"TimeSectorComplete" : true,
"TimeSectorLastUpdated" : "2025-01-29T11:15:24z"
},
{
"TimeSectorStart": "2025-01-27T8:00:00z",
"TimeSectorEnd" : "2025-01-27T9:00:00z",
"TimeSectorComplete" : false,
"TimeSectorLastUpdated" : "2025-01-29T04:00:00z"
},
{
"TimeSectorStart": "2025-01-27T9:00:00z",
"TimeSectorEnd" : "2025-01-27T10:00:00z",
"TimeSectorComplete" : false,
"TimeSectorLastUpdated" : "2025-01-29T10:23:10z"
},
{
"TimeSectorStart": "2025-01-27T10:00:00z",
"TimeSectorEnd" : "2025-01-27T11:00:00z",
"TimeSectorComplete" : false,
"TimeSectorLastUpdated" : "2025-01-29T11:15:24z"
}
]
}The provided recency metadata for non-time series dataset could look
like this:
{
"Dataset": "1234-abcde-12345-abcde-12345",
"RecencyLastUpdateDate": "2025-01-291T12:01:03.083z",
"DatasetInstanceLastUpdated" : "2025-01-29T04:00:00z",
"DatasetInstanceComplete" : true
}Understanding cost and usage data in billing datasets requires
identifying the roles of several participating entities involved in
resource or service provisioning, invoicing, and data generation. The
FOCUS Specification includes multiple columns to identify key
participating entities, these include:
The value for each of these may vary depending on how
resources or services are obtained — whether directly
from a Cloud Service Provider (CSP) or a SaaS provider, via a Managed
Service Provider (MSP), through a cloud marketplace, or from internal
service offerings. The table below provides examples that illustrate how
the value for each dimension may shift depending on the method of
acquisition and other contributing factors.
| # | Scenario | Service Provider | Invoice Issuer | Host Provider | Data Generator |
|---|---|---|---|---|---|
| 1.1 | Purchasing cloud resources or services directly from a CSP | CSP | CSP | CSP | CSP |
| 1.2 | Purchasing cloud resources or services from a CSP, where the underlying resources are operated by a 3rd party. |
CSP | CSP | Entity operating the region for the CSP | CSP |
| 2.1 | Purchasing cloud resources or services via an MSP, with visibility into the underlying hosting provider. |
MSP | MSP | CSP | MSP |
| 2.2 | Purchasing cloud resources or services via an MSP, without visibility into the underlying hosting provider. |
MSP | MSP | MSP | MSP |
| 2.3 | Purchasing cloud-agnostic resources or services from an MSP | MSP | MSP | MSP | MSP |
| 2.4 | Purchasing labor services from an MSP | MSP | MSP | MSP | |
| 3.1.1 | Purchase records for cloud marketplace offerings running on your CSP infrastructure and billed by the CSP. |
Marketplace Seller | CSP | CSP | CSP |
| 3.1.2 | CSP Infrastructure usage records for cloud marketplace offerings running on your CSP infrastructure. |
CSP | CSP | CSP | CSP |
| 3.1.3 | Usage records for cloud marketplace offerings running on your CSP infrastructure and billed by the CSP. |
Marketplace Seller | CSP | CSP | Marketplace Seller |
| 3.2.1 | Purchase records for cloud marketplace offerings not running on your cloud infrastructure, with visibility into the underlying hosting provider. |
Marketplace Seller | CSP | CSP | CSP |
| 3.2.2 | Usage records for cloud marketplace offerings not running on your cloud infrastructure, with visibility into the underlying hosting provider. |
Marketplace Seller | CSP | CSP | Marketplace Seller |
| 3.3.1 | Purchase records for cloud marketplace offerings not running on your cloud infrastructure, without visibility into the underlying hosting provider. |
Marketplace Seller | CSP | Marketplace Seller | CSP |
| 3.3.2 | Usage records for cloud marketplace offerings not running on your cloud infrastructure, without visibility into the underlying hosting provider. |
Marketplace Seller | CSP | Marketplace Seller | Marketplace Seller |
| 3.4.1 | Purchase records for SaaS products not running on your cloud infrastructure, purchased via a reseller. Reseller is issuing payable invoices. |
SaaS Provider | Reseller | SaaS Provider | SaaS Provider |
| 3.4.2 | Usage records for SaaS products not running on your cloud infrastructure, purchased via a reseller. Reseller is issuing payable invoices. |
SaaS Provider | Reseller | SaaS Provider | SaaS Provider |
| 3.5.1 | Purchase records for SaaS products not running on your cloud infrastructure, purchased via a reseller. Reseller does not issue payable invoices. |
SaaS Provider | SaaS Provider | SaaS Provider | SaaS Provider |
| 3.5.2 | Usage records for SaaS products not running on your cloud infrastructure, purchased via a reseller. Reseller does not issue payable invoices. |
SaaS Provider | SaaS Provider | SaaS Provider | SaaS Provider |
| 3.6.1 | Purchase records for SaaS products that have been white-labeled and sold by a reseller, not running on your cloud infrastructure. Reseller issues payable invoices. |
Reseller | Reseller | Reseller | Reseller |
| 3.6.2 | Usage records for SaaS products that have been white-labeled and sold by a reseller, not running on your cloud infrastructure. Reseller issues payable invoices. |
Reseller | Reseller | Reseller | Reseller |
| 4.1 | Purchasing SaaS products directly from a SaaS provider, with visibility into the underlying hosting provider. |
SaaS Provider | SaaS Provider | CSP | SaaS Provider |
| 4.2 | Purchasing SaaS products directly from a SaaS provider, without visibility into the underlying hosting provider. |
SaaS Provider | SaaS Provider | SaaS Provider | SaaS Provider |
| 4.3.1 | Purchasing SaaS products running on your cloud infrastructure, purchased directly from a SaaS provider (see 4.3.2 for charges related to the underlying cloud infrastructure). |
SaaS Provider | SaaS Provider | SaaS Provider | |
| 4.3.2 | Purchasing resources and services from a CSP used to host SaaS products separately acquired from a SaaS provider (see 4.3.1 for charges related to the SaaS products). |
CSP | CSP | CSP | CSP |
| 5.1 | Purchasing internal resources or services hosted in Data Center | Internal Name | Internal Name | Internal Name | Internal Name |
| 6.1 | Software license costs, reported separately from the costs of the resources or services they apply to. |
Licensable Software Provider | License Seller | License Seller |
The following section contains examples with how SaaS data generators
may implement the FOCUS specification. SaaS data generator
implementations will vary on the level of the detail available in their
data, contract terms, purchasing options, and other factors.
Many SaaS providers provide simple contract terms, therefore don't
need to support complex scenarios like spend commitments or pricing
strategies in their billing data.
The scenarios described below illustrate how a Cost and Usage FOCUS dataset should look
for simple SaaS agreement scenarios (these scenarios may not be specific
to SaaS agreements only).
ACME Corp allows its customers to purchase their service for a term
(in this case, a year) for a $10,000. ACME provides AwesomeCorp with a
single invoice for their usage. ACME does not provide detailed cost and
usage reports to AwesomeCorp throughout the Charge Period after the
initial purchase.
Given that ACME does not charge based on or track usage, its usage
details are irrelevant to this scenario.
Note the following details in the example dataset:
ACME Corp offers its customer the ability to purchase a fixed
quantity of licenses for their service. ACME provides AwesomeCorp with a
single invoice for their usage. ACME does not provide detailed cost and
usage reports to AwesomeCorp throughout the Charge Period after the
initial purchase.
On April 1st, 2025, ACME executes a contract and invoices AwesomeCorp
$50,000 (Billed Cost) for a Charge Period of April 1st 2025 to April 1st
2026. As there is no negotiated discount, List Cost of the purchase is
also $50,000.
Note the following details in the example dataset:
On June 1st 2025 ACME provides the following records due to
AwesomeCorp's $1,000 mid-contract purchase of an additional 10 licenses
for the same Charge Period (April 1st 2025 to April 1st 2026).
Note the following additional details in the example dataset:
Similar to Scenario A above, ACME Corp offers its customer the
ability to purchase their service with a fixed quantity of licenses.
However, in Scenario B, ACME issues the invoice at the end of the usage
period.
On April 1st, 2026, ACME invoices AwesomeCorp $50,000 (Billed Cost)
for the Charge Period of April 1st 2025 to April 1st 2026. As there is
no negotiated discount, List Cost of the purchase is also $50,000.
Note the following additional details in the example dataset:
Like Scenario A2 above, ACME Corp offers its customers the ability to
purchase their service with a fixed quantity of licenses. However, in
Scenario C, ACME issues invoices at the end of each month (usage
period). For this scenario, contract terms additionally include the
following terms:
AwesomeCorp's consumption looks like this:
Note the following additional details in the example dataset:
Many SaaS service providers support billing models that allow (or in
some cases require) consumers to agree to an amount to spend over a
period. In some cases, customers receive a negotiated discount for usage
during that period in exchange for the spend agreement. Spend agreements
can have different payment models like billing in arrears or pre-paid
contracts and may impose minimum spend requirements for parts of the
agreement.
The scenarios described below illustrate how a Cost and Usage FOCUS dataset should look
for various spend agreement scenarios.
The following baseline conditions apply to the scenarios described
below:
For this scenario A, contract includes the following terms in
addition to the baseline scenario mentioned above:
For this scenario, contract additionally includes the following
terms:
AwesomeCorp's consumption looks like this:
Note the following details in the example dataset:
The spend agreement with Acme requires the customer to spend a
minimum amount in each Billing Period (monthly). Unused fees are charged
per Billing Period when the consumption is below this level (use-it or
lose-it). For this scenario, contract additionally includes the
following terms:
AwesomeCorp's consumption looks like this:
Note the following details in the example dataset:
For this scenario B, contract includes the following terms in
addition to the baseline scenario mentioned above:
Scenario B1 is similar to scenario A1 with the difference being that
it's a pre-paid contract.
Note the following details in the example dataset:
Scenario B2 is similar to A2 with the difference being that it's a
pre-paid contract.
Note the following details in the example dataset:
Many SaaS service providers support pricing models that utilize
virtual currencies such as credits, tokens, or points. Charges may be
provided using a virtual currency, which can subsequently be converted
to a national currency such as USD or EUR at an advertised or
agreed-upon conversion rate.
The scenarios described below illustrate how a Cost and Usage FOCUS dataset should look
for various scenarios where a provider utilizes this pricing model.
The following baseline conditions apply to the scenarios described
below:
For this scenario, contract terms include the following terms in
addition to the baseline scenario mentioned above:
For this scenario, the initial purchase of virtual currency is
executed as follows:
Note the following details in the example dataset:
Awesome Corp uses Acme's services consuming tokens as follows in the
first day:
Note the following details in the example dataset:
For this scenario, contract terms include the following terms in
addition to the baseline scenario mentioned above:
For this scenario, the initial purchase of virtual currency is
executed as follows:
Note the following details in the example dataset:
Awesome Corp uses Acme's services, consuming tokens as follows in the
first day:
Note the following details in the example dataset:
Awesome Corp uses Acme's services consuming tokens as follows in the
first day:
Additionally, Acme Co offers a modified usage to token ratio for one
of their services as follows:
Note the following details in the example dataset:
For this scenario, Awesome Corp has exceeded their purchased tokens
on October 1st 2025 by 1,500 tokens and Acme Co has charged them for the
overage. The following conditions apply:
Note the following details in the example dataset:
Service 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.
Service 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.
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.