如何用OCR与ChatGPT自动化发票处理

简而言之： 用一个具备版面感知能力的OCR步骤，加上一个把提取文本转成结构化发票字段的语言模型，然后把所有低于置信阈值的项——以及每一次供应商银行账号变更，无一例外——交给人处理。技术能很好地解决录入和匹配。它解决不了发票欺诈，而那才是真正让你损失金钱的部分。

应付账款是一个整体已高度自动化的财务职能里，最后几个真正靠手工完成的流程之一。发票作为PDF过来，有人从上面读出几个数字，敲进会计系统，追着经理要审批，之后再回复供应商那封问"什么时候付款"的邮件。一个月两百次。

这恰恰是当前AI真正擅长的工作形态。多数文章略过的，是决定这个项目究竟是净收益还是一项新负债的那一部分：一条自动化的应付账款管线，同时也是一条从邮箱直通银行付款文件的自动化通路。核实做错了，你就为"谁把你的供应商仿冒得最像就把钱汇给谁"这件事，建成了一套又快、文档又齐全的流程。

应付账款的时间到底花在哪里？

在自动化之前先测量，因为这里的假设通常是错的。

录入发票数据。 从文件上读出供应商、发票号、日期、币种、行项目、税额和总额，再敲进系统。枯燥、易错，也正是AI提取能几乎完全拿掉的那一块。

匹配。 确认这张发票对应着你确实订过、确实收到的东西，价格是谈定的那个。部分可自动化，且完全依赖于你有没有采购订单和收货记录可供比对。

追审批。 通常是整个时钟上最大的一块。一张发票躺九天，不是因为有人在打字，而是因为它排在预算负责人收件箱里另外四百封邮件的后面。只自动化提取、不动审批，你的应付账款周转天数几乎不会变化。

处理例外。 缺采购订单号、数量不符、贷项通知单、部分交货、币种搞错。占用的时间不成比例，而且是自动化帮助最小的场景。

上面只有第一项是AI提取能完整解决的。这依然值得做，但在有人拿它去写商业论证之前，先把预期设定对。

搭建这条管线：先OCR，再AI提取

为什么OCR和语言模型是两件不同的事？

把这两步当成一件事，正是多数自建管线出问题的地方。

OCR把像素转成字符，同时给出它们在页面上的位置。成熟的文档AI服务——Google Document AI、AWS Textract、Azure AI Document Intelligence、ABBYY——返回的是带版面信息的结果：带边界框的词、被识别出的表格结构，以及往往已初步标出的键值对。这层几何信息比人们以为的更重要。一个数字之所以能被认成"合计"，一部分原因是它在页面上的位置和它旁边的东西，而不只是因为附近出现了"Total"这个词。

模型的工作从这之后才开始：把标签不统一的杂乱文本，变成一条干净的结构化记录。"Inv. No."、"Invoice #"和"Ref"说的是同一件事；03/04/26有三种互不兼容的读法；一个行项目可能跨两行折行。这种归一化的判断，正是模型存在的意义。

多模态模型可以直接读发票图像、省掉OCR这一步，在干净的数字PDF上通常做得不错——对一天只有几张发票的公司是合理的。但在有量的场景下，两段式管线通常更好：单份文档更便宜；可以存下OCR结果，改提示词后重跑提取而不必重新处理原始文件；以及能指出某个数值来自页面上的哪一块区域。最后这一条，在审计师第一次问"这个数字哪来的"时就显出价值。

无论走哪条路，都要求模型按固定schema输出严格的JSON，并明确指示：找不到的字段返回null，而不是推断出一个看起来合理的值。缺失的字段会被路由给人，而一个自信编造出来的字段不会。

置信阈值和审批关卡该怎么设？

三方匹配是传统的控制手段：发票必须与采购订单、以及与"实际收到了什么"的记录一致，逐行比对，落在你设定的容差内。没有采购订单纪律，这个控制根本不存在，再多AI也替代不了。

置信度有两种，只有一种可靠。模型对自己的评分是个弱信号——模型完全有能力"很有把握地错"。内部一致性有用得多：行项目加总等于小计吗？小计加税等于总额吗？供应商在主数据里存在吗？发票号是不是重复项？税率对那个法域合理吗？这些算术和交叉引用检查，抓到的真实错误比任何自评分都多，而且实现成本很低。

然后按风险路由，而不是只按置信度。以下一律交给人：超过你设定金额阈值的、第一次出现的供应商、付款信息与留档不一致的，以及疑似重复的。

