FinOps Certified FOCUS v1.3 Conformant

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

This certification is available to FinOps Foundation members that generate billing data which reliably supports the FOCUS v1.3 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.3 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 for FOCUS v1.2 and FOCUS v1.3.

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 Tier Model

This certification offers two tiers, allowing data generators to certify based on the FOCUS datasets their software produces. Tiers are self-selected at submission. A data generator may certify at the Essential-tier without supporting the additional dataset required by the Full-tier.

Generators holding Essential Tier certification may upgrade to Full Tier certification only by submitting a new full submission covering all contributing datasets together. Partial submissions are not accepted because the cross-dataset checks at Full-tier require all datasets evaluated together against current production data. The upgrade submission produces a new Full-tier certification with its own validity window, and replaces the prior Essential-tier certification.

Certification Requirements Quick Reference

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

1. Become a Member
2. Achieve Individual Certification Requirements
3. Provide Sample Data
4. Support the Mandatory Cost and Usage Columns (Essential Tier)
5. Support the Mandatory Contract Commitment Columns (Full Tier)
6. Satisfy the Cross-Dataset Integrity Checks (Full Tier)
7. Satisfy the Version Capability Demonstration Requirements
8. Provide a Declaration of Support for Key Elements
9. Satisfy the Semantic & Business Logic Validation Criteria
10. 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 Criteria

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 must be drawn from production data, or a functionally equivalent dataset used to serve production consumers, in a way that preserves the distribution of edge cases present in production. Samples engineered to avoid known nulls, conformance failures, or other edge conditions are not acceptable. If a gap exists in production, it must exist in the sample. Documentation of a deviation in a footnote is not a substitute for that deviation appearing in the submitted sample

Sample data must also 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.

All of the following criteria are required:

• Target Certification Tier [Essential or Full]
• Primary Contact Information as a point of contact for follow-up questions, process and data coordination
• Sample Data File(s) Type(s)
• Sample Data File(s) Names
• Sample Data Download Location and Link(s)
• Sample Data Row Count for each 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
• Sample Data Representativeness Attestation accompanied by a statement confirming that the submitted sample data satisfies the representativeness requirement. The burden of proof rests with the data generator if the attestation is later audited.

---

FOCUS Conformant Data Generator Requirements for FOCUS Version v1.3

The criteria in this section derive directly from the FOCUS v1.3 specification’s Requirements Model.

A column is in scope when its Feature Level is “Mandatory” and its Status is not “Deprecated.” As the specification evolves, the corresponding criteria for future certifications will be derived for each new version of the FinOps Open Cost and Usage Specification (FOCUS).

Two columns are designated “Mandatory” in the FOCUS v1.3 specification but are also marked as deprecated as of v1.3 and are therefore excluded from this version’s certification scope: ‘PublisherName’ and ‘ProviderName’. Both are removed entirely in subsequent FOCUS versions.

Mandatory Cost and Usage Columns (Essential Tier)

Data providers generating FOCUS conformant Cost and Usage datasets are required to support the FOCUS columns listed below. Column presence is non-negotiable: a missing Mandatory column is an automatic non-certification at any tier.

All of the following criteria are required for Essential Tier certification:

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.

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.

Billing Account Name [Column ID: BillingAccountName]

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

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 Period End [Column ID: BillingPeriodEnd]

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

Billing Period Start [Column ID: BillingPeriodStart]

• 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 Billing Period End represents the exclusive end bound.

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 Class [Column ID: ChargeClass]

• Charge Class indicates whether a charge represents a correction to a previously closed billing period. Charge Class is commonly used to differentiate such corrections from all other charges, including both regularly incurred charges and corrections to open billing periods.

Charge Description [Column ID: ChargeDescription]

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

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.

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.

Contracted Cost [Column ID: ContractedCost]

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

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.

Host Provider Name [Column ID: HostProviderName]

• 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. 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 or allow the customer to select the host provider.

Invoice Issuer Name [Column ID: InvoiceIssuerName]

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

List Cost [Column ID: ListCost]

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

