Prove a New Billing System With a Parallel Run

A billing migration usually gets signed off on a demo. The vendor walks through a few customer invoices that look right, and a cutover date goes on the calendar. The first real month then turns up the cases nobody demoed, like the customer who changed plans mid-cycle or the contract with a negotiated rate.

A parallel run finds those before your customers do. The new system calculates invoices from the same inputs as the old one without sending them, and you compare the two.

Run it in shadow first

Lago's migration guide describes the sequence well: run the new system in shadow mode, drafting invoices without sending them, then widen it in stages before cutover. The sources of mismatch it lists are proration, tax timing, time zones and rounding.

Run the shadow for at least one full billing cycle. Every kind of charge and adjustment needs to appear at least once. If some customers bill quarterly or annually, make sure the run covers a period where their invoices fall, or you'll meet them for the first time live.

Compare line by line

Totals hide offsetting errors. A missed discount and a duplicated fee on the same invoice can add up to the right amount, and the customer will still call about it.

Match invoices across the two systems by customer and period, then compare them line by line: product, quantity, rate, discount, tax.

Let an agent sort the differences

The first comparison can produce a long list of mismatched lines. Most of them share a handful of causes, and sorting them by hand is slow.

Hand an agent both sets of invoices and the pricing rules, and it can group the mismatched lines by likely cause, with a short explanation and a few example invoices for each group. A group might read: "About 300 lines differ by one cent; both systems round per line, the old one rounds every half cent up and the new one rounds half cents to the nearest even cent."

Finance reviews groups. Most differences will be bugs in the new configuration, though a few can turn out to be old-system behaviour that customers were billed under, and someone has to decide whether to keep it.

Agree on what "good enough" means first

Before the run starts, finance and the project team should write down the cutover criteria: which differences are acceptable, such as rounding within a cent, and who signs off on what evidence. Billing vendor Aria Systems puts it plainly in its migration planning guide: "Cutover only happens when results are within an agreed tolerance and the team has full confidence in the new environment."

Without written criteria, the parallel run ends in an argument about whether 97% matching is fine.

Avoid a quarter-end cutover

Don't cut over in the last week of a quarter. The close is busy, and any billing problem lands in the quarter's reported revenue. If your parallel run ends in late September, finish it, fix what it found, and cut over in October with a clean cycle behind you.

Keep the old system able to produce invoices for at least one more cycle after cutover. If the first live month turns up something the parallel run missed, you'll want a way to compare.