Master Data Synchronization: Master Data Management 2026
Customer numbers that read differently in three systems. An item named differently in the shop than in the ERP. A price list that is still from last year in the CRM. Such inconsistencies are not a cosmetic flaw but expensive: poor data quality costs organizations an average of 12.9 million US dollars per year (Gartner, 2021). In Germany, 76 percent of companies struggle with insufficient data quality and data silos, and only 6 percent truly exploit the potential of their data (Bitkom Data Economy, 2025). Master data management (MDM) addresses exactly this: it establishes a leading record for each entity -- the golden record -- and synchronizes it consistently across ERP, shop and CRM. This article shows how a reliable master data synchronization works technically: from the single source of truth through rule-based conflict resolution to a measurable data quality score.
Key takeaways
- Master data management establishes one leading, cleansed record for each entity -- the golden record -- instead of several contradictory versions across ERP, shop and CRM.
- Conflicts between systems are not forced but resolved via documented survivorship rules per attribute; ambiguous cases land in a review queue.
- Data quality becomes visible and deliberately improvable through a measurable score made up of dimensions such as completeness, uniqueness and consistency.
- Data governance defines who may change which data -- without this organizational framework, every technical synchronization remains piecemeal.
- The one-time initial cleansing before go-live decides whether the ongoing comparison delivers reliable results.
What Master Data Is and Why It Drifts Apart
Master data is the long-lived core data of a company: customers, suppliers, products, prices, accounts. Unlike transactional data such as orders or postings, it rarely changes but is read by almost every process. That is exactly why its consistency is so decisive -- and exactly why it regularly drifts apart in grown system landscapes.
The reason is structural. Every system maintains its own view of the same entity: the ERP knows the customer as a debtor with payment terms, the CRM as a contact with contact persons, the shop as an account with a delivery address. When an attribute is changed in one system, it often stays outdated in the others. With every additional interface, the number of possible discrepancies grows -- in Germany, 76 percent of companies already struggle with data silos and insufficient quality (Bitkom Data Economy, 2025). Studies put the share of duplicates in contact databases at 15 to 30 percent (Experian), and in automated integrations it can be considerably higher (Plauti, 2024). KPMG and Forrester also report that only around one third of decision makers really trust the analytics they generate from their data and only 10 percent rate their data quality management as excellent (KPMG, 2018).
Master Data Is the Prerequisite of Every Integration
Single Source of Truth: The Golden Record
The core principle of MDM is the single source of truth: for each entity there is exactly one binding, cleansed record -- the golden record. It is not created by declaring one system the sole master, but by merging the best available values from all sources into one consolidated record. Which system has authority over which attribute is governed by data governance.
In practice, three architecture patterns have established themselves. In the registry style, every system remains the owner of its data, and the MDM hub only holds the links and a cross-reference table. In the consolidating style, data is replicated into a central hub and cleansed there without writing it back. In the central style, the hub is the leading system that actively distributes changes to all connected systems. Which pattern fits depends on the system landscape -- a middleware forms the hub in all cases.
Registry Style
Source systems remain owners, the hub only holds links and cross-references. Low intervention, but no cleansed golden record in the hub.
Consolidating
Data is merged and cleansed centrally without write-back. Ideal for reporting and analysis, less for operational distribution.
Central Distributing
The hub is leading and actively distributes checked changes to ERP, shop and CRM. Highest consistency, highest coordination effort.
The Three Domains: Customers, Products, Prices
A master data synchronization rarely concerns only one type of data. In practice, it is mainly three domains that have to be kept consistent across ERP, shop and CRM -- and each has its own logic.
Customer master data connects debtor, contact and shop account. Here it is about unique identification, duplicate avoidance and the question of which system has authority over address, payment terms or consents. Product master data links item number, name, attributes and media -- often in interplay with a PIM system as the leading source for descriptive data. Price data, finally, is particularly sensitive because tiers, customer groups and currencies come into play and errors here directly cost revenue -- against the backdrop that poor data quality costs an organization an average of 12.9 million US dollars per year (Gartner, 2021).
| Domain | Typical master | Critical attribute |
|---|---|---|
| Customers | ERP (debtor) or CRM | Address, payment terms, consent |
| Products | PIM or ERP | Item number, name, classification |
| Prices | ERP | Tier price, customer group, currency |
| Accounts | ERP or DATEV | Account number, tax key |
Defining the leading system per attribute is not a technical but a business decision. It is made cleanly once and stored in the mapping. A robust data mapping between ERP and shop is the craft foundation of every synchronization and is maintained centrally in the integration layer.
Conflict Resolution: When Two Systems Contradict
The hardest part of any master data synchronization is the moment when two systems report different values for the same attribute. If the address is changed in the CRM and in parallel in the ERP -- which value wins? Without a clear rule, either an endless back-and-forth writing or a silent data loss arises. Both are dangerous.
The solution is so-called survivorship rules: precedence rules defined per attribute that determine which value survives. Four strategies are common: source priority (a certain system takes precedence for this attribute), recency (the most recent timestamp wins), completeness (the more filled value wins) and trust score (the system with the highest data quality for this field wins). It is decisive that these rules are documented traceably and versioned.
customer:
address:
strategy: source_priority
order: [erp, crm, shop]
email:
strategy: recency # most recent timestamp wins
payment_terms:
strategy: source_priority
order: [erp]
consent_marketing:
strategy: source_priority
order: [crm]
conflict_fallback: review_queue # on a tie: overwrite nothingWhen in Doubt, Do Not Overwrite
Making Data Quality Measurable
Data quality is not a gut feeling but measurable. A reliable MDM setup calculates a data quality score from clearly defined dimensions and thus makes visible where the master data stands and where it is improving. This is not only a metric for management but the basis for refining survivorship rules in a targeted way.
Completeness
Are all mandatory fields filled? Missing tax numbers or delivery addresses later block entire processes.
Uniqueness
Does each entity exist exactly once? Depending on the source, duplicates make up 15 to 30 percent of contact data (Experian).
Validity
Do values match their format? An invalid VAT ID or postal code otherwise only surfaces at shipping or invoicing.
Consistency
Do values match across systems? This is exactly the dimension a master data synchronization raises in a targeted way.
Timeliness
How old is the value? Outdated prices or addresses are formally valid but factually wrong.
Referential Integrity
Do foreign keys point to existing records? Orphaned references break evaluations and postings.
In projects we rely on a weighted score per domain, recalculated after every synchronization run. The mere act of making it visible changes behavior: as soon as maintenance becomes measurable, the duplicate share drops noticeably. The economic lever is substantial, since poor data quality is estimated to tie up 15 to 25 percent of revenue (MIT Sloan Management Review). Realistically, after a cleansing, score values in the high nineties can be held (project experience) -- not through one-off actions, but through ongoing validation in the data flow.
A synchronization can only be as good as the data it distributes. Anyone who distributes bad master data faster simply ends up with bad data everywhere faster.
Data Governance: Who May Change What?
Technology alone does not solve a master data problem. Just as important is data governance -- the organizational framework that defines who is responsible for which data, who may change it and according to which rules. This is exactly where many initiatives fail: Bitkom names missing data governance and a lack of data strategy as the main reasons why the potential of data remains unused -- only 6 percent of German companies exploit it today (Bitkom Data Economy, 2025).
- Data ownership: Per domain and ideally per attribute, a responsible role is named -- the data owner decides on rules and authority.
- Maintenance processes: Clear flows on where a record is created and changed prevent the same entity from arising in three places in parallel.
- Validation rules: Format and plausibility checks take effect as early as possible, ideally already at input in the leading system.
- Audit trail: Every change to the golden record is logged with source, timestamp and triggering rule -- traceable and audit-proof.
- GDPR relation: Especially for customer data, consents, deletion periods and rights of access belong in the governance model.
The audit trail is not just a mandatory item but a practical helper: in the event of an unexpected change, it can be traced seamlessly which system delivered which value when and which survivorship rule applied. This makes troubleshooting considerably shorter and is closely interlocked with clean error handling in the interfaces.
Technical Implementation of the Synchronization
On the technical level, the synchronization is realized via APIs and a clearly defined mapping. The MDM hub communicates with each system via its interface -- via REST or GraphQL API for modern systems, via file import or specialized connector for older ERP systems. Changes are ideally distributed event-driven: a webhook or event message reports the change, the hub consolidates and writes back only the changed attribute.
Two properties are non-negotiable here. First, idempotency: if the same change is accidentally distributed twice, no inconsistent state may arise. Second, a delta-based approach: instead of transferring all records on every run, only actual changes are synchronized. This keeps the load low and makes conflicts detectable in the first place. With large data volumes, a periodic full comparison complements the delta procedure to catch creeping discrepancies. The effort pays off, because without active cleansing the duplicate rate in contact data often sits at 15 to 30 percent (Experian).
Start Small, Grow Cleanly
Project Process of an MDM Initiative
An MDM project is in equal parts a data, a technology and an organization project. The proven process follows five phases, with the business coordination needing at least as much time as the technical implementation.
The Five Phases of an MDM Initiative
- 1
Data Audit
Survey of source systems, data models and the current data quality score. Where do duplicates arise, where do values contradict?
- 2
Define Governance
Determination of the data owners, the leading systems per attribute and the survivorship rules together with the departments.
- 3
Initial Cleansing
Deduplication, normalization and validation of the existing data before the ongoing synchronization starts.
- 4
Connection and Mapping
Connection of the systems via APIs or connectors, implementation of the mapping and conflict rules in the middleware.
- 5
Go-Live and Monitoring
Productive operation with ongoing monitoring of the data quality score and a review queue for the cases that cannot be resolved uniquely.
- Data audit: Survey of source systems, data models and the current data quality score. Where do duplicates arise, where do values contradict?
- Define governance: Determination of the data owners, the leading systems per attribute and the survivorship rules together with the departments.
- Initial cleansing: Deduplication, normalization and validation of the existing data before the ongoing synchronization starts.
- Connection and mapping: Connection of the systems via APIs or connectors, implementation of the mapping and conflict rules in the middleware.
- Go-live and monitoring: Productive operation with ongoing monitoring of the data quality score and a review queue for the cases that cannot be resolved uniquely.
The Lever Lies in the Initial Cleansing
The economic benefit is tangible: fewer duplicates mean fewer mis-shipments, correct prices prevent margin losses, and a consistent customer base accelerates sales and service. Against the backdrop of an MDM market estimated at around 21 to 30 billion US dollars for 2026 depending on the source (Mordor Intelligence, 2026; Persistence Market Research, 2026), where cloud-based deployment accounts for the larger share (Fortune Business Insights, 2026), the trend toward a consolidated data foundation is not a short-term effect but a structural development. In over 50 integration projects (project experience), it has shown that the clean master data foundation is usually the underestimated but decisive success factor.