本文内容
Odoo 发票 OCR：什么时候需要定制异常审核流程？
发票写着 10 件。订单也是 10 件。仓库只收到 8 件。即使每个字符都识别正确，仍有一项差异需要负责人作出决定。
如果已安装配置满足流程要求，就使用 Odoo 原生发票 OCR 和采购匹配。 只有在校验、证据或放行权限存在明确缺口时，才增加定制异常流程。保留原始值及业务预期值，为每项差异指定责任人，并在启用自动过账前验证真实效果。
资料核查日期：2026年11月5日。 产品事实依据 Odoo 官方 20.0 文档。下文账单、金额和验收用例均为虚构。我们没有执行 OCR 服务、模型、连接器或会计流程。示例税额只是计算输入，不是任何地区的税务建议。
Odoo 原生发票处理已经能做什么？
定义定制流程之前，先演示原生数字化、采购匹配和过账配置。记录实际 Odoo 版本、已安装应用及相关设置。需要验证的是：这套配置能否完成所需检查，并保留包括异常在内的证据。某个功能名称本身，无法回答放行政策是否得到执行。
Odoo 20 的数字化文档描述了读取账单、查找采购订单，再人工匹配未完成订单明细的过程。
这比“OCR 完全不参与采购匹配”更准确，也没有承诺每张账单都会自动正确匹配。应让实施负责人使用计划支持的文档和订单结构，演示实际路径。
供应商账单文档还列出了按供应商设置的自动过账选项。逐张审核属于政策和配置选择，不能无条件当作原生行为的描述。
本文建议的验收阶段按已商定的审核政策控制放行。评价结果前，记录哪些自动设置已启用。如果演示中悄悄更换配置，之前观察到的行为就不能证明新配置具有相同效果。
出现匹配异常，就能执行审批规则吗？
显示异常和强制执行审批规则，需要不同证据。状态可以提醒差异，却仍允许后续操作。如果流程要求暂停，必须演示实际身份无法从相关应用和集成路径绕过该限制。检查操作后的业务状态，不能只看页面警告。
Odoo 的账单控制文档区分订购数量与收货数量，也说明修改后的草稿可出现 Should Be Paid: Exception，而不阻止这些修改。
据此编写明确的验收要求。在示例政策中，收货差异未解决的账单不能通过受保护的放行步骤。解决差异的人应留下原因和相关证据。究竟由配置、模块还是定制控制执行这条规则，需要在实施阶段确定。
将准备、过账和付款分别纳入范围。算术检查通过，不代表三项动作全部获准。应确定每一步由什么身份执行、引用哪项审批，以及审核后金额或支持记录发生变化时如何处理。
不要仅凭字段名称推断存在通用的过账或付款硬性阻断，也不要反过来假定某个安装环境一定没有阻断。额外配置和模块可能改变行为，应验证实际部署路径。
什么情况下值得定制异常流程？
演示原生路径后，某项已商定要求仍无法满足，才有理由增加定制流程。明确缺少的是规则、证据来源还是责任安排，并将新增范围限制在该缺口。收货录入错误或政策尚未确定，并不能靠更换一个提取模型来解决。
| 观察到的需求 | 优先评估的方案 | 定制前所需证据 |
|---|---|---|
| 受支持账单及匹配依据已经在 Odoo 内。 | 原生数字化、匹配和审核配置。 | 代表性账单及异常到达约定状态，并保留证据。 |
| 缺少负责人、审批步骤或金额规则。 | 演示已有配置或持续维护的模块能否执行规则。 | 准确说明缺少哪项条件，以及当前能够绕过它的用例。 |
| 验收依据位于另一业务系统。 | 通过限定范围的集成获取并保留证据。 | 来源身份、时效、授权，以及来源不可用时的行为。 |
| 原生提取在某类已记录输入上失败。 | 用这些文档评估另一提取路径。 | 实际观察到的识别失败与后续人工工作量。 |
即使审核人选择采购订单中的预期值，也应保留供应商原文档。异常记录要让差异可见。若直接用预期金额替换候选金额，却没有保留来源，后续就难以理解争议所在。
已有的发票提取与人工审核指南负责讨论解析器评估。如果已证实的问题是识别质量，可先参考该文。本文讨论的是数值可供审核之后，业务如何继续。
为什么发票识别正确，仍然需要人工判断？
识别与接受回答的是不同问题，所以正确读取的发票仍可能无法通过业务检查。先验证原文金额的算术关系，再把计费数量和价格与获批订单、收货政策比较。分别记录每项差异，让审核人看清还有哪一个决定未完成。
示例使用供应商 V01、发票 INV-082 和公司 A。账单写明 10 件，每件 25 欧元，另有用于演示的 50 欧元税额，没有其他费用。采购订单为 10 件，收货记录为 8 件。
| 检查 | 原始值或预期值 | 计算 | 按示例政策作出的判断 |
|---|---|---|---|
| 明细净额 | 10 件，每件 25 欧元。 | 10 × 25 欧元 = 250 欧元。 | 算术一致。 |
| 含税总额 | 净额 250 欧元，加税额 50 欧元。 | 250 欧元 + 50 欧元 = 300 欧元。 | 算术一致；税务处理仍须遵循获批政策。 |
| 订购数量 | 订购 10 件，计费 10 件。 | 10 − 10 = 0 件。 | 与订单相比没有数量差异。 |
| 收货数量 | 收到 8 件，计费 10 件。 | 10 − 8 = 2 件。 | 按商定收货规则暂停，交由收货审核。 |
在这个例子里，OCR 输出可能完全忠于文档。但 2 件差异仍需解释。收货录入错误、分批交付和已同意的商业例外，需要不同证据。系统应展示差异，而不是猜测哪种解释正确。
现在只把提取的总额改为 310 欧元，净额和税额输入仍为 250 欧元与 50 欧元。无法解释的差额为 310 欧元 −（250 欧元 + 50 欧元）= 10 欧元。审核人需要判断是识别错误、漏掉费用，还是文档本身需要澄清。悄悄把总额改成 300 欧元，会掩盖这项调查。
附件用例中的“可交财务审核”，只表示按示例规则，所列检查没有未解决问题。它不代表已过账、已获付款授权或已付款。实际会计处理和放行条件由获授权的财务负责人决定。
异常记录应保存哪些内容？
异常记录应保留争议数值、来源、具体原因，以及能解决问题的人。明确公司和币种，避免看似合理的金额被匹配到错误背景。放行决定必须与它批准的证据和记录版本关联，便于以后确认当时实际审核了什么。
| 要素 | 必要内容 | 用途 |
|---|---|---|
| 身份 | 公司、供应商、文档引用及候选记录标识。 | 检查正确账单及业务背景。 |
| 观察值 | 原文位置及提取的数量或金额。 | 保留供应商文档实际写了什么。 |
| 预期值 | 订单、收货记录或其他获批依据及版本。 | 说明业务为何期待不同结果。 |
| 原因与负责人 | 明确的收货、价格、身份或算术差异。 | 将问题交给有权决定的人。 |
| 放行证据 | 决定、负责人员、当前版本和支持引用。 | 在受保护操作前确认批准内容。 |
重复引用应触发重复项调查，而不是自动删除账单。Odoo 文档指出，分批账单可以共用 Bill Reference。确认它们是否代表同一义务前，应比较实际文档和相关身份。
每种原因都要对应有用的下一步。采购可解决订单价格差异；收货人员可更正或解释数量记录；财务负责金额规则与会计放行。供应商主数据修改需要独立获批的核验流程，发票文字不应悄悄覆盖银行账户信息。
重要数值或支持记录变化后，应重新评估审批。保留原决定及其不再适用的原因，否则设计良好的异常队列也可能用旧证据放行新版本账单。
启用自动化之前如何验收？
在受保护环境中使用实际配置，分别检查允许用例和禁止转换的最终账单状态及支持证据。确认异常能到达负责人员，并在政策要求时保持阻断。页面出现警告或任务显示完成，只是验收证据的一部分。
下载包含 12 个用例的发票异常验收表。它覆盖收货与价格差异、算术、公司和供应商身份、币种、潜在重复项、主数据变化、未定义容差和过期审批。所有执行状态均为 NOT_RUN。
- 先批准政策。 由财务和业务负责人确定哪些问题必须暂停，以及谁可以放行。
- 记录初始配置。 包括 Odoo 版本、相关模块、账单控制、自动过账选项和技术权限。
- 运行合格用例与最接近的异常。 例如保持账单金额不变，仅将收货数量从 10 改为 8。
- 检查所有相关路径。 用实际身份演示允许的转换和一次绕过尝试，并保存最终状态。
- 改变支持证据。 审核后修改重要输入，验证旧审批无法授权另一账单状态。
- 检查恢复与责任归属。 外部来源或审核人不可用时，未解决工作仍须可见。
Odoo 代理业务状态验收指南解释更广泛的测试方法。发票流程的结果应表明，正确记录因正确理由推进，而被暂停的用例没有绕过约定条件。
若 AI 解释差异或建议匹配，应将建议与最终决定分别保存。只有在真实运行代表性、获准输入后，才能评价模型。这张建议验收表不能证明原生 OCR 准确率或定制模型性能。
我们会先实现什么？
先用一小组商定账单演示原生路径，再补充一条责任人和证据都明确的缺失异常规则。自动放行应留在已验收范围内。观察仍未解决的差异，以及审核流程实际需要多少工作后，再扩大范围。
每个获验收 Odoo 流程的成本把审核与失败工作计入商业评估。定制与标准软件选择指南帮助比较配置、模块和持续维护的集成。讨论 Wavect 的API 集成服务时，可准备一张现有流程能处理的账单，以及一项尚未可靠执行的异常规则。