Who: Usage Billing Report’s Open Meter Spec Working Group, convened by the publication with billing vendors, enterprise SaaS pricing teams and cloud-cost tooling providers.

What: The group released Candidate 0.9 of an open, vendor-neutral specification for exporting usage meters from SaaS platforms, and published reference implementations, test suites and early interoperability results.

When: Candidate 0.9 went public on August 15, 2026; the working group ran a focused interoperability sprint July 12–30, 2026 and published JavaScript and Python reference libraries on August 24, 2026. A conformance badge program launched September 1, 2026.

Where: Specification artifacts, test suites and implementer reports are available on the working group’s public GitHub repository and on usagebillingreport.com.

Why this matters now: As more vendors adopt usage-based pricing and enterprise buyers demand portable metered exports, a standardized, pragmatic export format aims to reduce migration cost, speed audits and enable accurate cross-vendor price comparisons.

Context — progress since the draft

The working group moved from requirements-gathering (March–April 2026) and a public draft in May 2026 into hands-on interoperability testing over the summer. Participation expanded from the early convening roster to 47 contributors across 29 organizations representing six billing platforms, eight enterprise SaaS vendors, nine cloud-cost analytics firms and several independent consultants across North America, Europe and APAC.

That growth reflected two industry drivers: (1) a 2024–26 acceleration in usage-based contracts for mid-market and enterprise buyers — vendors increasingly offer hybrid seat-plus-usage models — and (2) rising procurement pressure to provide auditable exports that feed third-party chargeback and FinOps tooling. For pricing and billing teams, these trends mean migration and reconciliation work is now a recurring operational cost rather than a one-off project.

What’s new in Candidate 0.9

  • Minimal core JSON schema finalized (fields and types): Candidate 0.9 mandates timestamp, metric_id, quantity, unit, granularity, source_id and meter_version as the core; optional fields include dimensions, sampling_rate, and user_id_hash for pseudonymous attribution.
  • Provenance and audit metadata: A signing envelope (detached JWS) plus sampling and reconciliation hints are specified to support auditor workflows without requiring vendors to disclose internal aggregation logic.
  • Core vs extended profiles: The candidate defines a lightweight "core" profile for most migrations and an "extended" profile for multi-dimensional meters (for example, seats × time × feature_flags).
  • Reference libraries and test-suite: JavaScript (Node) and Python reference libraries were published on GitHub on August 24, 2026, and a public conformance test-suite (v0.9-test) was released on the same day.
  • Conformance badge: The working group introduced a three-tier conformance badge (core, extended, interoperable) on September 1, 2026 to help buyers identify interoperable exports.

Interoperability results and practical examples

During the July 12–30 interoperability sprint, 18 adapters were developed by vendors and integrators to export and ingest Candidate 0.9 payloads. Of those, 14 passed all core conformance tests as of August 30, 2026; four reported partial compliance pending work on signed provenance handling.

Example outcomes observed during tests:

  • A mid-market CRM vendor exported per-minute seat-usage using the core profile; a cloud-cost platform ingested the export, normalized the metric_id to its canonical internal identifier and produced a per-customer charge reconciliation in under 45 minutes—down from a typical two-day integration in earlier projects.
  • A payments platform used the extended profile to export multi-dimensional event metrics (event_type × region × latency_bucket), which required a small adapter but avoided custom ETL at the buyer.

Impact — who benefits and how

Buyers: Faster migrations and clearer audits. Conformance badges let procurement teams filter vendors that can export auditable usage files without bespoke connectors.

Vendors: Reduced sales friction and lower integration support costs—billing teams reported that onboarding customers with a conformance badge eliminated several support tickets tied to metric translation.

Tooling providers: Chargeback and FinOps tools can build once against the core profile and cover a large portion of real-world deployments, reducing per-customer engineering effort.

Outstanding technical and policy trade-offs

Despite progress, several design questions remain open ahead of the planned 1.0 candidate in Q4 2026:

  • Canonicalization of metric meaning: Candidate 0.9 standardizes identifiers and export shapes but does not require vendors to expose internal metric definitions; buyers still must map semantics in some complex cases.
  • PII and privacy: The spec allows pseudonymous user identifiers (user_id_hash) but leaves regional compliance (GDPR/CCPA) implementation choices to vendors. Several European contributors flagged the need for explicit guidance on data minimization before 1.0.
  • Signed provenance adoption: Implementers are evaluating detached JWS signing for tamper-evidence; performance and key-management patterns differ across vendors and are on the working group’s security agenda for October 2026.

Reactions from the field

"We integrated the JS reference lib into a staging pipeline and matched 94% of historical reconciliation rows automatically," said Lina Morales, editor-in-chief of Usage Billing Report. "That's the kind of operational ROI pricing teams asked for."

An anonymous engineering lead at a cloud-cost platform that participated in the interoperability sprint said: "The conformance tests exposed a few real edge cases—sampling_rate semantics, in particular—but meeting a common baseline cut our average onboarding time by weeks."

Some vendors remain cautious about exposing metric-level semantics that they view as product differentiation. The working group has addressed this by defining an extensible vendor_metadata block that allows vendors to keep proprietary annotations while still exporting a canonical, auditable core.

What pricing and billing teams should do now (September 2026)

  1. Inventory your top 5 problematic metrics and map them to Candidate 0.9 core fields. Target completion by October 15, 2026 so you can join the Q4 conformance sprint.
  2. Designate a technical liaison to pull the JS/Python reference libraries from GitHub (published Aug 24, 2026) and run the v0.9-test suite against staging exports.
  3. Evaluate vendor conformance badges during procurement; require a staging export as part of proof-of-concept contracts before signing production agreements.
  4. Document privacy requirements (PII, retention) and share them with vendors; the working group expects to publish recommended privacy patterns in October 2026.

What’s next — timeline through Q4 2026

  • September 2026: Conformance badge program operational; early adopters display “core” badges on procurement pages.
  • October 2026: Security and privacy guidance published; second interoperability sprint scheduled Oct 10–28, 2026.
  • November–December 2026: Candidate 1.0 release window with finalized profile names and an expanded set of language libraries (Go and Java planned).

Frequently asked questions

Is Candidate 0.9 stable enough for production migrations?

Candidate 0.9 is intended for staging and pre-production testing. Several vendors used it successfully in pilot migrations during July–August 2026, but the working group recommends completing your mapping and running the v0.9-test suite before relying on it for high-volume production exports. Expect a formal 1.0 candidate in November–December 2026.

Will vendors have to reveal proprietary metric logic?

No. The spec separates exported, canonical identifiers from internal definitions. Vendors can include proprietary annotations in a vendor_metadata block while exposing a normalized core that buyers and tooling providers can ingest without needing internal aggregation algorithms.

How does the conformance badge work?

The badge has three tiers—core, extended and interoperable. Organizations run the public conformance tests (v0.9-test) and submit results for badge issuance. As of September 1, 2026, badges are self-attested with public test artifacts; the working group plans a third-party verification option in 2027.

What about privacy and regional compliance?

Candidate 0.9 provides optional pseudonymization fields (user_id_hash) and encourages minimal export of PII. The working group will publish concrete GDPR/CCPA mapping guidance on October 20, 2026; until then, buyers should require vendors to document retention, access controls and data deletion processes in procurement contracts.

Usage Billing Report will continue to publish progress updates and host the next public webinar on October 6, 2026. Pricing and billing teams that want to join interoperability sprints should sign up via the working group's GitHub repository.