Merging duplicate vendor records without losing payment history

A duplicate vendor record looks like a housekeeping problem until a payment, a tax form, or a reconciliation depends on it. Two records for the same supplier can split the payment history, create two 1099 totals, and make it impossible to see the real balance owed. The merge is therefore an identity and evidence decision, not a bulk cleanup of names that look similar. This report asks how a small bookkeeping team can find duplicate vendors and merge them without losing the history a reviewer needs. The unit is one vendor master record in a defined accounting system.

The output is a reviewed merge decision, a surviving identifier, a retired identifier, and a record of what moved. It is not a conclusion that every similar-looking vendor is a duplicate. The scope covers the accounts payable vendor master, the related transaction history, and the tax-form mapping for one entity. If the company uses several systems, each system needs its own mapping and a shared cross-reference.

A merge that works in the accounting system but leaves the procurement system pointing at the retired record creates a new problem. The protocol assumes the team can read vendor names, addresses, tax identifiers, bank details, and transaction history. It also assumes the team does not have authority to change the vendor's legal identity or tax classification. Those are client decisions, and the bookkeeper prepares the evidence for them.

Duplicates appear for ordinary reasons. A salesperson creates a record with the trading name while the invoice shows the legal name. A new clerk cannot find the existing vendor because the search is by exact name, so the clerk creates a second record. An acquisition adds the same supplier under a different remit-to address. The accounting software often makes the problem worse by allowing near-duplicates without a warning.

Some systems match on the first few characters, while others require an exact tax number. The result is a master file that looks clean in a list but fragments the payment history when the team searches for a supplier. The cost is not only administrative. A split vendor history can hide a duplicate payment, distort spend analysis, and produce two tax forms with amounts below a threshold that would have been met on a combined basis.

The risk grows when the team changes, because the next bookkeeper has no memory of why two records exist. GAO's internal-control standards emphasize documented transactions, assigned responsibility, and records that support review. A vendor master with two active records for one supplier weakens each of those points. The transaction record may be accurate, but the vendor identity behind it is ambiguous, so the reviewer cannot tell which history is complete.

Start with a written identity key rather than an informal sense that two records "look the same." A practical key combines the legal name, the tax identifier, the remit-to address, the bank account, and at least one stable external reference such as a contract or purchase order. No single field is sufficient, because names change and addresses move. Decide which fields are strong and which are supporting. A matching tax identifier plus a matching legal name is strong evidence. A matching phone number alone is weak, because a shared answering service can serve several legal entities. Write the ranking down so two reviewers reach the same conclusion on the same pair.

Record the evidence for each candidate pair. Include the source of each field, the date it was last confirmed, and whether the client or the vendor supplied it. A tax identifier copied from an old invoice may be stale, while one confirmed on a current W-9 is stronger. The identity key should also define what counts as a different vendor. Two legal entities under common ownership may share an address and a contact but require separate records for tax and liability reasons. The merge rule must allow a documented exception instead of forcing every shared attribute into a duplicate finding.

Export the full vendor master with the fields in the identity key. Do not rely on the accounts payable aging report, because it shows only vendors with open balances. A duplicate with no current balance can still distort tax reporting and spend analysis. Run a first pass that groups records by normalized name, tax identifier, address, and bank account. Normalization should remove punctuation, case, and common suffixes such as Inc or LLC, but it should not remove words that distinguish legal entities. Keep the original values next to the normalized values so the team can see what changed.

Review the candidate groups manually and classify each as confirmed duplicate, probable duplicate, shared-address entity, or not a duplicate. Write a short reason for each classification. A group that is left unclassified is not ready for a merge, and a count of raw name matches is not a duplicate count. Report the size of the population in a way that supports a decision. Useful measures include the number of candidate groups, the number of records in each group, the open balance affected, the payment volume, and the number of tax forms involved. This lets the client prioritize the groups that carry real risk rather than the groups that are easiest to merge.

The survivor is the record that will remain active after the merge. Choose it by the completeness and accuracy of its identity, tax, and payment history, not by which record has the most recent activity. A newer record may contain a cleaner address but no history, while an older record may hold years of payments and the correct tax identifier. Document the reason for the survivor in one or two sentences. "Survivor has the confirmed W-9, the active bank account, and the full payment history" is a usable reason. "Survivor is the one we use now" is not, because it does not explain what happens to the evidence on the other record.

Check whether the survivor has any attribute that the merge would make worse. For example, a survivor with an outdated remit-to address should be corrected before bills move to it. A survivor with a closed bank account should not receive new payment instructions until the vendor master change process is approved. The client's accounting owner should approve the survivor for any vendor with an open balance, a tax-form history, or a bank change. The bookkeeper can prepare the comparison and recommend a survivor, but the decision affects payments and reporting, so it belongs with the owner.

Merge in a fixed order: freeze new vendor creation, update the accounting system, update the procurement or expense system, then confirm the tax and payment mappings. Freezing new creation prevents a well-meaning colleague from adding a third record while the cleanup is underway. Before changing anything, export the retired record and its transaction history. Store the export with the merge record, including the record identifier, name, tax number, address, bank details, creation date, and last activity date. This export is the evidence that the retired identity existed and what it contained. In the accounting system, move open transactions first and confirm the total before and after the move.

Then move the historical references that the system allows, such as notes, attachments, and tax-form mappings. Do not assume that changing the vendor on an open bill also moves the original approval or purchase order reference. After the move, deactivate the retired record rather than deleting it. A deactivated record keeps the identifier available for old documents while preventing new postings. Record the retirement date and the merge reference in both records so a future search leads to the explanation.

Payment history is the part most likely to be lost. A merge that moves open bills but leaves cleared payments on the retired record produces an incomplete vendor history and a misleading spend total. Export the payment list before the merge, compare it with the vendor statement reconciliation, and reconcile the count and total after the merge. Tax history needs the same care. The IRS 1099 instructions require the payee name and taxpayer identification number to be consistent with the return that is filed. If the merge changes the legal name or tax number, the team should confirm the correct reporting identity with the client before the next filing season.

Keep a cross-reference from the retired identifier to the survivor. The cross-reference should be readable outside the accounting system, because a reviewer may not have access to the vendor master. A simple table with old identifier, new identifier, merge date, and approver is enough. Check the vendor's bank instructions after the merge. If the two records had different bank accounts, do not assume the survivor's account is current. Use the vendor master change process to verify any bank detail, including a callback through a known contact path rather than the contact information in the change request.

The review should confirm that the survivor is complete, the retired record is deactivated, the open items moved, and the payment and tax histories reconcile. It should also confirm that no new duplicate was created during the merge. Record the reviewer, the date, and the evidence location. The merge record should state what was not moved and why. Some systems cannot transfer attachments or audit comments, and some tax forms must remain under the original identifier. Naming those limits is more useful than implying a perfect consolidation.

The method has limits. It depends on the quality of the identity fields, so a vendor with a missing tax number and an old address may stay in the probable category for months. It also cannot detect a duplicate that uses two genuinely different legal entities or two different bank accounts with no shared identifier. The decision this protocol supports is a vendor-master quality decision, not a legal conclusion about the supplier. Used with that boundary, a merge record turns a messy cleanup into a reviewable change with a survivor, a retired identifier, and a payment history that still makes sense.