Configuring Match Rules, Scoring, and Best-Record Survivorship for Consolidation
A practical walkthrough of how match rules, similarity scoring, and best-record survivorship decisions are configured and executed in an MDG consolidation process.
Explanation
Once an organization has accepted the need for consolidation, the real design work begins with defining how records will be compared and how conflicts between matched records will be resolved. This lesson focuses on the two central technical building blocks of any consolidation exercise: match rule configuration (how the system decides two records might represent the same entity) and survivorship rules (how the system, or the steward, decides what the merged best record should actually contain). Match rule design starts with selecting the attributes that carry the most discriminating power for the object type being consolidated. For business partners and customers, this typically includes legal name, tax identification numbers, registration numbers, address components (street, postal code, city, country), and sometimes banking details. For materials, it might include description, base unit of measure, manufacturer part number, and dimensional attributes. Each attribute is assigned a comparison method - exact match, phonetic comparison, fuzzy string similarity, or normalized comparison after removing noise such as punctuation, legal form suffixes, or case differences. Attributes are also weighted, because a match on a rare, highly specific identifier such as a tax number is far more meaningful than a match on a common city name. The combination of weighted attribute comparisons produces a similarity score for each candidate pair of records, and the project team must define score thresholds: pairs above a high threshold may be treated as very likely duplicates and grouped automatically for steward confirmation, pairs in a middle band may be flagged as possible matches requiring closer manual review, and pairs below a lower threshold are left unmatched. Setting these thresholds is inherently a business risk decision - too aggressive and the process risks merging distinct entities; too conservative and it leaves genuine duplicates untouched, so most projects tune thresholds iteratively using a labeled sample of known duplicates and known distinct records to measure false positive and false negative rates before running at scale. Once records are grouped as a match cluster, survivorship logic determines which field values populate the resulting best record. Common survivorship strategies include: source system priority (values from a designated trusted source system win by default), recency (the most recently updated value wins), completeness (a non-blank value wins over a blank one), and manual override (a data steward explicitly picks or types the correct value for a specific field, typically for high-impact fields such as legal name, tax ID, or payment terms). In practice, most consolidation configurations combine these: automated survivorship rules populate the default best record proposal, but the steward's review screen shows all source values for material fields and allows explicit correction before confirmation. This hybrid approach balances efficiency (not every field on every record needs manual attention) with control (fields with regulatory or financial impact get human eyes). The runtime flow typically looks like this: source records are loaded into a staging or workbench area; the match engine executes and produces clusters of candidate duplicates with scores; a steward work list surfaces clusters requiring review, often prioritized by score band or by business unit ownership; the steward confirms, rejects, or manually adjusts a cluster and finalizes the survivor record; the survivor record is validated against the same governance rules (mandatory fields, format checks) that apply to normal governance change requests; and finally the confirmed survivor record is used to update the target master data, potentially triggering follow-on distribution or replication logic to keep connected systems synchronized with the newly consolidated record. Troubleshooting a consolidation run in production support usually falls into a few recurring patterns: match rules producing an unexpectedly high volume of low-quality matches (often a sign that attribute normalization, such as stripping legal suffixes, was not configured correctly), stewards reporting that a cluster contains records that clearly should not be merged (indicating a threshold or weighting problem, or a data quality issue such as reused tax numbers), and downstream systems reporting broken references after a merge because dependent transactional data was not remapped to the surviving ID. Because of this, most projects treat post-merge reference remediation and reconciliation reporting as part of the consolidation scope, not an afterthought. Performance is also a consideration at scale: comparing every record against every other record is computationally expensive, so match engines typically use blocking or indexing techniques to only compare records that share some coarse attribute (such as postal code or first letters of name) before applying the full weighted comparison, and large consolidation runs should be scoped and scheduled with this cost in mind rather than run ad hoc against full production volumes during business hours.
Real project scenario
During a vendor master cleanup project, a manufacturing company configured match rules weighting tax identification number and bank account number heavily, with company name given only moderate weight because many subsidiaries of large group vendors shared very similar names but were legally distinct entities requiring separate vendor records. The initial pilot run using only name similarity produced hundreds of false-positive clusters grouping distinct subsidiaries together; after re-weighting toward tax ID and bank details and introducing a middle score band for manual review, the false positive rate dropped substantially, and stewards were able to process the confirmed high-confidence clusters in batches while manually reviewing the smaller middle-band group.
Common mistakes
• Weighting common attributes like city or country too heavily relative to unique identifiers, inflating false-positive match rates • Failing to normalize legal form suffixes and punctuation in name fields before comparison, causing genuine duplicates to be missed • Setting a single hard threshold instead of a tiered scoring band, forcing all borderline matches into either fully automatic or fully manual buckets • Confirming merges without validating the survivor record against the same mandatory field and format rules used in standard governance • Not planning for remediation of transactional references (open orders, contracts, invoices) tied to non-surviving records after merge
Best practices
• Weight rare, highly discriminating identifiers (tax ID, registration number) above common descriptive attributes like city or name alone • Normalize and cleanse key comparison fields (remove legal suffixes, standardize case and punctuation) before running match rules • Use a tiered scoring approach with automatic, manual-review, and no-match bands rather than a single cutoff • Validate survivor records against standard governance rules before finalizing a merge • Plan and test performance-friendly blocking/indexing strategies before running match jobs against full production volumes
Interview angle
Interview questions in this area often probe whether a candidate understands that match scoring is a tunable, risk-based configuration rather than a fixed algorithm, and whether they know how survivorship rules interact with manual steward review. A good answer describes weighted attribute scoring, tiered thresholds, and a hybrid automated-plus-manual survivorship approach, and can explain a concrete troubleshooting scenario such as diagnosing high false-positive match rates.