On this page Jump to section
Question and scope
When two customer records are merged in QuickBooks Online, do the attachments from both records remain reachable from the surviving customer? The scope is one business's customer merges during a defined review window, not a general promise about how every QuickBooks file behaves. The test checks attachment reachability, not whether the merge decision itself was correct. It also separates a file that moved with a transaction from a file that was attached only at the customer level. The narrow purpose is to show whether the evidence a reviewer expects to find is still there after the merge.
Why a customer merge is an evidence event
A customer merge is usually treated as list cleanup, but it can also move transactions, open balances, notes, and attachments between records. The merge may look successful because the duplicate disappears and the new name appears on the invoice list. That visible result does not prove the supporting documents followed the transactions. A missing attachment can surface months later when a dispute or a refund review needs the original proof. Treating the merge as an evidence event makes the attachment check part of the change, not an afterthought.
Population and unit
Start with a dated list of customer merges completed during the review window. Record the surviving customer reference, the merged customer reference, the merge date, the person who performed it, the open balance before the merge, and the attachment count on each record before the change. The unit is one merge event, not one attachment, because the decision applies to the pair of records. A merge reversed and repeated stays one unit but needs separate evidence rows for each attempt. Exclude duplicate records that were simply renamed without a merge and record that exclusion.
Freeze the list before opening the customer files. If an attachment is added after the merge, keep the first observation and add a dated note about the later file. A moving list makes it too easy to count only the attachments that were easy to find. Use internal customer references instead of names in the working sheet, and store the source export beside the test notes. The frozen list is the evidence that the test covered a defined set of merges rather than a convenient example.
Definitions and measures
An attachment survives when a reviewer can open it from the surviving customer or from a transaction that now belongs to that customer. Record the attachment name, type, source record, destination record, and the path used to reach it. Reachability and readability are separate measures, because a file can appear in a list and still fail to open. Also record whether the attachment was linked to the customer profile or to an invoice, bill, or payment. The link type matters because a merge can preserve one path while losing another.
Capture the attachment count before and after the merge, plus the count of files that open successfully. If a file is reachable only through a search result or an old browser link, mark it as a weak path rather than a clean survival. Record whether the merge moved open transactions and whether any transaction kept the old customer reference. A reviewer needs that context to explain why one attachment is easy to find and another is not. The measures should let the team see both the count and the quality of the path.
Test design
Use a census when the number of merges is small, and a documented sample when the list is large. Include at least one merge with an open invoice, one with an unapplied payment, and one with a customer-level attachment that is not tied to a transaction. Include merges performed by different people if more than one person can merge records. Freeze the sample before opening the surviving customer and compare the before list, the after list, and the transaction links. Have a second reviewer recheck a subsample and record disagreements before the team resolves them.
Record why each merge happened, because a duplicate created by a misspelled name behaves differently from a duplicate created by two sales channels. A merge that clears an old duplicate with no activity is a weak test, since there may be nothing to move. Prefer merges that carry at least one transaction or one attached file. If the sample contains only empty duplicates, say so and treat the result as a list-cleanup check rather than an evidence test. The reason for the merge is part of the population definition, not a side note.
Data collection
Use the customer record, the attachment list, the audit log, and the transaction detail as the source set. Capture the attachment names and the date each file was added, not just the current count. If QuickBooks does not show a clean before-and-after view, export the attachment list before the merge and keep that file with the test notes. Mark reconstructed values and name the person who rebuilt them. Do not overwrite the original export when adding analysis columns, because the original list is the evidence of what existed before the change.
A worked example
Suppose a business merges a duplicate customer into the main record after an owner notices two open invoices. The duplicate had a signed estimate attached to the customer profile, while the main record had the invoice and the payment history. After the merge, both invoices appear under the main customer and the open balance is correct. The estimate, however, no longer appears on the customer profile and cannot be found from the invoice. The reviewer records a clean balance result but a failed attachment path.
A second case may keep the estimate but lose the payment attachment that was linked to the old customer record. The customer balance still looks right because the payment moved, but the proof of payment is missing from the new path. The test should report these as separate failures rather than averaging them into one score. It should also note whether the old customer record still exists in any searchable form. That detail tells the team whether recovery is possible or whether the file must be recreated from another source.
Evidence standard
Each row needs the pre-merge attachment list, the post-merge path, the transaction references, and the source of each observation. Keep the customer-facing documents in the approved system and use internal references in the working file. If an attachment had to be re-uploaded after the merge, retain both the original evidence and the replacement and record why the replacement was needed. Protect personal information and bank details by restricting access to the evidence folder. A test that cannot show the before list cannot prove whether an attachment survived or was simply added later.
Store the evidence with the merge date and the name of the person who performed the merge. Include the search terms used to look for a missing file, because a failed search is not the same as a missing attachment. If the file is found through a transaction but not through the customer profile, record both paths and mark the profile path as incomplete. Add the reviewer's name and the date of the check. That small amount of context turns a collection of screenshots into a repeatable evidence standard.
Interpretation limits
A missing attachment does not always mean the merge deleted it. The file may have been attached to a different record, stored outside QuickBooks, or removed before the merge. A surviving attachment does not prove the merge was safe, because the file may be readable but linked to the wrong customer or the wrong transaction. Pair this test with a review of open balances, duplicate payments, and customer complaints after the merge. Report the file version, the merge method, and the user who performed it so the result is not overread.
Review cadence
Run the test after any change to customer merge permissions, attachment storage, or the onboarding cleanup process. A quarterly cadence is usually enough for a stable customer list, while a monthly check fits a business that merges records often. Keep the same attachment categories and the same sampling rule so results can be compared. If the process changes, record a new baseline instead of mixing old and new definitions. End with a named owner, a specific repair, and a date to retest the next merge.