Research question: when two duplicate QuickBooks Online customer records are merged, do the open invoices and their balances follow the surviving record without changing amount, due date, or aging?

Testing Whether a QuickBooks Online Customer Merge Preserves Open Accounts Receivable Balances

A bounded test for whether merging duplicate customers in QuickBooks Online preserves open accounts receivable balances, with a defined population, evidence standard, and interpretation limits.

Testing Whether a QuickBooks Online Customer Merge Preserves Open Accounts Receivable Balances research thumbnail
On this page Jump to section

Question and scope

When two duplicate customer records are merged in QuickBooks Online, do the open invoices attached to the retired record move to the surviving record with their balances, due dates, and aging intact? The scope is one company file and a defined set of merges completed during a review window. The test compares the accounts receivable position before and after each merge at the invoice level, not only at the customer profile level. It does not decide whether the merge was commercially appropriate, because that depends on the customer relationship and the billing history. The test shows whether the accounting record survived the merge in a form a reviewer can verify.

Why a merge needs its own test

A customer merge looks like an address-book cleanup, but it changes the record that owns every transaction. If an open invoice is left on the retired record, the aging report may still show the balance while the surviving customer shows nothing. A team that checks only the merged profile can conclude the cleanup worked and still miss an invoice that no longer follows the customer. The receivable is the part that matters for collection, so it needs a separate observation.

The merge also interacts with payments, credits, and attachments. A payment applied to an invoice on the retired record may move with the transaction, or it may be reapplied in a way that changes the open balance. Attachments and notes may follow one record and not the other. Testing the receivable in isolation keeps the review from attributing a payment problem to the merge or a merge problem to the payment. The test records each layer separately.

Population and unit

Start with a dated export of customer records merged during the review window. Record the surviving customer reference, the retired customer reference, the merge date, the person who performed the merge, and the reason recorded for the duplicate. The unit is one merge paired with the open invoices that belonged to either record before the merge. A merge with several open invoices needs one row per invoice so a partial move is visible. Exclude merges with no open balance and record the exclusion so the population can be rebuilt.

Freeze the list before opening the customer history. If a merge is reversed or repeated during the test, keep the first observation and add a dated note rather than replacing the earlier state. A moving list makes it too easy to select only the merges that already show the expected balance. Use internal customer references in the working file instead of names, emails, and addresses. Store the export with the test notes so another reviewer can retrace the exact population.

Definitions and measures

A preserved balance means the invoice remains open after the merge, with the same amount, due date, and invoice number, and now belongs to the surviving customer. Record the open balance before and after as separate observations, and record the customer reference attached to each invoice at both points. Do not treat the absence of a duplicate invoice as proof of preservation, because a merge can leave the original invoice untouched and simply detach it from the active customer list. The measure should let a reviewer compare the invoice, the customer, and the aging report side by side.

Also record whether the merge changed the aging bucket. An invoice that stays open but moves from current to 30 days past due after the merge may indicate a due-date change rather than a balance change. Capture the report run date and the accounting period so a period cutoff does not look like a merge effect. Keep the measure at the invoice level, because a customer-level total can hide one missing invoice behind another invoice that was duplicated. The unit is the merge-invoice pair, not the customer total.

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 a single open invoice, one with several invoices across different aging buckets, one with a partial payment, one with an unapplied credit, and one where the retired record held the only open balance. Include a merge completed in the current open period and one from a closed period if both exist. Freeze the sample before opening the receivable reports and compare the customer list, the invoice list, and the aging report in that order.

Document how the sample was selected and which merges were left out. A sample built only from the largest balances will miss the routine duplicates that create most of the cleanup work. If the business uses projects or classes, include a merge where the invoices carry different project assignments. Record whether the merge was done through the customer screen, an import, or a third-party app, because the entry point can change which related records move. The selection note is what lets a later reader judge whether the result applies beyond the tested rows.

Data collection

Use the customer list, the open invoice list, the accounts receivable aging report, and the audit log as the source set. Capture the customer reference, the invoice number, the original amount, the open balance, the due date, and the merge date. Export the invoice list and the aging report before the merge when possible, and keep that file even if the merge is later reversed. Mark any reconstructed value and name the person who reconstructed it. Do not overwrite the original export columns when adding analysis fields, because the original values are the evidence.

Save the supporting files in one folder keyed by the merge reference. Include the before-and-after customer records, the invoice list, the aging report, and any customer message that explains why the records were treated as duplicates. If the merge was part of a bulk cleanup, record the batch reference and the time it was completed. A reviewer should not have to search across the customer list and the audit log to reconstruct one merge. The folder can be small, but it must let another person follow the same path without asking the preparer what happened.

A worked example

Suppose a business merges two records for the same customer, one holding three open invoices and the other holding a single unpaid balance. The merged profile shows the combined contact information, but one invoice may remain attached to the retired reference. The reviewer records the invoice number, the open balance, the due date, and the customer reference before and after the merge. That sequence shows whether the balance followed the surviving record or merely disappeared from the active list.

A second case may show the opposite pattern. All four invoices move to the surviving customer, but a partial payment that was applied to one invoice is reapplied to a different one, changing the open balance on both. The reviewer should report the payment reapplication as a separate event rather than treating it as proof that the merge preserved the receivable. These examples show why the test records the invoice, the payment, the aging report, and the audit log as separate observations.

Evidence standard

Each row needs the customer record before and after, the invoice list before and after, the aging report view, and the source of each value. Keep the merge approval with the internal record so the reviewer can see who authorized the change. If the merge was reversed, retain both the original and the reversal and record the dates. Protect customer details by using internal references in the working file. A test that cannot show the original invoice and the original balance is only a recollection of the merge.

Interpretation limits

A balance that stays the same may reflect a correct merge rather than a failure to consolidate, especially when only one of the duplicate records held open invoices. A balance that moves may reflect a payment reapplication, a credit application, or a due-date edit, not only the merge. A clean aging report does not prove the customer record is correct, because the merged profile may carry the wrong contact or payment terms. Pair this test with a review of the merge approval and a comparison of the customer statement. Report the merge method, the record type, and the report used so the finding is not overread.

Review cadence

Run the test after any change to the merge process, the customer import, or the accounts receivable workflow. A quarterly check fits a business with stable customer records, while a monthly check may be needed during a cleanup or a system migration. Keep the sample rule and the definitions stable so two periods can be compared. If the merge process changes, record a new baseline instead of mixing the old and new methods. End the review with a named owner, a specific repair, and a date to retest; for related evidence, compare the customer attachment merge test and the accounts receivable aging review.

Sources