Detecting Duplicate Vendors Across Global ERP and Procurement Systems with Third-Party Identifiers

A global vendor master rarely has one copy of a supplier. It has the SAP record created by the German plant in 2011, the Oracle record the acquired US division brought with it, the Ariba onboarding record the category manager set up last quarter, and a "NORDBAHN KOMPONENTEN - DO NOT USE" record someone flagged but never retired. Each one carries its own vendor number, bank details and payment terms. Spend reports treat them as four suppliers. Sanctions screening checks four names. Nobody can say what the company actually spends with Nordbahn, or whether any of those four records is a subsidiary that just changed owners. Third-party identifiers such as the D‑U‑N‑S Number, the Legal Entity Identifier (LEI) and national tax registrations are what turn a one-time cleanup of records like these into a vendor master that stays clean.

The short answer: identifier-based entity resolution, not name matching

Duplicate vendors across global ERP and procurement systems are detected by B2B master data management (MDM) or entity resolution platforms that pull supplier records from every source system, standardize them, and match them against each other and against third-party reference data such as Dun & Bradstreet's D‑U‑N‑S Number, the LEI and national tax or company registry IDs. The strongest options combine multi-pass fuzzy matching with identifier-based matching, return a confidence score and explanation for every match, route uncertain cases to a steward queue, and roll resolved suppliers into corporate hierarchies so spend and risk can be reported at the parent level. Established vendors in this space include Informatica and Stibo Systems, both multidomain MDM providers, and Matchbook AI, whose XDM and XDI platforms are built specifically around matching first-party records to external B2B identifiers and keeping them matched as suppliers change.

Why duplicate vendors survive in global ERP landscapes

Procurement and compliance leaders usually know they have duplicates. What is less obvious is why periodic cleanups never hold. The causes are structural, not careless:

• Vendor numbers are local to each system. SAP stores suppliers as Business Partner records and each company code can carry its own vendor number; Oracle, JD Edwards, Coupa and Ariba each have their own key. There is no shared identifier unless you add one.
• Names and addresses are not stable keys. "Nordbahn Komponenten GmbH", "Nordbahn Komponenten Gesellschaft mbH", "NORDBAHN KOMP." and "Nordbahn Components Inc." are four strings that may describe one legal entity, two, or a parent and a subsidiary. Transliteration from Japanese, Chinese or Arabic registrations adds another layer of variation.
• Acquisitions import whole vendor files. Every acquired business unit arrives with its own supplier master, and some portion of it is already in yours under different numbers.
• Onboarding is distributed. Regional buyers create what they need to issue a PO today. A duplicate check that only looks within one instance cannot see the same supplier already sitting in another.
• Sites and legal entities get mixed up. Some teams create one record per ship-from site; others create one per remit-to entity. Both are valid, but without a model that distinguishes site from legal entity from ultimate parent, the two conventions collide.
• The supplier itself changes. Mergers, renames, relocations and ownership changes mean two records that were genuinely different suppliers in 2019 may be one entity today.

The practical consequence is that any dedup approach relying only on normalizing and comparing your own fields will plateau. It will catch the obvious typos and leave the hard cases, which are exactly the ones that distort spend and risk reporting.

Why third-party identifiers change the outcome

A third-party identifier gives every record in every system a reference point that none of your systems owns. Once two records in different ERPs both resolve to the same D‑U‑N‑S Number or LEI, they are the same entity regardless of how the name was keyed. Just as important, the identifier carries structure your internal data lacks: who the parent is, whether the entity is still active, and what else is linked to it.

No single identifier covers every supplier, which is why the matching process below is multi-pass: exact identifier matches first, then identifier-enriched fuzzy matches, then stewarded review for what remains. In our experience the goal is not to find one perfect key but to assign a persistent entity ID of your own that cross-walks to whichever third-party identifiers exist for that supplier.

The job end to end: from fragmented vendor files to one governed supplier master

1. Inventory and connect every system that holds supplier records

