Deduplicating an overseas customer list is not about deleting rows with similar names. It means deciding whether records refer to the same commercial account while preserving contacts, interactions and source context. A company may use a registered name, English name, brand or former name; several legal entities may share a domain. This guide covers internal sales CRM list maintenance, not company-registry searches. Separate identity, aliases, domains, group relationships and merge history before deciding what to combine. First define what an account represents.
Which fields can help identify likely duplicates?
Do not deduplicate on exact company name alone. Compare stronger identifiers—company or registration ID when supplied, normalized domain, phone and address—with supporting clues such as company name and a contact’s email domain. Record each field’s source because a business card, event list and manual entry may not be equally reliable.
An email domain finds candidates, not proof: free accounts, agency addresses and group-wide domains can mislead. Strip URL paths, protocols and the common www prefix. Decide whether regional or product subdomains identify the same brand or legal entity. Normalize spaces, brackets, country codes and extensions in names and phone numbers, while retaining original values for review.
Set confidence levels: a company ID from a trusted source can be high confidence; a similar name plus shared domain needs human review; a contact match alone is not a reason to merge. If one record is an overseas distributor and the other brand headquarters, flag them despite similar names and a shared domain.
Before rollout, choose field priorities and try confirmed positive and negative examples. Log false positives, show matching and conflicting fields rather than only a score, and revise rules. Treat a shared company number as a strong clue but verify questionable sources; similar addresses or shared phone numbers are weak clues. Keep country codes and extensions separate so normalization does not collapse different numbers. After rule changes, sample merged and unmerged records to catch accidental merges and missed matches.
How should company names in different languages be compared?
Treat name text and company identity separately. In one master company record, keep distinct fields for the original source name, English and local-language names, brand name and former names. Never replace source data with a translation. Begin with reversible normalization of full-width and half-width characters, capitalization, spaces and punctuation. Put legal suffixes such as Ltd, Limited and 有限公司 in a separate comparison field.
Have a data steward maintain the suffix dictionary: the same string may be part of a company’s name. Removing suffixes can generate candidates but cannot prove identity. Connect transliterations, abbreviations and names in other languages to the master record through a confirmed alias table, recording the confirmer, source and date.
If 海嶼科技有限公司 and Ocean Isle Tech Limited appear in separate lists, a shared official website, address or reliable company identifier can justify review. A similar English translation alone is not enough; keep the records separate. Do not guess when characters are unreadable, spellings are old or translations were entered manually.
Keep standardized values in temporary fields and sample names across languages and common suffixes before adopting rules. Give aliases a language, type, validity period and source instead of packing spellings into one field. Search can include aliases while reports use a chosen display name. Do not generate aliases automatically from online translations or email usernames. If different companies use one brand name, mark it as shared and require review. Treat rare characters, romanizations and historical names as data-quality exceptions so normalization does not erase identifying detail.
How can you preserve separate legal entities in the same group?
A group is not one company. A parent, subsidiary, regional operator and brand may share a domain, logo or contact while contracting, quoting, payment and service involve different entities. Keep each legal or independent operating entity as its own company record. Link records using defined relationships such as parent/subsidiary, affiliate or brand ownership. A shared domain or the word “Group” in a name does not prove a relationship; use a trusted source or account-owner confirmation and retain the evidence.
For example, a brand may have operating companies in Hong Kong and Singapore. If both use the same brand domain but have different quotation headers and contact teams, keep both accounts and link them at group level. If a shared domain is the only evidence, mark the relationship unconfirmed; do not infer ownership or control. Record name changes, acquisitions and brand transfers as dated history rather than overwriting distinct entities.
A contact can have different roles or interaction histories across accounts; the same person does not make companies identical. Define whether “company” in your CRM means a legal entity, purchasing account or sales team before choosing an identifier. Group totals can roll up to a parent account without losing transaction records at legal-entity level. Record when a relationship applies and its evidence: a public group description, contract party and account-owner confirmation answer different questions. The parent field must not replace the actual transaction party. Link sales accounts that share a procurement department without changing legal-entity records. Check that reports and permissions still let market teams manage accounts separately.
What should you check before merging activity records?
Review the full interaction history, not only company fields. Check contact assignments, account owners, open opportunities, meeting and call notes, mailing status, quotation and contract references, and contact preferences. Confirm whether a contact represents different entities or an opportunity has a different payer or delivery party. A merge can move activities under the surviving record and hide their previous context or ownership.
CRM systems handle merges differently. Before acting, find out which fields survive, which may be overwritten, how duplicate contacts are handled and whether the change can be reversed. If unclear, rehearse on disposable records or a copy; never use a live customer record to discover the behavior.
Suppose record A has two completed meetings and record B has one open opportunity. Choose the surviving company record, map all three activities to the right account and confirm the original opportunity owner remains responsible. If addresses, currencies or contracting entities differ, ask the account owner rather than overwriting one value with the newer one.
Prepare a recovery list of merged IDs, the surviving ID and field differences. If results are unexpected, stop the batch and use the list to correct or reverse affected entries. A pre-merge checklist should cover why the master record was chosen, how conflicts are handled, activity and contact links, open-work owners and recovery steps. For quotations or agreements, verify each reference still points to the right account; do not guess document or payment ownership. Have someone familiar with the workflow sample a small batch before continuing. If rehearsal is impossible, validate field mapping on a copy first.
How can you trace records back to their source?
Keep raw imports separate from cleaned CRM records. For each import, retain the source name, batch ID, source row number or external record ID, import time, original company name and domain, and importing owner. Save normalized values separately. A match log should include candidate records, evidence, rule version, decision, reviewer and reason, and link duplicates to the surviving master record.
This makes it possible to distinguish a new company, a renamed company and the same row imported again. For spreadsheet workflows, add a stable source-row ID before import; sorting or deleting rows can change row numbers.
If rows 18 and 42 are candidates for the same company, the log should identify each source file, import time, matching reason and surviving CRM ID. “Deduplicated” alone is not enough. Set retention, access and personal-data fields under existing organizational policy, and keep only data needed for the business purpose. Regularly verify that raw rows trace to the master record and that someone can understand decisions after a staff handoff.
If records cannot be traced, add source fields and decision logs before expanding automation. Otherwise, mistaken merges are hard to restore and rules cannot be improved from evidence. Log non-merge decisions too—for example, “same domain, different legal entities” or “similar names, insufficient evidence”—and retain their status so later imports do not reopen the same case without context. Limit access to maintainers, keep exports in team-approved locations and handle copies under existing rules. Record spelling corrections separately from identity decisions: fixing a name does not confirm two records are the same entity. When a source or owner changes, preserve the earlier decision and append the new one so the team can follow how the judgment evolved.
Who should review merge decisions?
Assign clear ownership; salespeople should not delete companies that merely look duplicated. An importer can propose candidates, an account owner confirm the business relationship and a data steward maintain matching rules. One person in a small team may fill several roles, but record proposal and confirmation separately.
High-confidence, reversible candidates may be processed in batches. Send shared domains, different legal entities or payment parties, conflicting data and active opportunities to human review. The review list should show original and standardized names, domain, source, activity count, contacts, owner, differing fields and recommended action. Reviewers can then explain why records are the same or should remain separate.
Do not measure success only by how quickly the queue is cleared; that can encourage careless merges. Track pending-review reasons, mistaken-merge corrections and rule changes to see whether quality improves. If an account owner confirms two records belong to different legal entities under one brand, the decision should be “create a group relationship; keep both company records,” not “merge.”
After processing, have the proposer or next owner confirm that opportunities, activities and contacts remain usable. Send disputes to someone who understands the account, then let the data steward update aliases or exception rules. Start with a recent import: flag candidates, assign reviewers, record decisions and revise the process based on the results.
For brand information about Chan & Chung, visit the Chan & Chung website. Teach new staff that a shared domain does not prove identity, and different names do not prove different companies. Use confirmed positive, negative and undecided examples to calibrate the process. Review error types regularly: if mistakes cluster around shared domains, raise the manual-review threshold for that case rather than loosening every rule. Document the review owner, response target and escalation contact so candidates are not left unassigned.