ERP 数据录入里最容易被低估的，不是少填一个字段，而是同一条业务对象被不同人、在不同时间、用不同写法重复建档。客户名称多一个“（分公司）”、物料规格少一个字符、供应商沿用旧简称，看起来只是几行差异，后续却可能让查询、对账、统计和业务协作各自指向不同记录。我的判断是：数据去重不能只靠月底导出表格后集中清理，应该成为录入前校验、录入中复核、录入后追踪的一套日常机制。
很多企业把数据重复当成存量问题：发现重复，导出列表，人工筛选，再删除或停用。但如果新增流程没有变化，清理完成后重复项还会继续出现。真正值得优化的不是某一次清理速度，而是重复记录进入系统之前，是否有明确的识别条件和责任人。
我会把数据去重拆成四个连续环节：定义什么算同一对象、录入前查询已有记录、对疑似重复进行人工确认、处理完成后留下可追溯记录。四个环节缺一不可。只有定义没有执行，规则停留在文档里；只有系统提示没有复核，容易误判；只做删除没有留痕，则可能把历史业务关系一并破坏。
核心原则是：先确定数据身份，再决定是否合并；先控制新增入口，再处理历史存量。这比先追求自动化更重要。企业不需要一开始就拥有复杂的数据治理平台，但需要让每个建档动作都能回答三个问题：有没有相同对象、凭什么认定相同、谁来批准处理。
两条记录看起来相似，不等于它们代表同一个对象。两个客户可能名称接近，但属于不同法人；同一供应商可能有多个联系人或结算主体；同名物料可能因尺寸、材质、包装单位不同而不能合并。反过来，同一客户也可能因为简称、旧名称或录入格式差异而看起来完全不同。
因此，判重不是简单比较文本，而是判断两条记录是否指向同一业务实体，以及合并后是否会改变业务含义。名称相似度适合帮助发现疑点，不能独立作为合并依据。判断时应结合对象类别、关键字段、业务关系和企业内部规则。
| 数据类别 | 常见识别字段 | 高风险误判 | 优先处理方式 |
|---|---|---|---|
| 客户 | 统一标识、规范名称、业务主体、联系方式 | 集团公司与下属法人被合并 | 先核对主体关系，再核对业务联系人 |
| 供应商 | 主体标识、结算主体、开户信息、供货关系 | 同一品牌下不同结算主体被混为一条 | 区分供货方、开票方和收款方 |
| 物料 | 内部编码、规格型号、材质、单位、版本 | 名称相同但规格或计量单位不同 | 以编码规则和技术属性共同判定 |
| 员工或仓库 | 员工编号、组织归属、仓库编码、启用状态 | 历史停用记录被当成可删除的重复项 | 检查状态、权限和历史单据关联 |
我建议从“重复频率高、下游使用广、误合并代价大”的数据类型开始。若客户主数据每天都有新增，先规范客户建档；若物料导入量大且规格复杂，先治理物料。把所有主数据一次性纳入同一套审批，容易形成流程负担，还会让团队觉得治理只是增加工作。
一种实用的排序方式是给数据对象做风险评估：重复出现的频率、关联单据数量、错误修复难度、误合并影响范围分别打分。分数不必追求精确，它的作用是帮助团队明确先后次序，而不是把低风险对象和高风险对象用同一力度管理。
一个常见场景是销售先建客户，财务后续又按开票资料新建一条，采购再根据合同主体建立另一条。每个人都完成了自己的工作，重复记录却在部门交接中形成。问题并不一定是谁录错了，而是系统没有明确说明谁拥有建档权、其他岗位该如何申请补充信息。
另一个场景是同一对象以简称、品牌名、集团名或历史名称出现。业务人员搜索“华东制造”，财务按合同中的完整主体名称查找，两个查询都没有命中，最后分别新增。若企业没有统一命名规则，靠员工记忆去识别同一主体，实际上是在让个人承担系统治理工作。
手工新增通常一次产生一条记录，批量导入则可能把字段映射错误、空格差异、编码格式不一致和重复行一起带入系统。上传成功只说明文件通过了某种技术校验，不代表数据含义正确，更不代表记录没有重复。
我会把导入校验分成三层：文件层看列名、格式和必填字段；记录层看编码冲突、字段空值和疑似重复；业务层看新增是否合理、关键属性是否匹配。若只在导入结束后看“成功多少条、失败多少条”，就会遗漏那些格式合格、业务含义却重复的记录。
当建档需要填写很多字段、审核等待时间长，业务人员更容易通过新建记录绕过等待。此时再加一层审批，可能短期减少新增，却把业务推向私下维护表格、使用临时名称或重复申请账号等替代路径。
因此，重复管理要同时考虑控制效果和录入成本。对于低风险、可逆的字段，可以采用提醒和抽查；对于高影响主数据，则设置人工复核或受控建档。过度拦截和完全不拦截都可能让问题转移，而非真正消失。
一套新规则上线后，重复记录数量不一定立刻下降。存量数据可能有多年积累，名称规范也可能刚开始统一；如果只看系统总重复量，容易把历史遗留与新建问题混在一起。更有用的观察方式，是单独统计新建记录的疑似重复率、复核通过率和重复来源。
例如，每月新增 500 条记录，发现 20 条疑似重复，与存量库里仍有 2,000 条历史疑点，是两种不同问题。前者反映新增入口的控制效果，后者反映历史治理工作量。它们需要不同的负责人和处理节奏，不适合放在同一张“问题总数”里比较。
名称只是识别线索，不是所有数据对象的唯一身份。两个同名客户可能是不同地区的独立法人；同一家公司则可能存在全称、简称、旧称和品牌名。物料更不能只按名称判断，因为型号、材质、包装规格和计量单位都可能改变业务含义。
我的处理逻辑是先区分“硬条件”和“辅助条件”。硬条件通常是经过企业确认的关键标识，例如内部编码、主体识别信息或特定组合字段；辅助条件可以是名称相似、电话相同、地址接近等。硬条件冲突时应阻止自动合并，辅助条件重合时应生成待复核线索。
模糊匹配适合从大量数据中筛出可疑候选，但相似度分数不等于业务确认。名称中一个字符差异可能是录入错误，也可能代表不同规格；联系方式相同可能是总机、代办人或共享服务号码。将算法结果直接转成合并动作，容易把“发现疑点”误当成“确认身份”。
如果系统能够配置匹配规则，可以先把结果分成三类：明确不重复、需要人工确认、满足已批准规则的高置信重复。阈值应通过本企业样本验证，并检查误报和漏报。没有足够样本时，宁可先把模糊匹配用于提示和候选排序，不应默认自动合并。
停用可以减少后续误选，但不等于重复关系已经理清。旧记录可能仍被历史订单、凭证、库存流水或报表引用。直接删除或合并，可能影响历史追溯、权限判断和业务查询。即使系统允许操作，也要先确认关联数据会怎样处理。
治理结果至少要说明：保留哪条作为主记录、其他记录如何标记、历史关联是否迁移、谁批准了处理、处理时间和理由是什么。若系统没有合并功能，可以采用受控停用和备注关联，但要明确这只是风险控制方案，并非等同于完整合并。
集中清理容易形成“重复项很多、影响范围不清、处理人不知道业务背景”的局面。随着重复记录进入订单、采购和报表，判断难度通常会升高。日常校验不一定要每条都审批，但应尽量在记录刚创建、关联关系尚少时发现疑点。
这并不意味着要每天开会清查全部数据。更现实的做法是把新增校验嵌入已有录入动作，把待复核项放进固定工作队列，再按风险安排抽查。日常管理的目标不是把重复风险降到绝对为零，而是让问题尽早暴露、责任清晰、处理可追踪。
必填项可以减少空值，却不一定能提高真实性。员工可能用“无”“其他”或重复填入同一信息通过校验。字段越多，填报负担越大；若字段与业务决策无关，增加它们只会让录入更慢、绕过流程的动机更强。
每个判重字段都应该回答一个问题：它能否帮助区分不同对象，是否容易获取，错误填写会造成什么后果，是否有明确维护责任。无法回答这些问题的字段，不应仅因为“看起来完整”就被设为强制项。
客户、供应商、物料、员工并不存在通用的判重公式。每一类都需要一张简短的规则卡，至少写明识别字段、辅助字段、禁止自动合并的情形、复核角色和处理后状态。规则卡不必成为厚重制度，关键是录入人员能够在建档时查到，并能据此作出一致判断。
例如，客户规则可以把主体标识作为强证据，把名称相似作为搜索线索；物料规则则需要同时检查编码、规格和单位。供应商还应辨别合同主体、开票主体和收款主体是否一致。若这些角色在企业业务中可以不同，就不能简单用一组字段把它们压成一个记录。
我倾向于使用四级处理：无匹配、可能相似、需要业务确认、确认重复。前两级由系统或表格筛选，后两级由数据责任人根据业务证据决定。这样的分层既保留了自动化的效率，也避免把模糊结果直接变成不可逆的数据操作。
对于已经确认的重复记录，还要把“记录身份”和“业务关系”分开处理。确认两个档案代表同一对象，不代表所有字段都应简单相加；仍需决定保留的名称、编码、负责人、状态以及历史备注。重要字段冲突时，应让有业务责任的人参与，而不是由数据管理员单独猜测。
不同字段错误的代价差异很大。把同一联系人重复建立，通常可以通过关联或修正处理；把两种规格的物料合并，可能影响采购、库存和成本核算；把两个结算主体合并，则可能引起财务对账问题。校验力度应由潜在影响决定，而不是由录入量决定。
可以采用“风险分层、流程分层”的方式：低风险数据使用重复提示和抽样复核；中风险数据要求关键字段确认；高风险数据在新建、修改和合并时设置双人复核或审批。这里的重点不是审批越多越好，而是把不可逆或影响面广的动作置于更严格的控制下。
只在新建时查重并不够。已有记录修改名称、编码或关键身份字段后，可能让原来的匹配关系失效；批量导入可能跳过手工建档的提示；合并操作则需要重新检查关联数据。完整规则应覆盖对象生命周期，而不是只检查一个页面。
| 业务动作 | 主要检查点 | 推荐控制方式 | 需要留下的记录 |
|---|---|---|---|
| 新建 | 已有记录查询、关键字段完整性 | 录入前搜索；疑似项转复核 | 查询结果或复核结论 |
| 修改 | 身份字段变化、编码冲突、影响范围 | 检查变更前后差异；高风险字段受控 | 修改原因、经办人、确认人 |
| 批量导入 | 模板映射、重复行、系统内已有记录 | 先预检，再小批量验证，导入后抽查 | 文件版本、导入批次、异常处理结果 |
| 合并或停用 | 主记录选择、历史引用、业务关联 | 先确认影响，再由授权人员执行 | 处理依据、影响范围、操作时间 |
删除数量是清理动作的结果，不是数据质量的完整指标。若每月删掉很多重复项，可能说明发现能力强，也可能说明入口控制失效。建议至少同时观察新增疑似重复率、复核准确情况、异常处理时长和重复来源，避免团队为了降低数字而少报问题。
可把新增疑似重复率定义为“当期确认的新增重复记录数 ÷ 当期新增记录总数”。分母、统计周期和“确认重复”的口径要固定。对于不同类别数据，最好分别统计，不要把客户、物料和员工记录混成一个平均数，否则高风险类别的问题可能被低风险类别稀释。
以下是一个情景模拟案例，用于演示判断过程，不代表某家企业的真实经营数据。某公司在一个月内新增 240 条客户档案，复核发现 18 条可能与现有记录相似。其中，部分记录使用简称，部分用集团名称，另有几条只有相同电话。
如果只按名称相似度处理，团队可能会把集团与下属公司合并，也可能漏掉名称差异很大的同一主体。于是我们不先问“这两个名字像不像”，而是把问题拆成主体是否一致、业务关系是否一致、是否存在可验证的共同标识。
候选表不需要复杂，至少包含原记录、新记录、关键字段差异、关联业务、建议处理方式和复核人。名称相似但主体标识不同的，先标记为“不得合并”；主体信息相同、名称写法不同的，进入人工确认；只有共享电话、地址或联系人时，则继续补充资料。
在这个模拟场景中，18 条疑似项经过复核后，10 条确认是同一客户的不同写法，5 条属于集团与下属主体关系，不能合并但需要建立关系说明，3 条因证据不足暂缓处理。这个结果说明：疑似命中数不应被当作重复数，复核本身是判重流程的一部分。
| 复核类别 | 模拟数量 | 处理决定 | 判断依据 |
|---|---|---|---|
| 确认同一主体 | 10 条 | 选定主记录，关联或按系统规则合并 | 关键主体信息一致，名称差异可解释 |
| 关联但非同一主体 | 5 条 | 保留独立记录，补充集团或组织关系 | 主体不同，但存在业务关联 |
| 证据不足 | 3 条 | 暂缓合并，补充核验材料 | 仅名称或联系方式相似，无法确认身份 |
复核还要追问重复从哪里来。若 10 条确认重复里，主要原因是销售和财务各自建档，就应该统一建档入口或明确申请流程；若重复集中出现在批量导入，就应该检查模板和导入前筛查；若主要由简称和全称引起，则要完善命名规范和搜索方式。
假设这 10 条确认重复中，6 条来自不同部门分别建档，3 条来自导入文件重复行，1 条来自历史名称未登记。这个分布不能说明所有企业都会有相同比例，但可以示范如何把“重复数量”转化成“流程原因”。每种原因对应的改进动作不同，不能用一次全库清理代替原因分析。
规则上线前，可以选一个部门或一个数据类别试运行两到四周，记录新增量、疑似命中、人工复核时间和误报情况。若命中项过多而确认重复很少，说明规则可能过宽；若业务人员仍频繁发现系统未提示的重复，则可能是关键字段缺失或搜索条件不适合现场使用。
这类试运行的价值不在于制造漂亮的提升比例，而在于发现规则和真实工作之间的差距。复核人员应记录“为什么判为同一对象”或“为什么不是”，这些理由经过整理后，可以补进规则卡和培训材料，减少下一轮重复争议。
建档人不应只依赖完整名称搜索。可以按规范名称、常用简称、关键编号、联系方式或规格组合进行查询，但不同字段的证据力度要区分。搜索结果为空，不代表系统里一定没有同一对象；搜索结果相似，也不代表一定是重复。
一个轻量流程可以是：先搜索关键字段；发现候选项后核对身份信息；确认是同一对象则申请补充或修改已有档案；无法确认时提交复核，不要为了赶进度另建一条“临时记录”。如果业务确实需要先推进，应设置可识别的临时状态和责任期限，避免临时档案长期转成正式数据。
更改名称、编码、主体信息或物料规格时，要评估变更是否影响已有匹配关系和历史业务。特别是编码调整，可能牵涉条码、报表、订单引用和外部文件。不能只因名称写错就直接覆盖，而不检查这条记录是否已经被其他流程使用。
我建议变更申请至少说明原值、新值、修改原因、关联业务和确认人。对于不改变对象身份的格式修正，可以走简化流程；如果变更可能让两个记录变成同一对象，或让一条记录代表不同对象，则应先核实，再处理历史关联。
批量导入前先处理文件内部重复，再与系统现有记录比对，最后检查字段格式和必填项。导入文件中可能存在隐藏空格、全半角差异、日期格式混用、编码前导零丢失等问题。技术格式看似正常，仍可能改变对象身份或造成匹配失效。
如果企业当前没有自动预检能力，可以在受控表格中先做基础清洗和候选筛查。重要的是把人工检查做成有标准、有责任人的步骤，而不是默认某个 ERP 一定提供模糊匹配、自动合并或批量迁移等功能。具体能力和操作路径必须以实际系统配置及厂商说明为准。
处理重复项时，先确定哪条记录作为后续主记录。选择依据可以包括编码规范、业务使用频率、资料完整度、历史业务关联和责任部门意见。不能只选择创建时间较早的一条，因为旧记录可能字段残缺，也不能只选择信息最多的一条，因为它可能包含未经确认的错误内容。
确定主记录后，再核对历史单据、报表引用、权限和外部接口。若系统支持正式合并，应在测试或确认影响范围后执行；若不支持，应按企业规则停用冗余记录、补充关联说明，并限制继续被选用。每次处理都应保留依据，尤其是无法自动迁移关联关系的情形。
每日管理不需要对全库重新查重。数据责任人可以处理新增疑似项、导入异常和业务人员提交的候选记录；主管每周或每月查看未处理队列、超期项和高风险合并申请。具体周期应根据新增量、风险和人手设定，不存在对所有企业都适用的固定频率。
定期复盘要问“重复为什么产生”，而不是只问“清掉多少条”。如果问题来自权限分散，就调整建档边界；来自模板不统一，就统一数据模板；来自业务习惯，就改善搜索入口和培训；来自字段缺失，就重新审视必要字段。只有原因被修正，清理动作才会减少重复发生。
小团队通常不需要复杂的审批矩阵。可以先指定一名主数据责任人，确定建档入口和关键字段，要求新增前搜索已有记录。疑似重复通过简短复核表或工作群登记，但最终结论仍应记录在可查询的位置，不能只留在聊天记录里。
这种做法的优点是上手快、维护成本低；局限是依赖少数人的经验。团队扩大、数据量增加后，需要把口头判断沉淀成规则卡，并检查责任人是否成为流程瓶颈。不要因为当前规模小，就把所有规则写成只有某个人看得懂的个人经验。
批量建档多的企业，优先治理文件模板、字段映射、系统内匹配和导入后抽查。可以按批次设置风险级别：标准模板、低风险字段通过自动检查；关键主体信息或物料规格变化则进入人工确认。这样比所有行都走同一层审批更能兼顾速度和风险。
但批量检查也有边界。字段标准不稳定时，自动规则容易产生大量误报；外部数据来源不可靠时，格式校验通过也不代表主体真实。企业应先固定数据口径和模板，再逐步增加自动化程度，避免把不成熟的规则快速放大到大量记录上。
如果存量数据量大、关联关系复杂，不建议一开始就全库合并。第一步应先控制新增，避免清理期间继续产生新重复；第二步按风险和业务使用频率分批处理；第三步对证据不足的记录保留待核实状态，不要为了追求“清理完成率”做勉强合并。
历史治理可以按业务影响排序：仍被订单或库存引用的数据优先核验；长期停用且无关联的数据可以采用较轻的处理方式；涉及财务、结算或审计追溯的记录则需要更谨慎的审批和留痕。具体分类要结合企业数据模型和制度，不能只凭导出表里的状态字段判断。
当复核人手不足时，可以采用分层复核：关键主体字段冲突或物料属性敏感的记录全部复核；低风险记录采取抽样；重复发生较多的部门或导入批次提高抽查比例。这样能把有限精力集中在高影响事项上，同时保留发现漏报的机会。
抽查不是降低责任，而是把责任从“每条都由主管签字”转向“规则是否有效、异常是否及时升级”。抽查比例、频率和升级条件应根据业务量调整，并记录抽查发现的问题。一旦出现系统性漏判，应临时提高检查强度，直到原因确认并完成修正。
| 企业情形 | 优先控制点 | 适合的处理力度 | 不建议的做法 |
|---|---|---|---|
| 团队小、数据量少 | 统一入口、关键字段和责任人 | 建档前查询，疑似项人工复核 | 一开始建设复杂审批层级 |
| 导入批次多 | 模板、文件内重复、系统内匹配 | 分批预检、异常单独处理、导入后抽查 | 只看导入成功率 |
| 历史存量复杂 | 新增止损、业务关联、主记录选择 | 按风险分批治理，保留待核实项 | 为追求清理率批量强制合并 |
| 复核资源有限 | 高风险字段和高影响对象 | 风险队列、抽查和异常升级 | 所有记录一律审批或完全不检查 |
自动化的价值是减少重复搜索和初筛时间，不是取代业务判断。字段可靠、身份规则明确、误判代价可控的场景，可以逐步自动校验；只有名称相似、字段缺失或业务关系复杂的场景，应保留人工判断。若每次自动处理都需要大量人工纠错，说明自动化边界设得过宽。
人工复核也不是万能方案。若没有统一口径，不同人可能对同一组记录作出相反判断；若工作队列没有时限，疑似记录会长期堆积。因此，自动规则负责一致地筛选，人工负责解释业务含义，数据责任人负责把复核结论转化成规则改进，三者应形成闭环。
可以先抽取一个数据类别，观察一周内新增量、疑似重复量、最终确认量、人工复核耗时和重复来源。基线不必覆盖全部历史数据，也不必马上用于考核。它的作用是让团队知道问题主要来自新增录入、批量导入、命名差异还是权限分散。
统计时要统一口径。例如，“疑似重复”只表示规则命中，“确认重复”必须经过业务核实；“处理完成”还要说明是合并、停用、关联还是补充资料。不同状态不要合并成一个数字，否则管理者无法判断流程在哪一步卡住。
规则卡写清数据对象、关键识别字段、辅助字段、禁止自动合并情形、复核人和记录要求。异常清单则记录候选档案、差异字段、业务判断、处理结果和处理时间。两张表可以先用企业现有工具维护，不必等到系统改造完成才开始。
试行期间，每周挑选几条误报和漏报案例进行复盘。误报说明匹配规则可能过宽，漏报说明字段或搜索方式可能不足。比起不断增加规则数量，更重要的是让规则能够被录入人员理解、被复核人员执行，也能在出现争议时追溯原因。
当人工查询量大、疑似项集中、规则稳定且重复问题已影响业务时，再评估系统配置或开发需求。需求描述要写业务场景和验收条件，例如“新建客户时按哪些字段提示候选记录”“谁可以确认”“误报如何处理”“操作是否留痕”，不要只写“增加自动去重功能”。
系统能力因产品、版本、权限和配置不同而异。自动提示、唯一性校验、批量合并、操作日志等功能都应通过实际环境或官方说明确认。上线前需要测试误报、漏报和历史关联影响，不能把某一套系统的菜单路径或功能假定为所有 ERP 的通用能力。
我在整理 ERP 基础资料时，发现同一客户有全称、简称和旧名称，光看名称很难确定是不是同一家。想减少重复，又担心把不同主体误合并，应该怎样设定判重规则？
不要只凭名称相同或相似就合并。名称可能有简称、历史变更或录入差异；相反，同一主体也可能因名称写法不同而被重复建档。判重字段应按资料类型制定，并把“完全重复”和“疑似重复”分开处理。例如，客户资料可优先核对统一社会信用代码等主体标识，再参考名称、电话和地址；
物料资料则应结合内部编码、规格型号、单位等字段。具体字段要根据企业的业务规则和数据结构确定，不能照搬一套通用条件。可将规则分成三级：关键标识一致，列为高置信度重复并由责任人复核；名称相似且另一个字段也吻合，列为疑似重复；只有名称相近，则仅提示检查，不自动合并。这样比单纯按名称查重更能降低误合并风险。
我不想每个月都花时间整理一遍重复客户和物料，但日常录入时业务人员又常常赶着建档。有没有一种不增加太多操作负担的办法，让重复记录尽量在新增时就被发现？
把查重前移到“新增之前”，通常比月底统一清理更容易控制影响范围。录入人员先按关键字段搜索已有记录，确认没有匹配项后再新增；遇到相似记录时先标记待核实，不要为了赶进度直接另建一条。可以用一张简短的录入检查表落实：是否检索过现有资料、关键识别字段是否齐全、命名和编码是否符合规范、疑似重复由谁复核。
检查项应尽量贴合实际业务，避免让所有普通资料都经过复杂审批。如果 ERP 支持保存前校验，可按企业规则配置提示或拦截；如果不支持，也可以用共享待核清单和指定责任人承接。系统能力与管理流程要分开确认，不要默认每套 ERP 都支持相同的查重功能。
我准备把一批客户或物料资料从表格导入 ERP，担心文件里本来就有重复项，也怕导入后和系统已有记录撞上。除了检查列名和格式，导入前后还应该核对哪些内容？
批量导入可以分成导入前、导入时和导入后三段检查。导入前先统一字段格式、必填项、编码规则和空值写法，再在表格中按关键标识查重；同时将名称相似但关键字段不一致的记录单独列出，交给业务人员确认。导入时先用小批次验证字段映射和系统反馈，再决定是否导入其余记录。
比如一份 100 行的测试文件，可以先抽取少量代表性记录验证编码、单位、分类等字段是否落在正确位置；这只是操作示例，不代表适用于所有系统的固定批量或效率指标。导入后核对源文件行数、成功新增数、失败数和异常记录，并抽查关键字段及关联关系。
若系统没有预览或重复提示功能，可先在表格中完成预检，并保存原文件、导入结果和异常处理记录，便于追溯。
我查到几条看起来重复的资料，但其中有的已经关联过业务单据，直接删除似乎不稳妥。想知道处理重复记录时，怎样判断保留哪条，以及怎么避免影响历史查询和后续使用？
先确认记录是否确属同一业务对象，再决定处理方式。不能只看名称：应核对关键标识、业务部门的使用情况及必要的关联信息。信息不足时先标记待核实，不要把“疑似重复”当成“确定重复”。确认重复后，选定一条作为后续使用的主记录，并核对系统对历史单据、权限和关联资料的处理方式。
若记录已有业务关联，删除或合并可能影响查询与追溯；在没有确认系统规则前，优先考虑按内部制度停用旧记录，并在备注或台账中记录替代关系。处理前保存清单并明确复核人，处理后抽查相关单据和报表，再记录重复来源。若重复主要来自不同部门各自建档，下一步应统一新增入口和责任分工；否则，单次清理后仍可能再次出现。
读者评论
把名称相似当作线索、而不是合并依据，这个区分很重要，尤其客户和供应商可能涉及不同法人或结算主体。
文章把录入前查询、人工复核和处理留痕连成流程，也指出建档权限不清会造成重复，实际落地时责任划分值得优先明确。
文中的数量和风险评分注明是情景模拟数据，这点比较客观；企业采用类似指标时，仍需根据自身记录验证判重规则。