One customer, two records: where duplicates come from and what they cost
The customer got the same email twice, addressed slightly differently. One version had their new phone number, the other had the address they moved away from. Their invoice went to one of the two, and which one was not a decision anybody made.
There are now two of them in your system, and every process you run has to pick one without knowing the other exists.
This is a different fault from two systems disagreeing about what belongs in a field. That one produces a wrong value in one record. This one produces two records, both plausible, splitting a person's history down the middle.
Every system recognises people by a different field
Duplicates are not sloppiness. They are the predictable result of two systems being given different definitions of "the same person" and both applying theirs correctly.
HubSpot documents its rule plainly: contacts are automatically deduplicated using the Email property, while companies are deduplicated on the primary value of the Company domain name property. Two objects, two different keys, inside one product.
Stripe takes a different position entirely. Email is not a unique identifier there, and the documentation for the customer portal describes what happens when several customers share one: the portal selects the most recently created customer that has both that email and an active subscription. Not an error, not a prompt — a rule, applied silently.
Put those two side by side and the mechanism is obvious. Send a person through a process that touches both, and one system will decide they are the same as an existing record while the other decides they are new. From that moment the history is split, and neither system has done anything wrong by its own rules.
The everyday version needs no integration at all: a customer who books with the address on their phone and pays with the one on their laptop, a spouse booking on someone's behalf, a person whose work email became their personal one.
The import that quietly doubles everything
The single most common way a small business acquires hundreds of duplicates in an afternoon is an import, and HubSpot's documentation states the mechanism without drama: if you "include the Record ID column in your import file, any rows without a value for Record ID will create new records."
That is the whole trap. A spreadsheet exported from one place, edited by hand, with a few rows added at the bottom for the new customers — those new rows have no Record ID, so they arrive as new records. So does every row where the ID got lost to a copy-paste, a column shift, or the sort that moved values away from their headers.
The import reports success. It was successful. It did exactly what the file asked.
Some duplicates can never be merged
Most systems offer a merge, and it is easy to assume this is a chore rather than a problem. It is worth knowing where that assumption breaks.
Stripe's answer to whether two customer records can be combined is one sentence: "Unfortunately, Stripe does not support merging Customers." Its recommendation is not a fix but a coping strategy — identify the record "with the most relevant data (for example, most recent payment method, additional details such as name and address)" and use that one going forward.
Sit with what that means for the system your money runs through. The payment history stays split. The saved cards stay split. The subscription is attached to one of them permanently. Everything you might later want to answer — what has this customer spent, are they still active, which card is on file — has two answers, forever, and the reconciliation is manual every time.
That is why prevention matters more here than cleanup. Stripe's own advice is to create customers only when required rather than always, and to look up existing records before making new ones — advice that only helps before the duplicate exists.
"Find or create" is doing more creating than you think
Most no-code automations that touch customer records use some version of the same step: look for a record matching this value, and if there is not one, make it. It reads as safe. It is safe only to the degree that the lookup matches the way a human would.
Three ordinary things defeat it. The value arrives formatted differently — a trailing space from a pasted cell, a different capitalisation, a phone number written with the country code this time and without it last time. The lookup searches one field while the duplicate differs in that exact field, which is the case whenever somebody uses a second email address. Or two runs happen close enough together — a form submission and a payment a few seconds apart — that both look, both find nothing, and both create.
None of these produce an error. The automation reports success, because creating a record is a successful outcome of a step whose job includes creating records. You find out later, from the customer, or from a number that looks better than it should.
Before trusting a find-or-create step, it is worth asking what it searches on, whether that field is the same one the destination system uses as its identity key, and what happens when the search finds two.
What duplicates actually break
The visible symptom is the smallest part.
The customer notices first. Two copies of the same email is the polite version. The rude version is a chase for an invoice they already paid, because the payment landed on the other record.
Your numbers overcount. One person becomes two customers. Retention, lifetime value, "how many clients do we have" — all quietly wrong, and wrong in the flattering direction, which is why nobody questions them.
Automation acts on the stale half. A workflow triggered on a record that has not been touched for a year uses the old address, the old preferences, the old consent state.
History fragments. The complaint sits on one record and the follow-up on the other, so whoever picks up the conversation is missing half of it.
Cleaning up without making it worse
Find them before merging anything. Export and sort by the field each system actually uses as its key — email for contacts, domain for companies — rather than by name. Name matching finds the wrong pairs in both directions: it misses "Rob" and "Robert", and it falsely joins two genuinely different people at the same company.
Decide what survives, field by field. Not "keep the newest record". The newest record often has the current phone number and none of the history. Most recent contact details, oldest creation date, and every note and attachment combined is usually closer to right.
Check what points at the record you are about to delete. Invoices, subscriptions, bookings and automations may reference it by ID. In systems that cannot merge, the safest move is to stop using one record rather than remove it.
Then fix the entry point. A cleanup without a fix buys you a few weeks. The question to answer is which of your intake paths creates records without looking first — the web form, the import, the integration, the person typing during a phone call.
When it is worth more than a cleanup
For a business with one CRM and a few hundred contacts, an afternoon of sorting and merging solves this, and the entry-point fix keeps it solved.
It changes when the same person can enter your world through several doors at once — a booking page, a payment link, a marketplace, a form, a colleague typing during a call. Then you are not cleaning up duplicates; you are deciding, once, which field means "this is the same person" and making every door check it before it creates anything. Systems that cannot merge make that decision urgent rather than tidy.
Which of your doors need that, and which are fine as they are, is one of the things a process audit settles: $299, three business days, and a list of where your records actually split.
Sources
I read these pages in August 2026. Vendor documentation moves; check the vendor's own page before acting on it.
Which field each system treats as identity: HubSpot on deduplication of records and Stripe's no-code customer portal, on choosing between customers sharing an email.
What happens when a duplicate cannot be merged: Stripe on merging multiple customers.
Related: when two systems write the same field, whose value wins covers the other half of this — one record with two systems fighting over its contents, rather than one customer with two records.