FinOps Certified FOCUS v1.2 Conformant

The FinOps Open Cost and Usage Specification (FOCUS) is an open specification that normalizes billing datasets across data providers, reducing complexity for FinOps Practitioners.

This certification is available to FinOps Foundation members that generate billing data which reliably supports the FOCUS v1.2 specification by providing structurally conformant datasets, expected types and formats (with any deviations disclosed in the Conformance Gap Report), and consistent core calculations. It provides practitioners confidence that a provider’s data meets published specification requirements, providing assurance that datasets substantially align with the FOCUS v1.2 specification, within the published deviation thresholds.

Please contact member-cert@finops.org to request a Request for Information (RFI) document and kickstart the certification process for your FOCUS implementation. If your organization is not a FinOps Foundation member but wishes to participate in the FOCUS certification process, contact hello@finops.org to discuss membership options.

Certification Version Roadmap

The certification program currently validates conformance to FOCUS 1.2.

Subsequent versions of FOCUS are under active development. As the FOCUS specification evolves, the certification program will be updated and expanded to align with each new release.

Each version will have its own defined conformance criteria. Once released, each version will have a 24-month window during which certifications may be issued for that version. As future FOCUS versions add datasets, the Full-tier’s coverage will expand to include all datasets defined in that version. Each new dataset contributes its own Mandatory column requirements to Full-tier evaluation.

Please check this page regularly for updates, or contact member-cert@finops.org for the latest information on certification timelines and criteria for a specific FOCUS version.

Certification Requirements Quick Reference

An overview of the requirements for the FinOps Certified FOCUS v1.2 Conformant certification.

1. Become a Member
2. Achieve Individual Certification Requirements
3. Provide Sample Data
4. Support the Mandatory Cost and Usage Columns
5. Provide a Declaration of Support for Key Elements
6. Satisfy the Semantic & Business Logic Validation Criteria
7. Publish FOCUS Conformance Information

Certification Prerequisites

Become a Member

Being a FinOps Foundation Member and Linux Foundation Member in good standing are prerequisites to becoming a FinOps Certified FOCUS Conformant.

Individual Certification Requirements

The FinOps Certified FOCUS Conformant certification requires individuals in your organization to have achieved FinOps Certified FOCUS Analyst certifications based on your organization’s size.

The following table outlines the type and number of certifications that individuals in your organization require for a FOCUS Data Generator.

Company Size	FinOps Certified FOCUS Analyst
5,000 +	10
500 – 4,999	5
100 – 499	3
Less than 100	2

^{The “Company Size” column in this table refers to the parent organization size that was used for defining your fee structure when you joined the Linux Foundation and counts are not based on the individual business unit. For example, a 100 person product team that is part of a 1,500 person organization would fall into the “500-4,999” individual certification requirement tier, and not the “100-499” individual certification requirement tier.}

---

Certification Process and Sample Data Requirements

The certification process requires the following:

1. Submission of anonymized sample data in a FOCUS-formatted dataset with all Personally Identifiable Information (PII) removed.
2. Completion of a Request for Information (RFI) document based on the certification criteria outlined in the section below.
3. Provision of a conformance gap report and column mapping reference, both of which must be publicly available, that document alignment and deviations between the data generator output and the FOCUS specification

FinOps Foundation (F2) staff will run the FOCUS Validator – an F2 open-source application that validates sample data against a specific version of the FOCUS specification – on the submitted sample data. The results of the FOCUS Validator analysis, together with the information provided in the RFI, are used to complete the certification review and determine whether a data generator is eligible for FinOps Certified FOCUS Conformant status.

The certification process is considered complete only when F2 staff have verified that conformance gap and column mapping reports, and confirmed they are publicly accessible.

Sample Data

To support the conformance certification review and validation process, data generators are required to provide the information outlined below.

This information ensures accurate identification of the data generator, establishes a point of contact for follow-up questions, and enables effective evaluation of the submitted sample data against certification criteria.

Sample data should remove or mask personally identifiable information while preserving structural validity. Hash or replace IDs (BillingAccountId, SubAccountId, ResourceId), remove names and tag values. Do not anonymize cost columns, dates, currencies, categories, or quantities needed for validation.