有一条规则值得当作绝对律：提取可以生成一张应付单据，但绝不能放款。"直通到已审批的应付款"是合理目标；"直通到钱离开账户"不是，无论置信度多高。

一个完整例子：从收件箱里的PDF到一张已审批的应付款

供应商把发票发到专用的应付账款邮箱。管线对附件计算哈希，立即丢掉与已处理文件完全相同的重复件——这一步值得放在最前面，因为供应商是会重发的。

OCR返回带版面的文本。提取步骤把它连同你的schema交给模型，拿回一条结构化记录：供应商、税务登记号、发票号与日期、币种、行项目、税额、总额、付款条件，以及文件上印着的银行账户信息。

接下来是校验，由普通代码完成，不交给模型。算术必须对得上，供应商必须能解析到主数据，发票号在该供应商名下不能已存在，币种必须是你真在用的。然后是匹配：找到采购订单，逐行比对数量与价格，核对收货记录。一次干净的匹配会生成一张应付草稿，原始PDF作为附件，OCR坐标一并存下，这样任何数字都能追回到页面上的那个位置。

现在才是那个真正值回票价的检查。把这张发票上的银行信息与该供应商留档的信息比对。完全一致，照常进入审批队列。任何一处不同——账号、开户行、收款人名称，哪怕只是SWIFT码变了——就地停下，转给一位具名的人做线下核实。不是回复那封邮件，而是打电话，打给这张发票到达之前你就已留档的那个号码。

之后审批照旧，这张应付款进入一个由人放行的付款批次。AI拿掉了打字和大部分匹配工作，而它一步也没靠近"要不要把钱发出去"这个决定。

AI发票提取 vs 专用应付账款软件 vs 手工录入

• 搭建成本与时间 — 手工录入胜出，没有任何东西需要搭。自建AI管线是数周工作量。打包的应付账款软件介于两者之间，如果你的账套在它已支持的名单上，通常几天配好。
• 单张发票的运行成本 — 有量的情况下AI管线最便宜。打包软件按单据数或用户数收费，量一上来可能变成最大一笔支出。手工录入看起来免费，其实只是以工资形式支付。
• 在糟糕文档上的准确率 — 打包软件胜出，差距不小。厂商在数以百万计的真实发票上训练过，包括拍糊的照片。通用模型在干净PDF上表现可敬，在折过又斜拍的扫描件上明显更弱。
• 审批流程与审计轨迹 — 打包软件明显胜出。审批路由、代理、金额阈值和不可篡改的审计日志本身就是产品，而不是附加功能，把它们好好重建一遍是自建管线里的大部分工作量。
• 对接冷门账套 — 自建管线胜出。如果你的会计系统是区域性的、比较老的，或被大幅定制过，打包连接器往往根本不存在。
• 开箱即用的反欺诈控制 — 多数情况下打包软件胜出，但差异大到不该假设，应在选型时点名去问。"供应商银行信息变更告警"是要指名问的那个功能。

一个诚实的建议：每月发票量在一百张以下，先去修审批流程，暂时别自动化提取。超过这个量，先评估打包的应付账款软件，只有在打包方案确实够不到你的账套时才自建——因为你要重建的大部分是流程与审计的机器，而不是那个聪明的部分。

没人能自动化掉的欺诈这一面

改掉的银行账号就是全部的攻击。 成熟版本的发票欺诈不是一家假公司。它是一张真实的发票，对应你真的订过的货物，只有一个字段被改了。其他一切都完美对得上，这正是它能躲过每一项"检查算术是否正确"的控制的原因。

仿冒域名与被劫持的回复链。 那封邮件可能来自一个与供应商只差一个字符的域名，也可能真的来自供应商自己的邮箱——在其账号被攻陷之后。后一种情况下，攻击者是在一条真实会话里回复你，他那段话的上方是真实的往来历史。

紧迫感是破绽。 催你在截止日前付款、警告供货可能中断、为"新的银行安排"通知得太仓促而道歉。紧迫感存在的目的就是让人跳过核实。

模型读的是文件，不是处境。 提取模型会准确报告页面上印着的那个账号。那就是你交给它的活。它对"这个账号是不是属于你的供应商"没有任何判断。

用线下方式核实，比对你原本就持有的信息。 任何付款信息变更都触发一通电话，打给在变更被提出之前就已在档的号码，并且由处理这张发票的人以外的另一个人来打。让它在流程里无法被跳过，并让所有人知道：在这一步慢下来，永远不算做错。