Pricing Quantity [Column ID: PricingQuantity]

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

Pricing Unit [Column ID: PricingUnit]

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

Service Category [Column ID: ServiceCategory]

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

Service Name [Column ID: ServiceName]

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

Service Provider Name [Column ID: ServiceProviderName]

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

 

Mandatory Contract Commitment Columns (Full Tier)

Full-tier submissions must additionally support the FOCUS Contract Commitment columns listed below. Column presence is non-negotiable: a missing Mandatory column is an automatic non-certification at Full tier.

All of the following criteria are required for Full Tier certification:

Billing Currency [Column ID: BillingCurrency, Contract Commitment dataset]

• Billing Currency represents the currency of a contract commitment.

Contract Commitment Category [Column ID: 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. It is commonly used to identify and distinguish between categories of contract commitments that may require different handling.

Contract Commitment Cost [Column ID: ContractCommitmentCost]

• Contract Commitment Cost represents the monetary value of the contract commitment. It 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.

Contract Commitment Description [Column ID: ContractCommitmentDescription]

• Contract Commitment Description provides a high-level context of a contract commitment without requiring additional discovery. It 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.

Contract Commitment ID [Column ID: ContractCommitmentId]

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

Contract Commitment Period End [Column ID: ContractCommitmentPeriodEnd]

• Contract Commitment Period End represents the exclusive end bound of a contract commitment period.

Contract Commitment Period Start [Column ID: ContractCommitmentPeriodStart]

• Contract Commitment Period Start represents the inclusive start bound of a contract commitment period.

Contract Commitment Quantity [Column ID: ContractCommitmentQuantity]

• Contract Commitment Quantity represents the amount associated with the contract commitment, denominated in a service-provider-defined Contract Commitment Unit. It 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.

Contract Commitment Type [Column ID: ContractCommitmentType]

• Contract Commitment Type is a service-provider-assigned name to identify the type of contract commitment. It is a readable display name and not a code, commonly used for displaying and aggregating the types of commitments the practitioner has made, stated in service-provider-specific terms.

Contract Commitment Unit [Column ID: ContractCommitmentUnit]

• The Contract Commitment Unit represents a service-provider-specified measurement unit for the amount declared in Contract Commitment Quantity. It complements the Contract Commitment Quantity metric.

Contract ID [Column ID: ContractId]

• 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 commitments to a certain amount of spend or usage over an agreed period of time.

Contract Period End [Column ID: ContractPeriodEnd]

• Contract Period End represents the exclusive end bound of a contract period.

Contract Period Start [Column ID: ContractPeriodStart]

• Contract Period Start represents the inclusive start bound of a contract period.

 

Cross-Dataset Integrity (Full Tier)

Full-tier submissions are evaluated for valid join relationships between contributing datasets. The following cross-dataset checks apply to FOCUS v1.3.

• ContractCommitmentId references
• Every ContractCommitmentID value present in the Cost and Usage dataset (within the ContractApplied object, where the JSON property is keyed ‘ContractCommitmentID’ with uppercase D) must resolve to a ContractCommitmentId in the submitted Contract Commitment dataset. An unresolved reference (orphan) is an automatic Full-tier non-certification, equivalent in severity to a missing Mandatory column.
• ContractId consistency
• ContractId values referenced across datasets should resolve consistently. Inconsistencies are counted as deviations against the Contract Commitment non-mandatory threshold rather than as automatic non-certification.

Note the current FOCUS Validator processes a single dataset file at a time. For FOCUS v1.3 certification, cross-dataset integrity is evaluated through self-attestation supported by representative-sample inspection by F2 staff. Multi-dataset validator support is planned for future certification versions.

 

Version Capability Demonstration Requirement

A submission qualifies as FOCUS v1.3 certified at either tier only if the submitted data demonstrates at least one capability introduced in v1.3. This prevents a v1.3 certification from being claimed for a submission that exercises only pre-v1.3 content.

The Version Capability Demonstration Requirement is met when at least one of the criteria listed below is met in the submitted dataset sample.

At least one of the following criteria is required:

• One or more rows are populated with a non-null value in a column introduced at v1.3
• One or more rows demonstrate a value or relationship introduced at v1.3 (for example, a new ChargeCategory enum value or a new cross-dataset relationship)
• Presence of a dataset introduced at v1.3 with at least one row

For Cost and Usage submissions, populating ServiceProviderName satisfies this requirement, since ServiceProviderName is Mandatory and was introduced in v1.3. Full-tier submissions automatically satisfy this requirement through the presence of the Contract Commitment dataset, which was introduced at v1.3. Data Generators may still certify at a prior FOCUS version if their data meets that version’s requirements but does not exercise any v1.3-new elements.

 

Deviation Allowance

Deviations are counted at the column level. A column with one or more rule failures counts as a single deviation, regardless of how many rules failed on that column. Each dataset’s allowances and thresholds are evaluated independently. A Full-tier submission must pass both the Mandatory column gap allowance and the non-mandatory deviation threshold for every contributing dataset.

Mandatory Columns

All Mandatory columns are required to be present. However Mandatory column content rules are subject to a per-dataset gap allowance. When a Mandatory column is present in correct type and format but contains content rule failures (invalid values, unjustified nulls, or other deviations from FOCUS-defined behavior on that column), the column is counted as a “Mandatory column gap”. Submissions are allowed a limited number of “Mandatory column gaps” per dataset, calculated as approximately 20% of the Mandatory column count for that dataset.

The following table outlines the dataset type and the per-dataset gap allowance permitted for Mandatory column content rules.

Dataset Type	Mandatory Columns	Gap Allowance
Cost and Usage	21	4
Contract Commitment	13	3

Non-Mandatory Columns

For non-mandatory columns, the MUST and MUST NOT violations are counted separately using a per-dataset threshold. The threshold is calibrated as approximately one-third of the non-mandatory column count for each dataset, with a floor of 5.

Cost and Usage dataset:

• Up to 14 non-mandatory column deviations per submission. This threshold derives from the FOCUS v1.2 conformance program, which permitted up to 20 deviations across 50 non-critical-path columns (a 40% allowance with buffer above the one-third formula). The v1.3 calibration applies the same one-third formula to 42 non-mandatory Cost and Usage columns, yielding 14 deviations (approximately 33%). The proportional adjustment reflects the expanded Mandatory column scope at v1.3 (21 columns versus 7 critical path columns at v1.2), which now carries more of the structural conformance bar.

Contract Commitment dataset:

• up to 5 non-mandatory column deviations per submission. The v1.3 Contract Commitment dataset has no non-mandatory columns; the threshold’s floor of 5 applies to any cross-dataset rule violations counted against this dataset (see Cross-Dataset Integrity).

 

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

Any of the following criteria are required:

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

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	BillingCurrency 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 Limitation Exception Requests

Billing model constraints that impact multiple data generators 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 exception, data generators must supply evidence demonstrating multi–data generator impact, clearly describe the underlying architectural root cause, and document any available practitioner workarounds.

A Known Industry Limitation 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 Known Industry Limitation exception requests must be documented and included in publicly accessible FOCUS conformance information required for this certification.

Known Industry Limitation Request Example

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

---

Publishing FOCUS Conformance Information

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

To successfully complete the certification process, publish a 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.

Public Documentation	Details
Conformance Gap Report	Must be publicly accessible without paywall or registration wall Must include the following: Certification metadata: data generator name, certification tier, FOCUS version, certification date, and validity window Per-column results for each Mandatory column in the certified version’s scope, per contributing dataset, with gaps explicitly named Total count of non-mandatory MUST and MUST NOT violations per dataset, with individual rule IDs listed Cross-dataset integrity result (Full tier only) Version Capability Demonstration Requirement result, including which v1.3 capabilities the submission exercised Known Industry Limitations applied (if any) Remediation statement describing what the data generator is doing to close each gap and by when (when gaps exist) See an example conformance gap report here Submit the URL to F2 staff for validation; the certification process can not be completed without a verified gap report
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