Migrating to a new billing system is one of the highest-stakes projects a finance team can undertake. Get it wrong, and you’re sending incorrect invoices to customers, misrecognizing revenue, or scrambling to explain AR discrepancies to auditors.
A parallel run—where you operate both the legacy and new billing systems simultaneously, processing the same transactions and comparing outputs—is the standard method for validating accuracy before cutover. This guide walks through when to use a parallel run, what prerequisites you need in place, how to execute the process step by step, and how to define exit criteria that get you to go-live with confidence.
What Is a Billing System Parallel Run
What is a billing system parallel run and why do finance teams use it during system migrations?
A billing system parallel run is a transition method where you run both your old (legacy) billing system and your new billing system side-by-side at the same time, feeding them the same live or historical data to compare their outputs. The legacy system remains the “system of record” and actively processes real invoices, while the new system runs in shadow mode to validate accuracy before cutover.
During a parallel run, both systems process identical contracts, usage records, and amendments for the same billing cycles. Finance teams then compare the outputs line by line—invoice totals, tax calculations, revenue schedules, and AR balances—to catch discrepancies before the new system goes live. Real-world data reveals unexpected bugs, rounding differences, or configuration errors that synthetic test environments often miss.
Why Run Two Billing Systems in Parallel Instead of a Hard Cutover
Why do companies choose parallel runs over direct cutovers when migrating billing systems?
A hard cutover means switching from the old system to the new one overnight. If the new system produces incorrect invoices or revenue schedules, you’ve already sent those errors to customers or posted them to your general ledger. Parallel runs reduce this risk by keeping the legacy system operational while validating the new platform.
- Invoice accuracy validation: Catch calculation errors, proration mistakes, and tax discrepancies before customers receive incorrect bills
- Revenue recognition continuity: Verify that ASC 606/IFRS 15 schedules match between systems
- AR and cash application integrity: Confirm aging reports and payment allocations reconcile correctly
- Rollback safety net: Maintain the ability to revert if critical issues emerge post-cutover
When to Use a Parallel Run in a Billing System Migration
When is a parallel run necessary versus optional for a billing migration?
Not every billing migration requires a parallel run. For simple subscription billing with a handful of SKUs and straightforward pricing, a phased cutover with thorough testing might suffice.
However, parallel runs become essential when you’re dealing with usage-based or consumption pricing, tiered and volume-based rate structures, multi-entity or multi-currency billing, complex proration and mid-cycle change logic, or external audit requirements. The more edge cases your billing model contains, the more valuable a parallel run becomes.
Prerequisites Before Starting a Billing System Parallel Run
What needs to be in place before you can begin a billing system parallel run?
The success of your parallel run depends heavily on preparation. Rushing into parallel processing with incomplete data or misconfigured systems will generate unexplainable variances that derail the entire effort.
Clean and Migrated Customer and Contract Data
Customer master records, active contracts, and billing schedules need to be fully migrated and validated in the new system before parallel testing begins. Any missing or corrupted contract data will produce invoice variances that have nothing to do with system logic.
Mapped Products, Pricing, and Discount Structures
All SKUs, rate cards, tiered pricing, usage rates, and discount rules need to be configured identically in both systems. Even small differences—like rounding rules or discount application order—can cause line-item variances that complicate reconciliation.
Reconciled Opening AR and Deferred Revenue Balances
Starting AR aging and deferred revenue balances need to match between systems. Any variance in opening balances will compound through the parallel period, making it difficult to isolate new calculation errors from inherited discrepancies.
Configured Integrations With CRM, Tax, Payments, and the GL
Both systems require working connections to source systems like Salesforce or HubSpot and downstream systems like Avalara, payment gateways, and QuickBooks, NetSuite, or Sage Intacct.
Defined Reconciliation and Sign-Off Owners
Assign clear ownership for who compares outputs, investigates variances, and approves cycle completion. Typically this involves finance, billing operations, and IT working together with documented responsibilities.
How to Execute a Billing System Parallel Run Step by Step
How do you actually run billing in parallel across two systems?
A parallel run is an iterative process repeated for multiple billing cycles. Each cycle builds confidence—or reveals issues that require fixes before the next cycle.
Step 1. Define Scope and Billing Cycles to Run in Parallel
Decide which customer segments and billing frequencies (monthly, quarterly, annual) to include. Most organizations run for two to three consecutive billing cycles, though complex usage-based models may require more.
Step 2. Freeze Configuration in Both Systems
Lock down product catalogs, pricing rules, and discount structures in both systems. Configuration drift during the parallel period creates variances that are difficult to diagnose.
Step 3. Load Identical Source Data Into Each System
The same contracts, orders, usage records, and amendments need to feed both systems from your CRM, CPQ, or usage metering sources.
Step 4. Generate Invoices in Both Systems for the Same Period
Run the billing engine in each system for the same period. The new system typically generates invoices in draft or test mode to avoid duplicate customer communications.
Step 5. Compare Outputs and Investigate Variances
Reconcile invoice totals, line items, tax calculations, revenue schedules, and AR balances. A comparison table helps track discrepancies:
Step 6. Document Fixes and Re-Run the Cycle
Log root causes—data issues, configuration gaps, timing differences—and implement fixes. Re-run the cycle until variances fall within acceptable thresholds.
Step 7. Secure Finance and Audit Sign-Off
Obtain formal approval from the controller, CFO, or external auditors that reconciliation results meet go-live criteria.
How to Decide Which Billing System Is the System of Record
Which system is the official source of truth during a parallel run?
One system—and only one—owns each record type during the parallel period. Typically, the legacy system remains the system of record for live invoicing, AR, and GL posting until cutover. The new system runs in shadow mode, generating outputs for comparison without affecting customers or financial statements.
Both systems should never simultaneously send invoices to customers or post journal entries to the production GL. Duplicate communications or double-posted entries create customer confusion and accounting errors that are painful to unwind.
How Data Flows Between the Legacy and New Billing System
How does data move between systems during the parallel period?
The key principle: data flows in one direction only, from the system of record to the shadow system, on a known schedule. Never sync bidirectionally or allow the shadow system to write back to source systems.
- Contracts and orders: Flow from CRM/CPQ into both billing systems
- Usage and consumption data: Metered data loads into both systems from the same source
- Payments and cash: Apply in the system of record only during parallel
- GL journal entries: Post from the legacy system only until cutover
How to Reconcile Invoices, Revenue, and AR Across Both Systems
What exactly do you reconcile during a billing parallel run?
Reconciliation spans multiple financial outputs. Each requires its own comparison process.
Invoice-Level Reconciliation
Compare invoice counts, line-item amounts, discounts, prorations, and tax calculations. Investigate any line-item variance, even small ones—they often indicate configuration differences that will compound over time.
Accounts Receivable and Aging Reconciliation
Match total AR, aging buckets (current, 30, 60, 90+ days), and customer-level balances between systems.
Deferred and Recognized Revenue Reconciliation
Verify revenue schedules, recognition timing, and period-end deferred revenue balances align under ASC 606/IFRS 15.
ARR and MRR Reconciliation
Compare ARR/MRR totals by segment, product, and customer. Investor metrics reporting needs to remain consistent post-migration. Ordway’s SaaS Metrics reporting provides visibility into ARR movements across customer segments, making it easier to validate that investor metrics remain consistent through a billing system migration.
Exit Criteria for Ending the Parallel Run and Going Live
How do you know when the parallel run is complete and cutover is safe?
Define exit criteria before the parallel run begins—not after. Without clear thresholds, parallel runs can drag on indefinitely.
Variance Thresholds Met for Consecutive Cycles
Invoice and revenue variances need to fall below agreed thresholds for a defined number of consecutive billing cycles.
Zero Open Critical Defects
All severity-one issues affecting invoice accuracy, revenue recognition, or payment processing need to be resolved before cutover.
Finance, IT, and Audit Sign-Off Secured
Require formal documented approval from all stakeholders that the new system is production-ready.
Rollback and Contingency Plan Documented
A tested plan to revert to the legacy system needs to exist in case post-cutover issues emerge.
Common Risks and Failure Modes of a Billing Parallel Run
What can go wrong during a billing system parallel run?
Awareness of common failure modes helps teams mitigate them before they derail the project.
Incomplete Historical Data Migration
Missing contracts, amendments, or usage history causes unexplainable variances.
Mid-Cycle Contract Changes and Proration Errors
Upgrades, downgrades, and cancellations occurring during the parallel period can produce legitimate differences if not handled identically in both systems.
Usage Data Timing Gaps
For usage-based billing, even small differences in when consumption data is ingested can cause invoice variances.
Duplicate Customer Communications
Accidentally sending invoices or dunning emails from both systems damages customer experience.
Scope Creep Extending the Parallel Period
Without firm exit criteria, organizations can run in parallel indefinitely, increasing cost and delaying the benefits of the new system.
What a Billing System Parallel Run Costs
What are the cost drivers of running two billing systems simultaneously?
Parallel runs aren’t free. The longer they run, the more expensive they become:
- Software licensing: Maintaining subscriptions for both platforms during overlap
- Infrastructure and hosting: Running duplicate compute and storage
- Staff time: Finance, billing ops, and IT hours spent on reconciliation
- Opportunity cost: Delayed realization of new system benefits
Shortening Your Parallel Run with Ordway
Ordway’s billing platform is designed for efficient migrations. Our subscription billing, usage-based billing, and revenue recognition capabilities handle the complex pricing models that typically extend parallel run timelines—tiered usage rates, prepaid credits, mid-cycle prorations, and ASC 606/IFRS 15 revenue schedules.