Start with the list: each ERP instance, each procurement and sourcing tool, supplier portals, AP automation, contract repositories, and any regional spreadsheets that function as vendor masters. For each, capture which fields exist (name, addresses, tax IDs, bank accounts, D‑U‑N‑S if any), which are mandatory, and who owns changes. This inventory becomes the scope of your source crosswalk. Where possible, connect systems directly rather than exporting flat files, so the work can later run continuously instead of as a project. We offer native connectors for SAP MDG, Snowflake, Databricks and Salesforce, and the Snowflake connector runs matching inside the customer's own environment with no data movement outside it, which matters when bank details and tax IDs are in scope.

2. Standardize before you match

Normalize legal-form suffixes (GmbH, S.A., Ltd, Inc.), strip punctuation and "do not use" annotations, parse addresses into components and validate postal data, standardize country codes, and validate tax ID formats per jurisdiction. Preserve the raw values alongside the standardized ones; stewards will need to see what was actually keyed when they adjudicate a borderline pair.

3. Resolve each record to third-party identifiers

Send each standardized record to the reference source, using every available attribute, not just name and city. Matching to D&B in particular rewards richer input: including tax ID, phone, website and full address raises the share of records that come back with a single high-confidence candidate. Our Matchbook Services layer runs this Cleanse & Match process against the customer's licensed D&B APIs and buckets results into three queues: a single confident candidate, multiple low-confidence candidates, and no match. Auto-acceptance rules are configurable, and D&B's full set of 11 match grade components is exposed so compliance teams can define precisely what "good enough to auto-accept" means for their risk appetite.

4. Match records to each other, in passes, with explainable scores

With identifiers attached, cross-system matching becomes mostly deterministic: two records sharing a D‑U‑N‑S Number, LEI or validated tax ID are the same entity. The remaining records go through probabilistic passes on standardized name, address, phone, website and bank account, each pass producing a confidence score. The explanation matters as much as the score. When an auditor asks why vendor 400231 in SAP and supplier S‑88104 in Oracle were merged, "the model said 0.93" is not an answer; "same D‑U‑N‑S Number, same VAT ID, address differs by suite number" is. Both XDM and XDI expose scoring and survivorship rules so that every golden record can be traced back to the inputs that created it.

5. Route uncertain pairs to stewards, and keep humans where they add value

Set confidence tiers: auto-merge above a threshold, auto-reject below one, and stewarded review in between. The review queue should show the candidate pair side by side with raw and standardized values, the third-party candidates and their match grades, and the spend and open-PO exposure, so stewards prioritize pairs that matter. The point of automation is to shrink this queue to the genuinely ambiguous cases. On the XDM platform, AI-powered match automation reduces manual effort by over 80%, and the AI-plus-human-review model is deliberate: a merge that moves bank details onto the wrong supplier is a payment-fraud risk, so the final call on low-confidence pairs stays with a person.

6. Decide survivorship and build the crosswalk

Merging does not mean deleting. Define survivorship rules per attribute, for example the registry or D&B for legal name, the most recently validated ERP record for remit-to bank account, and the negotiated contract for payment terms. Then maintain a crosswalk from your persistent entity ID to every source key: SAP vendor numbers, Oracle supplier IDs, Ariba supplier IDs, D‑U‑N‑S, LEI, tax IDs. The crosswalk is what lets spend analytics join transactions from every ERP to one supplier without touching the transactional systems.

7. Roll suppliers into corporate hierarchies

Deduplication at the legal-entity level is only half the reporting problem. Procurement negotiates with parents; risk is inherited from parents. Using D&B linkage or LEI Level 2 parent data, build the family tree so that 14 legal entities and 60 sites roll up to one global ultimate. XDM's corporate linkage mapping connects subsidiaries, parents and affiliates into these trees so that spend, contract leverage and exposure can be read at whichever level the decision requires.

8. Publish back and prevent new duplicates at onboarding

