How to Clean Company Names Without Merging Different Businesses

Company-name normalization makes inconsistent names easier to compare; it does not prove that two rows represent the same business. A safe workflow preserves source values, defines whether each record represents a legal entity, brand, branch, subsidiary, establishment, or group, generates candidates from strict to flexible methods, verifies them with independent attributes, and records every merge, relationship, rejection, and unresolved case.

Related: CSV Leading Zeros: Preservation Checklist.

Start by separating normalization from identification

Normalization converts a company name into a consistent, comparison-friendly form. It can reconcile differences in case, spacing, punctuation, legal-form notation, diacritics, and other agreed formatting conventions.

Identification asks which real-world organization the record represents. Entity resolution identifies and links records referring to the same entity, potentially without a shared identifier. Deduplication is the narrower task of finding repeated records within a dataset. Fuzzy matching is one comparison technique used within these processes—not a synonym for entity resolution.

Normalized equality is not proof. If ACME LLC and Acme, Inc. both become acme, the transformation has shown that their base names are comparable. It has not shown that the legal entities are identical. Stronger identification can combine normalized names with domains, company URLs, addresses, or authoritative identifiers (company-name normalization guidance).

Before writing a cleaning rule, decide what one row represents: a legal entity, a brand, a branch, a corporate group, or an internal account. Keep those categories separate in the matching policy.

The correct outcome depends on that target. A CRM may group regional subsidiaries under a brand for account planning, while a legal-entity table may preserve each subsidiary. Often the appropriate operation is to link records through a subsidiary_of, brand_of, or branch_of relationship rather than merge them.

Design the output table before transforming the names

Do not overwrite the source name. Create derived fields so transformations can be inspected, revised, and reversed.

A practical company table can include:

Column	Purpose
source_record_id	Stable identifier for the original row
raw_name	Name exactly as received
normalized_name	Comparison form produced by documented rules
display_name	Reader-friendly presentation name
legal_name	Official legal name when established
legal_form	LLC, Ltd., GmbH, Inc., or another designation
brand_or_alias	Brand or alternate name; use a separate table for multiple or historical values
domain	Normalized website domain used as corroborating evidence
address	Source or registered address
country	Country associated with the record
authoritative_identifier	Registry number, LEI, or another trusted identifier
match_status	Accepted, rejected, linked, or unresolved
confidence_or_review_tier	Operational decision tier, not proof of identity
canonical_record_id	Canonical record for an accepted duplicate
source	Origin of the record or value
rule_version	Version of transformation or matching rules
reviewer	Person or process responsible for the decision
review_note	Evidence and reasoning
decision_timestamp	Time the decision was recorded

The name fields have distinct purposes. raw_name preserves provenance; normalized_name supports comparison; legal_name retains the official form when known; display_name provides a clean label without presenting it as registered; and aliases connect nonidentical names without erasing them.

Use canonical_record_id only when duplicate records have been accepted as the same target entity. A related but distinct subsidiary, parent, branch, or brand should retain its own record and appear in a relationship table:

from_record_id	relationship_type	to_record_id	evidence
1042	brand_of	812	Official company website
1043	subsidiary_of	812	Registry relationship
1044	former_name_of	1045	Registry history

Aliases and former names may be multiple and time-bound, so a separate alias or name-history table can store the name, type, source, and effective dates.

A display or brand name is not necessarily a registered legal name. Leave legal_name unknown until a suitable source establishes it.

Spreadsheet data pages published through that documented workflow are public. As a safety practice, use synthetic or already-public company information and exclude sensitive customer, employee, payment, compliance, and personal data.

Apply reversible normalization before risky simplification

Begin with transformations that preserve meaning, and store riskier search forms separately. These are configurable practices, not universal rules; test them against the languages, jurisdictions, and entity types in your data.

Transformation	Example	Recommended storage	Benefit / risk
Trim outer whitespace	" ACME " → "ACME"	normalized_name	Removes input noise; low risk
Collapse repeated spaces	"ACME Labs" → "ACME Labs"	normalized_name	Standardizes spacing; low risk
Comparison-only case	"Acme" → "acme"	Search field	Aids comparison; loses styling if overwritten
Standardize punctuation	"A.T.&T." → "AT&T"	Derived field with exceptions	Reconciles formatting; may alter a brand
Separate legal form	"Abc Ltd." → "Abc" + "Ltd."	base_name, legal_form	Aids comparison; may create collisions
Transliterate	"Müller" → "Mueller"	Additional search field	Broadens retrieval; may not be unique or official
Remove geography	"Acme France" → "Acme"	Candidate-generation field	Broadens retrieval; may erase regional identity
Remove parenthetical text	"Acme (UK)" → "Acme"	Candidate-generation field	Handles annotations; may erase identity
Remove generic words	"Acme Holdings" → "Acme"	Avoid or down-weight	May improve recall; can remove meaningful terms
Remove subsidiary labels	"Acme Germany" → "Acme"	Relationship search only	Finds a family; may merge distinct entities

