Designing customer identity across CRM and ERP
A fictional case about identity: what an account represents, how commercial accounts map to legal entities and ERP customer numbers, and what survives a merge.
Independently created. Contains no employer or client implementation detail, internal names or figures.
01The outcome
Three explicit identities—commercial, legal and transactional—linked by a canonical business identity, with governed rules for matching, merging and retiring.
Prospects, subsidiaries, several ERP customer numbers and duplicates all live under one word: ‘account’.
What does an account represent—and who issues the identity every system can trust?
Separate commercial identity (the CRM account) from legal and transactional identity (party and ERP customer numbers), linked through a canonical party ID issued by one authority.
A global B2B company sells to groups with many legal entities and delivery locations, through several of its own subsidiaries, each with an ERP that numbers customers independently. The CRM keeps prospects and customers in one account list. Duplicates appear, merges break history, and nobody can say whether an ‘account’ is a group, a legal entity or a ship-to address.
02The reality · current state
What the platform looks like today.
- ‘Account’ means a group for some teams, a legal entity for others and an address for a few
- The same legal entity has several ERP customer numbers
- Duplicates are created because matching happens after creation
- Merges in the CRM leave ERP references and opportunities pointing nowhere
- Integrations map IDs one-to-one and break when the relationship is one-to-many
- Group-level performance is invisible because hierarchies are incomplete
03System responsibilities
Every platform, one job—and a boundary.
What each platform owns in this design, and what it deliberately does not. These are the responsibilities for this context, not universal rules.
CRM
Commercial identity- Commercial account and relationship context
- Selling hierarchy (group → buying units)
- Duplicate checks before creation
- Merge requests for commercial records
- Legal entity data after validation
- ERP customer numbering
Integration layer
Identity correlation- Cross-reference of CRM, party and ERP IDs
- Correlation IDs on every message
- Propagation of merges and retirements
- Deciding whether two records are the same entity
ERPs
Legal and transactional identity- Legal entity (party) validation
- Customer numbers per company
- Billing, payment and tax attributes
- Prospects
- The selling hierarchy
Data platform
The group-level view- Performance rolled up through the hierarchy
- Duplicate-candidate analytics
- Identity decisions or merges
04Key dimension · Identity & hierarchy
Four levels, three identities
Integration becomes fragile when identity is treated as “just map the ID”. Each level has its own key, its own authority and its own cardinality.
- Commercial accountThe relationship we sell to
- Key
- CRM account ID
- Authority
- CRM
- Cardinality
- One per commercial relationship
- Legal entityThe registered organization that signs and pays
- Key
- Canonical party ID
- Authority
- Master data in the ERP
- Cardinality
- One or more per commercial account
- ERP customerThat legal entity as a customer of one of our companies
- Key
- ERP customer number
- Authority
- Each ERP
- Cardinality
- One per legal entity and company
- LocationWhere goods are delivered or invoices are sent
- Key
- Address ID
- Authority
- ERP, after validation
- Cardinality
- Many per ERP customer
- Match before create
Duplicate candidates are checked on natural keys—registration number, tax ID, normalized name and country—before any record exists.
- One issuer per identifier
The canonical party ID has exactly one issuer. Every other system stores it as a reference and never generates it.
- Merge keeps history
The surviving record keeps its ID; opportunities, activities and cross-references move to it; the retired ID stays as an alias.
- Retire, don’t delete
Retired identities stay resolvable, so historical orders, invoices and reports still point somewhere.
- Correlate every message
Each cross-system request carries a correlation ID and the canonical ID, so outcomes are matched without guessing.
- Hierarchy is not identity
Parent–child links describe how we sell and report. They never merge two legal entities.
Most integration defects in this area are identity defects in disguise.
06Candidate architectures
Credible options, judged against these premises.
One account equals one ERP customer
Single-entity customers and one ERP
Cost: Breaks as soon as a customer buys from two of our companiesThe CRM issues the canonical ID
The CRM is the first and only system to see every party
Cost: Prospects and legal entities mixed; the ERP must trust unvalidated dataCommercial account in the CRM, canonical party ID from master data, cross-reference in integration
Groups, several legal entities, several ERPs
Cost: Needs a cross-reference and a governed merge process07The second layer
Questions that change the architecture.
Meaning
- What does an account represent—legal entity, relationship, location or group?
- When should several ERP customers map to one account—and when not?
- Is a prospect the same record as the customer it becomes?
Authority
- Who issues the canonical identity?
- Who may merge two accounts—and who decides they are the same?
- How are duplicate candidates detected, and when?
History
- What survives a merge?
- What happens to historical opportunities and orders?
- How is a retired identity still resolved?
08Decisions & outputs
What the work produces.
- 01Identity model
- 02Hierarchy model
- 03Duplicate rules & natural keys
- 04Merge & retire policy
- 05Cross-system key register
- 06Identity quality measures