Configuring Search and Match Rules for Duplicate Check
Learn how duplicate check search criteria, matching fields, similarity thresholds, and change request integration are configured for governed entities in MDG.
Explanation
Once the business case for duplicate check is understood, the next step for an MDG consultant is configuring how the search and match logic actually behaves for a given data model, such as Business Partner, Customer, Supplier, or Material. Configuration decisions here directly determine whether the check catches meaningful duplicates without overwhelming requesters with false positives, so this work requires close collaboration between the functional consultant and business data stewards who understand what 'the same entity' really looks like in their industry and region. The first configuration decision is which attributes participate in the search. For Business Partner-based models this typically includes name fields, address components (street, postal code, city, country), identification numbers (tax number, registration number), and sometimes bank details or contact information. Selecting too few fields risks missing genuine duplicates that differ in the chosen fields but match on others; selecting too many, or fields that are inconsistently populated, can produce noisy results or fail to score well because incomplete data reduces match confidence. A common pattern is to combine a strong identifier (tax ID or registration number) with a fuzzy match on name and location, since identifiers alone may not always be captured at data entry time. The second decision is the similarity or matching algorithm and its threshold. Because manual, exact-string comparison is too rigid for real-world data (misspellings, abbreviations such as 'Intl' versus 'International', or different address formatting), MDG duplicate check leverages fuzzy/similarity search capability, generally powered by HANA search technology on S/4HANA landscapes. Consultants configure a threshold score above which a record is surfaced as a potential match. Setting this threshold is an iterative exercise: too low a threshold generates excessive false positives that frustrate requesters and erode trust in the check; too high a threshold misses genuine duplicates. Most projects run threshold tuning workshops using a sample of known duplicate pairs and known distinct pairs from the existing data set to calibrate the value before go-live. The third area is integration with the change request type and workflow. Duplicate check is generally activated for specific change request types (for example 'Create Business Partner' or 'Create Supplier') and specific steps in that request's process flow, commonly early in the request before extensive data entry to avoid wasted effort if a duplicate is found. When potential duplicates are returned, the UI typically presents a result list with the matched records and their similarity scores, and the requester or a data steward reviewing the request must take an explicit action: proceed as new, cancel, or reference/link to the existing record. Some configurations route requests with high-confidence matches to a dedicated approval step for a data steward to make the final call, rather than leaving the decision entirely to the initial requester, which adds a governance control point for higher-risk entities such as suppliers involved in payment processes. A further consideration is scope: duplicate check configured for the interactive UI does not automatically apply to all creation paths. Mass processing, file-based uploads, and API-driven or interface-based creation of master data may bypass or require separate configuration to invoke the same or equivalent duplicate checking logic, and S/4HANA public cloud extensibility options may differ from on-premise or private cloud configuration flexibility, so consultants must verify, rather than assume, that a given creation channel is covered. Finally, ongoing maintenance matters as much as initial setup. Search field selection and thresholds should be periodically reviewed as data volume grows, as new regions or business lines are onboarded with different data patterns, and as feedback from stewards indicates the check is either too noisy or missing known duplicates. Configuration is not a one-time activity but part of the operating model for master data governance.
Real project scenario
During an MDG implementation for a manufacturing group operating in multiple countries, the project team initially configured duplicate check for customer creation using only company name and country. Early testing revealed excessive false positives because many legitimate customers shared generic name patterns (for example common distributor names repeated across regions). The team revised the configuration to weight tax identification number and postal code more heavily alongside name similarity, and introduced a moderate threshold tuned using a sample set of 50 known duplicate pairs and 50 known distinct pairs supplied by the data governance team. After retuning, the false positive rate dropped substantially while known duplicate pairs were still correctly flagged, and the configuration was signed off by the data steward community before go-live.
Common mistakes
• Selecting search fields based only on technical convenience rather than what data stewards say actually distinguishes duplicate from legitimate records • Setting a similarity threshold without testing against real sample data, resulting in either alert fatigue or missed duplicates after go-live • Assuming the same search configuration works identically across regions with different address formats, naming conventions, or identifier standards • Forgetting to extend duplicate check coverage to mass creation, interface, or API-driven master data creation paths • Not revisiting or retuning configuration after go-live as data volume and business scope grow
Best practices
• Involve data stewards early to define which attribute combinations genuinely indicate duplicate entities in the business context • Tune similarity thresholds iteratively using labeled sample data of known duplicates and known distinct records before go-live • Explicitly verify and document which creation channels (interactive UI, mass processing, interfaces) are covered by duplicate check • Route high-confidence duplicate matches to a data steward approval step rather than relying solely on the initial requester's judgement • Schedule periodic review of duplicate check configuration as data volume, regions, or business lines expand
Interview angle
Interview questions at this level often focus on how a candidate approaches threshold tuning and field selection trade-offs, since this reflects real hands-on configuration experience rather than theoretical knowledge. Strong candidates describe an iterative, data-driven tuning process using known duplicate and non-duplicate samples, explain why identifier fields are usually weighted alongside fuzzy name/address matching, and acknowledge that different creation channels (UI versus mass/interface) may require separate verification of duplicate check coverage.