Executing Match, Merge, and Best-Record Survivorship in Consolidation
Learn how consolidation results in candidate match groups are reviewed, merged, and resolved into a single best record, and how survivorship rules and manual steward decisions interact with governance workflow.
Explanation
Consolidation initiatives typically follow an initial load or periodic batch run where records from one or more source systems are scored against each other using matching rules (exact, fuzzy, or key-based comparisons on attributes such as name, address, tax number, or identifiers). The output is a set of match groups, each containing candidate duplicate records with a confidence score. The intermediate-level work in consolidation is not building the matching rules themselves (that is a rules/configuration concern covered elsewhere in this topic) but operationalizing what happens once match groups exist: reviewing them, deciding which records genuinely represent the same business entity, and producing a single surviving record. In practice, a data steward or consolidation specialist works through match groups in a review environment. For each group, the steward confirms or rejects the proposed match. Confirmed matches move into a merge step where the system (or the steward, depending on configuration and deployment) determines which record becomes the 'surviving' record and which become subordinate or are marked for retirement. Survivorship logic can be attribute-level: for example, the surviving record might keep the most recently changed address but retain the oldest created tax identifier if that field is considered more authoritative from a specific source system. This is different from simply picking one whole record as the winner; production-grade consolidation usually blends field-level survivorship rules with steward override capability, because fully automated survivorship on all fields is rarely defensible for financially sensitive master data such as customer or vendor records. Once survivorship is determined, the merge is not typically an instant destructive operation. In most implementations, the merge proposal is routed through the same change request and workflow mechanism used for other governance-relevant changes, so that the merge can be reviewed and approved before it is committed. This matters because a merge is difficult to fully reverse once dependent transactional data (open orders, invoices, contracts) has been reassigned to the surviving record ID. Teams should verify, before approving a merge, what happens to references held by other systems: does merging trigger notification or replication to consuming systems so they can repoint their own references, or does it only update the MDG hub record while consumers still hold the old key until their own reconciliation runs? Deployment differences matter here. In an on-premise or private cloud S/4HANA landing with a mature governance setup, consolidation and merge activities are often integrated tightly with custom or delivered workflow steps, and organizations have more flexibility to build custom survivorship logic and audit trails. In public cloud or more standardized cloud deployments, consolidation capabilities may be more constrained, with fewer customization points and a stronger expectation that organizations adapt their process to delivered capabilities rather than the reverse; teams should not assume identical merge flexibility across these deployment types and should verify current capabilities against their specific release rather than assuming parity with on-premise behavior. Troubleshooting consolidation runs commonly involves three failure patterns: match groups that are too large or noisy (often caused by matching rules that are too permissive, resulting in steward fatigue and rejected merges), match groups that miss genuine duplicates (rules too strict, or key data quality issues such as inconsistent formatting), and merges that complete in the hub but leave orphaned or stale references in connected systems because replication or notification did not fire as expected. Production support therefore needs visibility into merge history: which records were merged, when, by whom, and what the pre-merge state looked like, since business users will periodically ask why a record they knew by one ID no longer exists or now shows different attribute values.
Real project scenario
A retail company migrating two regional ERP systems into one S/4HANA instance ran an initial customer consolidation and generated several thousand match groups. Early runs proposed too many low-confidence matches, overwhelming the steward team. The project reduced noise by tightening the matching criteria for legal name comparisons and adding tax ID as a stronger weighted factor, then re-ran the match step before opening steward review. Approved merges were routed through the standard change request workflow with a dedicated approval step for finance-relevant customers, and the team confirmed with the downstream billing system how repointed customer references would be communicated before allowing mass merges into production.
Common mistakes
ā¢ Treating merge as a one-step destructive action instead of a reviewable, workflow-governed proposal ā¢ Allowing fully automated survivorship on financially sensitive fields without any steward review path ā¢ Not validating how downstream or consuming systems will learn about a merged record's new surviving ID ā¢ Running consolidation matching with rules that are too loose or too strict without first testing against a representative data sample ā¢ Assuming merge behavior and customization flexibility is identical across ECC, on-premise S/4HANA, and public cloud deployments ā¢ Failing to retain accessible history of pre-merge record states for audit and business user inquiries
Best practices
ā¢ Route merge proposals through governance workflow with an explicit approval step, especially for financially or legally sensitive master data ā¢ Use field-level survivorship rules combined with steward override rather than picking one whole record as an automatic winner ā¢ Test matching rule tuning against a representative data sample before running consolidation broadly ā¢ Confirm with owners of consuming systems how they will detect and adopt a new surviving record ID after a merge ā¢ Preserve accessible merge history and pre-merge snapshots for audit and support inquiries ā¢ Validate current merge and customization capabilities against the specific deployment and release rather than assuming they match another environment
Interview angle
Interviewers often probe whether a candidate understands that consolidation match groups and merges are governance events, not just technical deduplication. Strong answers distinguish match/scoring configuration from the operational review-merge-approve cycle, explain why full automation of survivorship is risky for sensitive fields, and can describe how they verified or would verify downstream reference updates after a merge, along with awareness that cloud versus on-premise deployments may offer different levels of merge customization.