Duplicate customers: what to check before merging
Compare customer records with a matching matrix, preserve their identifiers and document unresolved questions before an irreversible merge.
TL;DR: Before merging duplicate customers, establish that the records represent the same entity and that one is actually redundant. Preserve identifiers from each system, separate likely matches from ambiguous cases, and check how the provider handles relationships. A decision log helps investigation; it does not guarantee that a merge can be undone.
Contents
To review duplicate customers, compare the identity and purpose of each record before deciding whether a merge is needed. One record in sales and another in billing can be correct. What may be missing is a reliable link between them.
The problem starts when an operations team finds two similar histories and someone proposes keeping “the most complete” record. One might hold the current contact; the other, the references an integration uses. Counting filled fields does not resolve that conflict. This guide provides a matching matrix and a decision log for reviewing the case before changing it.
One record in each tool can be correct
Distinguish the same entity represented in two systems from two redundant records within one system. The first may need an identifier mapping; the second, an investigation into how the duplicate arose. Neither justifies deleting a row because of its name.
Define what each record represents: an organisation, a contact person, a location or a commercial account. Someone working at a company is not a duplicate of that company. Two locations should also remain separate if your operations need to treat them separately.
This review fits into preparing a migration, but also works without switching tools. Keeping both records and explaining their relationship can be the correct outcome.
Preserve the source before normalising
Work from a read-only copy. For each row, retain the system, workspace, record type, original identifier and extraction date. CRM / W1 / account / A17 identifies something different from BILL / W1 / account / A17: identical numbers do not establish an identical customer.
Keep original values and add comparison columns for spacing, capitalisation or known name variants. Do not remove suffixes, departments or references that may distinguish entities. A blank field means “no data”, not “matches another blank”.
Record where each signal came from. A shared code is more useful when you know who assigned it and have checked its mapping. A code copied through a faulty import can spread the same error into both records. The most recent edit does not automatically make a value correct either.
Three outcomes, four fictional cases
This example is entirely fictional. All records belong to workspace W1; ORG and EV codes are exercise references, not tax identifiers or customer data. The described evidence is assumed to exist solely to illustrate the reasoning.
| Record pair | Evidence in the exercise | Provisional outcome | Next check |
|---|---|---|---|
CRM/A17 and BILL/B62 | Both refer to ORG-07; note EV-01 matches, but the responsible contact differs | Likely match; review required | Confirm the ORG-07 mapping and resolve the current contact |
CRM/A18 and BILL/B63 | Similar trading name; EV-02 confirms separate organisations, ORG-08 and ORG-09 | Confirmed non-match | Keep separate and record why the name is misleading |
CRM/A19 and BILL/B64 | Same abbreviated brand; no organisation references or independent evidence | Ambiguous | Ask the owner for evidence identifying each record |
CRM/A20 and BILL/B65 | EV-04 shows a contact person and an organisation | Records are not equivalent | Preserve each type; review their relationship if supported |
Do not invent confidence percentages. “Likely” starts a review; it is not an approved merge. “Ambiguous” keeps the case blocked and states what is missing. Even after confirming identity, you still need to decide whether anything should change.
A record without orders is not necessarily redundant: it may be new or serve another purpose. Classify it using evidence, not the number of empty fields.
An alias map does not execute a merge
Suppose the owner resolves the first case: A17 and B62 represent ORG-07, but both tools need their record. The decision is to retain them and document the mapping. In an independent worksheet, ENTITY-F07 can be your working reference:
system,workspace,record_type,source_id,entity_key,review_idCRM,W1,account,A17,ENTITY-F07,R-01BILL,W1,account,B62,ENTITY-F07,R-01These columns form a custom worksheet, not a Frihet import format or an instruction to a connector. entity_key groups reviewed identities; source_id preserves the original reference. Writing an alias in a spreadsheet does not change either tool.
Do not flatten people, companies and locations under one key. Do not combine them through an unchecked chain of similarities either: if A resembles B and B resembles C, you have not established that A and C are the same.
Write a decision someone else can review
Copy this record for each pair. When the decision changes, preserve the earlier proposal and add a new version that supersedes it.
Review: R-01 / version 1Full references: CRM/W1/account/A17; BILL/W1/account/B62Evidence: EV-01; ORG-07 mapping checked by the ownerConflict: different responsible contact; current value confirmed in EV-05Decision: retain both records and document mapping ENTITY-F07Reviewer: ROLE-OPSAction in the tools: noneOutstanding: check how the connector uses this mappingSupersedes: no previous reviewThe codes are fictional. In practice, reference evidence the reviewer can access and avoid copying unnecessary personal data into the worksheet. If a change is later authorised, separately record who performed it, when, the previous references and the observed result. “Approved”, “executed” and “verified” are different states.
This history is revisable, not a guarantee of reversal. Correcting a written decision does not automatically reconstruct data already changed.
Check the provider before merging
Behaviour depends on the product and record type. HubSpot documents that merges cannot be undone and that identifiers, properties and associations follow specific rules. Do not assume the ID selected as primary will always survive unchanged.
Shopify also states that a merge cannot be reversed and excludes certain profiles, including those that have or have had subscription contracts. These examples do not describe Frihet or another provider you use.
Before any irreversible action, answer these questions:
- Is this combination of record types supported, and do you have the necessary permissions?
- Which values are kept or discarded, and which ID will the result have?
- What happens to history, relationships and external references?
- Will synchronisation recognise the change, recreate a record or fail?
- What recovery is actually available, and what does your copy leave uncovered?
Read about integration scope and check the contract for the connector you use. Reading records does not prove that a connector can propagate merges.
Close the case by checking its origin too
If a merge is authorised, first agree how to limit its effects on connected systems. Rehearse with synthetic data in a supported test environment; if none exists, keep the case blocked until the provider resolves the unknowns. An export alone does not demonstrate that you can restore everything.
After an authorised change, compare fields and references with the expected result and check the next synchronisation before extending the batch. If the outcome is uncertain, investigate before repeating the action.
Frihet’s customer management includes exporting the customer list as CSV. That can provide input for a review; it does not imply support for importing this worksheet or automatically merging customers.
Finish by recording why the duplicate arose: manual creation, an import or a connector rule, where evidence supports it. If you do not yet know, assign an owner and a pending check. Two retained records with a clear relationship are a valid result; a shorter list with an unexplained history is not.
Sources checked on 14 September 2026. Review your provider’s current documentation before operating.
Was this article helpful?
FAQ
Are two customers with the same name duplicates?
A name is not enough to decide. They could be different people, companies in the same group, or a company record and a contact record. Names help find candidates; identity requires evidence and review.
Must I merge a CRM record with a billing record?
Not necessarily. Each tool may need its own record. If they represent the same customer, documenting the correspondence between their identifiers may be enough, without deleting or merging anything.
Can a CSV undo a merge?
Not on its own. It may preserve fields for investigation, but does not guarantee restoration of relationships, history, permissions or effects in connected systems. Check each provider’s documented behaviour and recovery options.