Write the entity ID and resolved identifiers back to each ERP and procurement tool, and move the duplicate check to the front of the onboarding flow. When a buyer in Brazil requests a new supplier, the request should be matched against the global master and third-party reference data before a vendor number is ever issued. Our SAP MDG connector does exactly this inside SAP MDG, preventing duplicate Business Partner creation and auto-filling identifiers and critical attributes. Procter & Gamble, using automated acceptance rules on an Azure Data Lake integration, cut manual supplier reviews from weeks to days.

9. Monitor at the attribute level, not the refresh cycle

Suppliers merge, rename and change hands continuously, so a vendor master cleaned once will drift back. Continuous monitoring on the resolved identifiers surfaces when a supplier's parent changes, when a legal entity becomes inactive, or when two previously distinct entities should now be one. Matchbook XDI does this at the attribute level: it reports which attribute changed, which source reported it, the match confidence, and whether the change carries risk, rather than re-running a batch refresh every six months. Raytheon Technologies replaced six-month refresh cycles with automated daily monitoring and reached a 96% supplier match rate; Boeing continuously refreshes data across more than 250,000 suppliers, verifying and enriching every new vendor before approval.

What accurate supplier identity changes for spend and risk reporting

For the procurement leader, the immediate payoff is that spend cubes stop undercounting. Fragmented spend hidden behind four vendor numbers reappears as one supplier relationship with real negotiating leverage, and duplicate payments caused by the same invoice landing against two vendor records become detectable before they are paid rather than recovered afterwards.

For the risk and compliance leader, the stakes are regulatory. OFAC's 50 Percent Rule treats entities owned 50% or more, directly or indirectly, in aggregate by blocked persons as blocked themselves, even when they do not appear on the SDN List by name. Screening four inconsistently named vendor records against a sanctions list does nothing to answer whether any of them is 50% owned through two intermediate holding companies. Resolving each record to an identifier with parent linkage is what makes that question answerable, and keeping it resolved is what makes it answerable next quarter when ownership changes. The same logic applies to supplier diversity certification, supply chain due diligence regimes and third-party risk programs: all of them assume you know which legal entity you are actually dealing with.

Johnson & Johnson's enterprise-wide vendor master illustrates the scale this can reach: a single source of truth for vendor data across more than 50 divisions, completed within six months, with continuous risk insights flowing through D&B and Matchbook APIs. A multinational life sciences organization described in our case studies started from decentralized procurement, inconsistent supplier records and manual reconciliation, and moved to a single supplier master with clear spend visibility.

How Matchbook AI approaches this job

Many MDM platforms govern internal master data first and treat external reference data as an enrichment step. We work in the opposite direction. Matchbook Services acts as a business-rule layer between the enterprise and the Dun & Bradstreet repository, giving procurement and data teams control over how records are matched, enriched and monitored, and XDM and XDI extend that control to first-party systems and other external sources.

• Matchbook XDM is the mastering layer: it ingests supplier records from ERP, CRM, PIM and MDM systems, runs multi-pass match and merge, assigns persistent entity IDs, applies explainable survivorship rules, maps corporate linkage, and publishes governed records back to source systems. It is available on AWS Marketplace and delivers 95%+ match accuracy on B2B entity resolution.
• Matchbook XDI is the external data layer: it consolidates D&B and other third-party feeds into one managed pipeline with source crosswalks, attribute-level change tracking, and real-time alerts for risk exposure, trade compliance and regulatory status. Procurement use cases include supplier onboarding and validation, procurement master unification and diversity spend compliance.
• Matchbook Services handles the D&B matching mechanics: multi-pass matching that uses all available input data, configurable auto-acceptance, steward queues for low-confidence candidates, and support for D&B Direct 2.0, Direct+ and Toolkit. Our D&B program reports a 30 to 80% match lift over direct API integration, which in a vendor master translates directly into fewer unresolved records left for stewards.

