MINJIBuyer resourcesAsk on WhatsApp

Vendor identity control

Supplier master duplicate record audit checklist

Two supplier IDs with similar names may be a duplicate, or they may represent different legal entities, branches, currencies, purchasing organizations or payment relationships. A careless merge can move invoices to the wrong beneficiary; ignoring duplicates can split controls and hide repeated payments.

Direct answer

The short version

Audit duplicate supplier master records by defining the entity, purchasing and payment systems in scope and extracting active, blocked, dormant and recently changed records with stable IDs. Normalize names, addresses, registration identifiers, tax fields, domains, phone details and bank attributes only for comparison while preserving the original values and access restrictions. Generate candidates from exact identifiers plus explainable near matches such as punctuation, transliteration, abbreviations, old names, branch addresses or reused contact data. Treat a match as a review lead, not proof. Independently verify legal entity, branch or site, supplier group, currency, remit-to relationship, tax treatment, bank beneficiary, purchasing organization, contract and onboarding history through approved sources. Determine whether the records are true duplicates, valid separate entities, valid separate sites or payment arrangements, legacy records, suspicious creations or unresolved. Before blocking, merging or redirecting anything, inventory open purchase orders, receipts, returns, invoices, credits, payments, disputes, contracts, catalogs, users and integrations attached to each ID. Select a survivor and mapping only with named business, finance, tax, legal and security authority appropriate to the case. Never copy bank details from one record to another merely because names match. Block new activity, migrate or cross-reference controlled objects, preserve the retired ID and change history, then test ordering, invoice matching, payment, reporting and audit retrieval. Monitor re-creation, payment duplication and activity on retired records.

Use this before requesting a quotation

Investigate supplier-record similarity before any irreversible master-data change

01

Define scope and preserve source records

Identify each enterprise resource planning, procurement, accounts payable, marketplace, warehouse and payment system included, plus legal entities, business units and regions. Export record ID, status, created and changed dates, creator, legal and trade names, address, registration and tax fields, website or domain, contact, currency, purchasing organization, payment method and masked bank comparison attributes where authorized. Include blocked, dormant, one-time and recently merged records so duplicates are not hidden outside the active population. Record extraction time and source. Restrict sensitive data and tokenize bank fields for matching when possible. Do not alter the master during candidate generation. Keep original spelling, scripts and identifiers alongside normalized comparison values. Separate missing data from unequal data; two blank tax IDs are not a match.

02

Generate candidates with explainable rules

Start with strong exact keys such as authoritative registration number or verified tax identifier within the relevant jurisdiction and entity type, then use layered name, address, domain, phone and beneficiary similarities. Normalize case, punctuation, common company suffixes, whitespace and approved transliteration without deleting meaningful legal words. Detect swapped address lines, former names, branch names, parent-company contacts and shared service centers. Compare creation timing and onboarding source. Use multiple signals and disclose why each pair was selected. A model score may prioritize review but should not merge records automatically. Test false positives using known separate subsidiaries and false negatives using known aliases. Track candidate rule version, threshold and reviewer outcome. Prevent an exact bank token from becoming public evidence; legitimate supplier groups may share treasury arrangements, while fraud can mimic a familiar name.

03

Verify entity and business relationship

Confirm the legal person or organization, registration status where applicable, registered and operating addresses, ownership or parent relationship only from authorized evidence, and the contract or onboarding party. GLEIF's Global LEI Index can support identity and relationship research for entities that have an LEI, but absence of an LEI does not invalidate a supplier. Determine whether records represent separate legal entities, branches, remit-to sites, factories, agents, distributors, one-time payees or the same organization. Check supplier communications through trusted contact details. Validate tax and regulatory fields with qualified owners. Keep brand, factory and payee identities distinct. Record evidence date and limitations. Do not treat a website, email domain, marketplace page or bank account alone as legal-entity proof. Escalate conflicting registration, contact or beneficiary information before transaction migration.

04

Map transactional and control dependencies

For every candidate ID, list open and historical purchase orders, acknowledgements, receipts, returns, invoices, credit notes, payments, refunds, deposits, rebates, disputes, contracts, price lists, product records, bank approvals, portal users and integrations. Identify which objects can be reassigned, which must retain the original supplier ID and which need a cross-reference. Check duplicate invoices and payments across the candidate pair before combining histories. Review segregation of duties, approval thresholds, tax reporting, currency, withholding, sanctions or other required controls with qualified owners. A record with no open balance may still support warranties, traceability, claims or historical audit. Freeze risky new activity when authorized, but do not cancel valid obligations simply because the identity review is open.

05

