Why you have duplicate customers in QuickBooks

Open the customer list in QuickBooks Online at a company that syncs from Stripe or a CRM, and you'll usually find some version of this:

Acme Inc.
Acme Inc. 2
Acme, Inc.
ACME Incorporated
acme

Five records, one company, invoices scattered across all of them. AR aging is wrong, the customer statement is wrong, and nobody can say which record is real.

There are three causes. They produce slightly different wreckage, so you can tell them apart.

Cause 1 — matching on email when the emails are different people

This is the most common, and it's a design error rather than a bug.

Your CRM holds a Contact: the person who bought. Your billing system holds a Customer: the inbox that receives invoices. At a company of any size those are not the same address. priya@acme.com signed the contract; ap@acme.com or invoices@acme.com pays the bills. An integration keyed on email sees two different addresses, concludes two different customers, and creates a second record.

How to spot it: the duplicates have different email addresses and near-identical names. Often one record has all the deals and the other has all the invoices.

The fix: match on company domain, not on email address. priya@acme.com and ap@acme.com share acme.com, and domain is stable in a way that a billing contact isn't. Then plant an explicit id — write the CRM company id into a Stripe metadata field and into a QuickBooks custom field at creation — so the second sync never has to guess again. Guessing is fine once; guessing every night is how you accumulate five records.

Domain matching has one known failure: personal-email customers (gmail.com, outlook.com) and any shared domain. Exclude free email domains from the match and fall back to exact email for those.

Cause 2 — create-before-search

Zapier's "Create Customer in QuickBooks" step does what it says. It creates. Unless the automation explicitly searches first and branches, every run produces a new record.

This bites hardest on webhook retries. A webhook that isn't acknowledged fast enough gets redelivered — that's the documented behaviour of every provider in this chain, not an edge case — and the second delivery runs the same create.

How to spot it: the duplicates are identical in every field, often created seconds or minutes apart. QuickBooks enforces uniqueness on DisplayName, so you'll either see failed runs in the automation's history or names with a numeric suffix where something appended a character to get past the constraint.

The fix: search first, create only on a miss, and make the whole operation idempotent — key it on something the destination can enforce, and check for an existing record before writing. "Search then create" in two separate automation steps is still racy if two events arrive at once; the check and the write need to be one operation with a lock or a unique constraint behind it.

Cause 3 — two writers, no agreed owner

Someone set up a Stripe→QuickBooks sync. Someone else, later, set up a CRM→QuickBooks sync for a different reason. Both create customers. Neither knows about the other.

How to spot it: duplicates with different formatting conventions — one set with legal suffixes ("Acme, Inc."), one set without, because the two source systems store the name differently. Check the created-by metadata if your tools record it; the two groups will have different origins.

The fix: this one isn't technical. Decide which system is the source of truth for customer records and turn the other writer off. If both genuinely need to write, decide a precedence rule and apply it in one place. The decision matters more than the implementation: pick CRM if sales creates accounts before they're billable, pick billing if customers can self-serve without ever touching the CRM.

Cleaning up what's already there

Merging in QuickBooks Online works by renaming: give the duplicate the exact DisplayName of the survivor, and QuickBooks offers to merge. It's irreversible, and it moves transactions to the survivor. Three cautions:

• Sub-customers and parent records behave differently — a customer with sub-customers can't merge the same way.
• Merge into the record with the longest transaction history, not the newest. Less to move, less to go wrong.
• Fix the cause before you clean up. Merging while the sync that created the duplicates is still running just means you do it again next month.

Before merging anything, export the customer list and the open invoice list. You will want the before-state.

The part worth internalising

All three causes are the same failure at different layers: nobody decided what identifies a customer. Email, domain, name and id are four different answers, and when two systems pick different ones, you get duplicates as a mathematical certainty rather than a bug.

Decide the key once. Write it down. Plant it as an explicit field at creation so nothing downstream has to infer it. Everything after that is just making sure both sides read the same field.

TruelineHQ asks who owns the customer record before it connects anything, then keeps the key planted on every write. See the five questions.