Master Data Governanceadvanced

Advanced Matching, Best Record and Survivorship in MDG Consolidation (Part 7)

Key takeaway

Design MDG consolidation matching and survivorship so duplicate records are identified confidently, merged with explainable source precedence and reviewed when certainty is insufficient.

Explanation

Consolidation combines records from one or more sources to identify duplicates and produce a trusted best record. Matching should use attributes with real discriminatory power—name, address, tax identifiers or other domain fields—while accounting for formatting and data-quality variation.

Thresholds create trade-offs. Aggressive matching reduces duplicates but can merge different real-world entities; conservative matching leaves more steward review. Use representative historical data to tune false positives and false negatives rather than choosing arbitrary scores.

Best-record calculation or survivorship determines which source value wins for each attribute. Source trust can differ by field: one source may own tax data while another owns marketing address. A single global source priority is often too crude.

Steward review should focus on ambiguous clusters, not every record. Preserve merge evidence and source lineage so the consolidated value is explainable.

After consolidation, replication and downstream key mapping must maintain continuity so target systems do not recreate duplicates.

Real project scenario

Two suppliers with similar names were merged because the matching rule over-weighted fuzzy name similarity and ignored distinct tax IDs. Retuning the rule and creating a hard tax-ID conflict prevented false merges.

Common mistakes

Optimizing only duplicate-reduction rate.
One source priority for every attribute.
No false-positive testing.
Losing source lineage after merge.
Replicating best records without downstream key mapping.

Best practices

Tune using real data.
Define trusted source by attribute.
Route ambiguous matches to stewardship.
Preserve lineage.
Reconcile target identities after merge.

Interview angle

Explain matching threshold, false positive/negative trade-offs and field-level survivorship.

Practice this lesson

Quick check

1. Scenario — Two suppliers with similar names were merged because the matching rule over-weighted fuzzy name similarity and ignored distinct tax IDs. In this Consolidation situation, which response best addresses the underlying design risk?

2. After records are grouped into a match group, the system calculates a single representative record by applying field-level rules that determine which source value wins for each attribute. What is this concept called?

3. A senior review of Match, Merge and Survivorship Rules in MDG Consolidation Processing finds this failure pattern: "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.". Which corrective action is strongest?

Interview questions

1. A senior architect is reviewing Consolidation. The project situation is: Two suppliers with similar names were merged because the matching rule over-weighted fuzzy name similarity and ignored distinct tax IDs. What design changes, validation evidence and production controls would you require before approving the solution?

Answer it in your own words first, then compare.

2. A project encounters this situation while working on Configuring the Consolidation Process: Matching, Best Record Rules, and Steward Review: During a post-acquisition data harmonization project, the consolidation team set an initial match threshold that was too permissive for vendor records, causing hundreds of distinct small suppliers with generic names like 'City Logistics' in different cities to be proposed as duplicates of each other. Walk through how you would analyze the requirement or issue, what you would validate, and how you would test the solution before release.

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.