ERP 批量导入最容易让人误判的一点是：文件上传成功，不等于数据已经正确进入业务。导入结果显示“成功”，仍可能出现商品单位错配、客户重复、库存归属错误，或期初余额与财务核对不上的情况。我的判断是，批量导入不是一次上传动作，而是一条由数据口径、字段映射、系统校验和业务验收组成的责任链；只盯着导入按钮，往往会把真正的问题留到上线后。
ERP 通常会对文件格式、字段类型、必填项等进行校验，但系统能够读取字段，不代表字段含义与企业的业务口径一致。例如，表格中的“可用库存”可能包含待检商品，而系统中的“可用量”可能不包含；表格中的“客户名称”也不一定是系统用来识别客户的唯一字段。
因此，我会把结果拆成三个层次检查：文件能否被读取、记录能否被系统接受、导入后的业务数据能否通过核对。只有第三层也通过，才适合把这批数据交给后续业务使用。
“导入成功率”也要说清口径。按文件行数计算的成功率，可能掩盖关键字段错误；按业务对象核验的准确率更有价值，但需要额外制定抽查规则和责任人。
导入前应约定验收口径，而不是等到系统报错后才开始讨论。例如，客户主数据导入完成，至少要明确：应导入多少条、哪些字段必须一致、重复客户如何识别、未匹配的联系人如何处理，以及谁有权确认异常记录。
库存数据则要进一步明确盘点时点、仓库范围、批次或序列号要求、冻结库存是否纳入，以及系统中的数量代表实物数还是可销售数。没有这些定义，即使数量完全相同，也可能不是同一口径。
实操原则：先把验收条件写成可以检查的规则，再把规则转换为表格校验、系统配置或人工复核步骤。没有规则的“准确”很难复核，也很难追责。
批量导入前，我建议先选择一批具有代表性、但出错后影响可控的数据进行试导。试导样本不能只挑最干净的记录，最好覆盖正常记录、边界值、特殊字符、缺失关联、重复候选和不同组织等情况。
如果试导只验证了“最简单的十条”，就容易得到虚假的安全感。样本应覆盖系统规则的边界；全量数据较大时，再按业务范围拆批，避免一个异常把整个文件卡住，也避免一次误操作影响所有主数据。
业务部门的表格通常围绕日常工作设计，列名可能是团队内部习惯用语；ERP 模板则需要把数据映射到明确的数据对象和字段。一个业务字段在不同系统中可能拆成多个属性，也可能要通过代码而不是展示名称来识别。
例如，业务表格写“华东仓”，系统里可能同时存在“华东中心仓”“华东退货仓”和“华东样品仓”。如果导入时只按名称相似度匹配，数据可能被分配到错误仓库。字段名称相似，不代表字段语义一致。
日期可能同时包含文本格式和日期值，编码可能因表格软件自动转换而丢失前导零，金额可能包含千位分隔符或货币符号。屏幕上看起来相同的“00125”，在文件中可能已被识别为数字 125。
这类问题的隐蔽之处在于，人工浏览几行通常发现不了。应检查列的数据类型分布、异常值和长度，而不是只看样例单元格。对于编码字段，尤其要先确认它是标识符还是可参与运算的数值。
空单元格、空格、公式返回的空字符串、“无”“不适用”等文本，可能被系统分别处理。更重要的是，空值的业务含义可能不同：有的表示未知，有的表示暂缺，有的表示不适用，还有的表示清除原值。
在更新型导入中，这些差异可能影响已有数据。如果系统把空白解释为覆盖，原有内容可能被清空；如果把空白解释为忽略，企业又可能误以为数据已经更新。应先确认具体导入模式和系统规则，不能凭表格视觉效果推断。
以客户为例，名称可能因简称、地区后缀、标点或历史更名而不同；反过来，两家不同法人也可能使用相同简称。用名称作为唯一判重依据，会同时产生误合并和漏判重。
判重规则应由业务对象决定。客户可结合内部客户编号、统一识别信息、组织归属等字段判断；商品可结合商品编码、规格和单位；供应商则可能需要结合供应商编号与主体信息。哪些字段可用于唯一识别，需要由数据责任人确认。
系统提示“字段不合法”，可能是字段映射错误、值超出配置范围、编码不存在，或当前用户没有对应权限。提示“关联对象不存在”，也可能是主数据尚未导入，而非这一行本身的数据完全错误。
因此，排查时不应只在报错行上反复改值。先看错误是否集中在某一列、某一批次、某一组织或某种业务类型，再判断是系统性问题还是单条异常。错误分布往往比单条提示更接近根因。
首先明确导入的是客户、商品、供应商、库存、期初余额，还是历史业务单据。不同对象的校验逻辑和风险等级不同，不建议为了省事把所有数据混在同一个批次中处理。
同时确定数据的有效时点。库存快照是某日盘点结果，还是实时业务余额？客户状态取数到哪个日期？期初数据从哪一天开始生效？如果来源系统还在持续变更，必须明确冻结时间或增量补录办法。
我会把数据范围写成可复核的描述，例如“导入截至某日盘点完成后的三座仓库现存数量，不包含已冻结待处理批次”，而不是只写“导库存”。范围越具体，后续越容易解释差异。
数据整理人不一定有权判断字段含义。例如财务人员可以确认账面金额，仓库负责人更适合确认库存状态，销售运营可能负责客户分类。若没有明确的字段责任人，问题会在部门之间来回传递。
| 数据对象 | 需要确认的典型字段 | 建议确认角色 | 验收关注点 |
|---|---|---|---|
| 商品主数据 | 商品编码、规格、单位、分类、启用状态 | 商品资料负责人、采购或仓储代表 | 编码唯一性、单位换算、分类归属 |
| 客户主数据 | 客户编号、主体名称、区域、状态、负责人 | 销售运营或客户资料负责人 | 主体识别、重复候选、负责人归属 |
| 供应商主数据 | 供应商编号、主体名称、结算条件、状态 | 采购、财务或供应商管理负责人 | 主体信息、付款口径、停用记录 |
| 期初库存 | 仓库、商品、批次、数量、单位、成本 | 仓储与财务共同确认 | 盘点时点、账实一致、单位和成本口径 |
表格里的字段和角色仅是常见示例，具体归属要以企业制度和所用 ERP 配置为准。尤其是库存、成本和期初余额，业务与财务的确认通常不能由单一整理人员代替。
字段映射表应记录来源列、系统字段、业务含义、数据类型、是否必填、允许值、转换规则、责任人和核验方法。它不仅是上传前的准备文档，也是出现争议时的依据。
| 来源列 | 系统字段 | 转换或校验规则 | 确认人 | 核验方式 |
|---|---|---|---|---|
| 货品编码 | 商品唯一编码 | 按文本处理，保留前导零，不允许重复 | 商品资料负责人 | 与商品主数据编码清单比对 |
| 入库单位 | 库存单位 | 仅允许已配置单位，换算关系需事先确认 | 仓储负责人 | 抽查商品单位及换算规则 |
| 盘点数量 | 期初数量 | 统一小数位和负数处理规则 | 仓储与财务 | 与签字确认的盘点汇总表核对 |
常见的返工原因不是系统复杂，而是团队不知道哪份表才是最终版本。原始导出文件、清洗工作文件和系统上传文件应分开保存，并记录文件名、生成日期、修改人和批次范围。
不要直接覆盖唯一的原始文件。可以将原始资料设为只读，清洗过程另存版本，正式上传文件保留校验记录。文件命名建议包含对象、范围、日期和版本，例如“商品主数据_国内_20260928_v03”，避免出现“最终版”“最终版2”这类无法追溯的名称。
如果系统提供专用导入模板，应先下载当前版本并保留原有列名和结构。自行重建模板容易漏掉隐藏必填字段、系统识别列或特定格式要求。若确实需要转换格式，也应在工作文件中完成，最后再映射回系统模板。
模板的版本要与当前系统环境匹配。系统升级、模块配置变化或字段自定义后，旧模板未必仍然有效。模板从哪里下载、是否支持增量导入、是否允许更新已有记录，都应以当前系统文档和管理员确认结果为准。
商品编码、客户编号、条码等通常用于识别对象，不应因为它们只由数字组成就自动转成数值。导出或清洗时，应检查前导零、科学计数法、长度截断和不可见空格。
日期字段应统一为系统接受的格式，并确认时区、日期边界和时间精度。金额与数量字段要确认小数位、负数含义、千位分隔符和币种。不能把“看起来整齐”当作规则，应通过模板说明或测试导入验证。
机器可查的内容适合批量检查，例如空值、重复编码、日期格式、字段长度、数值范围和非法字符。业务需判断的内容包括两个客户是否同一主体、某仓库是否应纳入范围、某商品是否停用仍需保留等。
自动化适合筛出候选问题，不适合替代业务判断。特别是去重，不要先按名称删除重复行，再让业务部门承担误删后果。更稳妥的做法是输出“确定重复”“疑似重复”“无法判断”三个队列，分别处理。
有些数据必须先有被引用对象才能导入。例如业务单据引用客户、商品、组织或仓库。如果先导入依赖对象，系统可能提示编码不存在；即使文件本身无误，也无法建立关联。
建议先梳理对象之间的依赖关系，再确定批次顺序。常见思路是先准备组织、仓库、单位、商品、客户和供应商等基础对象，再处理依赖它们的业务记录；但实际顺序取决于系统模块、企业配置和数据对象关系，不能照搬固定清单。
试导样本应能验证规则边界。除了正常记录，还要挑选最长字段、最小或最大允许数值、特殊字符、缺失关联、重复候选、停用对象和跨组织数据。这样做的目的不是追求样本数量，而是尽早暴露“只有某类记录才会触发”的问题。
每次试导只调整一类规则，记录修改前后差异。如果同时改了字段映射、编码和导入模式，即使结果改善，也很难判断是哪项变化起作用。小步验证会多一点记录工作，却能减少盲目返工。
如果错误集中在同一列，优先检查字段映射、格式和允许值；如果错误集中在某一业务范围，检查该范围的数据口径、组织权限或配置；如果错误分散且提示各不相同，再按错误类型分组处理。
下表是一套排查顺序示例，不是所有 ERP 的标准错误解释。系统提示可能因版本、配置和权限而不同，最终要对照当前产品文档、导入日志和管理员确认结果。
| 现象 | 先查什么 | 再查什么 | 避免的做法 |
|---|---|---|---|
| 整列字段被拒绝 | 模板列名、字段映射、数据类型 | 字段配置、导入模式、权限 | 逐行手工改值却不检查共同原因 |
| 部分记录提示编码不存在 | 编码是否保留前导零、主数据是否已存在 | 编码来源和批次依赖顺序 | 随意新建同名编码绕开关联错误 |
| 重复记录未被接受 | 系统的识别字段和重复规则 | 新增、更新或覆盖模式 | 不确认规则就批量删除疑似重复行 |
| 上传显示成功但业务数量不对 | 过滤条件、范围时点和导入行数 | 单位换算、状态字段及汇总口径 | 只依赖上传结果提示，不做业务对账 |
正式导入前，明确每批的范围、操作者、开始时间、文件版本和异常处理人。分批不只是为了方便上传，也是为了限制出错影响面。如果一个批次涉及多个组织或多类对象，应评估能否按风险拆开。
同时约定停止条件，例如关键字段异常超过预设阈值、关联对象大量缺失、导入后数量与来源差异超过允许范围时暂停后续批次。阈值需由业务风险和系统能力共同确定，不存在适用于所有企业的统一数值。
为避免把虚构结果包装成真实项目，下面使用一个明确标注的情景模拟：一家拥有两个仓库的贸易企业，准备导入期初库存。企业提供的表格包含商品编码、仓库、盘点数量、单位和批次信息。示例中的数量、错误数和耗时均为演示数据，不构成行业基准，也不表示任何具体系统的真实表现。
这个案例要说明的不是“某种方法一定能节省多少时间”，而是如何从原始表格建立可验证的处理过程。实际操作中，系统模板、字段名称、批次管理和导入结果需要以企业当前使用的 ERP 为准。
模拟数据共有 1200 行，汇总数量为 48,600 件。乍看之下，仓库总数与盘点汇总表一致，但抽查发现三个风险：部分商品编码被表格软件去掉前导零；同一商品出现在两个仓库，来源表没有明确仓库编码；有些商品的盘点单位是“箱”，系统库存单位是“件”。
如果只核对总数，前导零丢失的商品可能被系统识别为另一个编码；仓库名称匹配错误可能让库存落到错误地点；单位换算不清则可能造成数量放大或缩小。总量相等只能证明某个汇总关系相等，不能证明每个商品、仓库和单位组合都正确。
团队先冻结盘点时点，并确认本批只包含盘点确认的可用库存，不包含待检和冻结库存。仓储负责人确认仓库编码清单，商品资料负责人确认编码应按文本保存，财务与仓储共同确认单位换算和库存成本口径。
随后将来源表拆成原始文件、清洗工作表和导入模板三份。原始文件不作覆盖；工作表保留来源行号；导入模板只保留系统要求的字段。这样一旦出现异常，可以从系统错误回到具体来源行，而不是在最终文件中猜测记录来历。
模拟团队先做 30 行边界样本，覆盖前导零编码、不同仓库、箱与件换算、空批次字段及负数候选。试导后发现，前导零编码必须作为文本处理；仓库需使用系统认可的编码；未确认换算关系的商品不能直接把箱数当作件数导入。
这一步没有直接把所有异常自动修正，而是把记录分成三类：规则明确、可按映射转换的记录；需要业务人员确认的记录；不应进入本批次的记录。自动转换仅用于已有书面规则支持的情况，避免程序替业务做未经授权的判断。
完成映射确认后，模拟团队按仓库分批导入，并分别核对每批的来源行数、成功记录数、失败记录数和关键数量汇总。某一批的导入行数与文件行数相符，并不能自动证明数量正确；还需要按商品和仓库维度对比来源与系统结果。
若某商品导入前为 12 箱，系统单位为件，只有在确认换算关系后才能比较导入数量。复核时要检查换算前后的数量、单位和库存价值口径，不能把原表合计直接与系统中不同单位的合计相比较。
这个演示案例中，最终验收所需的证据包括：确认过的范围说明、字段映射表、原始与上传文件版本、导入批次记录、系统返回的成功与失败信息、按仓库和商品核对的结果，以及异常处理审批记录。
如果只留下“导入成功”的截图，后续发现账实差异时，很难确定问题来自盘点、清洗、单位换算还是字段映射。批次记录的价值是把结果连接回过程，使错误能够定位、解释和纠正。
如果企业使用序列号、效期、批次成本、寄售库存或多计量单位管理，普通的“商品，仓库，数量”核对不足以验收。若库存还与采购在途、销售预留或财务成本计算联动，也需要把相关业务状态纳入迁移方案。
同样，不应把模拟中的批次数量、调整数或流程时间当作实际项目承诺。不同 ERP 的模板、导入限制和事务处理方式不一样，正式方案应先在测试环境或受控小批次中验证。
导入后先检查预期记录数、实际新增数、更新数、失败数和忽略数。各系统对“成功”“跳过”“更新”的统计方式可能不同，应确认统计口径，避免把重复跳过误算成新增成功。
随后按业务对象选择关键字段核验。商品主数据可检查编码、名称、单位和状态；客户主数据可检查主体、负责人和区域；库存可检查仓库、商品、批次、单位和数量。抽查不应只看随机样本，还应覆盖高价值、边界值和异常修正记录。
汇总对账擅长发现整体差异，例如某个仓库的数量合计不一致；明细抽查擅长发现少数记录错位，例如某个商品被分配到相似名称的仓库。只做汇总可能掩盖一增一减相互抵消的错误，只做少量抽查又可能漏掉整批范围问题。
我建议至少保留两个层次的核对结果：一是按业务维度汇总的数量或金额差异；二是关键字段逐条抽查和异常行复核。对于财务期初、库存和高风险主数据，抽查比例与复核深度应按业务风险提高，而不是统一使用一个比例。
每个异常至少应有问题类型、来源行号、责任人、处理意见、审批记录和复核结果。状态可按“待判断、待修正、待复核、已关闭”管理，避免问题被修正后无人确认，或重复修正造成新的偏差。
批次关闭之前，应检查是否仍有未处理错误、是否存在未审批的人工改值，以及业务负责人是否确认了差异。若系统支持撤销、回滚或覆盖，也要先验证其适用范围和影响，不能默认所有导入都可以安全撤回。
差异可能来自源数据错误、业务范围理解不一致、单位换算、模板映射、系统配置、操作权限或导入后的业务变动。复盘时应先把差异归类，再判断由谁处理。
如果把所有差异都写成“导入错误”，团队容易只修改文件，却不修订盘点口径或主数据流程。相反，如果发现某种错误在不同批次反复出现，就应更新字段规则、数据校验或责任流程，而不是每次靠人工补救。
如果只有少量记录、字段关系简单、业务影响较低，使用系统模板并由负责人逐条复核可能更直接。为几十条数据搭建复杂的清洗链路，成本可能高于收益。
但“数量少”不代表可以省略备份和范围确认。客户、供应商、库存、财务期初等数据即便只有少量记录，也可能造成后续业务影响。应根据影响程度决定审核深度，而不是只按行数决定。
如果数据规模较大，且字段规则稳定、来源结构相对固定，可以用表格公式、脚本或数据处理工具做可重复的格式检查和转换。优先自动化确定性规则，例如去除首尾空格、标准化日期、检测重复编码，而不是自动判定业务语义。
自动处理需要保留输入、输出和规则版本。规则变化时，应能说明哪些记录受到影响。不要只保存最终文件，否则后续无法判断结果是由源数据变化还是清洗逻辑变化造成。
如果单据依赖客户、商品、组织、仓库或账户等多个对象，先做依赖清单和编码核对，再确定导入顺序。对于无法匹配的记录，应保留为待处理队列，不要为了让系统接受数据而随意创建临时对象。
临时编码可能在短期内绕过校验，却会把数据质量问题扩散到订单、库存和财务流程。只有在有审批、命名规则和后续清理责任的前提下，才考虑受控的临时对象方案。
时间紧并不会降低数据错误的业务影响，反而更需要缩小试错范围。如果系统是否支持回滚、覆盖或撤销尚未验证，就不要假设错误可以轻松恢复。可以先导入低风险、规则明确的数据，再处理高影响对象。
关键数据应预留核对时间和异常处理窗口。把全部时间留给上传，意味着一旦出现对账差异，就没有资源判断差异来自哪里。项目排期应包含准备、测试、正式导入和验收，而不只是上传操作。
同一字段被销售、财务和仓储赋予不同含义时，技术清洗无法解决根本问题。应由业务负责人确认唯一口径，必要时把一个含混字段拆成多个字段，或在迁移说明中明确转换规则。
这类讨论看起来会拖慢导入，但把争议留到系统运行后，往往会形成重复数据、报表口径冲突或责任争议。对关键字段，书面确认比口头说“大家都懂”更可靠。
并非每个字段都需要同等强度的人工核验。唯一编码、金额、库存数量、主体身份和组织归属通常需要更严格的检查；描述性备注等字段可依据用途采用抽样核验。风险分层能把有限时间投向后果更重的错误。
但分层不能成为忽略问题的理由。即使低风险字段采用抽样，也要明确抽样范围、样本选择方式和发现异常后的扩大检查规则。只抽取最整齐的记录，无法代表整批数据质量。
| 当前情况 | 建议做法 | 主要收益 | 需要接受的取舍 |
|---|---|---|---|
| 记录少、规则简单 | 系统模板加人工复核 | 准备成本较低，问题容易解释 | 记录增加后，人工复核耗时会上升 |
| 记录多、规则重复 | 规则化清洗、留存脚本或校验过程 | 重复劳动减少，处理步骤较一致 | 需要维护规则，并防止自动转换误判 |
| 关联复杂、主数据不齐 | 先梳理依赖与编码，再分阶段导入 | 减少孤立记录和临时对象 | 前期协调成本较高，进度可能更慢 |
| 回滚机制不明确 | 小批试导、逐批验收、限制权限 | 降低错误扩散的影响范围 | 操作轮次增加，整体导入窗口可能延长 |
| 关键数据影响高 | 双人确认、汇总对账和重点明细复核 | 更容易发现高影响差异 | 需要业务与财务等角色投入时间 |
检查表不是越长越好，而是要能指出具体谁检查、依据是什么、失败后怎么办。若某一项只能回答“看一下”，就还没有形成可重复的控制点。
每次批次结束后，建议记录异常类型、触发原因、修正方案和是否需要修改模板或业务流程。若同一错误重复出现，应优先改进源数据采集或字段规则，而不是不断增加人工补救步骤。
真正可复用的资产不是一份漂亮的上传表，而是字段定义、编码规则、数据责任人、校验逻辑、批次记录和验收口径。它们能让后续新增数据、系统升级和跨部门交接更容易复核。
ERP 批量导入看似是数据录入，实质上是在把一套业务口径写进系统。真正值得优先控制的，不是上传速度，而是错误是否会进入后续交易、库存、结算或报表流程。
我会用三个问题判断一批数据是否可以继续：范围和口径是否明确？异常能否追溯到来源并找到负责人？导入后的关键结果是否经过业务核对？只要其中一项答不上来，就应暂停扩大批次，而不是用“系统显示成功”替代判断。
如果你正准备导入 ERP 数据，可以先从一个对象、一个明确范围和一个小批次开始。整理字段映射，覆盖几类边界记录，记录系统反馈，再按业务口径核对结果。确认闭环可重复后，才逐步扩大规模。
最稳妥的导入流程不是一次把所有数据送进系统，而是每一批都能解释来源、验证结果、处理异常并留下记录。速度可以在规则稳定后提升；数据一旦错入并被后续业务引用，修正成本往往远高于导入前多做的一轮核对。
我整理过一份商品表，肉眼看不出问题，上传后却有几十行失败。我想知道这类错误究竟是数据内容错了，还是表格格式、字段映射出了问题？
表格“看起来正确”，不代表系统能按预期解析。常见原因包括：日期或数字被存成文本、必填字段为空、编码前后空格、同一列混用不同单位，以及表头与系统字段不匹配。先区分数据值问题和导入规则问题，比逐行猜错更有效。
下面是一个演示案例，不代表任何特定系统的实际项目数据：某批次有 1200 条商品记录，导入反馈 37 条失败。逐项检查后发现，失败行中有 21 条商品分类编码在系统中不存在，10 条计量单位写法与基础资料不一致，另有 6 条编码前后带空格。
问题并非集中在同一个字段，直接重传整张表反而会增加重复记录风险。建议先按错误日志中的行号和字段定位问题，再核对对应的系统模板、基础资料和字段定义。具体校验规则会因 ERP 配置不同而变化，不能把某个系统的字段限制当成通用标准。
我手头有客户、商品和库存三类表格，准备一次性导入，但不同表的字段和数据来源都不一样。我担心只检查格式不检查业务关系，最后虽然显示导入成功，实际数据却不能用。
导入前先确认四件事：导入范围与数据截止时间、每个字段由谁确认、编码和单位采用什么口径、原始文件和系统模板如何留档。不要先急着清洗整张表；如果字段含义尚未统一，清洗得越快，后续返工范围可能越大。
可以按下面的顺序准备： 检查阶段重点核对 范围模块、记录数量、数据来源和截止时间 字段必填项、字段映射、日期及金额格式 业务规则编码、分类、单位和关联基础资料 留档模板版本、原始文件、负责人和备份位置 若客户、商品等主数据之间存在关联，先确认被引用的基础资料是否已准备好。
最终以当前 ERP 的导入模板、字段定义和配置为准；不确定的字段应先找业务负责人或系统管理员确认，不要凭列名推断。
我遇到过导入结果显示一部分成功、一部分失败的情况，不确定再次上传会不会把已成功的数据重复创建。我也不知道该先修失败行，还是先撤回整批数据。
不要先假定系统会自动回滚，也不要不检查就重传全量文件。不同 ERP 对部分成功、重复识别、覆盖更新和撤销的处理方式不同；先查看导入结果、错误日志和系统说明，确认本批次哪些记录已经写入，再决定修复范围。较稳妥的排查顺序是：保存原始文件与错误报告；按行号拆出失败记录；核对成功记录是否已进入目标模块；
确认系统对重复编码的处理规则；修正失败数据后，仅对确认未成功的记录再次导入。若无法确认导入模式或撤销方式，先暂停操作并联系系统管理员。演示例子：假设 500 条记录中 470 条成功、30 条失败，不应直接把 500 条再传一次。先核对成功记录的唯一编码和当前状态，再评估是否支持增量导入。
保留每次文件版本、操作时间、批次范围和反馈结果，能让后续排查有据可查。
我以前把系统弹出的“导入成功”当作任务完成，但后来发现记录数量对上了，个别字段和关联关系仍可能不正确。我想知道怎样验收，才能避免数据进入后续业务流程才暴露问题？
“成功”通常只能说明系统接受了某种导入操作，不一定证明数据完整、准确或符合业务口径。验收至少要覆盖数量、关键字段和关联关系，并由熟悉业务的人确认抽查规则；只看成功提示或总行数，无法发现字段错位、单位不一致等问题。建议把导入前文件、系统导入结果和导入后的查询结果按同一批次核对。
对于商品数据，可抽查编码、名称、分类和单位；对于客户数据，可核对客户编号及必要的关联信息。抽查比例应按数据重要性和风险确定，关键字段可以全量校验，不能用一个固定比例替代判断。验收记录至少写清导入批次、文件版本、计划条数、成功与失败条数、异常说明、复核人和后续处理人。
若系统支持导出查询结果，可将其与源文件按唯一编码比对；无法确认的数据先标记待处理，不要为了完成进度直接进入后续业务。
读者评论
把文件校验、记录校验和业务验收分开很实用，尤其是导入成功不等于业务数据准确，能避免上线后才发现关联或口径问题。
库存导入前先确认盘点时点、仓库范围和冻结库存是否纳入，这些细节容易被忽略，也确实会影响后续账实核对。
字段映射表和文件版本管理值得落实。保留原始文件、清洗文件及上传批次记录，出现差异时更容易追溯；试导样本也应包含边界情况。