Usage data conformance with FOCUS

Documentation Index

Fetch the complete documentation index at: https://docs.nebius.com/llms.txt

Use this file to discover all available pages before exploring further.

Usage data that you can export from Nebius AI Cloud is compliant with the FinOps Open Cost and Usage Specification (FOCUS) 1.2. This article describes existing conformance gaps and workarounds for them.

​

Supported features

Nebius supports the following FOCUS-related capabilities:

​

Deviations

Usage data provided by Nebius has three deviations from the FOCUS specification.

​

#1: ChargeCategory

• Column: ChargeCategory
• Specification: Purchases of commitment discounts MUST use ChargeCategory = "Purchase".
• Deviation: Commitment discount purchases are not modeled as ChargeCategory = "Purchase" rows. Commitment discount costs are reflected differently depending on the discount type.
  
  Resource-based: Postpaid commitment discounts appear as ChargeCategory = "Adjustment" rows; prepaid commitment discounts are represented through amortized EffectiveCost on usage rows rather than as separate purchase rows.
  
  Spend-based: unlike resource-based commitment discounts, their cost impact is reflected in ContractedCost rather than EffectiveCost.
• Workaround: Resource-based: For both postpaid and prepaid resource-based commitment discount types – EffectiveCost at the usage row level reflects the net cost after the commitment discount is applied and can be used for per-service cost analysis.
  
  Note that Adjustment rows do not include CommitmentDiscountId or SkuId, so practitioners cannot programmatically link them to specific commitment discounts. For per-service commitment cost impact, use EffectiveCost at the usage row level rather than attempting to reconcile adjustment rows to individual commitments.
  
  Spend-based: Where a cost-based commitment affects pricing, the applicable price adjustment is reflected in ContractedCost.

​

#2: EffectiveCost

• Column: EffectiveCost
• Specification: Purchased discounts (e.g., commitment discounts) MUST be amortized. The sum of EffectiveCost for commitment usage and unused rows must equal the BilledCost of the corresponding purchase.
• Deviation: Commitment discount purchases are not modeled as ChargeCategory = "Purchase" rows (see deviation #3), preventing verification that amortized EffectiveCost sums match the original purchase amount.
• Workaround: Resource-based: commitment discount cost impact is reflected in EffectiveCost at the line-item level. For postpaid commitments – total commitment value can be identified from ChargeCategory = "Adjustment" rows. For prepaid commitments –  you can only sum EffectiveCost at the line-item level.
  
  Spend-based: Where a cost-based commitment affects pricing, the applicable price adjustment is reflected in ContractedCost.
  
  So row-level amortization reconciliation against the original purchase is not currently possible.

​

#3: CommitmentDiscountCategory

• Column: CommitmentDiscountCategory
• Specification: CommitmentDiscountCategory MUST indicate whether the commitment discount identified in CommitmentDiscountId is based on a predetermined amount of spend or usage. Allowed values are Spend and Usage
• Deviation: Spend-based commitments are not currently modeled as a distinct commitment discount category. Also unlike resource-based commitment discounts, their cost impact is reflected in ContractedCost rather than EffectiveCost.
• Workaround: Where a spend-based commitment affects pricing, the applicable price adjustment is reflected in ContractedCost.

​

Known industry limitations

Known industry limitations (KILs) are constraints that are common to multiple data generators. KILs are treated as exceptions and are excluded from the deviation count for the purposes of FOCUS certification. Usage data provided by Nebius has one KIL.

​

#1: ConsumedQuantity

• Column: ConsumedQuantity
• Specification: ConsumedQuantity represents actual consumption
• Deviation: Value includes minimum billing increments
• Workaround: Cost analysis: use PricingQuantity, not ConsumedQuantity. PricingQuantity × UnitPrice = BilledCost already accounts for the increment.
  Short-duration workloads: expect ConsumedQuantity to overstate actual usage by up to the minimum increment.
  Cross-provider comparison: normalize to the largest minimum increment in the dataset.