Decide survivor, separation or remediation

Classify as confirmed duplicate, valid separate entity, valid separate site or payment arrangement, legacy record, suspicious or unresolved. For a duplicate, select the survivor from verified identity, completeness, active contracts, system reach and control history—not the lowest number by habit. Document field-level source of truth and prohibit automatic overwrite of bank, tax, currency or payment terms. For valid separation, add controlled relationship and differentiating labels without exposing sensitive data. For suspicious creation, involve security, finance and legal owners and preserve evidence; do not accuse individuals from similarity alone. Approve block, merge, cross-reference or correction through named authority. Prepare rollback or compensating steps before bulk migration. NIST control guidance supports separated duties, least privilege, audit records and controlled configuration changes.

06

Execute the change with traceability

Stop new transactions on the retiring record at an agreed point, complete or remap open workflows deliberately and update integrations, portal access and reporting. Preserve the retired supplier ID, reason, effective time, approvers, survivor link and field history. Do not physically delete records required for financial, tax, quality, warranty or audit history. Revalidate beneficiary information through the normal bank-change control rather than copying it from the survivor. Test purchase order creation, receipt, invoice match, credit, payment proposal, withholding, currency, statement reconciliation and historical search. Confirm that open documents do not duplicate or disappear and that reporting can bridge old and new IDs. Communicate changed reference rules to authorized users and the supplier where appropriate.

07

Monitor recreation and control quality

Search new and reactivated supplier records against retired aliases and authoritative identifiers. Alert on invoices, payment proposals, bank changes or purchase orders using a retired ID. Review candidate volume, confirmed-duplicate rate, false-positive rate, time to resolution, records created outside onboarding and duplicate payments spanning aliases. Sample decisions in both directions: confirmed duplicates back to evidence and separately retained look-alikes for correct distinction. Analyze causes such as decentralized onboarding, missing identifiers, rushed one-time setup, acquisition, transliteration, interface mapping or unauthorized creation. Improve required fields and matching rules without making entry impossible for legitimate suppliers lacking a particular identifier. Retain an exception route and periodically retest known duplicate and separate-entity cases.

Reusable buyer brief

Supplier duplicate master review record

Audit scope, systems, entities, extract date and rule version:
Candidate supplier IDs, statuses, creation/change history and owners:
Original/normalized legal names, aliases and address comparison:
Registration/tax/LEI/domain/contact evidence and limitations:
Bank-beneficiary comparison token and restricted verification result:
Legal entity, branch/site, parent, agent or payee conclusion:
PO, receipt, return, invoice, credit, payment and contract dependencies:
Duplicate/separate/legacy/suspicious/unresolved decision and evidence:
Survivor, field source of truth, block/mapping and authorities:
Open-object migration, integration, access and rollback tests:
Retired ID history, cross-reference and supplier/user communication:
Recreation monitoring, duplicate-payment test, cause and closure:

Fill only the details relevant to your request

Before you send the request

Questions buyers often ask

What fields help find duplicate supplier records

Use authoritative identifiers where available plus explainable name, address, domain, contact, beneficiary-token, onboarding and creation-history comparisons.

Can two suppliers with the same bank account be merged

No. Shared banking can have legitimate or risky explanations. Verify legal entities, payee relationships and instructions through the approved process.

Should a duplicate supplier record be deleted

Usually preserve the retired ID and history, block new use and maintain a survivor cross-reference according to finance, legal and retention policy.

What must be checked before merging supplier records

Map every open and historical order, receipt, invoice, credit, payment, contract, user and integration, then test the controlled migration.

Keep the request specific

Similar supplier data is not proof that two records should be merged

Legal identity, tax status, beneficial ownership, sanctions, banking and retention rules vary by jurisdiction and relationship. Use qualified legal, tax, finance and security review. GLEIF data applies where an entity participates in the LEI system and is not a universal supplier approval. GAO and NIST sources provide public control examples, not private-company mandates. Protect tax, contact and bank data. Never merge beneficiaries or redirect payments from name similarity, and never delete history needed to explain prior orders or payments.

Send this checklist on WhatsApp

Editorial method

How this guide was prepared

MINJI separates candidate generation from identity proof and change authority. The audit preserves source values, uses explainable exact and near-match rules, verifies the legal and commercial relationship, maps every transaction dependency and retains retired history. GLEIF supports entity research where LEIs exist; GAO financial-system requirements and NIST controls support duplicate prevention, separated duties, audit records and controlled changes.

Ready with the key details

Discuss a wholesale request

Send the product reference, estimated quantity and destination so the conversation starts with useful context.

Continue on WhatsApp