Implementation
Mapping Customer IDs During a Billing Migration
By the Orvlin team · · 1 min read
Billing migration customer id mapping: what to decide
Two workspaces share an email domain but belong to different legal payers. A migration that groups them by domain can move charges onto the wrong invoice. Identity mapping deserves its own reconciliation before any price calculation.
Choose stable keys and document one-to-many relationships. Preserve old identifiers for historical lookup while defining which system owns the canonical account. Quarantine unmapped usage rather than guessing a payer from partial information.
How this works in practice
A parent organization pays for three workspaces, while a fourth has a separate agreement. The mapping table should express that fourth exception explicitly rather than letting an automatic domain match absorb it.
What can go wrong
Emails change, users leave and companies merge. Those events should not silently rewrite the payer of historical activity. Identity lifecycle and billing history have different requirements.
Questions for your team
- Inventory product and billing identifiers.
- Model payer and workspace relationships.
- Review ambiguous and missing mappings.
- Reconcile mapped usage before invoice generation.
Frequently asked questions
- Can email be the migration key?
- It may help locate records, but it is fragile as a permanent key. Use stable IDs and an explicit, reviewed mapping.