List Reduction

What we merge and how the audit log works

Each merge moves every transaction off the duplicate name onto the survivor, deactivates the duplicate, and writes a single line to a structured CSV log capturing the duplicate, the survivor, the count of transactions moved, and the timestamp of the merge. The CSV ships alongside the .qbm so the cleanup is fully auditable. We never delete a duplicate outright — deactivation hides it from drop-downs without losing the historical record, which is the right posture for reviewers who may need to see the original name months later. Survivors are picked by activity volume and recency, with ties broken in favour of the legal-format name.

How inactive-name pruning is scoped

Inactive pruning runs on a configurable rule, which defaults to 'no transaction activity in the last three years and no current balance.' That threshold catches the long tail of customers and vendors who have not been touched in a decade without ever deactivating a name a reviewer might want to see. The rule is adjustable up to five years or down to two before processing starts; pre-purchase chat in the Portal walks through the right setting for your industry. Names that fail the rule are deactivated, never deleted, so the historical record stays intact and reactivation is a single click on your end.

Lists in scope and lists out of scope

List Reduction covers customers, vendors, items, accounts, employees, classes, and locations — the high-volume operational lists. It does not cover terms, payment methods, customer types, vendor types, or other configuration lists, because those are typically small enough to clean by hand and the merge consequences are different. The verification PDF reports before-and-after counts on every list in scope, so the deliverable is auditable line by line. If you need cleanup on the configuration lists, that is best handled inside QuickBooks directly with our Extended Support upgrade attached for the support-ticket coverage.

Will any historical transactions be deleted during list reduction?

No. The service is structurally incapable of deleting a transaction — every merge moves transactions from the duplicate to the survivor, and inactive-name pruning only deactivates names with no transaction activity matching the configured rule. The verification PDF gates delivery on a trial-balance match against the source file even though list reduction does not touch balances by design, specifically because we want the deliverable to document explicitly that no posting was changed. If a balance ever drifted during processing the file would not leave our environment.

How are duplicate-name candidates actually identified?

We run a deterministic similarity rule across each list — exact match after punctuation normalization, case folding, and whitespace collapse, plus a configurable fuzzy match for transposed characters and obvious typos. Every candidate is paired with the suggested survivor and the merge is run only after the structured CSV log captures the pairing. Names that look similar but represent different real-world entities (two different 'John Smith' customers in different cities, for example) are kept separate by default; pre-processing chat reviews any ambiguous cases your file flags.

Can I exclude specific names from the cleanup before processing?

Yes — pre-processing chat in the Portal lets you flag any names that should be excluded from both merging and inactive pruning regardless of activity history. Common exclusions include placeholder customers used for cash sales, vendor records used for one-time payments, and item records that are intentionally retained for historical reporting even though they have no recent activity. The exclusion list is recorded in the verification PDF so the deliverable documents not just what was changed but what was deliberately left alone, which reviewers appreciate.

Does the cleanup affect inventory quantities or reorder points?

No. Item-level merges keep the survivor's quantity-on-hand, average cost, and reorder configuration, and add the duplicate's posted transactions to the survivor's history without changing any quantities. The verification PDF reports per-item quantity-on-hand against the source file as a separate gating item, so any drift would block delivery. If your reorder points need adjustment after the cleanup we recommend doing that inside QuickBooks once the new list shape is in front of you, since the right reorder level depends on the new aggregated history.