Same domain, different companies: should you merge the CRM records?
Two records share a website. A third shares a phone number. That does not make them one company. Work through a concrete example before merging a prospect list or CRM records.
Do not merge company records just because their domains or phone numbers match. First decide what each record represents: a legal entity, a location or a buying relationship. Then check identity evidence and conflicting facts. Merge confirmed duplicates at the same level; link verified related entities; keep distinct entities separate; review unresolved cases.
Define what “the same company” means in this list.
A headquarters, a factory and a subsidiary can share a brand. They may need different sales conversations. Before comparing names, write one sentence: “Each row in this list represents…” A duplicate is defined relative to that choice.
| Record represents | Question to answer | Information worth preserving |
|---|---|---|
| Legal entity | Which registered organization is this? | Jurisdiction, registry, identifier and checked status. |
| Operating location | Which site will use or receive the work? | Site identifier, address and relationship to the entity. |
| Brand | Which trading identity is visible? | The verified entity or entities operating the brand. |
| Buying relationship | Which people coordinate this particular job? | Roles, scope and conversation history. |
One legal entity can operate several sites. One brand can cover several legal entities. A branch need not be a separate legal entity; a subsidiary should not be assumed to be merely a branch. Verify the structure instead of inferring it from a regional name.
A public CRM discussion describes exactly this difficulty: sellers contact local operations and global headquarters with shared or different domains. Its replies suggest useful relationships. They do not establish a universal identity rule.
Two candidate matches can create a third unsupported match.
Consider a fictional list of legal entities. Its simplistic rule flags a pair when either the domain or the phone matches. The registration labels below are invented teaching labels, not valid registry numbers. All company names and circumstances are fictional.
| Record | Entity evidence in this example | Domain | Phone label |
|---|---|---|---|
| A — Arda Packaging Global | DEMO-REG-DE-A; a distinct entity. | arda.example | SWITCHBOARD-A |
| B — Arda Packaging Türkiye | DEMO-REG-TR-B; a distinct, related entity. | arda.example | SERVICE-LINE-X |
| C — Mavi Distribution | DEMO-REG-TR-C; an independent entity. | mavi.example | SERVICE-LINE-X |
The fictional evidence establishes a group relationship between A and B. B and C use the same outsourced telephone service. These are supplied facts of the example, not discoveries about real businesses.
- A ↔ B: same domain
- The rule proposes a match. In the supplied facts they are related entities, not duplicate legal-entity records.
- B ↔ C: same phone
- The rule proposes another match. The supplied facts explain the shared service number; the entities are distinct.
- A ↔ C: connected through B
- A grouping method can put all three into one component. That connection is not evidence that A and C are the same entity.
The two flagged pairs connect three records. Treating the component as one identity implies all three pairwise identities, including A–C. In this example, that would convert different relationships into duplicates.
Decision in this example: retain A, B and C. Link A and B with the verified relationship. Record the shared service explanation for B and C without inventing common ownership. No merge is justified.
Choose merge, link, separate or review.
| Decision | When it fits | What to preserve |
|---|---|---|
| Merge | Both records are confirmed to describe the same unit, with conflicts resolved. | Source IDs, selected field values and an activity mapping. |
| Link | Records describe different units with a verified relationship. | Separate IDs, the relationship type and its evidence. |
| Keep separate | Evidence establishes distinct units for the purpose of this list. | Their own contacts, locations and conversations. |
| Review | Evidence is missing, contradictory, old or at the wrong level. | The candidate pair, missing check and decision owner. |
When merging is the right option: two imports contain the same verified legal entity and both records are intended to represent that entity. One import may abbreviate its name. If no necessary site or relationship distinction would be lost, a checked merge can reduce duplicate administration.
That same entity can still have two valid site records. Keep them when the list is about locations. Decide where the legal-entity record belongs and associate the sites with it if your system supports that structure. Otherwise preserve explicit entity and site fields in a working file.
Do not manufacture a website address to force a CRM to accept separate records. Keep the actual domain and use supported IDs or relationship fields. Check the current product documentation before changing import behavior.
Resolve the contradiction before approving a merge.
Write the record scope
Choose legal entity, site or another explicit unit. Apply the same definition to both records.
Keep the originals
Retain the source IDs and raw fields in a review copy. Check what the CRM can export and restore before modifying records.
Name the matching evidence
Write “same domain” or “same current registry identity,” rather than just “high confidence.” Include the source and check date.
Look for conflicting facts
Compare entity identifiers, countries, sites and roles. Determine whether differences reflect separate units, changes over time or incorrect data.
Inspect the whole group
When several pairs connect, review the records across the group. Do not let one plausible pair certify every other pair.
Record the chosen action
Explain what is being merged or linked, where activities will belong and which unresolved condition would stop the change.
There is no research-backed universal threshold such as “95 means merge” in this guide. A model’s score depends on its training data, task and evaluation. A rule that performs well on one dataset can still misidentify your prospect records.
Separate matching research from our practical application.
Baas, Dastani and Feelders (2021) investigate the damage from enforcing transitive closure on predicted matches. Their experiments use semi-synthetic historical-person data, not sales records. We read the preprint; it supports examining groups rather than blindly extending predictions.
TransClean (2025) examines consistency to detect false-positive matches. Its benchmarks include synthetic company data and other record types. Results depend on the underlying matcher. It does not validate a domain-and-phone rule, our worksheet or Anivo performance.
GLEIF separates entity reference data from relationship data. Its Level 2 parent reporting concerns accounting-consolidating parents and includes reporting exceptions. It is not a complete map of every business relationship.
GS1’s GLN allocation standard distinguishes parties and locations. One GLN can identify a permitted combination of uses; different numbers should not automatically be read as different legal entities. Check what the identifier represents.
| Evidence | Practical application here | Boundary |
|---|---|---|
| Matching research | Inspect group-level contradictions. | A manual review aid, not an implementation of either algorithm. |
| Entity and relationship standards | Label the unit and the relationship separately. | Identifiers must be checked within their scheme and scope. |
| The fictional counterexample | Do not turn mixed shared fields into identity. | A logical demonstration, not a measured error rate. |
Sources were checked on 6 October 2026. This is a selected research synthesis and an original worked example. We have not performed a systematic review or a production benchmark. None of the sources tests the effect of this guide on sales results.
Keep a reason someone else can inspect.
| Field | Filled example |
|---|---|
| Records and unit | A and B; this list represents legal entities. |
| Shared evidence | The same domain: arda.example. |
| Conflicting identity facts | Distinct fictional registry identities in different jurisdictions. |
| Relationship evidence | A verified group relationship is a supplied fact of this example. |
| Decision and reason | Link; both legal entities must remain identifiable. |
| Preserved data | A and B IDs; each entity’s contacts, notes and activity history. |
| Next check | Confirm which entity coordinates the specific buying discussion. |
For real records, add the actual source address, check date, reviewer and the field-level changes you propose. The download includes a blank record, the three-record case and a separate example where merging is justified.
Use the text file in your own editor. It requires no signup and contains no upload step. It is a manual decision record, not an Anivo import format or an automatic identity checker.
Prevent a repeated approach without erasing a company.
List cleanup and outreach coordination answer different questions. Two valid site records may lead to the same purchasing contact. You can hold one planned approach while checking responsibility, without merging the site records.
Likewise, two related entities may need separate conversations. A common domain does not tell you whether a service is purchased centrally. Ask which entity and location the project covers, then keep that answer with the relevant record.
If identity remains unresolved, pause the action that relies on it. Write the missing check. Continue when you can explain who the record represents and why the conversation belongs there.
Use the lead qualification guide for project fit and buying roles after this identity check. The company-score guide explains why an interesting score does not settle the question.
Questions about company records
A proposed duplicate, a related entity and a repeated outreach target need different decisions.
Can different companies have the same website domain?
Yes. A shared website can represent several related entities, brands or locations. Check what each record represents and verify identity before merging.
Does the same phone number prove two records belong to one company?
No. A shared switchboard or service can explain the match. It is a candidate signal; check identity evidence, scope and the date of the information.
Should headquarters and branches be merged?
It depends on the record unit. Separate sites can be valid records even within one legal entity. Preserve the site distinctions when location matters, and record the verified entity relationship.
Can one company have several domains?
Yes. Different domains do not alone prove different entities. Verify the entity, the role of each domain and whether the records describe the same unit.
Is the same registration number enough?
Check the issuing registry, jurisdiction, source, status and identifier scope. Confirm that both records use the same scheme and represent the same unit. The number alone does not identify the buying role or operating site.
Why check three records when two pairs already match?
The pairwise rule may have matched different fields for different reasons. Putting all connected records into one identity can create an unsupported third match. Inspect the whole group and any conflicting facts.
When is merging appropriate?
When the records are confirmed duplicates of the same unit, conflicts are resolved and necessary location or relationship distinctions are preserved. Record the source IDs and the intended field and activity mapping first.
Is holding a repeated outreach target the same as merging records?
No. Holding an approach changes a campaign decision. Merging changes the data identity. You can coordinate contact with related entities or sites while preserving their separate records.
Sources and reading limits
Original research, official identifier standards and a public problem report. Research findings and the manual decision method are distinguished above.
- Baas, Dastani & Feelders — Exploiting Transitivity Constraints for Entity Matching in Knowledge Graphs (2021)
Preprint full text checked for experimental setup and limitations. Semi-synthetic historical-person data; not a CRM or Anivo benchmark.
- De Meer Pardo and colleagues — TransClean (IEEE Access, 2025)
Institutional publication record and published full text checked. DOI: 10.1109/ACCESS.2025.3632400. Synthetic companies and other benchmarks; matcher-dependent results.
- GLEIF — LEI data access and Level 2 relationships
Official overview read with the Level 2 page. Entity identity and accounting-consolidating parent reporting have different scopes; exceptions exist.
- GS1 — GLN allocation rules
Official sections on party, location and combined use checked through indexed excerpts. Used for identifier scope, not as a claim that every prospect has a GLN.
- HubSpot Community — Managing company duplication (2024–2025)
Full public discussion read. Evidence that the problem is asked about; replies are not independent research or a measurement of search volume.