Usage-based pricing (as well as their outcome-based and hybrid variants) sounds simple until you're the one running it in production.
"Just meter it and burn down the tokens". Sure Jan!
Solvimon processes about $2B in billing volume as of writing this, and lots of our customers run hybrid pricing, which means seats + usage + credits + wallets + overages + discounts + commitments and it's all in one contract.
Usage-based billing events on our platform grew 7x in Q1 2026 compared to Q1 2025, and the average number of pricing components per-contract went from 2 to about 5.
It's not unusual for companies to be running many more distinct billing elements - sometimes exceeding a dozen (but rare for now).
So here's some of the less obvious things we've learned so far:
What you bill, what you sell, and what you measure aren't always the same
Reson8 sells speech AI. Their product measures seconds of audio processed, but their customers buy credits.
Different workload types (realtime inference vs. batch processing) consume credits at different rates.
This sounds like a conversion table but it isn't just that. The raw events come in as seconds, and the billing system converts them to credits based on workload type, draws them from a wallet with its own balance and expiry rules, and the invoice needs to show the customer what happened in units they understand.
The conversion layer between product usage and billable units is where mistakes can happen. If the conversion runs outside your billing system (in a script, a spreadsheet, a serverless Lambda, etc.), it becomes hard to audit, test, and when pricing changes it may be hard to verify.
Rounding can still be hard, surprisingly
One of our fintech customers splits up their usage across different subscription groups. When you divide 10 units across 3 groups, you get 3.33… per group. Round each line on its own and you invoice 9.99, but the customer needs to pay 10.
One solution requested was to distribute the rounding remainder so 3x 3.3333 becomes 3, 3, 4. Not 3, 3, 3. This also applies to token-to-credit conversions where multiple token prices flow into one credit type, and to currency precision (EUR invoices round to 2 decimals, so a line item of €5.6789 becomes €5.68).
This is the kind of problem that shows up much much later, in a support ticket from a customer where the finance team says the invoice doesn't reconcile and it definitely gets worse at scale.
If you're running usage-based pricing at any volume, your billing system needs to handle decimal precision in a variety of places.
Every customer wants different wallet behavior
We spent a lot of internal time debating wallet expiry and rollover logic and there is no default happy path that works for everyone.
One of our customers wanted their monthly wallet grants to expire at the end of the billing period, whereas another wanted unused credits to roll over. Those are simple.
But when a third wanted auto-top-up behavior where the system buys another block of 100 credits for $5 when the wallet runs dry, and a fourth wanted overage to kick in at a different rate than the prepaid credits (with no rollover on the overage block either) - you realise you can't make one decision for everyone.
If you're designing a credit or wallet system, you have to build that flexibility in. You can't just pick one and ship it and hope that it works for everyone.
We talk to our customers regularly about it, but it doesn't make it easier. We build the configuration layer with expiry, rollover, top-up triggers, overage thresholds, grant frequency... But these are all per-customer decisions, and they only show up when you onboard customers in different regions, industries, and commercial models.
Your customer's customer needs the usage data too
Gigs (a telecom-as-a-service platform) runs on Solvimon. They bill their own customers based on the usage data generated and sent to Solvimon. So our usage reports need to land in their systems back in a format their downstream systems can consume.
Usage data doesn't terminate at your invoice. For platform businesses and marketplaces, the metering output is an input to someone else's billing. The export and reporting layer needs the same rigor as the metering layer itself. Gigs also told us that customers' finance teams were doing work on top of those reports we produced.
We'd originally built those reports as internal artifacts, but turns out they were customer-facing documents!
Billing and ERP are one evaluation
One of our customers told us "Billing and ERP form one coherent system. The two can't really be assessed in isolation". You're only as good as your connectivity to all of the downstream systems.
The customer needed one wallet for LLM pass-through costs, one-off implementation fees, and usage-based subscriptions for workflow executions. Their metering stack ingests raw events and evaluates rate cards, Solvimon receives the somewhat aggregated usage and handles invoicing, credits, and payments while downstream an ERP like Campfire records the revenue.
They didn't evaluate Solvimon on tablestakes like "can you generate an invoice", but on if a usage event that starts in a 3rd party metering stack can end up in the ledger with the right ASC 606 treatment for prepaid credits vs. overage vs. subscription revenue.
Prepaid credits get revrec'd as customers burn them and not when they're sold - which ends up creating deferred revenue entries.
On the other hand, overages get recognized when incurred, and the subscription revenue works month-by-month.
Those are three or four (depending on how you count) different recognition patterns on one customer's contract and they all need to end up in the ERP without the dreaded manual journal entries that anger finance people.
These are some of the triggers we hear from prospects:
"We price on tokens or credits or agents and it changes every quarter."
"Prepaid credits and wallets... we can't track burn-down or rollovers properly."
"We invoice in multiple currencies and entities and there's a monthly reconciliation mess."
And yes, complexity compounds
That 7x growth in usage events and the jump from 2 to 4.8 pricing components per contract aren't that different, they're tightly related and they feed into eachother.
More usage-based components means more metering which means more conversion logic which means more wallet mechanics, and that always ends up with more edge cases in invoicing
The companies we work at Solvimon don't plan up front for this complexity. This is doubly true if they're trying to build something in-house first.
They started with a subscription, added a usage component, then added credits, then needed wallets, then needed the wallets to go downstream to the ERP, then it turns out that the usage report format didn't work for their customer's finance team.
Each step, in isolation, is a reasonable decision. The total system really hurts (and yes - I know this first hand since I've built this about 4 times by now).
Look, if you're early in usage-based pricing or if you're considering building your own billing stack the thing I'd want you to know: the billing infrastructure decision is upstream of everything.
If you get that wrong, every pricing experiment and every deal you sign becomes a very lengthy and painful custom implementation.
