Separate commercial identity from legal customer identity
An account is a commercial relationship; a legal entity is a registered organization; an ERP customer is that entity in one of our companies. Model three linked identities—not one record that means all of them.
Independently created. Contains no employer or client implementation detail, internal names or figures.
01Context
A global B2B company keeps prospects, legal entities, subsidiaries and delivery locations in one CRM account list, while each ERP numbers customers independently. Integrations map one CRM account to one ERP customer, which breaks whenever a group buys through several legal entities or from several of the company’s own subsidiaries.
02Decision drivers
- D01
Prospects exist long before legal validation
- D02
One legal entity can be a customer of several of our companies
- D03
Selling and reporting at group level
- D04
Merges must not orphan history
03Options considered
One record for every meaning
Single-entity customers and one ERP
Cost: Every multi-entity relationship becomes a workaroundThe ERP customer as the CRM account
Transaction-led businesses with little prospecting
Cost: No place for prospects or group relationships; the CRM mirrors ERP structureThree linked identities
Groups, several legal entities, several ERPs
Cost: Needs a cross-reference and governed merge rules04Decision
Model the commercial account (CRM authority), the legal entity with a canonical party ID (master-data authority) and the ERP customer per company (ERP authority) as separate, linked identities. The integration layer owns the cross-reference; no system reconstructs identity from names.
05Consequences
- A commercial account can link to several legal entities, and each legal entity to several ERP customers.
- Duplicate checks run on natural keys before creation, not after.
- A merge keeps the surviving ID, moves history and keeps retired IDs resolvable as aliases.
- Reports roll up by commercial account or by legal entity without contradicting each other.
06Revisit when
An enterprise master-data service issues party identity for every system.
The business consolidates to one ERP and one legal entity per customer.
07Where this decision is applied
Cases that take this decision, and why it matters there.
- Architecture case / 001Designing a CRM–ERP customer lifecycleA premise-led architecture for a fictional global B2B company: from commercial intent to legally valid, operationally recoverable customer.
- Systems case / 05Designing customer identity across CRM and ERPSeparating commercial, legal and transactional identity—and governing how they map, merge and retire across CRM and ERP.
- Data case / 02Turning ERP transactions and targets into commercial intelligenceConforming orders, invoices, targets and accounts at a declared grain in the data platform—so one metric definition serves every team, and its result lands in the CRM as a governed signal.
- Automation case / 04Automating inbound lead validation and routingThe execution lens on inbound leads: a routing pipeline where each check has a deterministic outcome and a declared “when unsure” path, safe to re-run, with failed assignment visible.
- AI case / 05Using AI to assist data quality without giving it master-data authorityAn agent suggests duplicate candidates, normalized names and missing classifications—with evidence—into a data steward’s queue. It never merges, renames or reclassifies a record itself.
- Operating-model case / 04Designing customer ownership in a multi-subsidiary organizationOne customer relationship across several legal entities, subsidiaries and sales teams: who owns the relationship, each local transaction and the global account data—and who resolves the conflicts.