Understanding Consolidation in MDG: Why Duplicate and Fragmented Data Exists
An introduction to why master data consolidation is needed in MDG, what business and technical problems it solves, and how it differs from ongoing central governance.
Explanation
Every organization that has grown through mergers, regional rollouts, or years of decentralized data entry ends up with the same problem: the same customer, vendor, or material exists multiple times under slightly different names, addresses, or identifiers. This is not a hypothetical risk - it is close to universal in any company with more than a handful of years of operational history or more than one legacy system feeding master data. SAP Master Data Governance addresses two related but distinct disciplines. The first is central governance, where new master data is created or changed through a controlled change request process going forward. The second is consolidation, which looks backward: it takes existing, already-created records - often imported from multiple source systems - and works out which of them actually represent the same real-world business partner, customer, vendor, or material, so that duplicates can be identified, reviewed, and either merged or flagged. Why does this matter practically? Duplicate customer records mean a company cannot see its true total exposure or spend with a given business partner because activity is split across several IDs. Duplicate vendor records create compliance risk, because payment or Know Your Customer checks run against one ID while a shared bank account is registered against another. Duplicate material records inflate the material master, drive incorrect stock reporting, and cause procurement to buy the same item under two different numbers from two different plants. Analytics, reporting, and any downstream master data consumption (finance consolidation, spend analytics, customer 360 initiatives) suffer directly from an unresolved duplicate landscape. Consolidation is therefore usually a foundational, one-time (or periodic) exercise that a company runs before, or in parallel with, rolling out central governance for day-to-day maintenance. Without it, an organization risks governing new records well while carrying forward decades of unresolved duplicates. At a conceptual level, MDG consolidation processes involve loading candidate records (often from multiple source systems, sometimes via files or interfaces) into a staging area, running matching algorithms that compare key attributes (name, address, tax number, identifiers, banking details, and so on) to compute a similarity score between record pairs, and then presenting groups of matched records to a data steward. The steward reviews suggested matches, decides which records genuinely represent the same real-world entity, and determines what the resulting 'best record' should look like by selecting or overriding field values from the source records (survivorship rules can suggest defaults, such as preferring the most recently updated record or the one from a trusted source system, but a human decision point is typically retained for anything above a certain risk threshold). It's important for beginners to understand that consolidation in MDG is not simply a bulk delete-duplicates utility. It is a governed, auditable process: every match decision, every merge, and every resulting best record is tracked, because downstream financial and operational processes depend on which records were merged into which surviving ID, and because incorrect merges (treating two genuinely distinct entities as one) can cause serious business and compliance problems - for example, wrongly merging two vendors that happen to share a similar name but are legally separate entities. This is why consolidation projects typically start with a data quality assessment, agree on match rule thresholds and tolerances with business stakeholders, and pilot on a smaller data set before running at full volume. Consolidation also interacts with the governed data model used by central governance: the target record structure, mandatory fields, and validation rules that apply to newly governed data typically also apply to the survivor record produced by consolidation, so that the outcome is not just deduplicated but also compliant with the same governance standards used going forward. Finally, beginners should understand that consolidation capability and terminology can differ meaningfully between deployment options. On-premise and private cloud editions of MDG have historically offered dedicated consolidation and mass processing capabilities integrated with the governance data model. Public cloud and more recent product packaging may expose these capabilities differently, sometimes bundled with broader data quality management tooling, and organizations should confirm current capabilities for their specific product edition and license rather than assuming full functional parity across deployment options.
Real project scenario
A retail company merged three regional ERP instances into a single S/4HANA system. Before go-live, the migration and data governance team was tasked with consolidating roughly 400,000 customer records that had been extracted from the three legacy systems, because early sampling showed the same large retail chain existing under at least four different customer numbers with inconsistent addresses and tax IDs. The project team ran an MDG-based consolidation exercise prior to central governance cutover: staging the extracted records, applying matching rules based on tax number, name similarity, and postal code, and routing high-confidence matches to data stewards by business unit for review before the final customer master was loaded into the production governance environment.
Common mistakes
• Treating consolidation as a fully automated bulk-merge process instead of a governed, human-reviewed workflow, leading to incorrect merges of distinct legal entities • Running consolidation directly against production governance data without first piloting match rules on a sample to validate false positive and false negative rates • Ignoring downstream system dependencies (open orders, open invoices, contracts) tied to the records being merged, resulting in broken references after merge • Assuming all MDG deployment options offer identical consolidation tooling without checking capabilities for the specific product edition in use • Underestimating the effort needed to agree survivorship rules and field-level ownership with business stakeholders before the technical match run begins
Best practices
• Run a data quality assessment and sample-based pilot before committing to full-volume consolidation • Agree match rule thresholds and survivorship logic with business data owners, not just IT, before execution • Maintain full audit trail of match decisions and resulting best records for compliance and rollback traceability • Coordinate with functional teams to understand downstream references (open transactions) before finalizing merges • Confirm current consolidation capabilities and terminology for the specific MDG deployment option being used
Interview angle
Interviewers commonly ask candidates to explain the difference between central governance and consolidation in MDG, and to describe what happens when two records are incorrectly matched as duplicates. A strong answer distinguishes the forward-looking governance of new/changed data from the backward-looking cleanup of existing duplicate data, and explains that consolidation decisions are staged and reviewed by a steward rather than applied automatically, precisely to control the business risk of wrongful merges.