Anonymized sample data that meets all the certification requirements will be contributed to the FOCUS Sandbox and attributed to your organization. Contributing to the FOCUS Sandbox is part of becoming a FinOps Certified FOCUS Conformant data provider. The FOCUS Sandbox helps practitioners learn from real-world, certified FOCUS implementations and demonstrates your organization is actively contributing to the advancement of the FinOps practice and strengthening interoperability across the ecosystem.

All of the following criteria are required.

• Primary Contact Information as a point of contact for follow-up questions, process and data coordination
• Sample Data File Name
• Sample Data Download Location and Link
• Sample Data Row Count for the dataset provided; the total number of records included in the sample data per dataset
• Sample Data Billing Period(s) and date range represented in the sample data; submissions should cover at least one complete billing cycle
• The version of the software/product used to generate the submitted sample data

FOCUS Conformant Data Generator Requirements for FOCUS Version v1.2

The certification criteria outlined in this section is specific to FOCUS 1.2.

Mandatory FOCUS Columns

Data providers generating FOCUS conformant datasets are required to support the FOCUS 1.2 columns listed below. The certification process can not proceed if support for any of these columns are missing.

All of the following criteria are required.

Applicability Criteria	Description
Billed Cost [Column ID: BilledCost]	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.
Effective Cost [Column ID: EffectiveCost]	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.
Billing Currency [Column ID: BillingCurrency]	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.
Billing Account Id [Column ID: BillingAccountId]	A Billing Account ID is a provider-assigned identifier for a billing account. Billing accounts are commonly used for scenarios like grouping based on organizational constructs, invoice reconciliation and cost allocation strategies.
Charge Category [Column ID: ChargeCategory]	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.
Charge Period Start [Column ID: ChargePeriodStart]	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.
Charge Period End [Column ID: ChargePeriodEnd]	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.

Declaration of Support for Key Elements

Indicate if the data you generate for key areas – including infrastructure, billing and pricing, and account management features – can be mapped to FOCUS columns. This information helps practitioners understand the scope of support for non-mandatory FOCUS columns.

Any of the following criteria are required.

Applicability Criteria	Description
Availability Zones	Mapped to the AvailabilityZone FOCUS Cost and Usage column
Capacity Reservations	Mapped to any of the CapacityReservation.* FOCUS Cost and Usage columns
Commitment Discounts	Mapped to any of the CommitmentDiscount.* FOCUS Cost and Usage columns
Multi-Currency Pricing	Mapped to the PricingCurrency, and any of the PricingCurrency.* FOCUS Cost and Usage columns
Multiple Billing Account Types	Mapped to the BillingAccountType FOCUS Cost and Usage column
Multiple Sub Account Types	Mapped to the SubAccountType FOCUS Cost and Usage column
Regions	Mapped to the RegionId, and RegionName FOCUS Cost and Usage columns
Resource-Based Billing	Mapped to the ResourceId, ResourceName, and ResourceType FOCUS Cost and Usage columns
SKU Pricing	Mapped to the SkuId, SkuPriceId, SkuMeter, and SkuPriceDetails FOCUS Cost and Usage columns
Sub Accounts	Mapped to the SubAccountId, and SubAccountName FOCUS Cost and Usage columns
Tags	Mapped to the Tags FOCUS Cost and Usage columns
Unit Pricing	Mapped to the ListUnitPrice, and ContractedUnitPrice FOCUS Cost and Usage columns

Semantic & Business Logic Validation

Some criteria involve semantic or business logic rules that cannot be automatically verified. In this section, data providers are asked to self-assess their sample data and disclose any areas where their datasets do not meet the expected outcomes.

Examples include cross-row relationships (like commitment amortization totals), alignment with external data (such as the BilledCost FOCUS column sums matching invoice totals), and semantic correctness (for instance, the ConsumedQuantity FOCUS column accurately reflecting actual usage).

Any known deviations from the expected outcomes must be documented and included in publicly accessible FOCUS conformance information required for this certification.

Attestation and deviation documented for the following criteria is required.

