Every AI company I talk to is running two pricing motions at once:

1. A subscription for platform access

2. + consumption charges on top.

Sometimes a third if we consider the prepaid credits…

The single-bill view is the easy part. The hard part is what's underneath with three different rating engines arguing about who owns the customer's invoice this month.

This is a piece about what usage-based billing actually requires from your stack, the pricing models people are running, and where the comparison between Stripe Billing + Metronome and Solvimon actually stops being relevant (hint: not cost)

How usage-based billing works

There are typically three components, working in sequence in UBB:

1. Event collection. Your product emits an event for every billable action (an API call, a token consumed, a task completed). High volume, no data loss, audit trail, the whole shebang.

2. Metering and aggregation. Raw events get aggregated into billable quantities, per customer, per product line, per billing period, you name it.

3. Rating and invoicing. Aggregated quantities get multiplied against the applicable rate to produce an invoice.

The hard part is in step 3 because of the complexities of "actioning" the math.

Two customers can consume identical volume and owe different amounts because they're on different plans, different commitment tiers, or have a custom rate the AE negotiated at 2am on the contract close. The billing engine has to hold all of that in its head simultaneously, and apply the right logic per customer per cycle.

You may think that's a minor thing but that's most of the work.

The pricing models people are running

Here's what I see across our customers at Solvimon:

Pure consumption. Pay per unit, fixed rate, no minimum. Common in dev-facing AI APIs (e.g., the early OpenAI API). Volume varies wildly, customers refuse to commit, you eat the variance.

Tiered. Per-unit rate decreases with volume, in two types:

You need to support one or both, and you need to do it consistently. (The number of pricing pages I've seen that claim "graduated" and silently rate as "volume"... well.)

Committed consumption with overage. Customer commits to a minimum spend or volume at a negotiated rate. Usage inside the commit bills at that rate. Usage above bills at a higher overage rate. This is the dominant structure for enterprise AI contracts right now. Predictable revenue for the vendor, predictable cost for the buyer, until the commit doesn't cover the year-end traffic spike. Then it gets interesting.

Credit-based. Customer prepays into a balance. Usage draws it down and new credits get bought any time and all the time. You then have to decide:

• Do credits expire? At period end, never, or with a max balance roll-over?

• How is breakage (unused expired credits) recognized?

• How fresh does the balance need to look in the customer's UI? (Real-time, if you want to keep enterprise customers.)

• If one balance spans multiple products, who tracks which product drew which credits?

Again, like before - these aren't things you can just guess or decide because they're the architecture you'll be stuck with for eons.

Hybrid. The catch-all for recurring base fee plus usage on top, consolidated onto a single invoice. Most enterprise B2B AI deals are shaped this way (e.g., a $50K/quarter platform fee plus tokens-consumed overage). The system runs subscription logic and consumption metering and then reconciles them.

What the billing infrastructure actually has to do

The list of things is long but the bar to reach, meaning the quality you have to live up to is surprisingly hard to get right:

1. Event ingestion from a warehouse (Snowflake, BigQuery, Redshift) or directly via API. AI products at scale are doing millions of events a day. The pipeline has to handle that without dropping events.

2. Real-time metering. Enterprise customers expect to watch usage accumulate in their dashboard, not wait for the invoice. For credit-based products this is non-negotiable.

3. A rating engine that holds custom terms. Per-customer overrides, ramp schedules, mid-cycle plan changes, currency conversion, recalculation when terms change. Pricing exceptions stay attached to subscriptions as structured data, not as PDF amendments stuffed in Salesforce.

4. Subscription and contract management at the structured-data level. Bulk migrations, i.e., moving hundreds of customers from one plan version to another while preserving per-customer custom terms, is a routine operation in mature systems. In immature ones it's a JIRA epic.

5. Multi-entity, multi-currency. Different legal entities, different currencies, different tax jurisdictions, different invoice formats, intercompany reconciliation. Becomes a hard requirement the day you sign a customer in a country that wasn't on the roadmap.

6. Tax. My favorite topic - because you can either go native, or via Avalara, Anrok, Sphere, etc. Usage-based tax is harder than subscription tax because the taxable amount changes every invoice.

7. Revenue recognition. My second favorite because under ASC 606 / IFRS 15, you recognize revenue as performance obligations are satisfied. For consumption: as usage occurs. For credits: deferred until consumed. Your billing system needs to feed period actuals, deferred revenue balances, and contract modification records into the finance team's stack in a form they can actually use. This is where most billing-system replacements get triggered.

   
   

Stripe Billing + Metronome vs Solvimon

Series B AI companies scaling internationally usually look at two architectures:

1. Stripe Billing + Metronome. Stripe runs subscriptions, invoicing, and payment collection. Metronome sits above it as the metering, rating, and event processing layer. You're integrating two systems and owning the seams.

2. Solvimon. Catalog, Metering, Subscriptions, Wallets, Entitlements, Invoicing, Revenue, Workflows in one system. Solvimon connects to Adyen, Stripe, Checkout.com as payment gateways rather than replacing them. (Built by the team that ran billing at Adyen at over €1T in annual payment volume.)

The cost question is the wrong question to lead with because it doesn't matter as much as the architecture:

The Stripe + Metronome stack works when you have engineering capacity to own the seam between the two systems and your pricing changes infrequently. Solvimon makes more sense when finance or RevOps wants to own pricing configuration directly, when enterprise custom terms are accumulating faster than you can wrangle them in code, and when you want pricing iteration to move at the speed of a product manager rather than an engineering sprint.

These are different bets. They're not better-or-worse bets.

What to evaluate when choosing a billing architecture

Forget feature lists. Five questions cut through:

1. Configuration ownership. Can finance or RevOps change a pricing model directly, or does every change require an engineering ticket? This determines how fast you can respond to a competitor or to model-cost shifts.

2. Mid-cycle changes. A customer upgrades in week two. How does the system prorate? The right answer is automatic, auditable, consistent across customers.

3. Credit architecture. Expiration rules, breakage handling, balance freshness, multi-product allocation. Hard to change post-launch.

4. Bulk operations. Moving customers across plan versions while preserving per-customer custom terms. How the platform handles this tells you whether it was designed for enterprise scale or shipped with the assumption that you'd never need it.

5. The data pipeline to your finance stack. Where do usage events enter, what's the lag from usage to billing record, and what does reconciliation look like when event counts don't match invoice amounts? This is where most billing-system errors originate. Ask to see the data model before you commit.

When you're ready to evaluate, check out Solvimon's generous free offering or give us a shout for a discovery session.