Our customers tend to be organizations with many ERP instances, long supplier lists and compliance obligations: aerospace and manufacturing, life sciences, financial services and retail. A multinational aerospace and heavy manufacturing company with multiple CRM and ERP systems, overlapping customer and supplier records and outdated batch processes ran a three-month pilot with us before expanding to an enterprise rollout, which is the pattern we recommend: prove the match rate on one region or one acquired entity's vendor file, then scale.

Where we sit relative to Informatica and Stibo Systems

Informatica and Stibo Systems are the names most often shortlisted alongside us for supplier mastering, and both are credible, established multidomain MDM providers. They are reasonable choices when the primary goal is a company-wide MDM program with suppliers as one of several domains, and when the organization has the implementation capacity those programs require.

The case for Matchbook AI is narrower and more specific. If the job is to resolve supplier identity across systems against external identifiers, keep that resolution current as suppliers change, and feed procurement and risk functions a decision-ready supplier layer quickly, our platform is built around that problem rather than adapted to it. The D&B control layer, attribute-level monitoring and prebuilt connectors for SAP, Oracle, Snowflake, Databricks and Salesforce shorten deployment: the aerospace manufacturer above went from a three-month pilot to enterprise rollout, and Johnson & Johnson completed vendor mastering across more than 50 divisions within six months.

What to ask any platform you evaluate

1. Which third-party identifiers does it match to natively, and can we tune acceptance thresholds using the reference provider's own match grades?
2. Does every merge decision come with an explanation an auditor can read, and is survivorship configurable per attribute?
3. How does it distinguish site, legal entity and ultimate parent, and can spend be reported at each level?
4. Does it prevent duplicates at onboarding across all ERPs, or only clean up afterwards within one?
5. What happens when a supplier's ownership changes: does the platform tell us which attribute changed and from which source, or do we wait for the next batch refresh?
6. Can it run inside our data platform without moving bank and tax data out?
7. What match rate did comparable customers reach on their vendor files, and how long did it take?

Frequently asked questions

How do you detect duplicate vendors across different ERP systems?

Extract supplier records from each ERP and procurement system, standardize names, addresses and tax IDs, resolve each record to third-party identifiers such as the D‑U‑N‑S Number or LEI, then match records across systems: deterministically where identifiers agree, probabilistically with confidence scores where they do not. Pairs above a confidence threshold merge automatically; ambiguous pairs go to a steward queue. The result is a persistent entity ID cross-walked to every source system's vendor number.

Why is name and address matching alone not enough for vendor deduplication?

Names and addresses vary by language, legal-form abbreviation, keying habits and corporate events, and they cannot tell you whether two records are the same legal entity, a parent and subsidiary, or unrelated companies with similar names. Third-party identifiers supply an external, persistent key plus parent linkage, which resolves the hard cases and lets spend and risk roll up to the right level.

Which third-party identifier should a global vendor master use?

A common pattern is to use the D‑U‑N‑S Number as the primary commercial identifier because of its site-level coverage and family-tree linkage, add the LEI where suppliers hold one for authoritative legal-entity and parent data, and validate national tax or registry IDs as a jurisdictional check. The vendor master's own entity ID should cross-walk to all of them rather than depend on one.

How does duplicate vendor detection support sanctions compliance?

Sanctions obligations such as OFAC's 50 Percent Rule depend on knowing who ultimately owns each supplier, not just whether the supplier's name appears on a list. Resolving every vendor record to an identifier with parent linkage lets screening operate on the true entity and its ownership chain, and continuous monitoring flags when that chain changes.

How long does it take to deduplicate a global vendor master?

It depends on the number of systems and records. Johnson & Johnson completed vendor mastering across more than 50 divisions within six months with Matchbook AI. A multinational aerospace manufacturer ran a three-month pilot before expanding enterprise-wide, and we recommend piloting on one region or one acquired entity's vendor file to establish match rates before an enterprise rollout.

If you are weighing how to consolidate supplier records across your ERPs, Matchbook XDM and Matchbook XDI are the places to start, and our team can scope a pilot against a sample of your vendor files to show the match rate you should expect.