What it means
Finance systems store the identity and payment terms of each supplier, and a company may accidentally create another entry when a name, address or contact changes. That duplicate can make invoices and credits harder to see together.
Oversight describes risks from duplicate vendor-master data, including payment visibility, and the Washington State Auditor warns about protecting vendor files from fraud; those sources support review and verification, not a claim that every duplication is fraudulent. Begin with legal identity by comparing registration numbers, tax identifiers, established contacts and the contractual party, because names alone can mislead when related companies share branding.
Duplicate records can arise after migration, an acquisition, a spelling correction or a department creating a new account without searching first, so understand the cause before changing records. Payment details need stronger verification, as the same bank account across records can be a clue, not proof of common ownership, and a changed account can be legitimate or suspicious, so use independent trusted contact routes.
Look at transaction history, since one record may hold purchase orders while another holds invoices, hiding a full picture of commitments, and an unpaid credit may be overlooked. Duplicates can also weaken duplicate-invoice checks if the system compares invoice numbers only within one vendor ID, so a bill entered under two IDs might pass a narrow automated check and cross-record payments should be reviewed.
Do not automatically merge, because two records may represent different currencies, legal entities or approved remit-to arrangements, and a cleanup that combines them wrongly can misstate taxes and send money to the wrong party. Create a controlled decision of confirmed duplicate, distinct supplier, or unresolved, and record the evidence, approver and actions.
Keep suspected records on review without blocking legitimate payments indefinitely, and leave unverifiable records open with an assigned owner rather than deleting them. For confirmed duplicates, designate the active record, map the retired ID to it and preserve order, invoice, tax and audit history, because inactivation is usually safer than erasing old entries.
Check open items before inactivation, since unpaid bills, unapplied credits and pending orders can be stranded and should be reconciled under approved accounting procedures. Review permissions and separate vendor creation, sensitive changes and payment approval where practical, because an unchecked user who can create a duplicate and approve a payment creates avoidable risk.
Search controls can prevent recurrence using normalised names, legal identifiers and address comparisons, but fuzzy similarity should not trigger auto-merging because human review is needed for consequential matches. Track duplicate candidates and verified resolutions, because the percentage of suspected matches is not the percentage of confirmed errors and both numbers should be reported honestly.
Supplier communications should be neutral, asking for entity information if needed without disclosing unrelated account details, and a look-alike inbound message is not authority to change payment instructions. Review high-risk changes, such as a record created just before a large bill, before the next payment run, and reconcile identity before drawing spend conclusions, since splitting one supplier across IDs can understate concentration while a mistaken merge can overstate it.
In practice
Real-world examples.
Example
One supplier appears under a legal name and an abbreviated name after a spelling correction. A fictional AP clerk refuses to rely on a new email's bank instructions while reconciling the two vendor IDs. She uses the existing vendor contact to confirm the details before any payment.
Example
A fictional supplier resends an invoice to a different branch, and it is entered under a second vendor ID. AP checks the underlying delivery and both master IDs before paying. The same bill is therefore not paid twice, even though a narrow check on one ID would have missed it.
Example
Finance retires a verified duplicate while preserving history. A fictional controller marks the older record inactive and retains a cross-reference for past reports. Before doing so, the company finds a supplier refund still owed on the record it planned to retire and moves it to the active ID.
Formula
Calculation
Illustrative verified duplicate rate = confirmed duplicate records / active supplier records reviewed x 100%; suspected matches are separate.
Worked example. A fictional team reviews 2,000 active supplier records, flags 60 as suspected duplicates and verifies 24 of them as true duplicates.
- Verified duplicate rate: 24 / 2,000 x 100% = 1.2%
- Suspected rate: 60 / 2,000 x 100% = 3%
- Reporting only the 3% would overstate the confirmed error, because the other 36 flagged records were distinct suppliers or remain unresolved.Case study
Seen in the real world.
In this fictional case, Cedar Works finds two vendor IDs with similar names and the same registration number. AP checks the original contract and known supplier contact, then verifies the records refer to one legal entity. Finance reconciles open bills and credits, designates one active record and retains the other for history. It separately checks whether an invoice was entered twice. The fictional system also flags "Cedar Ltd" and "Cedar Limited" for review rather than combining them automatically, and a controller spots a new vendor ID created on the same day as an unusually large invoice.
Both items go to a human reviewer with the evidence recorded. A fictional group with two subsidiaries named after the same brand keeps both records because each is a valid separate payee. The goal is a trustworthy supplier identity trail. A duplicate vendor record should be resolved with evidence and controlled changes, not a quick name-based deletion.
Watch out
Common mistakes.
- Merging similar names without verifying legal identity.
- Deleting a record before reconciling open items.
- Assuming every flagged pair proves fraud.
Questions
People also ask.
Are identical names proof of duplication?
No. Check the actual legal entities and payment relationship.
Why can duplicates cause payment errors?
They can split invoice and credit history across IDs.
Should the older record be deleted?
Usually preserve its history and use a controlled inactivation.
From the founder's library
Take it further with the book.
Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.
25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.
View the book and save 25%