Arnon Shimoni
✓ Expert opinion
A billing system has one job, roughly - to tell you what a customer owes right now, and why (and then to act on it).
The "why" matters more than the "what" because if you can't trace the answer back through the events, contracts, prices, credits, and prior invoices that produced it, you don't really have a billing system that you can defend.
After watching some announcements this week, it's clear most companies running modern pricing models split that single job across two systems and that's not great.
A metering engine ingests usage events, rates them against contracts, and produces line items, and then afterwards a billing system takes those line items, applies subscription logic and discounts, generates invoices, and collects payment.
That's two systems and a pile of sync code holding them together (even if it's not YOUR sync code).
I think the split is the source of most billing pain at scale, and the right shape is one ledger. Stripe and Metronome are the most recognizable example of the split right now, and we'll get to them in a bit but the split-system is not great.
The seam that is problematic
Every multi-system billing setup has a seam which is the place where the metering side hands data off to the billing side, or the other way around. It is also the place where things go wrong.
The metering side knows what events came in, when, and how they were rated. The billing side knows what invoice got produced, what payment got collected, and what the customer's balance is. Neither side, by itself, has the full chain from event to dollar.
When everything is the happy path that's not a big problem, but you and I both know the happy path doesn't always apply.
What goes wrong at the seam
Say a customer disputes a $51,000 invoice - your customer support and finance team both needs to know why. If the metering system shows the events and the billing system shows the invoice, somebody has to still walk the contract by hand and check two separate dashboards, understand what happened, and issue the credit note. This happens every time someone asks why.
With two systems operating side-by-side, a late event that arrives three days after period close won't be processed because the invoice would've already been issued. So now you need to decide what the behaviour is like: Credit+Reissue, or carry it forward with multiple lineitem periods? Both can be confusing if you don't handle them well enough in your app, communication, billing portal, and even your own internal dashboards.
These two aren't "bugs", they're natural when invoice records live in two places.
Why companies split it in the first place
The split usually happens by accident:
You launch with a payment processor that has a built-in subscription billing module and that's the easy thing to do. That module handles fixed-price subscriptions cleanly and it works for you, at least until you add usage-based pricing, or AI inference billing, or a credits model, or a hybrid contract with platform fees. The subscription module wasn't designed for any of that, so you bolt on a metering tool.
Heck, you might even bolt on the metering tool that your payment processor recommends - but now you have two systems: the metering tool ingests events and produces line items and the subscription module turns those line items into invoices.
The other path is custom-built. Your team writes its own metering on top of an event stream, and keeps the existing billing tool for invoices and payment collection. Same seam, different vendors.
Both paths produce the same architecture. An event ledger and a transaction ledger, federated by sync code your team has to maintain forever.
What this actually costs you
When I talk to CTOs or engineering leaders running this shape, the costs come up in three places:
Pricing agility. The number of pricing experiments a company runs per quarter tracks pretty directly with how many systems pricing logic lives in. Vercel runs 5-6 pricing changes a month. They aren't faster because their billing vendor shipped scripts. They're faster because pricing logic lives in one place they own.
Engineering time. Two to three engineers maintaining billing glue full-time. Not building features. Not improving the product. Maintaining sync. The team usually doesn't call this a "billing team" until they hire the third engineer and someone notices.
Close cycles. Two-week closes are normal for companies running parallel ledgers. Finance doesn't feel productive during those two weeks. They feel like they're chasing two systems and writing memos to explain the gaps. This usually only happens in bigger companies, though.
These costs don't get better when your vendor ships more features, but they do do get worse as you scale, because every new product line, every new entity, and every new pricing experiment lands on top and messes up your sync code.
You need to make a data-model decision
A unified billing ledger means the same data structure holds events, contracts, rate cards, prices, credits, balances, and invoices. The state of any customer at any point in time is one query against one source of truth. There is no "metering side" and "billing side." Events flow into the ledger, contracts and prices apply, credits draw down, invoices come out, payment status updates the ledger.
That's good for a few reasons:
Tracing is one query
Asking "why does this customer owe $51,000 this month" returns the rated events, the applicable contract, the price applied, the credits drawn, and the invoice generated, in one coherent walk. You don't open two dashboards. You don't run a join across two databases.
Pricing logic lives in one place
Changing a price means changing the rate card in the ledger so that the change applies to future events. Past events should remain immutable, and there is no "now sync the new price to the billing system" step, because there is no separate billing system.
Reconciliation is constant and continuous instead of periodic
The ledger is reconciled by definition. Period-end isn't a reconciliation event. It's a snapshot of state that already balanced.
The PSP layer stays separate
This part matters the most as you grow internationally. A unified billing ledger should not be married to a payment service provider - because PSP selection is a commercial decision. These decisions matter based on rates, geography, and local payment methods that belong in a separate layer.
When you renegotiate or switch PSPs, the ledger doesn't change.
This is the inverse of the bundled-vendor pattern because the bundled vendor wants billing inside payments. The right architecture keeps billing inside your control and treats payments as a swappable backend.
Let's look at Stripe Billing + Metronome
The clearest current example of the split-system pattern is Stripe's billing stack, especially after its January 2026 acquisition of Metronome and the 288 launches at Sessions 2026.
There's some serious upgrades there, but what didn't change is the underlying architecture. Stripe's own integration documentation lays it out plainly. From How Metronome works with Stripe:
"Metronome and Stripe maintain independent invoice records. Void the invoice in both systems (and any other downstream system) to keep records in sync."
That's the seam, named plain and simple. A few paragraphs further down on the same page, you'll see that Metronome pushes finalized invoices to Stripe via the Invoicing API in a one-way sync. Stripe doesn't send invoice data back to Metronome. Payment status syncs back. The invoice itself is owned by whichever system created it.
One-way sync is how engineers describe a federation between two systems, not a single system with one ledger.
Read that again if you have to - because I think it's very dangerous.
Why this happened
Stripe Billing was built as a payments-first ledger and its data model assumes static charges: you set a price, you generate an invoice, you collect a payment.
Adding event-ingestion to that model means rebuilding the foundation. Rebuilding the foundation means breaking every existing Stripe Billing customer or maintaining two parallel codebases for years.
Stripe picked a third option by acquiring the company that already had an event ingestion engine, integrate at the API and Dashboard level, and let customers wire the two systems together themselves.
It's a reasonable business decision - but it probably isn't as temporary a state as it sounds.
What this means if you're on Stripe today
What Stipre Sessions 2026 didn't change is where pricing logic lives, how reconciliation works, or who owns invoice records and those answers are the same as they were last year. In at least two systems
It's worth mentioning that the lock-in shape gets worse over time. If your billing logic ends up encoded in Stripe's scripting DSL, with custom objects modeled inside Stripe and Workflows orchestrating your invoice flows, none of that comes with you when you leave or want to grow internationally.
Other vendors land in the same architectural neighborhood for similar reasons. Zuora plus a metering tool. Chargebee plus an event pipeline. Recurly with sync code stitched on top. Custom-built systems with two databases. The case study is Stripe because the documentation is the most explicit. The pattern is everywhere.
What right looks like
At Solvimon we ran into the split-system pattern at scale back at Adyen. There, It was one ledger, by design, because every alternative they evaluated produced the same problem: more sync code, slower close cycles, less pricing flexibility.
Solvimon is built on the same premise, so there's no second system to reconcile against, because there is no second system. Hybrid pricing (subscription + usage + credits + platform fees + custom contracts) is one data model, not an integration. The PSP layer stays separate, where it belongs.
What to do about it
If you're scaling a company that's currently running billing across two systems, you have three options.
You can keep going. It's manageable until it isn't, and most companies hit "isn't" somewhere between $10M and $50M ARR, depending on how complicated the pricing gets.
You can wait for your bundled vendor to fix it. The reasons it hasn't been fixed aren't new, and Sessions 2026 was a clear signal that the current plan is to ship around the seam, at least as far as the public roadmap is concerned.
Or you can move to a unified ledger before the sync code grows further. Migration is a one-time project. Sync code is a permanent line item on your engineering roadmap. The longer you wait, the more sync code you're migrating away from.
Whichever option you pick, keep coming back to the question we started with. What does this customer owe right now, and why?
If your system can't answer it from one place, you're paying for the seam every month, and the bill is showing up in places you might not be tracking.
