How to merge duplicate vendors in bookkeeping

To merge duplicate vendors in bookkeeping without losing history, group the vendor list by fuzzy name match, pick the survivor in each group (the record with the W-9 and the correct legal name), merge the rest into it many-to-one so every transaction is reassigned and nothing is deleted, and then fix the categorization rules so the next transaction lands on the survivor. Done in that order, a 450-vendor list becomes 180 real vendors in an afternoon, with every transaction still attached to a name and the 1099 totals correct for the first time.

We run an accounting firm, and the vendor list is the first thing we look at on a new file, because it predicts how the categorization went. Here's where duplicates come from, why they matter more than they look, and how we clear them.

Where duplicate vendors come from

Nobody creates a duplicate vendor on purpose. They arrive four ways.

Feed descriptions. The bank sends "AMZN Mktp US*2K4T7," then "AMAZON.COM*MK3L9," then "Amazon Prime." A bookkeeper coding line by line creates a vendor from each, or the ledger's auto-add does it for them. One retailer, nine vendor records.

Receipt OCR. A document tool reads the receipt and creates a vendor from the printed name: "Home Depot #4471" on one receipt and "THE HOME DEPOT" on the next. Each receipt with a slightly different header is a new record.

Imports. A migration from another ledger, or a year of bills imported from a spreadsheet, carries in a vendor list that doesn't match the one already there. "ABC Supply Co." meets "ABC Supply Company" and both survive.

Staff turnover. Three bookkeepers over four years, each typing the electrician's name from memory: "Mike's Electric," "Mikes Electric LLC," "M. Rodriguez Electric." All correct, all different, all reportable on a 1099.

A file that's been through all four has a vendor list two to three times the size of the real vendor population, and the surplus isn't cosmetic.

Why duplicates are a categorization problem, not a tidiness problem

Every duplicate vendor is a place for the next transaction to go wrong.

Categorization rules are built on payees. If the electrician exists three times, the rule that codes him to Repairs was written for one of the three, and the other two land in Uncategorized or get coded by hand to whatever the bookkeeper picks that day. The same vendor ends up in Repairs, Contract Labor, and Maintenance across the year, and the P&L can't say what electrical work cost.

1099 totals are per vendor. The electrician paid $1,400 under one name, $900 under the second, and $1,100 under the third crossed the $2,000 threshold for 2026 payments and got no form, because no single record did. Or he got three forms, each wrong. The W-9 is attached to one of the three records, and the January report checks the other two and flags them as missing.

Vendor reports are useless. "Top vendors by spend" shows Amazon in fourth, sixth, and eleventh place instead of first. The owner asks what they spent with the supply house and the answer is a manual sum across four names.

And the duplicates breed. Each new bookkeeper sees three versions, can't tell which is right, and creates a fourth. The vendor list is the memory of the file, and a corrupt memory produces corrupt coding forever.

Duplicate transactions: the check also entered as an expense

Duplicate vendors usually travel with duplicate transactions, and the merge is the moment to find them. The patterns:

• A check written to the electrician, entered as a bill and bill payment under "Mike's Electric," and again from the bank feed as an expense under "Mikes Electric LLC." Two expenses, one check.
• A deposit recorded from the invoice payment and again from the feed.
• A vendor bill paid once in reality and twice in the books because it was entered under two vendor names.

After the merge, all of those sit under one vendor, and a sort by date and amount shows the pairs. Before the merge they're invisible, because the two halves are under different names. That's the reason the cleanup sequence puts the vendor merge in the duplicates step, before categorization: a transaction categorized in week one that turns out to be a duplicate in week three is work done twice.

When to merge versus when to inactivate

Not every near-match is a duplicate, and the decision is a judgment.

Merge when the records are the same legal entity: the same electrician, the same supply house, the same Amazon. All history reassigns to the survivor, and the survivor is the record with the W-9, the correct legal name, and the right 1099 classification. If none of the records has a W-9, the survivor is the one with the most accurate legal name, and the W-9 request goes out that day.

Don't merge when the names look alike and the entities aren't: "ABC Supply" the local hardware store and "ABC Supply Co." the regional distributor with a different TIN. Two vendors, two 1099s if applicable, and the fix is to rename them so nobody confuses them next year.

Inactivate rather than merge when the vendor is genuinely gone (the landscaper the client stopped using in 2023) and there's no duplicate; the history stays, the name drops out of the pick list, and the rules referencing it are retired.

Split in the rare reverse case: one vendor record that's been catching two different payees because a rule was written too broadly. That's the "PAYPAL *" rule that swallowed every PayPal merchant into one vendor, and the fix is narrower rules and a re-code.

Merging is not deleting. A many-to-one merge reassigns every bill, payment, expense, and document from the merged records to the survivor and keeps the merged names as aliases so the feed's next "AMZN Mktp" lands on the right vendor. Nothing leaves the ledger, and the audit trail shows the merge.

The 450-vendor example

A restaurant group's file arrived with about 450 vendor records for four entities that between them used maybe 180 real vendors. The list had been built by three bookkeepers, two receipt tools, and one migration.

The method: run a fuzzy-name grouping across the list, which produced about 120 groups of two or more. Review each group in an afternoon, picking the survivor (the one with the W-9, or the correct legal name) and confirming the members were the same entity. About a dozen groups were false matches and were left alone. Merge many-to-one, group by group. Then sort transactions under each survivor by date and amount, which surfaced about forty duplicate transactions, most of them checks entered as bills and again from the feed.

Then the rules. Each survivor got one rule with its account and its class, replacing the three or four partial rules that had been written for the duplicates. The next month's feed coded to the right vendor without anyone touching it, and the 1099 report in January showed one total per contractor, several of which crossed the threshold only when the pieces were combined. The group's four years of books closed in under ten hours of staff time the week before the September deadline, and the vendor merge was the step that made the categorization step short. The rest of that sequence is in a bookkeeping cleanup is a sequence, not a project.

Where the platform comes in

Woven is our product, and the duplicate finder and vendor merge in it were built for exactly the file above: it groups vendors and customers by fuzzy name match, shows each group with the W-9 status and legal name so the survivor is obvious, merges many-to-one with every transaction and document reassigned and the merged names kept as aliases, and leaves the audit trail intact. Categorization rules carry the vendor, so after a merge the next feed line lands on the survivor. The same tool folds the vendors that receipt OCR created back into the real ones. To see the duplicate finder on a live vendor list, book a demo.