FOCUS 1.3 and Kubernetes split cost allocation: a 2026 multi-cloud chargeback playbook

A Spec That Finally Takes Shared-Resource Costs Seriously

The FOCUS Steering Committee ratified FOCUS 1.3 — the FinOps Open Cost and Usage Specification, version 1.3 — on December 5, 2025. By early May 2026 the spec is now landing in production data feeds across the major hyperscalers and the broader vendor ecosystem, and the FinOps Foundation has announced the conformance certification program that will run across 2026.

Three problems get materially better in 1.3: contract-commitment tracking, data-freshness verification, and — the one that matters most for platform engineering — split cost allocation for shared resources. New allocation-specific columns let providers expose how shared resources (Kubernetes pods, database instances, multi-tenant data-platform compute) are split across workloads. Practitioners now see the methodology, not just the output. Platform engineering teams can verify that provider allocation methods align with their internal cost models and chargeback systems.

That single change is the difference between FOCUS as a best-effort cost-data interchange format and FOCUS as a verifiable contract for chargeback. The spec is now the backbone the multi-cloud chargeback playbook can rest on.

The Kubernetes Allocation Problem, Stated Plainly

A multi-tenant Kubernetes cluster runs a fleet of pods across a node pool. Each node has a per-hour cost from the cloud provider. Each pod has a CPU request, a memory request, an optional GPU request, and an actual runtime usage profile that may or may not match the request. The chargeback question is: how do the engineering teams that own the workloads each see a spend number that matches what their workloads actually consume?

Three families of answers:

• Resource-based allocation. Charge each workload for its requested CPU + memory + GPU as a fraction of the node’s total. Predictable and easy to explain. Penalizes workloads that over-request resources they don’t use; under-charges workloads that consistently spike beyond their requests.
• Usage-based allocation. Charge each workload for its actual measured CPU-seconds, memory-byte-seconds, and GPU-seconds as a fraction of the node’s total measured usage. Reflects reality. Harder to explain, harder to budget against, and sensitive to measurement infrastructure.
• Hybrid allocation. Charge each workload for the larger of (its request) and (its measured usage), or for a weighted blend. The pattern most production teams converge on once they have run the prior two for a quarter.

Before FOCUS 1.3, each provider’s chargeback feed expressed the answer at most as a per-row dollar figure with no methodology field. Two providers using two different allocation models produced two different per-workload spend numbers for the same cluster, and the chargeback team had no clean way to verify or reconcile them. The new allocation-specific columns close that gap.

What the New Columns Actually Express

FOCUS 1.3 adds allocation-specific columns that expose, per row:

• Allocation method. Resource-based, usage-based, hybrid, or vendor-defined custom. Required when the row represents an allocated portion of a shared cost.
• Allocation scope. What boundary the allocation is computed across — node, node pool, cluster, region, account, organization. The scope determines how the per-row dollar figure aggregates upward.
• Allocation source and target identifiers. Which shared resource is being allocated from (the node, the database instance, the shared compute pool) and which workload is being allocated to (the pod, the namespace, the application). Allocation sources and targets are what the chargeback team joins on to roll up to the customer-facing chargeback report.

Together, the columns let an enterprise platform team verify, row by row, that the per-workload chargeback number is computed against a methodology the organization’s internal FinOps governance has actually approved. They also let the team independently recompute the allocation from the underlying utilization data, which is the only reliable way to catch a provider feed that has drifted from the documented method.

The columns are optional in the spec but strongly encouraged for any provider whose feed includes allocated rows. The 2026 conformance certification program is the mechanism that turns the encouragement into a market expectation.

What the 2026 Conformance Certification Program Adds

The FinOps Foundation’s 2026 conformance certification program is the structural piece that elevates FOCUS from “agreed-upon format” to “verifiable contract.” The program centers on:

• Public availability of sample data that validates conformance for a specific FOCUS version. Vendors publish a representative slice of their FOCUS-conformant feed, the FinOps Foundation tooling verifies the slice against the spec, and the result is a public conformance gap report.
• Versioned conformance. A vendor can be conformant against FOCUS 1.2 and not yet against 1.3 (or vice versa for newer columns). The version-specific conformance gives buyers the language to ask about the specific columns they actually depend on.
• A public registry. The conformant-vendor list is public, with the per-version detail. Procurement teams now have an external signal to use during vendor selection rather than taking the vendor’s word on cost-data quality.

Combined, the spec changes plus the certification program turn cross-platform chargeback from an integration project owned by the customer’s FinOps team into a contract enforcement project owned by the buyer’s procurement team. That is a meaningful structural shift.

Multi-Cloud Chargeback Patterns Worth Codifying

A 2026 multi-cloud chargeback playbook running on top of FOCUS 1.3 converges on a small set of patterns:

• A unified daily chargeback warehouse. Pull the FOCUS-conformant feed from every cloud provider into a single warehouse table on Snowflake / BigQuery / Databricks. Add the FOCUS-version column so multi-version feeds can coexist. The warehouse becomes the single source of truth for every chargeback question.
• Internal allocation rules layered on top of the provider feed. Some allocation choices the organization makes itself: how to split shared platform infrastructure across product lines, how to amortize one-time onboarding cost across teams, how to handle savings-plan and reserved-instance allocation. These live in a separate, version-controlled layer that joins onto the provider feed by allocation source / target.
• Chargeback report generation against the warehouse, not against any single provider feed. Each customer-facing chargeback report is the result of a deterministic SQL query against the warehouse. The deterministic-query pattern is the chargeback team’s reproducibility guarantee — any historical chargeback can be re-derived from the same data.
• Drift detection between the provider’s allocated number and the team’s recomputed number. Run the comparison continuously. Flag rows where the divergence exceeds a per-workload-class threshold. The drift detection catches changes in provider allocation methodology before they show up in a customer-facing bill.