Intentional capitalization and punctuation require canonical exceptions. Generic title casing can damage names such as IBM, eBay, and AT&T. Run mechanical rules first, then apply an exception dictionary to the display form.

Legal forms need a deliberate policy:

1. Preserve: retain the suffix as part of the legal name.
2. Standardize: map variants such as Limited and Ltd to an agreed code.
3. Expand: convert abbreviations to jurisdiction-specific full forms.
4. Separate: retain the suffix in legal_form and derive a base-name field.

For example:

raw_name:   "Abc Ltd."
base_name:  "Abc"
legal_form: "Ltd."

The original remains intact; the base name is only a comparison aid. Indiscriminate deletion of Ltd., LLC, GmbH, and similar terms can collapse separate entities. Full legal names may also need to remain available where a contract or compliance process calls for the legal form; practitioner guidance specifically cautions that operational normalization does not replace the legal name in those contexts (brand-name normalization guidance).

Diacritic removal and transliteration should likewise create retrieval forms rather than replace official spelling. Keep Müller and derive Mueller or another locale-appropriate search form. The conversion may improve retrieval, but it can also create collisions.

Use a staged identification workflow

Move records through a documented sequence instead of asking one algorithm to make the entire decision:

1. Inventory sources. Record origin, field definitions, jurisdictions, update frequency, and known quality problems.
2. Define the target entity. Decide whether the canonical record represents a legal entity, brand, location, or group.
3. Preserve raw values. Assign stable source-record identifiers before transforming data.
4. Normalize both sides. Apply the same versioned comparison rules to query and reference data.
5. Attempt identifier matches. Use reliable shared identifiers or maintained crosswalks first.
6. Attempt normalized exact matches. Automate only rules whose collision risk has been evaluated.
7. Generate more candidates. Use token, edit-distance, phonetic, alias, or blocked retrieval.
8. Verify other attributes. Compare domains, addresses, countries, registry records, and historical names.
9. Review uncertainty. Route ambiguous or conflicting candidates to a qualified reviewer.
10. Choose an outcome. Merge duplicates, link related entities, or retain both as unresolved.
11. Document the decision. Store evidence, status, rule or model version, reviewer, and timestamp.

Strict, inexpensive comparisons generally belong before looser candidate generation. Published research guidance similarly describes a cascade from deterministic identifiers and crosswalks to probabilistic matching and more intensive screening, supported by an audit framework (entity-matching workflow).

Consider:

Record A: ACME LLC
Record B: Acme, Inc.

After punctuation handling and legal-form separation, both produce the candidate base name acme. That is enough to compare them, not merge them. A merge may be appropriate if a reliable identifier, domain, and compatible address support the same target organization. Conflicting identifiers or jurisdictions should keep them separate or trigger review.

Now consider Acme France SAS and Acme Germany GmbH. An aggressive rule may reduce both to acme, but a legal-entity dataset should retain separate records and, where supported, link each to an Acme brand or parent.

Decision policy should reflect consequences. Exploratory duplicate discovery can accept a broad candidate set because people will review it. For payments, compliance, or legal-entity publication, use a more conservative policy for automatic consolidation because a false merge carries greater operational risk.

Match the method to the variation

No company-name algorithm or threshold is universally best. Select methods according to the expected variation and validate them against reviewed examples from the intended use case.

Variation	Suitable method	Example	Safeguard
Shared trusted identifier	Exact identifier or crosswalk	Same registry number	Confirm identifier type and issuer
Case, spaces, punctuation	Normalized exact match	ACME LABS / Acme Labs	Measure normalization collisions
Typographical difference	Levenshtein or Jaro-Winkler	Microsfot / Microsoft	Verify another attribute
Reordered words	Token or set comparison	Berlin Bakery / Bakery Berlin	Preserve order-sensitive tokens
Pronunciation variant	Soundex or Metaphone	Similar-sounding spellings	Test by language and region
Unrelated alias	Curated alias mapping	Big Blue / IBM	Store alias provenance
Brand and legal-name difference	Relationship table	Brand / incorporated entity	Link rather than merge by default

Levenshtein distance counts the insertions, deletions, and substitutions needed to transform one string into another. Jaro-Winkler is character-based and emphasizes matching prefixes. Both can retrieve likely typographical variants but do not understand corporate relationships.

