Why Duplicate Check Matters in MDG Governance
Understand the business and technical purpose of duplicate check in MDG, why duplicates are costly, and where the check fits into the change request lifecycle.
Explanation
Duplicate master data records are one of the most persistent and expensive data quality problems in any SAP landscape. When the same customer, vendor, business partner or material is created multiple times under slightly different names, addresses, or tax IDs, the organization suffers in several concrete ways: fragmented spend visibility across procurement, incorrect customer credit exposure, failed automatic matching in invoice processing, duplicated marketing and compliance screening, and inflated reporting numbers that erode trust in analytics built on top of master data. SAP Master Data Governance addresses this problem proactively by embedding a duplicate check step into the governance process itself, rather than relying purely on downstream data cleansing. In MDG, the duplicate check is typically triggered at defined points in the change request (CR) process for governed data models such as Business Partner, Customer, Supplier, or Material. When a requester enters data for a new record, MDG can automatically run a search against existing master data using configured search criteria (for example name, address, tax number, bank details, or a combination of these attributes with similarity/fuzzy matching). If the search returns records above a configured similarity threshold, the system presents these as potential duplicates to the requester or reviewer, who must then decide whether to continue creating a new record, link to an existing one, or reject the request. This human decision point is important: duplicate check is a decision-support mechanism, not a fully automated hard block in most standard configurations, because business context often determines whether two similar-looking records are genuinely the same legal entity or two distinct entities that happen to share attributes (for example a franchise structure with shared addresses). Technically, the duplicate check relies on a search infrastructure that can perform fuzzy or similarity-based matching rather than simple exact-match queries, because real-world data entry contains typos, abbreviations, transliterations, and formatting differences. On S/4HANA, this search capability is generally powered by HANA-based search technology that supports fuzzy search and scoring, which MDG leverages to compare newly entered attribute values against existing governed records. The configuration defines which fields participate in the search, how they are weighted, and what score threshold counts as a 'hit' worth showing to the user. For a beginner consultant, the key mental model is: duplicate check = a quality gate inside the change request workflow, not a separate standalone tool. It reuses the master data model already governed by MDG (Business Partner, Customer/Vendor integration, Material) and plugs into the same UI Framework (Floorplan Manager / Fiori-based UIs depending on release) that requesters use to create or change records. Understanding this integration point is essential before moving into configuration details, because most implementation questions in real projects are not 'how does fuzzy matching work mathematically' but 'at which step in my specific change request type does the check fire, and what happens to the workflow if a duplicate is found.' From a project perspective, duplicate check is usually one of the first quality controls stakeholders ask about when justifying an MDG investment, because the business case (avoiding duplicate vendors that lead to duplicate payments, or duplicate customers that split sales history) is easy to articulate to finance and compliance stakeholders. This makes it a strategically visible feature, and expectations must be managed carefully: duplicate check reduces the risk of duplicates but does not guarantee zero duplicates, especially when source data is poor quality or when the check is configured with narrow criteria that miss valid matches.
Real project scenario
A consumer goods company implementing MDG for supplier master data found that finance had over 3,000 supplier records, with an estimated 8% being duplicates created by different regional purchasing teams using slightly different company name spellings and address formats. During the MDG rollout, the project team enabled duplicate check on the supplier creation change request type so that any new supplier request first ran a similarity search against existing active suppliers using company name, city, and tax number. Requesters saw a list of potential matches before submission, and were required to either confirm the record as genuinely new or cancel and reference the existing supplier. Within the first quarter after go-live, duplicate creation requests dropped noticeably, and the accounts payable team reported fewer duplicate payment investigations.
Common mistakes
• Assuming duplicate check will automatically block all duplicate creation without human review, leading to disappointment when near-duplicates still get created due to low similarity scores • Treating duplicate check as a one-time technical switch rather than a business process requiring requester training on how to interpret potential matches • Ignoring data quality of existing master data when enabling duplicate check, so the search runs against a base that already contains duplicates, undermining trust in results • Not aligning duplicate check scope with the specific change request types in use, so the check is skipped for certain creation paths (for example mass creation or interface-driven creation) • Failing to communicate to business users that duplicate check adds a step to the process, causing resistance if not explained during change management
Best practices
• Position duplicate check as part of the overall data governance narrative when presenting MDG value to business stakeholders • Run a baseline data quality assessment on existing master data before enabling duplicate check, so early results are meaningful • Train requesters explicitly on how to interpret and act on potential duplicate results shown during change request creation • Confirm which change request types and creation entry points (UI, interfaces, mass processing) are in scope for duplicate check early in the project • Set realistic expectations with stakeholders that duplicate check reduces but does not eliminate duplicate creation risk
Interview angle
Interviewers commonly ask candidates to explain, in plain business terms, why duplicate check exists and where it sits in the MDG change request process, then probe whether the candidate understands it is a decision-support step rather than a fully automatic block. A strong answer connects the business cost of duplicates (financial, compliance, reporting) to the technical mechanism (similarity search integrated into CR workflow) and shows awareness that results depend heavily on the quality of existing master data and the chosen search criteria.