Enterprises that have run this playbook for two quarters report a material reduction in the chargeback-team headcount they need to keep the report defensible — and a sharp improvement in the speed at which the report can answer ad-hoc questions from finance.

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

What Tooling Helps and Where It Falls Short

The 2026 FinOps tooling landscape covers parts of the FOCUS 1.3 chargeback playbook well. Vendors like Vantage, CloudZero, Apptio Cloudability, Anodot, and Spot.io ingest FOCUS-conformant feeds and surface chargeback reports. Cost-attribution products like Kubecost (now Kubecost-as-part-of-IBM after the acquisition) and OpenCost ship the per-pod allocation primitive that feeds the FOCUS allocation columns from the cluster side.

Where the tooling landscape is still thin is on the cross-vendor reconciliation step. Each vendor’s chargeback report represents a single view of the data. None of them resolve the question: when two vendors report different per-workload numbers for the same shared resource, which methodology is correct, and what is the procurement team’s escalation path? That cross-vendor reconciliation lives in the gap between point-tool FinOps and operational governance.

Three things in particular are hard to wire up with off-the-shelf tooling:

• A continuously-validated cross-cloud allocation reconciliation. Provider drift is real; the customer’s recomputed allocation is the only ground truth.
• A pre-authorized policy escalation path for chargeback disputes. When the chargeback team flags a methodology disagreement with a provider, the path to a procurement-team-driven resolution requires approval primitives that live above the FinOps team.
• An immutable audit trail of every chargeback report, every allocation-rule change, and every methodology dispute — the artifact internal audit and finance reconcile the customer-facing chargeback against.

Those three live above any single FinOps tool. They are the work of an active operational layer, not a passive cost dashboard.

Capability Tiers Mapped to Multi-Cloud Chargeback

The Observe / Operate / Administer capability-tier model maps cleanly to FOCUS 1.3 + Kubernetes split-cost-allocation chargeback:

• Observe. Continuous FOCUS-conformant feed ingestion across every cloud provider, allocation-column parsing, internal allocation-rule application, drift detection between provider-reported and customer-recomputed allocations, and chargeback-report generation. Auto-execute, fully audited.
• Operate. Allocation-rule application against pre-approved scopes, materialized chargeback-report regeneration, and drift-investigation jobs. Auto-execute for reversible / scoped actions; gated when an allocation-rule change crosses an organization-wide boundary.
• Administer. Allocation-rule definition itself, methodology disputes, separation-of-duties exceptions for chargeback corrections, and any change to the chargeback governance policy. Always requires explicit approval.

The mapping is what turns chargeback from a quarterly fire drill into a continuously-defensible artifact.

How IAN Helps: The Resource Agent on the Active Operational Layer

IAN is the AI DevOps team for cloud infrastructure, delivered as a coordinated team of specialized agents on the active operational layer. The resource agent is one of those agents, and it runs continuous resource-and-allocation tracking across every connected cloud account, including the FOCUS-conformant feeds from each cloud provider, the in-cluster allocation feeds (OpenCost, Kubecost-derived), and the internal allocation rules layered on top.

Drift detection between provider-reported and customer-recomputed allocations lands in the audit trail with the per-row delta and the methodology comparison attached. Reversible Operate-tier actions — allocation-rule application against pre-approved scopes, materialized chargeback-report regeneration, drift-investigation jobs — execute automatically when policy permits. Irreversible or organization-wide actions (allocation-rule definition, methodology disputes, governance-policy changes) escalate to the Administer tier with separation-of-duties enforced.

Pricing is BYOK and usage-based with a monthly minimum. Customers bring their own model keys (Claude, OpenAI, or another provider) and pay inference cost directly to their model vendor. IAN charges for the orchestration layer, per agent action, per cloud account, per operation class. Usage scales with the volume of chargeback reports generated and the number of allocation reconciliation actions taken — which is itself a strong signal of the chargeback governance maturity.

The Three-Phase Rollout

Phase 1 — Stand up the FOCUS 1.3 Observe layer. Wire continuous FOCUS-conformant feed ingestion across every connected cloud account, plus the in-cluster allocation feeds, into the resource agent’s read path. Two-to-four weeks for a team with reasonable platform-engineering and FinOps capacity.

Phase 2 — Codify the internal allocation rules and the chargeback report contract. Express the allocation methodology in version-controlled rules. Pre-authorize the allocation-rule application scopes the resource agent can act on. Run a tabletop exercise comparing the customer-recomputed allocation against the provider-reported allocation for at least one full quarter of historical data and resolve every divergence. Two-to-three months of pattern tuning.

Phase 3 — Cross the resource / cost / security agent loop. FOCUS 1.3 chargeback is also a cost-agent input (the same allocation primitives drive optimization decisions) and a security-agent input (the same workload-tagging primitives drive blast-radius analysis). Once the resource agent’s chargeback Observe layer is live, its signals feed the cost agent’s optimization loop and the security agent’s exposure-analysis loop. Each agent’s outputs make the others more accurate.

The combined effect is the same the platform team would get from hiring a senior FinOps engineer plus a chargeback-systems specialist, except the agents run continuously, generate a defensible chargeback report on every reporting cadence, and produce an immutable audit trail that satisfies internal audit, external auditors, and finance. For most mid-market platform teams, that is materially better than the current state.

FOCUS 1.3 is the backbone the chargeback playbook can finally rest on. The active operational layer is what turns the backbone into a continuously-defensible product.

Get a free infrastructure audit → | See pricing →