Duplicate Prevention and Data Quality Rules for Business Partner Change Requests
Learn how SAP MDG uses search-based duplicate checks and rule-based validations to prevent low-quality or duplicate Business Partner records from entering a governed change request, and how to interpret and tune these checks in a project.
Explanation
Business Partner governance is only as valuable as the quality of data it lets through. Without effective duplicate checks and validation rules, a Change Request (CR) workflow can faithfully route bad data through approvals and still end up creating a duplicate customer or vendor record, which then causes downstream problems in pricing, credit management, payments, and reporting. This lesson focuses on the quality gate that sits inside the CR process: duplicate check services and Business Add-In (BAdI) or rule-based validations that fire during CR processing. In SAP MDG, duplicate checking for Business Partner typically relies on a search-based comparison against existing BP records using key attributes such as name, address, tax number, and identification numbers. When a user creates or edits a BP within a CR, the system can trigger a duplicate check step that returns a ranked list of similar existing partners. The steward or requester then has to review these hits and decide whether to link to an existing partner, reject the request, or proceed if the match is a false positive. The quality of this check depends heavily on which attributes are configured for comparison, the matching algorithm's sensitivity, and how clean the existing data set already is. If the existing database already contains duplicates, the check will only ever be as good as what it is compared against, so data quality initiatives often start with a one-time cleansing exercise before turning on strict duplicate prevention in the live CR process. Beyond duplicate checking, validations and derivations enforce business rules at the field or entity level. Validations can enforce mandatory combinations (for example, requiring a tax number format consistent with the partner's country) or block specific combinations of attributes considered invalid for the organization. Derivations can auto-populate fields such as classification, grouping, or default payment terms based on entered data, reducing manual entry errors. These rules are commonly implemented through configuration-driven rule frameworks, BAdIs, or Business Rule Framework plus (BRFplus) rules called from the CR processing steps, evaluated at specific points such as at CR creation, at save, or before submission to workflow. A critical design decision is where in the CR lifecycle these checks execute. Running duplicate checks too early (before the user has entered enough distinguishing data) produces noisy, low-value results and encourages users to ignore them. Running checks only at the final approval step means a requester might invest significant effort before finding out the record is a duplicate, causing frustration and rework. Most well-tuned implementations trigger an initial duplicate check as soon as core identifying fields (name, address, and tax or registration IDs) are entered, then optionally re-check before submission for approval. From a governance perspective, false positives and false negatives both carry cost. Too many false positives slow down legitimate business and lead to steward fatigue, where every hit gets waved through. Too many false negatives let duplicates through and undermine the entire consolidation value proposition of MDG. Regular monitoring of duplicate check outcomes, tuning of match thresholds, and periodic mass duplicate search runs against the existing production data set are standard governance disciplines, not one-time setup activities. In S/4HANA on-premise and private cloud, these rule frameworks are typically configurable by the customer within the delivered extensibility points. In S/4HANA Cloud Public Edition, the degree of custom rule extension is more constrained and delivered through cloud-compatible extensibility, so architects must validate what customization is actually supported in a given release rather than assuming on-premise flexibility is available.
Real project scenario
A retail company's shared services team frequently received complaints that the same vendor was being created two or three times under slightly different name spellings, causing duplicate payments to be investigated by AP. After introducing a stricter attribute-based duplicate check that included tax registration number and bank account details alongside name and address, along with mandatory review of any hit above a certain similarity score, the volume of true duplicates dropped substantially within two quarters, though the volume of change requests requiring manual duplicate review increased and had to be staffed for during the initial tuning period.
Common mistakes
ā¢ Enabling duplicate checks only on creation and not on significant changes such as address or tax ID updates, which can also introduce duplicates ā¢ Comparing against too narrow a set of attributes, so obvious duplicates with different name spellings are missed ā¢ Ignoring a backlog of existing duplicates in production data, which erodes trust in new duplicate check results ā¢ Treating every duplicate check hit as a hard block instead of allowing informed steward judgment for legitimate near-matches ā¢ Failing to monitor false positive and false negative rates over time, leaving thresholds static as data patterns evolve ā¢ Assuming the same rule configuration and extensibility options are available identically across on-premise, private cloud, and public cloud editions
Best practices
ā¢ Trigger an initial duplicate check as soon as core identifying attributes are captured, and a final check before workflow submission ā¢ Include multiple identifying attributes such as tax ID, registration number, and address components, not just name, in match criteria ā¢ Run a one-time cleansing and deduplication project on existing data before enforcing strict checks on new requests ā¢ Periodically review duplicate check hit rates and steward decisions to recalibrate match sensitivity ā¢ Document validation and derivation rules clearly so business and IT share a single source of truth on what is enforced and why ā¢ Confirm what extensibility for validations, derivations, and duplicate checks is actually supported in your specific S/4HANA deployment before designing custom rules
Interview angle
Interviewers often probe whether a candidate understands that duplicate prevention is a tuning discipline, not a one-time switch. Be ready to discuss how you would design the timing of duplicate checks within a CR, how you would balance false positives against steward workload, and how you would approach cleansing existing duplicates before tightening checks on new data. Also expect questions distinguishing validation/derivation rules from duplicate search, since these are related but distinct governance mechanisms.