Your June invoices came from Stripe Billing and your July invoices came from Orb, and now your accountant is asking a question neither system can answer on its own: how much metered revenue did you actually earn in the quarter? The old platform rated June usage under one set of aggregation rules, the new platform rates July usage under another, and the ledger in between holds two months of unbilled-receivable accruals that no longer tie to anything either system reports. That gap — between usage events, invoices, and recognized revenue — is where billing-platform migrations quietly fail. Not in the API integration, which takes days, but in the reconciliation, which takes months if you do not plan for it.
This is a mainstream problem now. A January 2025 survey of 100 SaaS companies found 85 percent had adopted usage-based pricing, and Stripe reports that 74 percent of suppliers had adopted usage-based models as of 2026. For AI companies the shift is even sharper: in Stripe's 2025 survey of AI-company leaders, 56 percent reported hybrid pricing and 38 percent pure usage-based pricing. And the vendor landscape keeps moving under your feet — Stripe completed its acquisition of Metronome in January 2026, and Adyen completed its acquisition of Orb in July 2026 — so even staying put means your platform's roadmap, pricing, and integrations can change mid-contract. Founders switch to get SQL-defined metrics, real-time metering, prepaid commits and credits, or pricing-iteration speed their current platform cannot offer. The switch itself is the easy part. Keeping the books believable through it is the real project.
Why two billing systems never agree with each other
A usage-based invoice is the output of a rating pipeline: raw usage events go in, aggregation rules roll them into billable quantities, the rate card prices them, and adjustments (credits, minimums, proration, late events) produce the final line items. Every platform implements each stage slightly differently, and those differences compound.
Aggregation rules differ in the details that matter. One platform sums a tokens property across events; another takes the max concurrent, the last reported value, or a unique count. Free thresholds, tier boundaries, and rounding (per-event vs. per-invoice) each move totals by small amounts that look like noise until you try to tie a migrated invoice back to the usage your product actually metered. The only reliable way to catch these differences is to replay a full billing period of raw events into the new system and compare rated output against invoices you already sent and know were correct.
Late and corrected events land in different periods. Usage pipelines always have stragglers: events that arrive 24 to 72 hours late, duplicates from retried ingests, corrections your product emits after the fact. Each platform has its own backfill and backdating behavior — whether a late event re-opens a closed period, lands as a catch-up adjustment in the current one, or gets dropped past a cutoff. During a migration month, the same straggler can be counted by one system and missed by the other, or counted by both.
Proration and period boundaries are platform-specific. Mid-cycle plan changes, upgrades, seat-count true-ups, and billing anniversary dates are computed per each system's rules. Move a customer mid-cycle and the two platforms can split the same month's usage across different service periods, which matters because revenue recognition follows service periods, not invoice dates.
Tax and payment plumbing moves too. Neither Stripe Billing, Orb, nor Metronome is a merchant of record: Stripe handles tax through the separate Stripe Tax add-on, Orb routes through Avalara or Anrok integrations, and Metronome leans on its Stripe-native integrations. A migration that changes how tax is calculated or which gateway collects payment changes the gross-to-net math on every invoice, which is exactly the math your reconciliation ties out.
The three-way tie-out that breaks: events, invoices, revenue
Under ASC 606, usage-based fees are variable consideration, and the revenue is recognized in the period the customer uses the service — not when you bill for it. Usage delivered but not yet invoiced at month-end is recorded as an unbilled (accrued) receivable, included only to the extent a significant reversal is not expected once the uncertainty resolves. In plain terms, your books carry three related numbers every month:
- Metered usage — what your product and the billing platform agree the customer consumed.
- Billed invoices — what the platform actually charged, after rating, credits, and adjustments.
- Recognized revenue — usage earned in the period, whether invoiced or still sitting in unbilled receivable.
In a steady state these three reconcile: recognized revenue equals invoiced usage plus the change in unbilled receivable. A mid-year platform switch breaks all three legs at once. The old system stops producing invoices but still holds the only record of how June usage was rated. The new system starts producing invoices rated under different rules, so July's invoices are not comparable to June's. And the unbilled-receivable balance accrued under the old regime has to be relieved by invoices issued under the new one, which will not match to the dollar. If you cannot explain each variance line by line, your auditor cannot either — and "we switched billing systems" is a reason for variances, not a substitute for reconciling them.
The finance-safe migration playbook
Billing migrations fail in reconciliation, not integration. Work through these in order, and do not compress the parallel run.
1. Freeze closed periods before you touch anything. Lock the accounting periods the old system already billed, and treat any late-arriving usage for those periods as catch-up adjustments in the next open period — which is also how mature platforms handle it natively. Never re-rate a closed period in the new system and restate history unless you are prepared to re-issue invoices and amended tax filings to match.
2. Dual-ingest raw events from day one of the cutover. Point your product's usage-event stream at both platforms simultaneously, with stable idempotency keys (event_id per event) so retried ingests do not double-count. Both systems should see identical raw input; every downstream difference is then a rating difference you can investigate, not a data difference you can only guess at.
3. Replay one full historical period and reconcile line by line. Re-ingest at least one complete billing cycle of historical events into the new system and compare the rated output against the invoices you actually sent. Reconcile at the line-item level, not the invoice-total level: totals hide offsetting errors — one line wrong high and another wrong low net to a small variance that clears a gate it should fail. Aim for tight tolerances (industry playbooks suggest around 1 percent for high-volume meters and 0.1 percent for billing-critical events), and log a root cause for every delta before go-live.
4. Run one full parallel billing cycle. Both systems live, both producing invoices, only one sending them. Keep the old platform authoritative while the new system's shadow invoices go through the same review your real invoices get. Published guidance treats billing as revenue-critical and puts parallel runs at 8 to 16 weeks rather than the 2 to 4 weeks non-critical systems get; vendor timelines that promise a two-week migration are describing the integration, not the financial sign-off. Orb's own migration guidance recommends running a new-customers-on-the-new-system approach for 60 to 90 days before moving the installed base.
5. Cut over customers in waves, not all at once. The safest pattern is new customers on the new platform while existing contracts ride to renewal on the old one, then migrate cohorts at natural boundaries (contract renewal, month-end, never mid-cycle). Each wave gets its own reconciliation before the next begins. A big-bang cutover concentrates every rating difference, every straggler event, and every proration edge case into a single close — the one your auditor will sample first.
6. Keep the old system read-only, not deleted. You need the old rating rules, the old invoices, and the old event log for at least a full audit cycle. Tax authorities and auditors ask about the migration year specifically because they expect the seam; "we decommissioned it" turns a reconcilable variance into an unexplainable one.
How the cutover month looks in your ledger
The bookkeeping connection is straightforward once you separate the platforms with clearing accounts instead of letting both post straight to revenue. Accrue earned-but-unbilled usage each month-end under whichever platform metered it, then relieve the accrual when that platform's invoice issues — and book any rating difference between the two systems as an explicit true-up, not a plug.
Suppose June usage was metered on the old platform and you accrued $4,820 of unbilled revenue at June 30. The replacement platform issues the actual invoice in July for $4,805.50 — a $14.50 rating difference from rounding and a late event landing in different periods. In a plain-text ledger that looks like this:
2026-01-01 open Income:SaaS:Usage
2026-01-01 open Assets:Unbilled-Receivable
2026-01-01 open Assets:Accounts-Receivable
2026-01-01 open Assets:Checking
2026-06-30 * "Accrue June unbilled metered usage (old platform)"
Assets:Unbilled-Receivable 4820.00 USD
Income:SaaS:Usage
2026-07-02 * "Invoice 1042 issued from new platform for June usage"
Assets:Accounts-Receivable 4805.50 USD
Assets:Unbilled-Receivable -4820.00 USD
Income:SaaS:UsageThe second transaction auto-balances $14.50 against Income:SaaS:Usage, reducing recognized revenue by exactly the rating difference — visible, dated, and explainable instead of buried. Scale this pattern with per-platform subaccounts (for example, Assets:Unbilled-Receivable:Stripe-Billing and Assets:Unbilled-Receivable:Orb) so the migration-month trial balance shows which system every dollar came from. When finance can point at the subaccount balances and the true-up entries, the auditor's hardest question — "prove these two invoice populations add up to your revenue" — already has its answer. If you track usage metrics alongside the ledger, the Beancount documentation on running queries against your books shows how to pull unbilled balances by subaccount at close.
Metronome, Orb, or just Stripe Billing?
With the reconciliation plan in hand, the platform choice comes down to where your complexity actually lives:
- Stay on Stripe Billing if your usage model is straightforward metered subscriptions, your payments already run on Stripe, and your team can manage tax (via the Stripe Tax add-on) and revenue recognition (via its add-on or your ERP) as separate pieces. Post-acquisition, Metronome's real-time metering is increasingly available inside the Stripe stack, which narrows the gap that used to force a switch. Cost is roughly 0.7 percent of billing volume on top of standard processing fees.
- Move to Orb if your pricing needs SQL-defined metrics over raw event data — multi-dimensional usage, complex rating logic, frequent price-version changes with mass migration of customers between versions. Orb brings metering, invoicing, and revenue reporting (recognized, deferred, and unbilled views) into one system, and its migration tooling imports customers and subscriptions while leaving Stripe customer records and payment methods intact. Pricing is custom and sales-led, so budget for a platform fee on top of billings-based charges.
- Move to Metronome if you are Stripe-native and need real-time streaming ingestion, centralized commits and prepaid-credit models, or cloud-marketplace billing (AWS, Azure, GCP). The free Starter tier makes it accessible early, with custom pricing as you scale. The trade-off is coupling: it is the right answer if Stripe is your long-term payments home, and the wrong one if you plan to diversify processors.
Whichever you pick, confirm four things before signing: how late events and backfills land across period boundaries, who owns tax calculation and remittance, what the shadow-invoicing story is for your parallel run, and what happens to your historical rating rules if you ever migrate away. The answers to those four questions are your reconciliation plan.
The mistakes that turn a switch into a restatement
- Reconciling totals instead of lines. Net variance hides offsetting errors. Every material line needs its own tie-out between old invoice, new invoice, and ledger.
- Migrating mid-cycle. A customer moved on the 15th gets two partial invoices computed under two proration rules. Migrate at cycle boundaries.
- Letting both systems send invoices. During parallel runs exactly one system is authoritative for sending; the other produces shadows. Double-sent invoices mean double-booked revenue and a wave of refunds.
- Skipping the historical replay. If the new system cannot reproduce a month you already billed correctly, it will not bill next month correctly either. The replay is the cheapest test you will ever run.
- Accruing unbilled revenue without a collectibility check. The constraint on variable consideration exists because not every metered dollar is collectible — usage above a customer's credit threshold, disputed overages, and draft invoices need a policy before they become revenue.
- Decommissioning the old platform before the audit. Keep it readable for a full cycle. Storage is cheap; an unexplainable migration year is expensive.
Your last useful step is a small one: before you sign the new contract, export one complete billing period — raw events, rated lines, invoices, and the ledger postings — from the old system into a format you control. That export is the answer key every later reconciliation grades against. Migrations succeed when finance can prove, line by line, that the new system's invoices plus the true-up entries equal the revenue the old system would have produced. Do the replay, run the parallel cycle, keep the receipts — and the platform switch stays an engineering project instead of becoming an accounting one.
