Why Consolidation Exists in SAP MDG: Business Case and Core Concepts
Understand the business problem consolidation solves in MDG, the difference between consolidation and central governance, and the core building blocks: source systems, match rules, and best record.
Explanation
Most organizations run master data creation in multiple systems over many years: different ERP instances after mergers and acquisitions, regional systems, legacy CRM, or manually maintained spreadsheets that eventually got loaded into SAP. The result is that the same customer, vendor, or material often exists many times with slightly different names, addresses, tax IDs, or spellings. This duplication causes wrong reporting, duplicate payments, failed compliance checks (for example sanctioned party screening missing a hit because the vendor is spelled differently), and poor customer experience when the same account is treated as several unrelated parties. SAP MDG Consolidation is the discipline and toolset for solving this specific problem: taking data from one or more source systems, loading it into a staging area, identifying which records actually represent the same real-world business partner or material, and producing a single 'best record' that becomes the trusted master. Consolidation is distinct from central governance, even though both live under the MDG umbrella. Central governance is the ongoing, transactional process of creating and changing master data going forward, using change requests and workflow, so that new duplicates are prevented at the point of creation. Consolidation, by contrast, is typically a project-based or periodic activity that cleans up the accumulated backlog of already-existing duplicate data, or onboards a newly acquired company's data into a harmonized structure. In practice, organizations often run a consolidation project first to clean the existing landscape, and then activate central governance to keep it clean going forward. Some cloud-ready deployments position consolidation as a data quality and matching capability that can also run on a recurring basis to catch drift, not only as a one-time cleanup. The core building blocks a beginner needs to know are: source system definitions (where the raw data physically comes from and how it is loaded into the consolidation staging tables), match rules (the logic that decides two records are likely duplicates, based on fields like name, address, tax number, or bank details, often using fuzzy or phonetic matching rather than exact string comparison because real-world data has typos and formatting differences), match groups (the cluster of records that the system believes represent the same entity), and the best record (the single, most complete and trustworthy version of the data that survives from a match group, assembled either automatically by survivorship rules or manually by a data steward reviewing the group). A critical beginner-level point is that consolidation does not silently delete or overwrite source records without human oversight in most well-run implementations. Instead, it presents proposed matches and a proposed best record to a steward, who confirms, adjusts, or rejects the grouping before anything is finalized and distributed. This human-in-the-loop step exists because false positives (treating two genuinely different companies as duplicates) can be as damaging as missed duplicates, especially for subsidiaries of large corporate groups that legitimately share addresses but are separate legal entities. From a platform perspective, exact configuration steps, specific transaction codes, and cloud versus on-premise capability differences evolve across SAP MDG releases, so this lesson intentionally focuses on durable concepts rather than a specific menu path, which should always be verified against the current system and release documentation before a project starts.
Real project scenario
A manufacturing group acquired a regional distributor and needed to merge the distributor's customer master, held in a separate legacy ERP, into the parent company's S/4HANA system. Before consolidation work began, finance reported that several large customers appeared to be new accounts with zero payment history, when in fact they were long-standing customers already known under a slightly different legal name in the existing system. The MDG team ran a consolidation exercise on the incoming customer extract, which surfaced roughly 15% of the incoming records as likely duplicates of existing master records, allowing the credit and finance teams to correctly link payment history instead of creating fragmented, risk-blind new accounts.
Common mistakes
• Treating consolidation as a fully automatic process and skipping steward review, leading to incorrect merges of genuinely distinct legal entities. • Confusing consolidation (cleanup of existing duplicates) with central governance (prevention of new duplicates), and assuming one replaces the need for the other. • Assuming exact string matching is sufficient and not accounting for typos, abbreviations, or transliteration differences in company names and addresses. • Starting a consolidation project without first agreeing on which source system's data should win when conflicts occur in the best record. • Ignoring the downstream impact on transactional documents (open orders, invoices) that still reference the old, soon-to-be-merged record IDs.
Best practices
• Run a data profiling and quality assessment before configuring match rules so field completeness and format issues are known upfront. • Define clear survivorship rules with business stakeholders before processing begins, not during exception handling. • Always route ambiguous or high-value matches to a human steward rather than auto-merging. • Document source system precedence for conflicting field values so decisions are auditable later. • Pilot consolidation on a representative but limited subset of data before running it against the full data population.
Interview angle
Interviewers commonly ask candidates to explain the difference between MDG consolidation and central governance, and to describe what a 'best record' is and why manual steward review typically remains part of the process even when automated matching is used. Being able to give a concrete example of a false-positive risk (two legitimate but similarly named entities) shows practical understanding beyond textbook definitions.