Salesforce signed a definitive agreement to acquire m3ter on June 8, 2026, six months after Stripe acquired Metronome. The headlines call it a usage-based billing story, which it is. The more useful framing for any AI team picking a billing stack is what the deal pushes into focus underneath the headlines. AI billing splits into two layers, metering and authorization, and most platform comparisons treat the two as the same thing. This article maps the layers, shows where each platform fits in the real-time billing architecture debate, and explains why the sophisticated AI teams we work with run both.
Two layers, not one
A usage-based billing stack does two distinct jobs.
Metering and rating. Capture every usage event, attach pricing logic, produce a calculated bill line item, and feed that into an invoicing or ERP system. The output is a clean invoice at cycle end. m3ter, Metronome, Orb, and Lago are designed for this job.
Authorization and settlement. Before a usage event runs, check the customer's balance. If the balance allows it, debit it in one atomic operation and let the event proceed. The output is real-time control over what the customer is allowed to spend. Credyt is designed for this job.
Both layers handle usage. They handle it at different points in time. Metering looks backward and reconciles. Authorization looks forward and decides. Treating one as a substitute for the other is the conceptual mistake that has shaped most AI billing comparisons published in the last twelve months.
What the layers do in sequence
In a metering-only architecture, the authorization layer is missing. The customer can rack up cost in any volume; the metering layer records it faithfully; the invoice arrives at cycle end. In an authorization-only architecture, every event is gated against a balance, but the metering and invoicing details on the back end are simpler. In a combined architecture, the authorization layer protects unit economics in real time and the metering layer produces the enterprise-grade invoice.
What Salesforce bought
m3ter is metering and rating middleware. The platform ingests usage events, applies pricing logic, and produces calculated bill line items. It does not generate invoices. It does not process payments. The line items get fed into the customer's existing billing stack: Salesforce Revenue Cloud, NetSuite, or Stripe Invoicing.
This is m3ter's own framing. From the company's product documentation: "We don't, by design. m3ter is an infrastructure product. We focus on the things ERP and billing systems don't do well (usage data processing and complex rating) and then feed them with calculated bill line items."
The customer roster reads as a who's who of mid-market and enterprise UBB: ClickHouse, Sift, Onfido, Snyk, Codat, HouseCanary, AccelByte, Regal. HouseCanary's case study reports compressing billing operations from three weeks to three hours. Onfido recovered roughly 1% of revenue by replacing a homegrown system (m3ter customers page, accessed June 2026).
Salesforce was already an m3ter investor and the platform's designated metering and rating partner. In March 2026, m3ter shipped a Salesforce connector covering Revenue Cloud Advanced, Revenue Cloud Billing, Agentforce Sales, and Salesforce CPQ. The June deal formalizes that integration inside Agentforce Revenue Management. Expected close: Q2 of Salesforce's fiscal year 2027 (Salesforce press release).
One pattern note. Stripe acquired Metronome in December 2025, and now Stripe and Salesforce both own a metering layer. The metering job is consolidating into the two largest revenue platforms. Authorization is not.
Where Credyt sits
Credyt is the authorization layer. Every usage event hits the platform first; the customer's balance is checked; the event is allowed or blocked; on allow, the debit is atomic with the authorization. Cost cannot land against the platform's own COGS without first having been authorized against a known balance.
Two things make this useful for AI products specifically. A single misbehaving agent or runaway prompt can spike a customer's costs ten times over in an hour; in the AI teams we work with, that pattern shows up repeatedly. Authorization checks let the platform refuse the eleventh request when the first ten have already consumed the balance, instead of producing the bill three weeks later. What real-time monetization actually means is exactly this: deciding before the model runs, not after.
The second thing is multi-asset balances. AI usage is not denominated in dollars at the point of consumption; it is denominated in tokens, requests, or GPU-seconds. Credyt's custom assets let the authorization decision happen in the native unit, then settle to dollars on the back end. Both properties matter because AI companies need real-time economic control, not a cycle-end accounting layer.
Credyt and m3ter, side by side
The right way to read this table is by layer, not by platform. Each row describes how a platform handles a specific job, not which platform wins.
| Axis | m3ter (post-acquisition: Agentforce Revenue Management) | Credyt |
|---|---|---|
| Primary layer | Metering and rating | Authorization and settlement |
| When usage is captured | Ingest after the event | Authorize before the event |
| Atomic debit at usage time | No (cycle-end reconciliation) | Yes |
| Output | Bill line items for downstream invoicing | Real-time wallet balance + branded portal |
| Handling a 10x cost spike | Visible at cycle end, after costs landed | Platform can block before the cost lands |
| Multi-asset balances (tokens, GPU hours) | Native (m3ter Balances) | Native (custom assets) |
| Customer-facing portal | Build your own via API | Branded billing portal included |
| Salesforce integration | Native (post-close) | API and MCP server, not native to Revenue Cloud |
| Common pairing | Standalone, or with a downstream ERP | Standalone, or paired with a metering layer for enterprise invoicing |
| Fits when | Adding UBB to a Salesforce or NetSuite subscription stack | AI and API products with real-time cost variability |
m3ter answers the question "how do we produce a clean enterprise invoice for usage." Credyt answers the question "how do we control whether the usage runs at all." Both questions are real; sophisticated AI companies tend to answer both at once.
When you only need metering
If usage costs are predictable and low-variance, authorization adds operational complexity without much upside. Storage products, traditional API products with stable per-unit costs, anything where the worst-case cost in any hour stays within a known band. These slot cleanly into invoice-based middleware. The cycle-end reconciliation is the native shape, and the metering layer alone produces the right business outcome.
Companies running a stable Salesforce or NetSuite stack who need to add UBB to an existing subscription business are usually better off starting with m3ter than with a real-time authorization layer. Migration cost matters. The right question is whether the worst-case overspend in any cycle is large enough to justify a second layer; for predictable products, the answer is no.
m3ter has product depth in specific areas Credyt does not match: multi-attribute rating, parent-child account hierarchies for channel and distributor billing, and deep ERP integration patterns Salesforce shops already rely on. If any of those is the binding constraint, the choice starts with m3ter. Even then, adding real-time authorization alongside without replacing the stack stays an option for later.
When you only need authorization
If the metering and invoicing surface is simple, with flat per-token pricing, a small product catalog, and a single billing currency, adding a separate metering middleware adds latency between event and invoice without adding accuracy. The authorization layer's own debit log is already the source of truth for what the customer used. A direct line from authorization to invoicing keeps the architecture simpler.
This is the common shape for early-stage AI products and API-first companies. One platform, one balance, one invoice trail. The same wallet that gated the request produces the receipt.
When you need both
The sophisticated case, and the one we see most often in AI teams beyond seed stage, is running both layers. Authorization sits at the request edge and protects unit economics in real time. Metering sits behind it, applies enterprise rating logic across multiple products and price plans, and produces the invoice line items that enterprise procurement teams expect.
The two-layer setup is what makes contracts with quarterly true-ups, volume commits, and multi-attribute pricing work without giving up real-time cost control. The authorization layer enforces the spending policy the contract specified; the metering layer translates accumulated usage into the invoice the finance team signs off on.
Running both layers is the practical path for teams that already have a metering or invoicing investment. It is not a forced rewrite.
Closing
Metering and authorization are not competing answers to the same question. They are two layers of a usage-based billing stack, and AI products at scale need clear thinking about which layers they own and which they outsource.
m3ter and Agentforce Revenue Management own metering and rating. Credyt owns authorization and settlement. The two layers can run together, and for AI products with real cost variability they usually should. The Salesforce deal is a useful prompt to look at the stack you already have and ask which layer is missing.
See Credyt for AI companies for how the authorization layer maps to specific AI product shapes.
Frequently asked questions
Did Salesforce acquire m3ter?
Yes. Salesforce signed a definitive agreement to acquire m3ter on June 8, 2026. The transaction is expected to close in the second quarter of Salesforce's fiscal year 2027, subject to customary closing conditions. Deal value was not disclosed.
What is the difference between metering and authorization in usage-based billing?
Metering captures usage events after they happen, applies rating logic, and produces bill line items for an invoice. Authorization checks a customer's balance before a usage event runs and decides whether to allow it; on approval, the debit is atomic with the authorization. Metering is a settlement job; authorization is a control job. Both are part of a complete usage-based billing stack.
Can m3ter and Credyt run together?
Yes. The authorization layer (Credyt) sits at the request edge, gating usage against the customer's balance. The metering layer (m3ter, Metronome, or similar) applies enterprise rating logic and produces invoice line items downstream. This pairing is common in AI products that have outgrown a single-layer setup but need to keep real-time cost control.
What happens to existing m3ter customers?
Salesforce has stated that m3ter's mediation, metering, and rating capabilities will be integrated natively into Agentforce Revenue Management. The press release frames this as more choice alongside existing Salesforce billing models. Post-close product roadmap for non-Salesforce customers is not yet detailed publicly.
How does m3ter compare to Credyt?
m3ter is invoice-based metering and rating middleware that feeds bill line items into an existing billing stack like Salesforce Revenue Cloud or NetSuite. Credyt is a real-time authorization and settlement layer where the customer's balance is checked before each usage event and debited atomically on approval. The two platforms address different layers of the billing stack and can be paired in a single architecture.