Explaining Duplicate Checks in Supplier Requests

The default supplier request duplicate check searches for existing suppliers in your site's vendor database by a combination of:

• Exact match to Dun & Bradstreet ID (D-U-N-S number)
• Strict match to the full supplier name
• At least a partial match to the supplier name followed by a partial or full address match
  Note

  At least a partial name match must occur before address matching is attempted.

• Exact match to country/region-specific tax IDs, if your organization uses default duplicate check based on tax IDs
  Note

  Evaluation of country/region-specific tax IDs is supported only in internal supplier requests.

In addition to the questions already used in default duplicate checks, your organization can set up other questions in the internal and external supplier requests for duplicate check. Custom duplicate checks can increase the probability of matching supplier requests to existing duplicate suppliers by contributing additional variables to matching algorithms.

If your site uses custom duplicate check, partial matches to answers are also used for custom duplication check. For custom duplicate check, the answer must match starting with the first character. If the answer contains any spaces, each space-separated word or group of characters is matched separately, and each must either fully or partially match starting with the first character.

For example, if your site has an existing supplier with the value "Green Energy Corporation" in a field used for a custom duplicate check, "Green," Energy," and "Corporation" are all indexed for matching separately. Any corresponding supplier request answer that starts with "G," "E," or "C" is considered for matching, and answers such as "Gre," "Energ," and "Corp" are matched. Answers such as "Greed," "Reen," and "Gre Energion" aren't matched.

Matching is case insensitive. The duplicate check scores different matches based on predefined logic. The score is expressed as a percentage between 0 and 100, with scores of 70% and above considered strong matches and scores of less than 70% considered weak matches.

In match scoring, a D-U-N-S number match scores either 100% for an exact match or 0% for no match. Strict name matches score 100%, while partial name matches can vary between 0% and 100%. For matches on country/region, the duplicate check assigns maximum scores to exact matches but also accepts synonyms, ignoring case, and scores synonym matches based on the degree of similarity to the request answer, with an exact string match scoring 100%. The duplicate check assigns a total matching score to existing, potentially matching suppliers based on all matching fields.

When a requester submits an internal supplier request and during supplier request approval for both internal and external supplier requests, the duplicate check displays the top 20 matching suppliers, based on match score, in the following order:

• Exact matches, meaning a score of 100%, are listed first.
• Partial matches are shown next, in descending order based on score.

The duplicate check popup includes information on which current supplier request answers match existing suppliers.

The following screenshot highlights how match scores are displayed in the duplicate check popup:

The following restrictions apply to duplicate checks in supplier requests:

• Duplicate checks don't match against denied supplier requests or inactivated suppliers.
• For default duplicate check on supplier D-U-N-S number, name, and address, the duplicate check cleanses the values in those fields. It replaces newlines, white spaces, and ASCII punctuation with a single space before matching values to existing suppliers. Because of this cleansing, a new supplier request with a supplier name of "Supplier A, Ltd." matches an existing supplier named "Supplier A Ltd" but not an existing supplier named "Supplier A, Ltd.".
• Custom duplicate checks match answers in internal or external supplier requests against mapped answers from existing submitted supplier requests. They don't match against mapped data that originates from sources outside of supplier requests, such as data import, ERP integration, or other types of questionnaires.