Token methods help when words move. Jaccard similarity measures overlap between sets, making it useful for order-insensitive retrieval. Because word order can carry meaning, token similarity should surface candidates rather than replace the original sequence.

Soundex and Metaphone can retrieve pronunciation-related variants, but performance depends on language and regional conventions. Curated aliases are more appropriate when names have little textual resemblance: Big Blue and IBM represent a known alias mapping, not a fuzzy-string conclusion. These method categories and threshold tradeoffs are outlined in a vendor-authored overview and should be validated locally rather than treated as an independent benchmark (fuzzy-matching methods).

Keep retrieval thresholds separate from decision thresholds. A lower retrieval threshold exposes more candidates and more false positives; a higher one can miss valid variants. Short names and acronyms are especially collision-prone, so require stronger corroboration rather than allowing a string score alone to determine the outcome.

Verify candidates with evidence beyond the name

Use an evidence hierarchy:

1. Authoritative identifiers and registry records
2. Domains and official company URLs
3. Registered addresses and countries
4. Known aliases, former names, and effective dates
5. Name similarity

Corroboration is especially important for short names, common words, transliterations, and names stripped of legal forms or geographic terms. Disagreement also matters: a conflicting authoritative identifier should block automatic consolidation, while incompatible domains, countries, or addresses should reject the candidate or trigger review if a relocation, subsidiary, or historical change could explain the difference.

One useful identifier is the Legal Entity Identifier (LEI), a unique 20-character alphanumeric code representing one legal entity in the Global LEI System (GLEIF’s LEI overview). It identifies a legal entity, not every brand, branch, or organization.

GLEIF describes Level 1 data as “who is who,” including official names and registered addresses. Level 2 data covers reported direct and ultimate parent relationships, or “who owns whom.” The Global LEI Index contains current and historical records and is accessible through search, downloads, and an API (GLEIF’s LEI data guide).

A safe LEI workflow is:

1. Search with the available company name and address.
2. Compare candidate official names, registered addresses, countries, and other reference attributes.
3. Inspect relevant historical information when the source may be old.
4. Assign the LEI only when evidence supports the same legal entity.
5. Record the source and assignment date.

Not every organization or brand has an LEI. Fuzzy results are candidates, not proof. Level 2 ownership data may be absent or carry reporting exceptions, so missing parent data does not establish that no parent exists.

Review, document, and publish the result responsibly

Test rules and thresholds against a manually reviewed sample containing both plausible matches and difficult nonmatches. Include short names, common words, regional subsidiaries, transliterations, former names, conflicting domains, and collisions created by suffix removal. Select thresholds according to the costs of false merges and missed matches; do not adopt an unsupported universal target.

Track outcomes separately:

• Accepted: records judged to represent the same target entity
• Rejected: candidates judged not to match
• Linked: related records intentionally kept separate
• Unresolved: insufficient or conflicting evidence

Retain the candidate pair, score where applicable, corroborating and conflicting evidence, reviewer decision, rule or model version, and timestamp. Preserve enough provenance to undo an incorrect merge and reconstruct the source rows.

Ongoing controls should include:

• Validation at ingestion
• Jurisdiction-specific legal-form dictionaries
• Curated alias and former-name mappings
• Exceptions for intentional branding
• Periodic quality reviews
• Reprocessing when rules or reference data change
• Named data-stewardship ownership
• Monitoring of reviewer overrides and normalization collisions

Rebrands, mergers, acquisitions, and legal-name changes require temporal handling. Keep former names, sources, and effective dates in a history table instead of silently replacing prior values.

Before publishing, include a data dictionary explaining:

• The unit of observation
• The meaning of each name field
• Normalization and matching rules
• Identifier sources
• Treatment of brands, subsidiaries, and groups
• The unresolved-record policy
• The dataset update date
• Known geographic, registry, and source limitations

Use this publication checklist:

• [ ] Remove sensitive and restricted information.
• [ ] Confirm that the organization has authorized the data for public release.
• [ ] Retain provenance fields suitable for public viewing.
• [ ] Label inferred matches and relationships.
• [ ] Distinguish legal entities from brands, branches, and groups.
• [ ] Keep unresolved records visibly unresolved.
• [ ] Include rule versions and a data dictionary.
• [ ] Confirm that accidental merges can be reversed.

These are risk-management checks rather than a statement of universal legal requirements. For TablePage specifically, the supplied documentation describes published spreadsheet pages as public, so the publication file should contain only synthetic, already-public, or otherwise approved data (TablePage).

The compact rule is: normalize names to make them comparable, but identify companies with corroborating evidence. Preserve raw values, keep legal entities and brands conceptually separate, use fuzzy methods to surface candidates rather than prove identity, and record how every merge or relationship was decided.