The riskiest way to leave a billing spreadsheet is to pick a go-live date and switch everything on it. If the new system is even slightly wrong on one contract shape, you find out from an angry customer instead of from a reconciliation report.
Phase 0 — decide scope honestly
Before migration, list what the spreadsheet actually models:
- Flat subscriptions vs usage vs seats vs minimum commitments
- One-time fees and deferred instalments
- Payment-gated starts
- Credit notes and upgrade proration you already do manually
If a shape is not in Sonic yet, name it — parallel run will surface it. Do not hide it in "we'll fix later."
Phase 1 — catalog as source of truth
Customers, products, and list prices need to exist and be correct. A contract on a blank catalog either rejects or creates duplicates you will merge painfully later.
Sonic can materialise customer and products at contract approve when still unlinked, linking existing name matches instead of duplicating. That accelerates ingest but does not remove catalog discipline — someone still validates IDs and pricing.
For freight migration, stand up shippers and carriers before contracts — bill-to and hauler are not the customer catalog.
Phase 2 — cohort contract import
Import contracts in cohorts, not all at once.
Good first cohort: flat monthly fee, single phase, no usage, immediate activation.
Save for later: deferred tranches, seat snapshots with confirmation days, payment gates, volume overage companions, multi-currency quirks.
Each PDF becomes a reviewable structured result before schedule activation. Use the first cohort to calibrate trust in extraction — fix org parsing context when the same ambiguity repeats.
Phase 3 — parallel run one full cycle
Let the spreadsheet keep issuing real invoices. Let Sonic compute what it would bill:
| Compare | Why |
|---|---|
| Line totals per product | Catches proration and phase boundaries |
| Tax lines | Catches rate config, not just subtotal |
| Seat/usage quantities | Catches template mapping |
| Invoice dates | Catches billing day and gate materialisation |
Disagreements are not failures. They are contract terms the spreadsheet was already approximating, or Sonic config you still need to tune.
Do not send Sonic invoices to customers during parallel run unless you have explicit dual-run approval.
Phase 4 — cut over cohort by cohort
When a cohort agrees for a full cycle:
- Send from Sonic for that cohort's next period.
- Freeze the spreadsheet tab for that cohort (read-only archive).
- Move Watchtower/dunning to sent Sonic invoices only.
- Match cash against Sonic invoice numbers in bank rec.
The spreadsheet shrinks until the last renewal moves. No funeral required.
After cutover — keep the chain connected
- Enable recognition only when billed numbers are trusted.
- Connect Stripe/Razorpay before scaling self-serve pay links.
- Train operators on immutability after send — corrections are credit notes, not Excel overrides.
Watch out for
- Big-bang go-live is a bet against edge cases you have not met yet.
- Skipping review on cohort 2+ reintroduces silent parse errors.
- Usage/seat templates need Process discipline before production uploads — bad mapping × monthly volume hurts.
- Sequence numbers — if you backfill historical invoice numbers, sync sequence floors or auto-number repeats.
- Freight parallel run must include shipper match and rate index gaps, not just subtotals.