On this page Jump to section
Published November 3, 2026
Question and scope
When duplicate vendor records are merged in QuickBooks Online, do the vendor credits remain attached to the correct vendor, bills, and balances? A merge can clean up a cluttered vendor list while quietly changing the path between a credit and the bill it should offset. The result is a vendor balance that looks plausible but cannot be explained. This test asks whether the credit record survived the merge in a usable form. It does not decide whether the merge was appropriate or whether a credit is valid. Those questions belong to the accounting owner. The narrow purpose is to compare the pre-merge and post-merge records and identify where the link broke.
Population and unit
Start with a dated list of vendor merges completed during the review period. Record the surviving vendor, the merged vendor, the merge date, the person who performed it, and the source records that were combined. Keep the list stable and document any later correction. The unit is one vendor credit affected by the merge. A merge that touches ten credits has ten units, because each credit can behave differently. If a credit was applied to several bills, record each application separately while keeping the credit as the parent record. Exclude merges with no credits on either vendor, but record them as out of scope rather than as passes. A merge with no credits does not test the behavior this protocol is designed to observe.
Definitions and measures
A credit survives when it remains linked to the surviving vendor, the original credit amount and date are unchanged, and any prior applications still point to the correct bills. A credit is partially preserved when some fields remain but an application or balance link is missing. A credit is lost when it can no longer be found under the vendor or when its balance cannot be reconciled. For each credit, record the pre-merge vendor, the post-merge vendor, the original amount, the remaining balance, the applied bills, and the evidence link. Compare the pre-merge and post-merge states field by field rather than relying on a total balance. Also record whether the merge created a duplicate credit or left an orphaned application. Those side effects may not appear in the vendor balance and can surface later during bill payment or reconciliation.
Test design
Use a census when the number of affected credits is small. For a larger set, select a documented sample that includes open credits, fully applied credits, credits with multiple bill applications, and credits created close to the merge date. Freeze the sample before reviewing the records. Have one reviewer compare the records and a second reviewer check a subsample. Record disagreements before resolving them, because a difference in what counts as "linked" can change the result. Keep the original records and the comparison sheet separate from the live accounting file. Where the merge removed a record entirely, use the audit trail or an earlier export to reconstruct the pre-merge state. If no earlier record exists, mark the credit as unverifiable rather than assuming it was handled correctly.
Data quality checks
Confirm that the vendor identifiers in the credit record, the bill record, and the merge log agree. A credit that points to a vendor name rather than an identifier can appear correct while linking to the wrong record. Check the merge date against the credit dates to ensure the sequence is possible. Look for credits that were applied after the merge but before the review. A new application can make the credit look healthy while hiding an earlier broken link. Record the application date and the person who applied it, and preserve the original state where possible. Check the audit trail for deleted or edited credits. A deleted credit may leave less evidence than a reversed one, and the team should record that limitation rather than treating the absence as a clean result.
Interpretation limits
A surviving credit does not prove that the vendor balance is correct. The merge may have preserved the credit while changing the bill it offsets, or the credit may be valid but applied to the wrong period. Pair the survival test with a balance reconciliation before drawing a conclusion about the vendor account. A lost credit does not prove that the merge caused the loss. The credit may have been removed earlier, or the merge may have exposed a pre-existing duplicate. The test should describe the observed state and the evidence available, not assign fault without a complete trail. Avoid using the result to rank the person who performed the merge. The same merge can behave differently depending on the number of open credits, the age of the records, and the system version. The useful management question is whether the merge checklist includes a credit verification step.
Review cadence
Run the test after any vendor merge that affects open credits, and run a broader review at the next month-end close. A short check at the time of the merge catches the immediate break, while the close review catches patterns across several merges. End each review with a decision record: add a credit check to the merge procedure, require an export before merging, assign a reviewer for high-balance vendors, or leave the process unchanged. Name the owner and the recheck date. Archive the merge list, the comparison sheet, and the supporting records so a later reviewer can repeat the test. The value of the test is not a perfect survival rate. It is a repeatable way to see whether a cleanup step quietly changed a vendor balance before that change reaches a payment or a reconciliation.