Two records with the same name are not necessarily the same business. Two records with different names may belong to the same legal counterparty. Customer and vendor deduplication before NetSuite migration needs a governed identity decision, not a spreadsheet command that deletes repeated text.
The practical goal is to reduce avoidable duplicates while keeping invoices, payments, addresses and legacy references attached to the right party. A smaller master file is useful only if it preserves those relationships.
This approach gives a master-data owner a review process, a crosswalk structure and a set of false-positive tests. All company names and records in the examples are hypothetical. The proposed controls must be adapted to the features, record types and access rules in your NetSuite account.
Start by defining the target identity model. Is the customer record intended to represent a legal contracting party, a billing relationship or a separately managed account? How will ship-to sites, branches and parent relationships be represented? Which vendor relationships must remain separate for operational or accounting reasons?
These decisions affect matching. If two regional branches transact under different legal entities, a shared brand and website do not justify combining them. If one legal entity has three delivery addresses, three legacy records may reflect a source-system limitation rather than three distinct customers.
Write a short identity policy before reviewing candidates. Include the evidence required to consolidate records and the conditions that require separation. Resolve disagreements with the finance and commercial owners rather than allowing whichever spreadsheet operator is available to decide.
Names are useful for finding candidates. They are weak evidence for approving a consolidation. Punctuation, abbreviations and trading names vary, while unrelated companies can have similar names.
Compare available identifiers, registered details, verified addresses, transaction history and known relationships. Treat tax or registration identifiers carefully: missing values, formatting errors and jurisdiction-specific structures can reduce their reliability. A common identifier is evidence to investigate, not permission to bypass review.
Email domains and phone numbers can be shared by a group, outsourced finance service or purchasing agent. Bank details are sensitive operational data and should not be used as a casual matching shortcut or copied into broadly accessible review files.
Separate exact matches from probable matches. Give reviewers the original values alongside normalized versions so they can see whether normalization erased a meaningful distinction.
Consider four hypothetical groups:
A candidate worksheet should show the proposed decision, supporting evidence, contradicting evidence, reviewer and review date. “Looks duplicated” is not a sufficient rationale for moving open financial documents.
Approving two records as one identity does not mean one entire row should overwrite the other. The surviving billing address may come from one source, the current credit terms from another and the verified legal name from a third approved record.
Define survivor rules by field. Prefer a verified current value over an unverified recent edit. Preserve useful historical addresses where the target design supports them. Resolve conflicting currency, subsidiary, tax and payment settings with the responsible owner.
Avoid silently inheriting the most permissive credit limit or payment arrangement. These are business decisions, and combining records can materially change how future transactions behave.
For contacts, retain role and consent context where applicable. A person associated with collections should not automatically become the recipient of every purchasing or sales communication after consolidation.
Every source record needs a documented destination, even when several source records map to one target entity. A simple crosswalk can include source system, legacy record ID, source role, target migration ID, resulting NetSuite ID, decision status and reason.
For the hypothetical Harbor Parts consolidation, legacy IDs C-0041 and C-0892 might both map to the approved migration identity CUSTOMER-017. After creation, the crosswalk records the actual target identifier. Preserve both legacy IDs rather than replacing one with the other.
Choose external identifiers according to the supported record model and integration design. Do not assume an identifier is globally unique merely because it is unique in one exported file. Prefixing by source or record category may help, but the convention must be consistent and tested.
The crosswalk is also the key to support. When a user searches for an old invoice reference, the team should be able to explain which target counterparty owns it and why.
Count customers and vendors, but also count their dependent records. Compare open invoices, bills, credits, orders and relevant balances before and after transformation. A reduction in master-record count should not create a reduction in valid transaction count.
Test a sample from each decision category: exact match, reviewed probable match, deliberately separate lookalikes and rejected consolidation. Confirm subsidiary access, currency availability, billing details and statement presentation through representative workflows.
Check for orphaned references and many-to-one mappings with unexplained conflicts. Review records with open balances more closely than dormant records with no dependencies. If a decision remains uncertain, holding the candidate for review is safer than forcing consolidation to meet a cosmetic cleanup target.
No reliable identity process should rely on name alone. Names identify candidates; verified business evidence and an approved target model determine the decision.
They can share normalization and candidate-review methods, but their transaction dependencies and target record behavior differ. Keep those differences visible in approval and testing.
Assign an owner and a decision deadline. If migration must proceed, document the approved interim representation and how users will avoid creating further confusion.
Only the initial cleanup is finished. Define who can create records, which checks they perform and how exceptions are reviewed so the same ambiguity does not return immediately.
CuriousRubik can help scope a master-data review around your highest-risk candidate groups and transaction crosswalks. Start with records that have open balances, conflicting identities or multiple regional relationships.