把这件事做对：付款数据治理、邮件安全，以及何时该让IT介入

发票不是中性文件：它们带着供应商的银行信息、你谈下来的价格、合同编号，以及真实个人的姓名。请刻意地决定你用哪家服务商、哪个层级，并去读真正适用于它的数据处理与训练条款——商业版和API层级通常与消费级聊天产品不同，而且条款会变，所以请以服务商当前的文档为准。让文档通过你自己应用里的API走，而不是让员工把附件粘进聊天窗口。

这条管线需要一个API密钥、一个邮箱连接，以及对会计系统的写入权限——这个组合值得当作敏感资产对待。密钥应放进密钥管理服务；邮箱连接应仅限于应付账款那一个邮箱；会计系统集成应拿到能创建应付草稿、且仅此而已的最小权限集。我们的AI+支持服务负责把这类管线从一开始就搭成"被治理的"，而托管IT支持则在依赖它的人不止一个之后，接手身份、权限和生命周期这一侧。

邮箱本身现在是你付款流程的一个生产输入，这改变了它需要什么：域名上的认证控制、能识别仿冒发件域名的过滤，以及供应商会话出现异常时的告警。这正是托管邮件安全存在的意义，也是做应付账款自动化项目时杠杆率最高的一件事——因为它针对的是那个会让你损失六位数的失效模式，而不是那个只浪费一个下午的。如果你关心的是员工报销那一侧而不是供应商发票，我们的姊妹篇用ChatGPT与QuickBooks/Xero自动化费用归类讲的就是那条流程。Brocent自2007年在北京创立以来一直在亚洲提供托管IT服务，总部位于新加坡，并自2016年起设有香港办公室。

常见问题

AI能可靠地读扫描件或拍照的发票吗？

可靠到有用，但没可靠到可以不看着。干净的数字PDF提取效果很好，平整的扫描件通常也没问题。而一张在光线不好的环境里斜着拍的照片、一份折过的传真件，或者打印文字上有手写批注的文件，就是准确率下降的地方——而且是无声地下降，因为输出看起来照样很笃定。

AI提取出来的发票，可以自动付款吗？

不可以。自动化提取和入账是合理的；自动化放款不是，无论置信度多高。在付款关卡保留一个人几乎不花时间——付款本来就是批量跑的——而它正是横在"一次提取错误"与"钱真的离开账户"之间的那道控制。

现实中能做到多高的准确率？

去测你自己的，而不是相信某个宣传数字，因为准确率几乎完全取决于你的文档构成。拿几百张真实发票跑一遍，逐字段与人工提取的结果比对，并按字段而不是按单据统计错误——98%的字段准确率，仍可能意味着相当比例的发票里至少有一个字段是错的。把总额、银行信息和发票号分开统计。

怎么才能抓住被改掉的银行账号？

为每个供应商存下留档的付款信息，让每张进来的发票自动比对，并把任何差异变成一次无条件的中止。核实的方式是打电话给你原本就持有的号码，并且由处理这张发票的人之外的另一个人来打。不要用回复邮件的方式核实，也不要接受在提出变更的那同一封邮件里给出的新号码。

把供应商发票发给AI服务商安全吗？

这是一个需要刻意做的决定。发票包含第三方银行信息和个人数据，所以请查清：你所在的那个具体层级，服务商当前条款关于留存和训练是怎么说的；处理所在的区域是否符合你的义务；以及你与供应商的合同就其信息作了什么承诺。很多组织的结论是：商业版或企业版API层级可以接受，消费级聊天产品不可以。

如果自动化了提取，还需要采购订单吗？

需要，而且比以前更需要。三方匹配才是让自动处理变安全的东西，而它需要有采购订单和收货记录可以比对。没有采购订单，管线只能确认一张发票在算术上正确、内部一致，这与"确认你订过这批货、收到了它、并同意了那个价格"完全不是一回事。

从哪里开始

在动手建任何东西之前先花一周测量：数发票、给各环节计时，弄清楚延迟里有多少是录入、有多少是审批躺在收件箱里。如果是审批，先修那个——更便宜的项目，更大的效果。如果录入确实是约束，就挑一个PDF干净的供应商品类做试点，第一个月让人复核每一次提取，并在建其他任何东西之前先把银行信息比对做出来。如果你更希望由做过这件事的人，把管线、邮箱控制和权限模型一起搭起来，欢迎联系我们。