ERP里出现重复数据时，最危险的动作往往不是“没及时清理”，而是看到两个名称相似的档案，就把其中一条删掉。客户档案、商品编码、供应商信息或业务单据一旦与订单、库存和财务记录发生关联，误合并可能让历史记录失去清晰的业务含义。我的判断原则是：先诊断重复类型和形成原因，再确认业务对象是否相同，最后才决定合并、修正、保留或删除。对中小商家而言，去重不是一次性的清理任务，而是一套能追溯、可复核、可回退的数据处理流程。
两条记录看起来一样，不等于它们代表同一个业务对象。两个客户可能同名但分属不同门店；同一客户也可能因为简称、全称或历史名称不同，被建成多个档案。商品名称相似，也可能在规格、颜色、包装单位或计量方式上存在差别。
所以我不会把“名称相同”直接当成删除条件，而会先问三个问题：它们是否指向同一个现实对象？现有差异是格式问题、历史变更，还是业务上确实不同？两条记录分别关联了哪些订单、库存、结算和操作记录？只有这些问题有了答案，处理动作才有依据。
中小商家的 ERP 重复数据通常落在三类里：主数据重复，例如客户、商品和供应商档案；业务单据重复，例如重复导入的订单或入库单；录入痕迹重复，例如导入前后留下两份相同表格记录。三类数据的风险和处理方式不同，不能用同一条“查重后删除”规则处理。
例如，两条客户档案可能可以确认是同一客户，但各自关联了不同订单。正确做法通常不是把其中一行从系统里硬删除，而是确认系统能否合并档案、保留历史关联和操作轨迹。如果系统不支持安全合并，先冻结新增、保留两条记录并咨询服务商，可能比贸然清理更稳妥。
我建议把每次去重拆成四种动作：保留、修正、合并、删除。保留适用于不能确认重复或业务上需要分别管理的记录；修正适用于同一档案的字段写法错误；合并适用于确认是同一对象且系统能正确迁移关联数据的记录；删除只适用于尚未被业务引用、确认无效且有审批记录的数据。
这个次序看起来不如“批量删除”省事，却能降低误操作后的恢复成本。处理前要有备份或可回退方案，处理后要能回答：谁确认了重复、依据是什么、保留哪条记录、另一条关联了什么业务信息、谁执行了操作。
| 诊断对象 | 优先核对 | 常见处理方式 | 主要风险 |
|---|---|---|---|
| 客户、供应商等主数据 | 主体信息、联系方式、结算关系、历史单据 | 确认主体后合并或保留并标注关联 | 把不同门店、主体或结算对象误合并 |
| 商品主数据 | 编码、规格、单位、条码、状态 | 统一字段规范，按业务规则处理编码 | 把规格不同的商品当作重复品 |
| 业务单据 | 单据号、来源、日期、金额、审批状态 | 核实重复来源，按系统规则冲销或作废 | 破坏账务、库存或审批链条 |
| 导入表格记录 | 来源文件、导入批次、关键字段 | 清理导入源，修正规则后重新校验 | 只清系统记录，未处理源头文件 |
在中小商家的日常工作里，建档任务可能落在采购、销售、仓库和财务等不同岗位。销售为了快速报价建了客户简称档案，财务为了开票补录了完整主体名称，仓库又从一张旧表格导入了带地区前缀的客户记录。每个人都完成了眼前任务，系统里却慢慢出现了多条疑似指向同一个对象的记录。
商品数据也有类似情况。采购表里用供应商商品名，仓库按包装规格建档，电商运营用平台标题导入，财务则关注计量单位和核算口径。名称相近并不能说明编码应该相同；如果新增权限没有分工，或者导入模板没有校验规则，重复就会不断回流。
排查时，我会先问“重复从什么时候开始增加”，而不是先问“哪个员工录错了”。若某一周集中出现大量相似档案，问题更可能与一次导入、系统迁移、活动期间的集中建档或权限调整有关。找到时间和来源，才能把清理和预防连接起来。
客户档案重复，可能导致销售人员看不到完整的往来记录，也可能让应收账款和客户经营统计分散。商品档案重复，可能使库存分布在不同编码下，报表里同一款商品被拆成多个名称。业务单据重复则可能影响库存变化、订单执行和账务复核。实际后果取决于系统的关联方式和企业流程，不能把所有重复都说成一定会造成财务损失。
更重要的是，重复会让“哪个数字可信”变得模糊。比如经营报表显示某客户本月采购额降低，原因可能是客户档案被拆分；库存报表显示某商品库存不足，实际货物可能记在另一个相似编码下。此时继续基于报表做补货、授信或营销决策，问题就从数据质量扩展到了经营判断。
名称只是识别信息之一。企业名称可能有简称、曾用名和门店名；商品名称可能有促销标题、内部简称和供应商叫法。相反，两个不同主体也可能刚好同名。单字段查重适合缩小筛查范围，不适合直接决定合并。
对客户档案，通常还要结合主体信息、联系方式、地址、结算关系和历史交易。对商品档案，需要看规格、单位、条码、供应商货号及商品状态。字段组合要按业务类型设计：客户的识别逻辑不能原样套给商品，商品的匹配规则也不能直接用于供应商档案。
模糊匹配的价值是把可能重复的记录排到复核队列里，而不是代替业务判断。名称相似度高，可能是两个同品牌、同系列但规格不同的商品；手机号相同，也可能是家庭共用号码或门店统一电话。阈值设得越宽，候选记录通常越多，人工复核量也会增加。
我更倾向于把自动匹配用于“初筛”，把自动合并限制在条件非常明确、经过小批次验证的场景。即使规则看起来成熟，也要留出“无法判断”这一类，不要为了追求自动化覆盖率，迫使系统把不确定记录分到确定结果里。
目标不是让档案数量尽量少，而是让每条记录都对应清晰、可解释的业务对象。不同门店可能有独立结算与库存，不同包装规格可能有不同条码，不同客户主体可能共享联系人。把这些记录合成一条，数量下降了，业务准确性却可能更差。
清理报表中“删除了多少条”也不是充分的效果证明。删得多，可能只是候选规则太宽或保留标准过于激进。更值得关注的是：确认重复的比例、误合并数量、复核耗时、重复新增是否回落，以及相关单据是否仍能正常追溯。
若建档入口、导入模板和字段标准没有变化，清理后的数据很容易重新变脏。员工找不到已有档案，就新建一条；旧表格继续沿用旧编码；同一文件重复导入，系统又出现一批相似记录。清理只是处理存量，流程规则才决定新增数据的质量。
因此，去重项目要同时交付两样东西：一份经过复核的存量处理结果，以及一组能减少重复再发生的规则。后者可以很朴素，例如明确谁负责主数据、建档前必须先搜索哪些字段、导入文件如何编号、重复候选由谁确认。
表格适合做候选筛查，不一定适合完成最终清理。导出文件通常未必包含所有系统关联关系、审批状态和操作日志；如果把整理后的表格全量覆盖导入，可能覆盖有效字段、重复生成新记录，或丢失系统内部的主键关系。
更稳妥的做法是先确认系统支持的导入模式、更新匹配字段和错误处理方式，再用少量数据验证。若系统不能安全执行合并或回滚，就把表格作为复核清单，记录建议动作，再由有权限的人员按系统流程处理。
没有一套适用于所有数据的万能查重字段。中小商家不需要一开始就建设复杂的数据治理体系，但应该为最常出问题、影响最大的对象定义最小识别规则。规则的重点不是字段越多越好，而是字段能够区分真实对象，并且企业日常能维护。
| 数据类型 | 可用于初筛的字段组合 | 必须人工确认的差异 |
|---|---|---|
| 客户 | 规范名称、手机号、地址或主体识别信息 | 不同门店、结算主体、客户归属和历史更名 |
| 供应商 | 规范名称、联系方式、主体信息或供应商编码 | 分支机构、收款主体、供货范围和合同关系 |
| 商品 | 内部编码、条码、规格、计量单位 | 包装层级、颜色型号、停售状态和替代关系 |
| 业务单据 | 单据号、来源系统、业务日期及关键金额 | 重试单、冲销单、拆分单和审批状态 |
我建议设置“高置信候选”“需要人工复核”和“明确不同”三档。高置信候选只是优先复核，不代表可以无条件合并；需要人工复核的记录往往存在字段缺失或关键差异；明确不同的记录应从候选池移出，并记录容易误判的原因，方便以后调整规则。
这套分档的好处，是承认数据里存在不确定性。很多系统治理失败，并不是找不到相似项，而是把模糊结果包装成确定答案。保留“暂不能判断”，能让商家避免为了快速完成清单，把疑难记录强行处理掉。
旧记录不一定更完整，新记录也不一定更可信。选择主记录时，我会优先核实编码是否已被外部单据引用、字段是否完整、状态是否有效、关联记录是否较多、是否有未结业务，以及哪些部门正在使用它。若系统可以显示审计日志，还要确认关键字段是否被修改过。
如果两条记录都已被重要流程引用，不能简单认定“一条主、一条废”。应先确认 ERP 的合并机制是否会迁移历史关系、如何处理冲突字段、是否保留原记录编号，以及是否支持恢复。不同产品和版本的实现不同，操作前要看产品文档或向服务商确认。
如果 ERP 支持主数据合并，先核实合并后旧编码是否保留、历史单据是否自动关联、冲突字段如何处理、操作日志能否查询。如果系统只支持停用或标记重复，就要确认停用记录会不会影响历史查询和新单据选择。
如果 ERP 没有安全合并能力，不代表必须立刻换系统。商家可以先限制重复档案继续被选用，建立主记录对照表，由责任人逐步迁移未结业务，并请服务商确认历史关联处理方案。决定能否做的关键，是风险能否被解释和控制，不是按钮是否存在。
下面是一个情景模拟：一家经营多个销售渠道的小型商家，准备检查客户档案。导出后发现同一组客户名称存在简称、全称和地区前缀等不同写法。为便于讲清流程，假设筛出120条疑似记录；这不是实际客户数据，也不是行业统计，只用于演示如何从候选清单进入业务判断。
如果只按名称相似度合并，120条都可能被当成重复。但复核后，可能发现一部分是同一客户的不同写法，一部分是不同门店或不同结算主体，还有一部分缺少足够字段，暂时无法确认。真正需要处理的数量，必须以业务复核为准。
这家商家可以先约定，客户主体名称作为基础字段，结合联系方式、地址、开票或结算信息和历史交易记录判断。规则不是说每个客户都必须有完整字段，而是让复核人知道哪些字段能支持判断、哪些缺失会导致暂缓。
遇到相同手机号但不同名称时，先查联系方式是否是门店公共电话；遇到相同名称但不同地址时，确认是否为不同分店；遇到简称与全称时，查看合同、订单或结算记录是否指向同一主体。每条结论都应写明依据，而不是只在表格里打一个“重复”标签。
假设两条记录确认是同一客户，但一条关联了历史订单，另一条补全了开票信息。此时主记录不能只按哪条资料更多来选，还要确认系统是否支持把历史订单关联到保留记录，以及这样做是否会影响对账和报表。若不能确认关联迁移结果，先保持两条记录并限制错误新增，比立即删除更安全。
若系统支持安全合并，则由业务责任人确认主档案，执行人员按权限操作，复核人检查订单、未结账款和历史查询。若系统不支持合并，可以用状态标记、备注或内部对照表管理过渡，但需要规定新单据只选择哪条记录，避免过渡期出现新的分叉。
复核结果至少应包括候选记录编号、关键字段、判断类别、处理动作、保留记录编号、复核依据、责任人和处理时间。对暂缓记录，还要写明缺少什么信息、由谁补充、何时复查。这样，下一位处理人不用从头猜测，也能在发现问题时还原决策过程。
在这类模拟项目中，项目是否成功不取决于清理了多少条，而取决于处理后能否回答：哪些候选被确认重复？哪些相似但应保留？无法确认的记录是否有后续责任人？系统关联是否正常？重复新增是否继续发生？这些问题比单一的“删除数”更能反映治理质量。
如果想判断清理是否有效，可以在试点前后记录同一口径的指标。例如，每周新增客户档案中疑似重复的数量、每批候选清单的复核耗时、误合并或回退次数，以及客户报表中需要人工拼接的次数。数据要来自商家自身的系统记录、操作表或工时记录，不能把模拟案例中的假设数字写成真实改善成果。
试点前设定观察周期和统计口径，试点后再用同样的口径核对。若疑似重复减少，但复核耗时显著增加，可能说明规则过宽；若处理速度快但回退增多，可能说明合并条件过于激进。指标之间要一起看，避免只优化一项而把成本转移到别的岗位。
对于几十条以内、集中在某一类客户或商品的疑似记录，通常不必先采购复杂的数据治理工具。先统一复核字段，指定业务负责人和执行人，挑选一小批候选项试做，记录判断难点，再修正规则。小规模试点的价值，是让商家看见自己的数据问题究竟来自命名、流程还是系统能力。
试点中要把容易误判的案例单独记下来。例如，同一商品不同包装是否要分开建档、不同门店客户是否独立核算、历史停用档案是否参与查重。这些边界问题一旦不写清楚，后续扩大处理时就会出现不同岗位给出不同结论。
导入数据量大、重复集中出现在某个批次时，先检查模板和导入流程，别急着逐条清理。确认文件是否有唯一批次编号、是否保留来源文件、导入失败后是否可能重复提交、系统按哪些字段判断更新或新增。
新流程可以要求导入前执行字段校验，导入后保存成功、失败和跳过的记录数，并由业务负责人抽查关键字段。若是从旧系统迁移，还要明确旧编码与新编码的对应关系，不能把“旧系统同名”当成充分的映射规则。
当重复记录已经被多个业务流程引用，优先动作是减少新问题继续发生：明确新单据应选哪条档案、限制可疑档案被继续新增业务，必要时设置审批或联系服务商确认合并影响。此时一次性批量处理并不一定是效率最高的方案，因为错误操作可能波及正在执行的订单、库存和账款。
处理前至少确认历史单据能否查询、未结业务如何迁移、库存流水如何保留、对账口径是否变化。如果这些问题暂时没有答案，先建立对照关系和人工复核流程，再分批处理。对已发生业务的档案，保留完整审计信息比清单看起来整齐更重要。
员工反复新建档案，不一定是没有规则，也可能是系统搜索难用、查询权限不足、已有档案名称不规范，导致使用者找不到记录。只在制度里要求“新增前先查重”，却不提供好用的搜索方式，规则很难稳定执行。
可以把新增权限集中到少数责任岗位，也可以允许业务人员提交建档申请，由主数据负责人审核后创建。哪种方式更适合，取决于每天建档量和业务响应要求。高频、紧急场景要兼顾速度；低频但影响大的档案可以采用更严格的审核。
没有自动查重功能时，仍可以通过统一命名、标准模板、主数据维护人和定期抽查改善问题。维护一份主档案对照表，记录历史别名、旧编码、当前有效编码和停用原因，能帮助不同岗位识别同一对象的不同写法。
但表格方案也有边界：多人同时维护时容易出现版本不一致，权限和历史修改追踪能力通常有限。因此，轻量方案适合过渡和小范围管理，不应被误认为可以无限扩展。数据量、协作人数或业务风险上升后，要重新评估系统能力。
| 当前情况 | 第一优先动作 | 适合的处理方式 | 暂时不要做 |
|---|---|---|---|
| 少量、单一数据类型 | 定义复核规则并做小批次试点 | 人工确认后修正或合并 | 未验证规则就批量删除 |
| 某次导入后集中增加 | 核对批次、模板和重试记录 | 从源文件和系统记录两端排查 | 只在系统里删，不修导入源 |
| 已关联订单、库存或账务 | 确认关联影响与回退方案 | 服务商协助、小批量处理、留痕复核 | 直接覆盖导入或强行合并 |
| 重复持续发生 | 检查权限、搜索和建档责任 | 优化入口、模板和复核流程 | 把责任全部推给录入人员 |
| 短期没有系统支持 | 统一编码、命名和维护责任 | 用对照表过渡并定期检查 | 将临时表格当成永久主数据系统 |
自动规则适合字段稳定、业务对象容易定义、错误后果较轻且能回滚的场景。人工复核适合主体差异复杂、历史关联多、合并后影响较大的场景。两者不是非此即彼，较实用的方式通常是机器筛选候选项，人来判断业务含义，系统按明确规则执行操作。
当候选量增长时，可以先优化排序和复核界面，而不是马上放宽自动合并范围。让高置信候选优先进入人工队列，减少无关记录干扰；同时保留低置信和资料不足记录，等待补充。系统化的目标是让人把时间花在有价值的判断上，而不是让系统掩盖不确定性。
合并能减少同一对象被重复选择的机会，也可能统一历史查询口径；代价是需要判断主记录、处理字段冲突，并确认系统如何保留关联信息。保留多条记录更保守，但若没有标记和使用规则，员工可能继续选错档案，重复问题仍会影响业务。
因此，我会按风险而不是按“数据行数”做选择。未发生业务引用的空档案，确认无效后可以按制度删除；已发生交易的记录，要优先考虑系统合并、停用或对照管理；业务主体确有差异的记录应保留。无法确认时，暂缓往往比错误合并更容易补救。
集中维护的优势是规则统一、重复入口少，缺点是可能形成处理队列，影响一线响应。分散维护能让业务更快，但要求岗位有统一规范、查询能力和复核机制。对于每天新建档案很少、影响大的业务，集中审核通常较易控制；对于高频业务，可以采取一线提交、专人审核重点字段的混合模式。
不要只看审核步骤多不多，还要观察档案等待时间、退回补充次数和重复新增数量。若严格审核导致员工为了赶进度绕开系统，流程设计就需要调整。好的规则应该让正确做法比绕过规则更方便。
一次性全面治理有利于统一规则和报表口径，但需要充足时间、业务参与和系统支持；分阶段治理投入较小、反馈快，但短期内可能存在新旧规则并行。中小商家可以先从影响经营最大的对象开始，例如高频商品、核心客户或近期交易供应商，再根据结果扩大范围。
分阶段不等于任意拖延。每一阶段应明确数据范围、责任人、完成条件和遗留问题。例如，先处理某类有效商品档案，同时把历史停用商品列入后续复核；先规范新建客户入口，再逐步清理历史客户。把范围写清楚，才能避免“部分处理”被误认为“全部完成”。
省略复核记录，表面上减少了操作步骤，问题发生时却很难定位错误原因，也难以判断是否需要恢复数据。对涉及客户结算、商品库存或财务单据的操作，留痕本身就是控制风险的一部分。至少应保留操作依据、执行人、时间、处理前后记录和关联检查结果。
如果系统没有完整审计日志，就用经过权限控制的处理台账补足，并明确谁可以修改。台账应与系统记录对应，而不是只写“已处理”。当处理量较大时，先确认能否导出操作日志、是否存在备份恢复机制，以及服务商对合并操作的支持范围。
指标不必多，关键是口径稳定。适合中小商家先跟踪的项目包括：新增档案中的疑似重复数、候选记录确认重复的比例、每批复核耗时、处理后回退或纠错次数，以及同一类型重复在后续周期的复发情况。
“确认重复比例”能帮助判断筛查规则是否太宽：候选很多但多数是不同对象，说明初筛噪声较高；候选很少但业务人员不断发现漏网记录，说明规则可能太窄。“复核耗时”则能提醒团队，是否把过多人工成本投入到低风险数据上。
刚清理完时，记录数量下降是预期结果，但这不代表入口已经改善。商家可以选一个业务周期持续观察，例如覆盖一次常规补货、对账或客户建档高峰，按固定口径统计新增疑似项和重复来源。周期长度应符合业务节奏，不必机械照搬某个统一天数。
如果清理后疑似重复又快速增加，优先回查谁在新增、是否使用旧模板、搜索结果是否能找到主档案、权限是否仍允许任意建档。复发记录不只是失败，也能提供线索：是哪条规则没有落地，哪个字段最容易缺失，哪个岗位最需要调整流程。
只复查已处理清单，会产生一种盲区：规则找出来的候选得到了处理，但规则遗漏的记录没有人看见。可以定期从近期新增记录里抽取一小部分，检查是否存在漏检；也可以针对容易混淆的品类或客户群，复核相似名称、空缺编码和多种写法。
抽样的重点不是追求一个漂亮的准确率，而是发现规则边界。如果抽查发现漏检，要记录漏检类型并更新筛查字段；如果发现误报，则调整候选排序或复核说明。规则变化应有版本记录，避免团队不知道某段时间采用的判断标准是什么。
每轮清理都会暴露一批可复用的信息：哪些简称需要加入别名字段，哪些商品规格必须拆分，哪些客户主体不能合并，哪些导入模板容易产生格式变化。把这些经验整理成简短的维护规范，比每次靠老员工口头提醒更可靠。
规范要能被一线执行。与其写“保证数据准确”，不如说明建档前搜索哪些字段、什么情况下必须申请新编码、导入文件如何命名、疑似重复找谁复核。能落实到具体动作的规则，才有可能改变数据输入质量。
清单至少要包含记录编号、关键字段、来源或创建时间、疑似原因、复核结果、建议动作、主记录编号、业务依据、责任人和处理状态。字段不用追求繁多，但要能解释为什么作出这个判断。处理表和系统记录之间应能互相定位。
对疑难记录，设置“暂缓”状态并明确下一步需要补什么资料。不要把暂缓当作项目失败，它是在防止不确定性被伪装成确定结论。每一条暂缓记录都应有负责人，避免无限期留在清单里无人处理。
先挑选一组字段比较完整、业务关系容易确认的记录试做，检查系统操作结果和相关报表，再逐步处理复杂记录。若发现关联数据没有按预期迁移，立即暂停扩大范围，先修正方案。小批量验证不是形式步骤，而是让企业用真实数据验证判断规则和系统行为。
处理后至少抽查一部分记录，确认保留档案可以正常用于新业务，历史单据仍可追溯，停用或合并的记录不会误导使用者。抽查比例由风险和处理量决定；高风险数据需要更充分的复核，不能用一个固定比例替代判断。
项目收尾时，不只交付“处理完成”的清单，还要总结重复来源、字段缺口、容易误判的业务边界和系统限制。把结果转成命名规范、编码原则、导入检查、权限设置或复核机制，并指定后续维护人。
如果目前没有条件配置系统自动校验，可以先从可执行的低成本规则开始：新增前搜索名称与关键识别字段；导入前检查批次和重复键；新建重要档案由责任人复核；定期抽查新增数据。之后再根据实际工作量决定是否需要更强的自动化能力。
第一，哪些记录被确认是同一个业务对象，判断依据是什么？第二，处理动作有没有保留历史关联和可追溯信息？第三，暂时不能确认的记录是否有人负责跟进？第四，重复的来源有没有被修正？这四个问题能够回答，才算从“清理数据”走到了“改善数据录入”。
中小商家不必一开始追求复杂的治理项目。先选择一类高频或高风险数据，备份后生成疑似清单，由业务人员复核，挑小批次验证处理动作，再检查关联记录和新增入口。过程可以从简，但判断必须清楚，操作必须可追溯。
今天就可以选出最近新增的一小批客户、商品或供应商记录，按关键字段筛出疑似项，并标记为“确认重复、确认不同、暂不能判断”。先记录数量和复核时间，不急着承诺改善比例；完成复核后，再决定是否合并、修正、停用或保留。
我对 ERP 数据去重的核心判断是：规则负责发现相似，业务负责确认含义，系统负责安全执行，记录负责让决定可追溯。当这四件事形成闭环，去重才不只是让表格看起来干净，而是让库存、客户、订单和经营报表重新建立在可信的数据基础上。
我在整理 ERP 数据时发现，客户档案重复、商品编码重复和单据重复看起来都像“录了两次”，但处理方式可能完全不同。我不确定应该先删记录，还是先查重复是怎么产生的，担心清理错了会影响库存或历史单据。
先别批量删除，先给重复项分类。客户、供应商、商品档案属于主数据；订单、出入库单、付款记录属于业务单据；同一对象的不同名称或规格，则可能只是写法相似，并非重复。可以先抽取一小批疑似记录，查看创建时间、操作人、导入批次和关键字段。例如，同一客户档案如果在某次表格导入后集中增加，问题可能在导入流程；
如果重复记录分散在不同岗位和时间，可能需要检查新增权限与建档规范。诊断顺序建议是：确认数据类型，再查重复来源，最后判断处理方式。把“疑似重复数、人工确认数、误判数”分开记录，比只统计删除了多少条更能看出问题在哪。
我遇到过公司全称、简称和门店名称混在客户档案里的情况，名称相似，但联系人、地址或结算主体不完全一样。我想知道该用哪些字段判断，才不会把不同客户合并，或者把同一个客户继续留成多条记录。
不能只凭名称判断。名称相同可能对应不同门店或结算主体；同一个客户也可能因简称、标点、空格或名称变更而出现不同写法。更稳妥的做法是把字段组合起来核对，并区分“初筛”和“确认”。例如，可先用“统一识别信息＋联系方式＋地址”筛出候选项，再由业务人员检查合同、开票资料或历史交易关系。
手机号相同也不一定足够：联系人可能离职，号码也可能由多人共用。可以用三档处理：关键字段一致且业务关系确认相同，列为高置信候选；只有名称相似，列为待复核；结算主体、门店或交易关系不同，保留独立档案。相似度工具适合找线索，不宜直接自动合并。
我想清理一批重复的商品或客户档案，但担心记录已经关联订单、库存流水或应收应付。我们没有专职数据团队，也不确定 ERP 是否支持合并和撤销，应该怎样把风险控制在可接受范围内？
采用“小范围、可回退、有人复核”的流程，而不是一次性全量清理。先确认数据范围、负责人和审批人，导出备份或确认系统恢复方式；再生成疑似重复清单，由熟悉业务的人判断主记录、历史使用情况和关联关系。处理前先核实当前 ERP 对合并、删除、历史单据和操作日志的具体规则。
若不支持安全合并，不要用删除一条记录的方式代替；可以先限制新增、修正字段或请服务商确认处理方案。先选一个部门或一类数据做小批次试点，完成后抽查关联单据、库存与报表。每条处理记录至少留存原记录标识、保留记录、处理原因、复核人和日期。
示例清单中的数量、耗时应以自己的试点结果填写，不能把假设数据当成实际改善成果。
我担心清理完一次之后，员工继续用表格导入或不同名称建档，重复数据很快又回来。除了看删掉多少条，我还应该记录什么，才能判断去重流程有效，并找到反复出现的原因？
不要只看删除数量。建议在试点前后使用相同口径，记录疑似重复数、人工确认的重复数、误合并数、复核耗时，以及处理后新出现的重复记录数。比如“确认重复率”可按确认重复数÷检查记录数计算，但检查范围和判定规则必须保持一致。
如果清理后新增重复仍多，优先查入口：导入模板是否允许缺少关键字段、不同岗位是否能随意新建档案、命名和编码规则是否明确、系统是否有重复提醒。问题可能在流程或权限，不一定是员工不认真。中小商家可以先选客户、商品或供应商中的一种数据试行，观察一个业务周期后再调整规则。
把新增、修改、合并的责任人和复核方式写清楚，并定期抽查；具体频率按业务量和风险确定，不必照搬统一周期。
读者评论
文中把名称相似和业务对象相同区分开来很重要，尤其商品规格、单位不同，不能只凭名称合并。
先备份、再小批量处理并检查订单和库存关联，这套步骤比较适合人手有限的中小商家。
文章提到重复数据常来自不同岗位和导入流程，说明只清理存量不够，建档权限和模板规则也要一起调整。
暂不能判断”这个处理选项很实用。遇到主体信息不全或历史记录复杂的档案，保留待复核比强行删除更稳妥。