FinOps Certified FOCUS 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 FinOps Certified FOCUS Conformant certification is for data generators producing FOCUS-conformant billing data. It provides practitioners confidence that a provider’s data meets published specification requirements, ensuring datasets are structurally and semantically aligned with a corresponding FOCUS specification version.

This certification is available to FinOps Foundation members that generate billing data which reliably supports the FOCUS specification by providing structurally conformant datasets, correct field types and values, and consistent core calculations.

---

Certification Version Roadmap

The certification program currently validates conformance to FOCUS 1.2.

Note: Τhe FOCUS 1.3 certification criteria is scheduled for release ahead of the FinOps X conference June 8-11 2026.

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.

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.

---

Membership & Expertise 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.

Validate Your FOCUS Expertise

Demonstrate your team’s knowledge and FinOps expertise through FinOps training and certifications.

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 types and number of certifications that individuals in your organization require.

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

---

Why get certified?

The FinOps community trusts the FinOps Foundation as a neutral party with no stake in positioning one data provider, FinOps service provider, or FinOps tool over another.

This certification signals to the community that:

• Your software reliably supports the FOCUS specification by providing structurally sound datasets, correct field types and values, and consistent core calculations that help practitioners solve their realworld use cases with confidence.
• Your investment in FOCUS enables FinOps Practitioners to spend less time on data normalization and improve how they report value back to the business.
• Your organization is actively contributing to the advancement of the FinOps practice and strengthening interoperability across the ecosystem.

The FinOps Certified FOCUS Conformant certification badge will be displayed on your FinOps Foundation Member Page, the FinOps Landscape, and on booths at the FinOps X conference.

---

FOCUS Conformant Data Provider 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.

Applicability Criteria	Description
Primary Contact Information	Point of contact for follow-up questions, process and data coordination
Sample Data File Name	Name of the file containing the submitted sample data
Sample Data Download Location	Link to the file containing the submitted sample data
Sample Data Row Count	Total number of records included in the sample data file
Sample Data Billing Period(s)	Billing period or date range represented in the sample data
Product Version	The version of the software product used to generate the submitted sample data

FOCUS Conformant Data Provider Criteria for FOCUS Version 1.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

---

Get Started on Your Certification

Please contact member-cert@finops.org to request an RFI document and kickstart the certification process for your FOCUS implementation.

---

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