Applicability Criteria	Attestation/Deviation
Invoice Alignment	Sum of BilledCost for InvoiceId matches invoice total from InvoiceIssuer
Marketplace Billing	BilledCost is 0 (zero) for charges where payments go to third parties
Commitment Amortization	Sum of EffectiveCost equals BilledCost of commitment purchase (both used & unused)
Commitment Purchase EffectiveCost	EffectiveCost is 0 (zero) for purchases covering future charges
Consumed Quantity Semantics	ConsumedQuantity represents actual consumption, not billed quantity
Pricing Math	The UnitPrice multiplied by the PricingQuantity equals corresponding FOCUS Billing or Pricing Cost column
Currency Consistency	TBillingCurrency matches currency used in invoices from InvoiceIssuer
Billing Period Boundaries	BillingPeriodStart/BillingPeriodEnd correctly represent inclusive/exclusive time period bounds
Charge Period Boundaries	ChargePeriodStart/ChargePeriodEnd correctly represent inclusive/exclusive time period bounds
Identifier Uniqueness	IDs (BillingAccountId, ResourceId, …etc) are unique within a provider scope
Immutable ID Consistency	Immutable identifiers remain consistent across billing periods

---

Known Industry Limitations (KIL) Exception Requests

Billing model constraints that impact multiple data providers across the industry may impact FOCUS conformance. In these cases, an exception may be requested to allow the certification process to move forward.

When requesting a Known Industry Limitation (KIL) exception, data providers must supply evidence demonstrating multi–data generator impact, clearly describe the underlying architectural root cause, and document any available practitioner workarounds.

A KIL exception request is considered when it meets the following criteria:

• Affects two or more data providers
• Results from a billing architecture limitation rather than a data generator implementation choice
• Has a clear and documented workaround that practitioners can leverage

Any approved KIL exception requests must be documented and included in publicly accessible FOCUS conformance information required for this certification.

Known Industry Limitation Example

Below is an example of a KIL that uses the FOCUS column called ConsumedQuantity to illustrate an exception request format.

• Column Affected: ConsumedQuantity
• Requirement Violated: ConsumedQuantity MUST represent the volume of a metered SKU associated with a resource or service used, based on the Consumed Unit.
• Description of Limitation: Cloud platforms measure and bill usage in minimum increments rather than exact consumption. For example, compute services may bill in 1-second or 1-minute minimum increments even when actual usage is shorter. A VM running for 45 seconds may be reported as 60 seconds of ConsumedQuantity.
• Root Cause (Architectural): Billing systems round up to minimum increments at the metering layer, before data reaches the billing export. Providers cannot retroactively derive actual sub-increment consumption because the underlying telemetry is aggregated and discarded. This is fundamental to how metering pipelines operate at scale, not a transformation choice.
• Multi-Provider Impact:
  • Major IaaS providers exhibit this behavior for compute services.
  • AWS bills Lambda in 1ms increments, EC2 historically in per-second minimum
  • Azure bills VMs in per-second with 1-minute minimum
  • GCP bills Compute Engine per-second with 1-minute minimum
• Practitioner Workaround: Use PricingQuantity for cost calculations rather than ConsumedQuantity when analyzing short-duration workloads. When comparing consumption across providers, normalize to the largest minimum increment in your dataset.

---

Publishing FOCUS Conformance Information

Practitioners rely on documentation about the behavior of your FOCUS implementation.

To successfully complete the certification process, publish a conformance gap report and column mapping reference, both of which must be publicly accessible, that document alignment, deviations, and known industry limitations between the data generator output and the FOCUS specification.

The published information may include additional context, and examples not provided by the gap report or column mapping reference to help practitioners understand the derivation of FOCUS columns from your source data.

The certification process is considered complete only when F2 staff have verified the gap and column mapping reports, and that they are publicly accessible.

All of the following criteria are required.

Publish a Conformance Gap Report

• Must be publicly accessible without paywall or registration wall
• Must include the FOCUS version, total deviation count, and known industry limitations (if any)
• See example conformance gap reports here and here
• Submit the URL to F2 staff for validation; the certification process can not be completed without a verified gap report.

Publish a Column Mapping Reference

• Must be publicly accessible without paywall or registration wall
• Document how each FOCUS column is derived from your native billing data. This transparency helps practitioners understand your transformation logic and troubleshoot discrepancies. For each FOCUS column provide: Source Field(s),
• Transform Logic, FOCUS Columns, and Notes
• Must cover all FOCUS columns populated
• Submit the URL to F2 staff for validation; the certification process can not be completed without a verified column mapping reference

---

Frequently Asked Questions (FAQ)

Have a question about FOCUS conformance and/or the certification not answered by these FAQs?

Contact us at member-cert@finops.org