ERP 数据录入自动化最容易被误解的一点，是把“单据格式统一”当成了“可以自动写入”。一张采购订单即使版式固定，供应商编码、物料单位、税率、重复单号和审批状态仍可能出错。真正可靠的方案，不是把 OCR 接进 ERP 就结束，而是把识别、字段映射、业务校验、人工复核、系统写入和结果追踪连成闭环。下面我按方案设计、风险判断和试点落地逐步拆解，并用一组明确标注的模拟数据说明如何评估成效。
我设计 ERP 数据录入方案时，会先问一个问题：系统最终要对什么结果负责？如果目标只是从 PDF 或图片中提取文字，那是信息识别；如果目标是生成一张字段正确、业务规则成立、能够被 ERP 接受并可追溯的单据，才是业务自动化。
两者的差别很实际。识别结果里出现“物料编码 A102”并不代表这个编码在当前组织、仓库或业务日期下有效；识别出金额 12,000 元，也不代表数量乘以单价等于金额，更不代表税额、币种和含税口径都符合企业规则。
因此，自动化方案至少要包含七个环节：接收单据、识别内容、映射字段、校验规则、处理异常、写入 ERP、反馈并留痕。少了其中任何一环，都可能把人工重复劳动变成自动化错误。
很多企业第一反应是挑单量最大的业务做自动化，但单量大不等于适合先做。若单据规则经常变化、来源格式混杂、主数据缺失严重，项目会先花大量时间处理例外，自动化收益反而不稳定。
我更倾向于优先选择同时满足“字段稳定、规则明确、来源可控、异常可拦截、失败可恢复”的单据。可以先从某一类供应商的采购发票、固定模板的费用申请，或一组来源稳定的销售订单做起，而不是一开始覆盖所有部门和全部单据类型。
试点阶段的目标也不应设为“无人参与”。更稳妥的目标是：让系统自动处理规则清晰的部分，把不确定事项送到人工复核队列，并确保每一张单据都能解释为什么通过、为什么拦截、谁做过修改。
单一自动化率容易掩盖风险。例如，一批 1,000 张单据中有 900 张自动进入 ERP，看起来自动化率达到 90%；但如果这 900 张里存在编码错配，或者剩余 100 张需要人工逐字段重录，实际业务价值可能并不理想。
我建议至少分开看四类结果：识别是否正确、业务规则是否通过、ERP 是否成功接收、异常是否被及时关闭。它们分别对应不同责任环节，不能用一个数字代替。
| 评估层次 | 要回答的问题 | 适合观察的指标 | 不能单独证明什么 |
|---|---|---|---|
| 内容识别 | 单据上的内容是否被正确提取？ | 字段识别正确率、表格行识别完整率 | 不能证明字段符合业务口径 |
| 业务校验 | 字段组合是否符合企业规则？ | 规则拦截率、异常复核率 | 不能证明 ERP 接口已成功落单 |
| 系统写入 | ERP 是否接受并生成目标单据？ | 写入成功率、重复提交率 | 不能证明单据已审批或业务已完成 |
| 运营闭环 | 失败和疑问是否有人处理、可否追溯？ | 异常关闭时长、重试成功率、审计记录完整率 | 不能只凭上线初期表现判断长期稳定性 |
这张表的重点是把“识别准确”与“业务正确”分开。前者解决机器读得对不对，后者解决企业是否愿意让这张单据进入正式账务或业务流程。
设想一个采购团队：大部分供应商都通过统一模板提交订单，文件格式固定，表头包括物料名称、数量、单价、金额和交货日期。表面上看，识别难度不高；但同一个“数量”字段可能有人填采购单位、有人填库存基本单位，还有人按包装箱计数。
一旦 ERP 里的物料单位和单据单位不一致，系统即使识别出数字“20”，也不知道它代表 20 件、20 箱还是 20 千克。若系统直接写入，问题可能要到收货、对账或盘点时才暴露，修正成本远高于录入环节。
所以我会把“单据规范”拆成四层判断：版式是否稳定、字段定义是否统一、业务规则是否明确、关联主数据是否完整。只有四层都达到可管理状态，自动化才有比较清晰的边界。
自动化项目里，最容易被低估的不是扫描件倾斜或印章遮挡，而是单据之外的上下文：供应商状态是否有效、物料是否已停用、采购组织是否正确、单据是否重复提交、业务日期是否落在允许期间。
这些信息通常不在文件里，却决定了单据能不能进入 ERP。方案必须能够查询或调用 ERP 的主数据与业务状态，不能只依赖 OCR 输出。无法及时查询的字段，也要明确降级方式，例如转人工确认，而不是用默认值“先写进去再说”。
企业计算录入成本时，常只统计键盘操作时间，却忽略了文件下载、命名、字段查找、编码确认、错误退回、重复核对和状态追问。自动化方案如果只缩短了键盘输入，流程总耗时未必会明显下降。
我建议在试点前记录完整的处理链路：从收到单据到 ERP 返回可确认结果，一共经过多少分钟；其中录入、核对、等待、补件和返工各占多少。这样才能知道真正的瓶颈是识别、主数据、审批还是接口。
例如，如果人工录入本身只占总处理时间的三分之一，而大部分时间都花在等待供应商补资料，那么仅做 OCR 的收益上限就很有限。此时先改善资料提交规范，可能比购买更复杂的识别能力更有价值。
技术团队可以实现字段读取、规则判断和接口调用，但“什么情况下允许写入”必须由业务责任人确认。比如金额差异是否允许在某个范围内自动通过、供应商名称与税号不匹配时是否拦截、跨期单据如何处理，都属于业务控制，不应由开发人员自行猜测。
在项目启动会上，我会要求至少明确三类负责人：规则负责人、主数据负责人和异常处理负责人。规则没人维护，自动化会逐渐过时；主数据没人治理，编码匹配会持续失败；异常没人认领，队列会变成新的积压区。
识别引擎可能正确读出了发票号码、日期和金额，但业务上仍可能存在币种不符、税率不适用、供应商关系错误或重复单据。识别准确率的分母、字段范围和测试样本也会影响结果，不能脱离具体单据类型比较。
我通常把准确性拆成字段级和单据级两套口径。字段级统计每个字段是否与人工核验结果一致；单据级则要求一张单据的关键字段全部满足约定条件。前者有助定位错误类型，后者更接近业务能否自动放行。
如果一张单据有 20 个字段，每个字段单独看都很准确，但关键字段中任意一个错误都可能导致错账，那么“平均字段准确率”并不能代表整张单据的风险。关键字段要单独设门槛，不能被大量低风险字段稀释。
自动通过率越高并不总是越好。如果系统为了追求高自动通过率，把不确定字段默认填入、把异常校验关掉，短期看起来人工工作减少了，长期可能积累更大的对账和审计风险。
更合理的目标是在风险可接受的前提下，减少不必要的人工操作。对于金额、税号、供应商、物料编码等高影响字段，宁可把边界样本转人工，也不要为了报表好看强行放行。
反过来，复核率也不是越低越好。如果业务风险高，人工复核本来就是控制设计的一部分。正确的问题不是“能不能把复核率降到零”，而是“哪些单据需要复核、复核是否聚焦于高风险事项、复核人是否获得足够上下文”。
ERP 接口超时、权限变化、期间关闭、单据状态冲突和重复请求都可能发生。方案如果只规定“调用接口后成功”，没有定义失败状态、重试条件和人工接管方式，运行一段时间后就会出现系统显示失败、ERP 实际已落单，或重复点击造成重复单据的情况。
我会要求技术方案明确一个核心机制：每个业务单据都有稳定的外部唯一标识，写入前先检查是否已经处理，写入后保存 ERP 返回的单据编号和状态。接口没有明确响应时，先查询结果再决定重试，不能盲目重复提交。
对于可重试错误和不可重试错误也要区分。网络超时可能适合延迟重试；字段校验失败通常需要修改输入或业务规则；权限不足需要管理员处理。把所有失败都放进同一个重试队列，只会反复制造无效请求。
OCR 负责从文件中提取内容，不负责判断企业业务规则；RPA 可以模拟界面操作，但页面变化、弹窗和会话状态会影响稳定性；API 便于结构化调用，但接口能力、权限和业务状态约束要以目标 ERP 的实际文档和配置为准；表格导入适合批量、结构稳定的场景，却不一定适合实时、逐笔确认。
选型应从约束条件出发，而不是从技术名词出发。要先确认输入是什么、数据量多大、系统是否开放接口、是否要求实时回执、失败能否补偿、是否需要保留原件，再决定哪些环节用哪种技术。
字段字典是方案中最基础、也最容易被跳过的工作。每个字段至少要有业务名称、来源位置、目标 ERP 字段、数据类型、格式要求、是否必填、主数据关联方式、校验规则、错误责任方和允许的人工修改范围。
“供应商”不是一个足够具体的字段定义。还要判断输入的是供应商名称、税号还是内部编码；如果输入名称，是否存在简称、分支机构或历史名称；如果要匹配内部编码，匹配失败时是否允许候选项选择；最终写入 ERP 的究竟是名称还是主数据编码。
我会把字段分为三类：可以直接读取的原始字段、需要转换或映射的字段、必须调用业务数据确认的字段。日期格式转换属于第一类或第二类；供应商编码通常属于需要关联主数据的字段；审批状态则不应从单据图像中猜测，必须以系统业务状态为准。
格式校验处理日期格式、金额类型、字符长度和必填项；主数据校验处理供应商、客户、物料、仓库、单位等编码是否有效；业务关系校验则判断多个字段组合是否成立，例如币种是否允许、数量和金额关系是否合理、业务日期是否处于开放期间。
分层的好处是异常可以准确归类。若系统只返回“录入失败”，业务人员无法知道要改文件、补主数据还是请管理员开放期间。异常信息越具体，人工处理越快，后续规则优化也越有依据。
| 校验层 | 示例规则 | 典型处理动作 | 规则负责人 |
|---|---|---|---|
| 格式校验 | 日期格式有效、金额为数值、必填字段不为空 | 自动规范格式；缺失时退回补件 | 业务流程负责人或系统管理员 |
| 主数据校验 | 供应商有效、物料编码存在、单位关系可转换 | 查询主数据；无法匹配时进入人工选择 | 供应商、物料或主数据维护人员 |
| 业务关系校验 | 金额关系合理、组织匹配、期间开放、单据未重复 | 拦截、提示差异或转授权人员确认 | 财务、采购或业务控制负责人 |
识别系统通常会给出置信度，但置信度不是业务风险等级。一个金额字段识别置信度 98%，如果小数点错位，影响可能很大；一个备注字段置信度 75%，可能对单据有效性没有实质影响。不能只设“高于某个分数自动通过，低于就人工处理”的单一规则。
更实用的做法是把字段重要性、识别置信度和业务校验结果组合起来。高影响字段即使置信度较高，只要金额关系不成立仍然拦截；低影响描述字段允许较低阈值，但要保留原文和修改记录；主数据映射失败则不自动猜测编码。
试点时可以设置三种状态：自动通过、人工复核、拒绝写入。自动通过必须同时满足关键字段可信、业务规则通过、主数据匹配和重复检查通过；人工复核用于信息不完整但可由授权人员判断的情况；拒绝写入用于明确违反规则或风险过高的情况。
如果复核人员只能看到一个字段值和“请确认”按钮，系统只是把录入工作换了一个页面。有效的复核界面应同时展示原始单据片段、识别值、候选主数据、触发规则、历史处理记录和允许的修改范围。
例如，供应商名称匹配存在两个候选项时，应展示税号、组织关系和历史交易信息等可用依据，而不是仅按名称相似度排序。复核人员做出的选择也应记录原因，方便后续判断是输入规范问题、主数据问题还是匹配规则需要调整。
写入 ERP 前应为每张来源单据生成稳定的唯一标识。这个标识可以由业务系统生成，也可以由来源系统编号与文件校验信息组合而成，具体做法要符合企业数据和接口约束。关键目标是：同一业务请求重复发送时，不应重复生成正式单据。
调用接口时要保存请求时间、请求摘要、返回状态、ERP 单据编号和错误信息。若接口超时，先查询是否已经写入，再决定是否重试；若返回字段校验错误，则把错误映射成人能看懂的提示；若系统权限或期间设置异常，则转交相应管理员。
下面是一段用于说明字段映射结构的示意数据，并非任何 ERP 的标准接口格式。实际字段名、数据类型和权限要求必须以目标系统接口文档及配置为准。
{
"source_document_id": "PO-SOURCE-2026-000128",
"document_type": "purchase_order",
"supplier_code": "SUP-00418",
"currency": "CNY",
"business_date": "2026-09-18",
"lines": [
{
"item_code": "MAT-1026",
"quantity": 20,
"unit": "箱",
"unit_price": 135.00
}
],
"validation_status": "passed",
"human_review_required": false
}
下面以一家中型制造企业的采购订单录入为例。该企业每月处理约 1,200 张供应商订单，主要通过邮件接收 PDF 和电子表格。为避免把推演数字误当成客户实绩，以下所有数值均为情景模拟，用于展示测算方法，不代表行业平均水平，也不构成某个工具或方案的效果承诺。
模拟中的现状是：人工从文件中提取字段、查供应商和物料、录入 ERP，再由另一名员工抽查。项目试点范围只覆盖固定模板、固定采购组织和主数据相对完整的一组供应商；扫描图片、自由格式附件和规则未确认的订单先进入人工处理。
这样的范围选择看起来保守，却有利于判断自动化本身的贡献。若同时改变模板、供应商管理、审批规则和 ERP 接口，最终结果变好或变坏时，很难知道究竟是哪项措施起作用。
模拟基线中，单张订单从进入队列到成功录入平均需要 22 分钟，其中直接输入约 6 分钟，查编码和核对约 7 分钟，等待补件与确认约 6 分钟，返工约 3 分钟。方案上线后，识别和映射承担重复处理，人员主要处理异常与抽查；但等待供应商补件的时间仍然存在。
为了避免用“节省了多少键盘时间”误导决策，模拟比较的是每月投入的人时、人工复核比例、首次写入成功率和异常关闭时长。处理时长下降不等同于业务风险下降，因此也要同步观察重复提交和字段错误。
| 指标 | 试点前模拟值 | 试点后模拟值 | 口径说明 |
|---|---|---|---|
| 每月处理单据量 | 1,200 张 | 1,200 张 | 假设试点前后业务量相同，用于比较流程耗时 |
| 单据平均处理时长 | 22 分钟/张 | 11 分钟/张 | 从进入处理队列到得到可确认结果，不含供应商外部等待时间 |
| 人工复核比例 | 100% | 28% | 模拟中部分规则明确且数据可信的单据可自动通过 |
| 首次写入成功率 | 94% | 97% | 指第一次提交 ERP 后成功生成目标单据的比例 |
| 重复提交事件 | 每月 6 次 | 每月 1 次 | 假设通过唯一标识、状态查询和重试控制减少重复 |
这组模拟结果不表示所有企业都能达到同样变化。它展示的是一种比较方法：先确定处理时长口径，保持业务量和试点范围可比，再分别看效率、质量和控制结果。若试点期间业务量、模板或规则明显变化，应在报告中说明，不能简单归因于自动化。
模拟试点中，异常被归为四类：供应商匹配失败、物料单位不一致、金额关系异常、接口或权限问题。分类后，团队可以把修复动作分给不同负责人：供应商匹配由主数据团队处理，单位换算由采购和库存共同确认，金额关系由财务确认，接口问题则交给系统管理员。
如果只统计“本月有 36 张失败”，无法区分这些失败是识别技术不足，还是业务规则本来就未定义。分类分析能帮助团队判断下一笔投入应该用于改模型、补主数据、改模板，还是修复 ERP 接口。
自动化项目应把实施成本和持续运维成本都纳入评估。实施成本包括需求梳理、字段字典、规则确认、接口联调、测试和培训；运行成本包括识别服务、接口维护、异常处理、规则变更和监控。只拿人工节省的人时与软件采购费比较，容易漏掉后续维护。
用模拟数据举例，若 1,200 张单据每月平均节省 11 分钟，理论上释放约 220 小时/月。这个数字只表示“处理时间差”的估算，不等于减少了 220 小时编制，也不等于全部变成现金收益。还要扣除人工复核、异常维护和系统运维投入，并判断释放的人力是否被用于更高价值工作。
我通常要求业务方区分三种收益：可直接减少的外包或加班支出、可重新分配的人力容量、难以直接折现但能降低的错账和审计风险。只有第一类适合直接按现金节省计算，后两类应分别说明衡量方式，避免把潜在价值写成确定收益。
如果单据模板稳定，核心字段定义清楚，主数据匹配率较高，ERP 接口或导入机制也明确，可以从一个部门、一种单据和有限来源开始。第一阶段优先自动完成字段提取、校验和预填，再由人员确认；稳定后，再逐步对低风险、规则明确的单据开放自动写入。
这一路径的关键不是尽快取消人工，而是建立可复核的基线。试运行时应保留人工抽查，并对自动通过单据做风险抽样，检查系统是否存在“看起来成功、实则字段错配”的隐性问题。
有些 ERP 没有可用接口，或接口开放要经过较长的安全评审。此时不必为了追求架构完整而暂停所有自动化，可以先评估结构化文件导入、系统内置导入功能或受控的辅助录入方式。
但要确认批量导入是否能返回逐行错误、是否支持重复检查、是否能区分校验失败和系统故障。如果只返回“导入失败”，却无法定位到具体行和字段，后续人工排查可能抵消前期节省的时间。
如果文件来源复杂，可能包含手机拍照、低分辨率扫描、手写内容、多页附件和供应商自定义版式，先别急着承诺全自动。应先按来源和质量分层，统计哪些供应商、哪些字段、哪些文档类型最容易产生异常。
可以通过设置提交模板、要求关键字段同时提供电子数据、规范文件命名和补充必填附件来降低输入不确定性。图片识别能力解决的是“从文件读出内容”，而输入端治理解决的是“让内容更容易读、字段更容易解释”。两者往往要一起做。
当供应商、物料、单位、仓库等编码缺失或重复时，自动映射会频繁失败。若项目团队用模糊匹配强行选一个最相似编码，错误可能比人工录入更隐蔽。我的建议是先建立候选匹配和确认机制，再把高频映射沉淀为经过业务确认的规则。
对于新供应商或新物料，可以设计待建档流程：单据被识别后先保存为待处理状态，要求主数据责任人完成建档，再继续写入。这样虽不能做到全自动，却能避免把错误编码带入正式业务。
涉及付款、税务、财务过账或高金额采购时，不应单纯以处理效率决定自动化范围。需明确提交人与审批人是否分离，关键字段修改是否触发重新审批，自动化服务账户具有什么权限，日志是否记录输入来源、规则版本和最终写入结果。
高风险业务可以自动完成识别和校验，但将最终提交保留给授权人员；也可以只对低金额、低风险、历史表现稳定的单据开放自动写入。自动化程度应随控制成熟度逐步提升，而不是一次性切到无人操作。
试点开始前，我会把指标定义写进方案，而不是等上线后再临时挑一个好看的数字。每个指标都要说明统计对象、分母、时间范围、异常是否计入、数据从哪里取、由谁确认。
试点数据应能回溯到原始单据和 ERP 结果。如果指标只来自项目组手工汇总的表格，却无法和系统日志、抽样记录相互核验，就不适合作为扩围决策的唯一依据。
我会把实施拆成四个可验证阶段。第一阶段只做流程和字段梳理；第二阶段离线测试历史样本；第三阶段进入真实单据的辅助录入或影子运行；第四阶段才逐步开放自动写入。每个阶段都设有通过条件和回退方式。
“样本验证通过”不等于正式上线准备完成。历史样本通常缺少实时接口超时、权限变化和期间关闭等情况，所以必须通过真实环境的受控运行，验证系统故障和流程边界。
全自动写入适用于输入稳定、规则明确、主数据质量较高、错误影响可控、接口状态可查询的场景。它的好处是减少重复操作和排队时间，代价是需要更完善的异常分级、权限管理、审计日志和回滚机制。
如果企业还不能回答“接口超时后如何判断是否已写入”“规则变更由谁批准”“错误单据如何撤回或冲正”，就不应仅因为技术上可以调用接口而直接开放全自动提交。全自动不是功能开关，而是控制能力成熟后的运行模式。
自动预填适合规则大体清楚、但关键字段仍需人员确认的场景。系统负责提取、映射、预校验和准备提交内容，人员负责处理候选匹配、金额疑问和授权动作。
这种方式仍保留人工环节，但可以把人员从重复查找和机械输入中解放出来。是否划算取决于复核界面效率：如果每张单据还要重新打开文件、逐字段找位置，预填带来的节省会大打折扣。
文件导入适合定期批量处理、模板相对稳定、ERP 能提供清楚错误回执的场景。它实现成本可能低于逐笔接口集成，但通常要额外处理模板版本、批次追踪、重复导入和失败行修复。
如果业务需要每张单据即时返回 ERP 编号或审批状态，批量导入可能不够灵活；如果单据量较大而且批次规律明显，它则可能是更合适的阶段性选择。方案不必追求单一架构，也可以先批量处理稳定部分，再为高时效场景建设接口。
界面模拟适用于接口暂不可用、业务流程主要通过固定页面完成、短期希望降低人工重复操作的情况。它的实施速度可能较快，但对页面结构、弹窗、登录状态、权限变化和运行环境更敏感。
采用这一路线时，应预留页面升级后的回归测试、运行失败监控和人工接管能力。若页面变更频繁、操作路径长或业务量持续增长，长期维护成本可能超过一开始建设接口的投入。
如果不同部门对同一字段定义不一致，或者供应商经常缺少必要信息，继续增加识别能力并不能解决根因。先统一模板、建立字段责任、清理主数据、定义异常处理规则，往往能同时改善人工和自动化流程。
我的判断顺序是：先确定业务规则，再判断输入质量；先确认数据责任，再比较技术路线；先验证风险控制，再讨论自动通过范围。这个顺序能避免把组织问题误判成技术问题。
| 业务条件 | 优先考虑的方式 | 主要收益 | 需要承担的代价 |
|---|---|---|---|
| 字段稳定、接口成熟、状态可查询 | 规则校验后通过接口写入 | 适合逐笔处理和回执闭环 | 前期接口梳理、权限和异常设计工作较多 |
| 模板稳定、批次处理、时效要求一般 | 结构化文件导入 | 可快速覆盖批量重复录入 | 模板管理、失败行定位和重复导入控制不可少 |
| 接口暂不可用、界面操作固定 | 受控的界面模拟 | 较少改动现有 ERP 配置 | 依赖页面稳定性，需承担持续维护和回归测试 |
| 文件复杂、图片和 PDF 占比较高 | 识别加字段映射与人工复核 | 减少重复查看和手工抄录 | 识别结果不能直接等同于业务正确，需要校验和人工分流 |
| 主数据混乱、规则未统一 | 先治理流程与数据，再启动自动化 | 减少错误来源，改善人工和系统处理 | 短期看不到全面自动化，需要跨部门协作 |
当自动通过率上升，但异常类别、责任人和恢复方式仍不清晰时，我不会建议立即扩围。因为这说明系统处理得更多了，却未必代表企业控制得更好。
相反，如果关键字段错误率稳定在企业设定的可接受范围内，异常处理有明确责任人，接口失败能够恢复，系统日志可以追溯，且单位处理成本低于现有方式，就具备讨论扩围的基础。具体门槛应由企业结合风险等级和流程要求设定，不应套用统一行业数字。
还要看扩围后的边际成本。新增一种单据可能只需复用现有字段和规则，也可能带来新的审批链、税务口径和主数据关联。扩围不是“多接一个模板”这么简单，应重新评估新增规则、维护负担和风险暴露。
单据规范是自动化的起点，但不是上线的充分条件。自动化能否长期有效，取决于企业是否能明确字段含义、维护主数据、验证业务规则、处理异常，并对每次写入保留可追溯记录。
我会把方案质量归结为一个判断：系统不仅要能说明自己做对了什么，也要能说明遇到不确定情况时为什么没有继续做。只追求自动写入数量，容易把错误从人工环节转移到系统环节；把异常分流设计好，才是真正降低重复劳动的开始。
如果你正在准备项目，不需要立刻定 OCR、RPA 还是接口。先选一种单据，收集一段时间的真实样本，完成以下评估，再决定技术投入。样本应覆盖正常单据、缺字段单据、主数据不匹配、重复提交和系统异常等情况。
答案清楚之后，再选择一个范围小、边界明确的试点，并用相同统计口径比较上线前后。若结果显示主要瓶颈在补件，就先治理输入；若主数据匹配失败占多数，就先整理编码；若重复录入和接口状态不明是主要风险，就先补齐幂等与回执设计。
最稳妥的落地顺序不是“先上工具，再找场景”，而是“先定义业务边界，再自动化确定性最高的部分”。从一类单据开始，把字段、规则、异常和回执做扎实，再逐步扩展到其他流程，通常比一开始追求全场景无人录入更可控，也更容易获得真实、可验证的业务收益。
我手头有采购单、送货单和报销单，版式看起来都比较固定，是不是都适合直接自动录入？我担心只看版式会漏掉业务规则和主数据差异，应该先用什么标准筛选？
先别只看单据版式。更有用的判断是：字段定义是否稳定、业务规则是否明确、来源是否可控、ERP 主数据是否完整，以及异常能否被人工及时处理。版式统一但客户名称经常写简称、物料编码缺失的单据，仍可能需要大量人工核对。
建议先给候选单据做一张评估表，逐项标记“稳定、部分稳定、不稳定”：字段与版式、单据来源、编码匹配、校验规则、异常比例。优先试点字段少、规则清楚、来源集中的类型；若某类单据经常需要业务人员解释特殊情况，应先统一规则，而不是急着接入自动化。
例如，采购订单如果供应商、物料编码、单位和税率都能从系统主数据匹配，通常比自由格式的费用票据更适合先评估。这里的判断是方案筛选方法，不代表所有企业都能获得相同效果；最终应以一批真实历史单据和试运行结果验证。
我在看方案时发现，有的供应商主打 OCR，有的说用 RPA，还有的建议直接对接 ERP 接口。我不太确定它们解决的是同一个问题，还是应该按流程分工？
这几种方式并不是互相替代的按钮，而是处理链路中的不同环节。OCR 负责从图片或 PDF 中提取内容；字段映射和规则引擎把识别结果转换成 ERP 可用的数据；ERP 接口负责创建或更新业务单据；RPA 更适合接口暂不可用、但有稳定页面流程的场景。
设计时可按“接收单据，识别，映射，校验，复核，写入，回执”拆分责任。能使用受支持接口时，通常优先评估接口，因为它更便于传递字段、接收明确的成功或失败结果。RPA 若操作页面，需额外考虑页面改版、登录状态、重复点击和任务中断后的恢复。
无论采用哪种连接方式，都应给每张来源单据保留唯一标识，并在重复提交时先检查 ERP 是否已生成对应记录。否则网络超时后重试，可能出现重复单据。具体接口能力、权限和字段限制，应根据目标 ERP 版本及厂商文档确认，不能仅凭演示环境下的成功操作判断可上线。
我最担心的不是系统认不出单据，而是它把错误内容当成正确数据写进 ERP。比如金额识别有误，或者供应商名称相似但编码不同，怎样设置规则才比较稳妥？
把“识别置信度”当成业务正确率，是常见的设计误区。系统即使清楚地识别出一个名称，也不代表它对应了正确的供应商编码；因此至少要分开设计格式校验、主数据匹配、业务规则校验和人工审核。例如，格式校验检查日期、数量和必填项；主数据校验确认供应商、物料及单位是否存在且状态有效；
业务校验检查金额关系、税率和单据间引用关系。供应商名称匹配到多个编码、金额勾稽不一致或关键字段缺失时，应暂停自动写入并进入复核队列，而不是靠识别分数放行。试点阶段可把异常分成三类：可按明确规则自动修正、需要人工确认、禁止提交 ERP。
复核界面应同时展示原始单据、识别值、目标字段和触发规则，人工修改后记录修改人、时间及前后值。自动放行阈值不要照搬供应商宣传数字，应按单据类型用真实样本验证，并设置抽检机制。
我不想只看演示时录入得很快，最后上线却因为异常单据和返工拖慢业务。试点阶段要准备哪些材料，又该用哪些指标判断方案是否值得扩展？
先选一个单据类型和一个明确的业务范围，整理字段字典、主数据对应关系、校验规则、异常处理人及 ERP 写入权限。测试样本应覆盖常见版式，也要包括模糊图片、缺字段、编码不匹配、重复单据和接口失败等情况；只拿最干净的样本演示，无法验证真实运行边界。指标至少分成效率、质量和运维三组。
效率可比较自动化前后的单据处理时长；质量可看自动通过率、人工复核率、字段错误率和重复提交率；运维可看失败任务恢复时间及未处理异常数量。每项都要明确分子、分母和统计周期，例如“自动通过率”应说明是自动写入成功单据数除以收到的有效单据数，还是除以全部提交数。
先记录现有流程的基线，再在同一单据类型、相近业务量和一致口径下比较试点结果。若自动通过率提升但错误率或返工量也上升，就不能简单判定为成功。只有异常有人接、失败可重试、操作有留痕，并且业务负责人认可指标后，再逐步扩大范围。
读者评论
把识别准确率和业务校验、ERP写入成功率分开评估很有必要，单看自动化率容易忽略错单风险。
文中提到等待补件可能比录入更耗时，这点对试点选型有参考价值；输入资料治理也应纳入项目范围。
外部唯一标识、写入后查询和失败分类能减少重复提交问题，建议试点时同时验证超时及重试场景。