Supplier master data is tractable. A few thousand records, one team that owns them, a natural unique key in the VAT number. Get the governance right and it stays governed.
Customer master data is a different problem. The volume is typically 100x higher. Four or five systems each maintain their own copy. No single team owns the whole thing. And GDPR adds a regulatory obligation that supplier data does not carry. The governance patterns that work for suppliers need rethinking before they work for customers.
Why customer data fragments the way it does
Customer records do not start as duplicates. They start as four separate records created by four different teams using four different systems, each with a legitimate reason to create them.
Sales creates the contact in the CRM the day they first reach out. Finance creates a billing record when the first invoice goes out. Marketing adds the email to their automation platform for the onboarding sequence. Support creates a ticket record the first time the customer calls. Each system was built for a specific job. None of them was designed to be the master. So you end up with four records that share a name and not much else.
The unique key problem makes it worse. For suppliers, the VAT or registration number is externally assigned, unique per legal entity, and verifiable. For customers — especially in B2C — there is no natural external identifier. Email addresses change. Phone numbers get recycled. Company names have legal variants and trading names. Building a reliable match key is hard to get right, and the cost of a false merge (two different customers collapsed into one record) is often higher than the cost of a duplicate.
The ownership problem
Customer data has no natural owner because four different teams all have a legitimate claim on different parts of it.
| Team | What they own | Their argument |
|---|---|---|
| Sales | Contact + deal history | They created it in the CRM |
| Finance | Billing entity, payment terms, credit limit | Invoice needs to go somewhere |
| Marketing | Subscription preferences, consent records | GDPR consent is theirs to manage |
| Support | Service tier, SLA, case history | They own the service relationship |
When nobody fully owns the customer record, nobody is accountable for the whole thing. Marketing cleans up their email list. Finance reconciles the billing entity quarterly. Sales updates contacts when someone leaves. None of them knows what the others did, and none of them is wrong. They are each maintaining their part. The fragmentation is not a technical failure. It is an organizational one, and no platform fixes that until ownership is sorted out first.
Settle the data ownership question before the platform question. Buying an MDM tool and importing four fragmented customer lists into it does not solve fragmentation. It centralizes it.
What “correct” means for a customer record
For supplier master data, “correct” is concrete: the legal entity on the invoice, the right payment terms, the verified bank account, the current primary contact. A data steward can evaluate all of those.
For customer data, it depends who you ask. Sales cares about who to call. Finance cares about who to bill and what their credit limit is. Marketing cares about consent status and channel preferences. Support cares about service tier and whether the customer has an open complaint. The “correct” customer record looks different from each seat.
A practical customer master holds the authoritative core: the unique identifier, the verified legal name, the canonical contact details, and the attributes every team agrees on. Extension data — deal history, consent records, service tier — stays in the system that owns it, linked back to the master record. The goal is an anchor record that the CRM and marketing tool reference, not a replacement for either.
The GDPR complication
Customer data, unlike supplier data, is personal data. That creates three governance requirements that have nothing to do with data quality:
Provenance
You need to know where every personal data point came from and what the legal basis for holding it is. “We imported it from a legacy CRM” is not an answer that survives a regulatory audit.
Deletion response
You must respond to subject access and erasure requests within 30 days. That means knowing where every copy of a customer record lives — across the CRM, ERP, marketing tool, and support system — and being able to act on all of them. Not just the master.
Audit trail
You need to show that consent was obtained and that deletion was carried out. A governance log matters as much as the data. Fragmented customer records make all three requirements harder. A deletion request that should take five minutes becomes a two-hour cross-system audit if nobody knows where all the copies live.
Why approval workflows work differently for customers
For supplier data, each new record sits in a queue until a steward approves it. That model breaks at customer volumes. A human cannot approve 500 new customer registrations per day — see the approval workflow post for how that works when it does work.
Two things change. Automated validation does the heavy lifting at creation: format checks, required fields, duplicate key detection. Human review handles the exceptions automation flags, not every new record.
Periodic reconciliation between systems replaces per-record approval. Rather than gating every change, you run regular comparisons between the master and the consuming systems, flag divergence, and let a steward investigate the cases that matter. The steward's job shifts from approving records to maintaining rules and handling escalated exceptions. Same governance skills, different daily rhythm.
A practical starting point
Customer MDM is one of those domains where “start small” is genuine advice rather than hedging.
The right starting point is whichever downstream problem is causing the most visible pain right now. Not the full customer MDM vision — the thing that is actually breaking:
If duplicate billing records are generating double invoices, start with the billing entity and build the governance around that scope.
If marketing emails are bouncing at 15% because addresses are stale, start with the canonical contact record and the process for keeping it current.
If customer service cannot see purchase history because it lives in a separate ERP, start with the linking key that connects both systems to the same master record.
Each of these is tractable as a first scope. Build the governance model around it, get it working, and expand from there. A five-year customer MDM roadmap is how projects die in committee. A six-month pilot that fixes the thing causing pain gets funded for the next phase.
The unique key question, resolved
B2B customers: use the VAT or company registration number, same logic as supplier master data. Externally assigned, unique per legal entity, verifiable.
B2C customers: assign a system-generated GUID at first record creation and treat it as the immutable key. Use email and phone as supporting match fields for deduplication, not as the primary key — both change too frequently. The rule is the same in both cases: the key is assigned once and never changed. The moment you allow a key to be reassigned because someone made a mistake, you have restarted the fragmentation problem with extra steps.
Most customer fragmentation traces back to one of two causes: no key was enforced at creation, or the same customer was allowed to exist as separate records in separate systems that were never reconciled. Fix the key enforcement first. Reconciliation is a project. Governance is a habit.
Common questions
What is the best unique key for customer master data?
For B2B customers, the VAT or company registration number is the strongest choice — externally assigned, unique per legal entity, and publicly verifiable. For B2C customers, there is no single external identifier, so assign a system-generated GUID at first record creation and treat it as the immutable key. Use email address and phone number as supporting match fields, not as primary keys — they change too often. Once a key is assigned, it must never be changed. Allowing key reassignment restarts the fragmentation problem.
What is the difference between customer MDM and a CRM?
A CRM manages the commercial relationship: contacts, deals, activities, pipeline. Customer MDM manages the master record of who the customer actually is: the authoritative legal name, identifiers, addresses, and attributes that downstream systems — including the CRM — should use. The CRM is a consumer of the master data, not the system of record for it. When the CRM is treated as the MDM system, you end up with data that reflects what sales entered, not what is verified and governed.
Should customer MDM and supplier MDM share the same platform?
Yes, if the platform supports multi-domain management. Running separate tools for supplier and customer master data creates the same integration problems at the tool layer that you are trying to solve at the data layer. A multi-domain MDM platform lets you configure different entity structures, validation rules, and workflows for each domain while sharing a single governance infrastructure. The data models are different; the governance patterns are the same.
How does GDPR affect customer master data governance?
GDPR adds three governance requirements on top of normal data quality concerns. First, you need to know where every personal data point came from and what your legal basis for holding it is. Second, you must be able to respond to access and deletion requests within 30 days — which requires knowing where all copies of a customer record live across your systems. Third, you need an audit trail demonstrating that consent and deletion were handled correctly. Fragmented customer data makes all three of these much harder. A customer master that centralizes the record and tracks provenance and change history makes compliance tractable.
One platform for every domain — including customers
Primentra supports multi-domain master data management on SQL Server. Configure separate entity structures, validation rules, and approval workflows for suppliers, customers, and products — all in one place, no consulting engagement required. The 60-day trial includes everything.