Match, Merge and Survivorship Rules in MDG Consolidation Processing
Explains how MDG consolidation processing uses match rules, merge/group decisions, and survivorship (best record) logic to turn multiple candidate source records into a single trusted golden record, and how consultants configure and validate this flow.
Explanation
Once source records for an object such as business partner, customer, supplier, or material have been loaded into the consolidation staging area, the core value-adding step is turning many overlapping, inconsistent records into one governed golden record per real-world entity. This happens through three conceptually distinct activities: matching, grouping/merging, and survivorship (best record calculation). Understanding how these fit together, and where they can go wrong, is essential for any consultant who configures or supports an MDG consolidation initiative. Matching is the process of comparing records pairwise or in blocks to decide whether two records likely represent the same real-world object, for example the same legal entity appearing as a customer in one ERP and a vendor in another, or the same material described slightly differently across plants. Match rules combine field comparisons (exact match, fuzzy match, phonetic match, normalized address comparison) with weights and thresholds. A match rule set typically blocks records first, for example by postal code or by a normalized name fragment, to avoid comparing every record against every other record, which does not scale. Consultants tune blocking keys and comparison algorithms based on data quality realities: free-text address fields, inconsistent legal form abbreviations, and duplicate tax IDs are common sources of both false positives and false negatives. Grouping takes the pairwise or blocked match results and forms clusters of records believed to represent the same entity. This is where transitive matches must be handled carefully: if record A matches B and B matches C, the tool must decide whether A, B and C form one group or whether the A-B and B-C matches were coincidental. Poorly tuned thresholds create either mega-clusters that incorrectly merge unrelated entities or fragmented clusters that fail to consolidate genuine duplicates. Survivorship, sometimes called best record calculation, decides which field values win when multiple source records in a group disagree. Survivorship rules are typically defined per attribute and can be based on source system priority (for example, values from an ERP system of record outrank values from a marketing or CRM system), recency (most recently changed value wins), completeness (a populated value wins over blank), or explicit business rules for regulated fields such as tax classification or compliance flags. A single survivorship strategy rarely fits every attribute, so the rule set is usually attribute-specific and documented as part of the governance data model design agreed with data stewards. The runtime flow generally is: source extraction/loading into the consolidation workspace, standardization and cleansing of key fields, match rule execution to identify candidate duplicates, steward review of ambiguous matches through a governance or exception handling step, automatic or steward-confirmed grouping, survivorship calculation to produce the golden record, and finally promotion of that golden record into the active, governed master data area where change request and workflow processes take over for ongoing maintenance. In S/4HANA and cloud-oriented deployments, this consolidation exercise is most often a project-based, time-boxed initial load activity feeding into ongoing central governance, rather than a permanently running background process, and the vendor tooling used for large-scale fuzzy matching may sit alongside or be integrated with core MDG rather than being a single monolithic engine; consultants should confirm the specific tool combination in use for a given landscape rather than assuming one universal architecture. Troubleshooting consolidation issues typically starts with understanding whether a bad outcome is a matching problem (wrong records grouped or missed), a survivorship problem (right group, wrong field values chosen), or a downstream mapping problem (correct golden record, but replication or key mapping errors). Isolating the layer at fault before changing rules prevents wasted rework and repeated cycles of full reprocessing on large data volumes.
Real project scenario
A consumer goods company merging two regional ERP instances into one S/4HANA system needed to consolidate roughly 40,000 customer master records before go-live. Initial match rules based only on exact tax ID comparison missed thousands of duplicates because one legacy system stored tax IDs with punctuation and leading zeros while the other did not. The project team added a normalization step before matching and introduced a secondary fuzzy match on name plus postal code as a fallback blocking key. Survivorship rules were then defined per field: tax and compliance fields always sourced from the finance-owned legacy system, contact and address fields took the most recently updated value, and sales-relevant fields required steward confirmation because both systems were considered equally authoritative for that domain. This staged approach reduced steward review volume by focusing manual effort only on genuinely ambiguous or business-sensitive fields.
Common mistakes
ā¢ Using only exact-match rules on fields such as tax ID or registration number without normalizing formatting first, causing missed duplicates. ā¢ Applying one blanket survivorship rule (e.g., always take the newest record) across all fields, ignoring that regulated or compliance fields need authoritative-source rules instead of recency rules. ā¢ Setting match thresholds too loosely, creating oversized clusters that incorrectly merge distinct legal entities or materials. ā¢ Treating consolidation as a purely technical exercise and not involving data stewards early to validate ambiguous match decisions before mass promotion. ā¢ Promoting golden records to the active governed area without validating downstream key mapping, causing broken links to transactional data after go-live.
Best practices
ā¢ Normalize and standardize key comparison fields (IDs, addresses, names) before running match rules, rather than relying on raw source data. ā¢ Design survivorship rules per attribute group in collaboration with data owners, distinguishing regulated fields from operational fields. ā¢ Start with conservative match thresholds and progressively tune based on steward feedback to balance false positives against false negatives. ā¢ Log and retain match/merge decisions and the source lineage of survived field values to support audit and rollback needs. ā¢ Validate downstream key mapping and replication before mass-promoting golden records into the active governed data area. ā¢ Run consolidation in staged batches for large volumes rather than a single full-population pass, to make defect isolation and reprocessing manageable.
Interview angle
Interviewers assess whether a candidate can explain the difference between matching, grouping, and survivorship as distinct configurable steps, rather than treating consolidation as a black box, and whether they understand why survivorship rules must be attribute-specific rather than uniform. Strong candidates can also describe how they diagnosed whether a consolidation defect was a match rule issue versus a survivorship issue versus a downstream replication issue, and can discuss trade-offs between match rule strictness and steward review workload.