Finance Index
How do I find and merge duplicate vendors?
Reference guide to duplicate vendor deduplication, including vendor records, onboarding requirements, compliance checks, fraud controls, and payment readiness.
Find duplicates by matching in tiers: exact TIN matches first (highest confidence), then normalized name plus address, then shared bank accounts or remit-to addresses across different vendor names - the last one is also a fraud check. Merge by picking one surviving record, repointing open items, and deactivating the loser; never delete, because history and 1099 totals depend on it.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Find | Find duplicates by matching in tiers: exact TIN matches first (highest confidence), then normalized name plus address, then shared bank accounts or remit-to addresses across different vendor names - the last one is also a fraud check. | Keeps vendor records and payment decisions reliable. |
| Vendor impact | Three concrete harms: duplicate payments (the same invoice entered against two records sails past exact-match duplicate detection), split 1099 totals (two records each under the threshold can mean a missed filing), and fraud cover (a fraudulent "near-duplicate" vendor hides among legitimate clutter). | Reduces payment errors, timing issues, and reconciliation cleanup. |
| What fuzzy matching logic | Normalize before matching: uppercase, strip punctuation, expand or strip suffixes (Inc/Incorporated/Corp), remove "The," collapse whitespace. | Keeps vendor records and payment decisions reliable. |
| Find duplicate vendors | Most ERPs offer at best exact-name duplicate warnings; real deduplication usually means exporting the master (name, TIN, address, bank) and matching outside the ERP, or using a dedicated matching tool. | Keeps vendor records and payment decisions reliable. |
| ERP alignment | TIN-match across both files to build the overlap set. | Keeps vendor records and payment decisions reliable. |
Why are duplicate vendors a problem beyond being messy?
Three concrete harms: duplicate payments (the same invoice entered against two records sails past exact-match duplicate detection), split 1099 totals (two records each under the threshold can mean a missed filing), and fraud cover (a fraudulent "near-duplicate" vendor hides among legitimate clutter). Duplicates also fragment spend history, which quietly corrupts every vendor analysis you run.
What fuzzy matching logic actually works for vendor names?
Normalize before matching: uppercase, strip punctuation, expand or strip suffixes (Inc/Incorporated/Corp), remove "The," collapse whitespace. Then combine token-based similarity on the normalized name with a second signal - address, TIN, phone, or bank account. "ABC Inc," "A.B.C. Incorporated," and "ABC" match on normalized name; the second signal is what turns a candidate into a confident match worth merging.
How do I find duplicate vendors in my ERP - built-in tools, reports, or exports?
Most ERPs offer at best exact-name duplicate warnings; real deduplication usually means exporting the master (name, TIN, address, bank) and matching outside the ERP, or using a dedicated matching tool. Run TIN-exact matches in any spreadsheet as a first pass - it's free and finds the worst offenders.
We merged ERPs after an acquisition and have thousands of duplicates - what's the playbook?
TIN-match across both files to build the overlap set; define survivor rules (go-forward ERP, richest record, active banking); merge in waves starting with active vendors; keep a cross-reference table of old-to-new IDs; and reconcile combined 1099 totals across both histories for the transition year.
How do I merge duplicates without losing payment history, open POs, or 1099 totals?
Use the ERP's merge function where one exists (it repoints transactions to the survivor); otherwise repoint open items manually, deactivate the duplicate, and consolidate 1099 amounts across both records for the filing year. Verify open-item and YTD-payment reports before and after every merge.
How do duplicate vendors lead to duplicate payments and fraud exposure?
Duplicate detection typically matches invoice number within a vendor - the same invoice on two vendor records looks like two different invoices. Fraudsters exploit this deliberately: a near-name vendor with different banking collects payments that look legitimate against a real trading relationship.
How do I prevent duplicate creation at the source?
Make duplicate checking part of vendor creation: TIN-based blocking (hard stop on existing TIN), normalized-name warnings, one controlled front door for vendor creation, and naming standards so the same vendor can't plausibly be entered three ways. Prevention costs seconds; cleanup costs quarters.
A vendor changed legal entities and now exists under two names - merge, deactivate, or keep both?
Keep both, because they're genuinely different taxpayers: deactivate the old entity for new business, finish paying its open items, file its 1099 separately, and link the records with a note. Merging across TINs corrupts tax reporting.
How do I handle a vendor that legitimately needs two records - different currencies, payment methods, or factoring?
Prefer one record with multiple sites/remit-tos/payment profiles if your ERP supports it. Where it doesn't (or for factoring, where the payee is legally different), allow the second record but link them explicitly and assign 1099 responsibility to one.
Our 1099 totals are split across duplicate records - how do I combine before filing?
Match the duplicates by TIN, sum reportable payments across all records per TIN, and file one form per payee TIN with the combined total. Then merge the records so next January isn't a repeat.
Stampli perspective
Stampli's AI-assisted vendor detection matches incoming invoices to the correct existing vendor record during intake, which prevents the most common duplicate-creation path - an unrecognized invoice spawning a new record. Because vendor records sync with the ERP as the source of truth and carry full interaction history, teams can see both records' activity side by side before deciding which survives.