How do I parallel-run a new rebate system before cutover?
Run both systems on the same inputs for full calculation cycles, compare at the agreement-period level — never at totals, which hide offsetting errors — and define numerically, before you start, what counts as a match. The legacy system stays authoritative for the books until the day you cut over.
Cut over on evidence, not a date: consecutive periods where every variance is either zero or explained and signed off. A parallel run that ends because the calendar said so is a hope, not a validation.
Compare the right thing
The unit of comparison is the agreement-period accrual — each program, each customer, each period — and beneath it, the qualifying base each system computed. Two systems can agree on the quarter’s total while being wrong in opposite directions on ten agreements; totals-level reconciliation certifies coincidences. Line-level comparison is more work on day one and dramatically less work every day after, because each variance arrives already localized.
Define “match” before the first run
Split the calculation into its deterministic and judgment parts, and hold them to different standards:
- Deterministic parts — qualifying base, rate application, proration — must match to the penny. Any difference is a definition or a defect, and both are findable.
- Estimate-driven parts — finishing tiers, growth baselines — may legitimately differ, because the two systems may embody different estimation policies. That difference is not an error to be forced to zero; it is a policy decision to be made once, in writing: which method governs after cutover. The selection logic is on estimating a tiered rebate accrual.
Triage every variance into one of four buckets
- Data — the systems read different inputs (timing cutoffs, late files, entity mappings). Fix the feed, not the calculator.
- Definition — the qualifying base is computed differently (returns, freight, currency). This is the parallel run doing its real job: forcing the base definition to be written down once, unambiguously.
- Policy — estimation method, rounding, proration convention. Decide, document, move on.
- Defect — an actual bug, in either system. Expect some to be in the old one: a parallel run is also an audit of your historical calculation, and it is common to discover the legacy number was quietly wrong. Decide in advance who adjudicates when legacy loses — force-matching a new system to an old error institutionalizes the error.
How long to run
Think in calculation cycles, not weeks. Monthly programs need at least two full accrual cycles plus one settlement. Annual programs can’t wait a year — so run them retrospectively: replay the new system against last year’s closed data and reconcile to the certified results, then run live-forward for a cycle or two. The replay only works if last year’s numbers still exist as they were certified — which is exactly what correction-by-supersession preserves and correction-by-overwrite destroys. Migrating from spreadsheets is the messier variant: the workbook becomes the spec, and part of the run’s value is discovering where the workbook disagreed with itself — the migration path is on spreadsheet rebate reconciliation.
The cutover evidence
- A variance register with every line-level difference from the run — each one closed as data, definition, policy, or defect, with an owner and a date;
- N consecutive clean periods (pick N before you start; two is a common floor) with zero unexplained variance;
- A rollback plan that nobody expects to use and everybody has read;
- Cutover at a period boundary, never mid-period — and the first close after cutover run with the checklist from the audit checklist, because the first post-cutover close is the one your auditors will look at hardest.
The variance register doubles as an audit artifact: it is documentary evidence that the numbers were validated line by line before the system of record changed — the strongest possible answer to “how do you know the new number is right?” The accrual-vs-settlement causes are the same causes your variances will decompose into; knowing them in advance makes the triage fast.