新西兰 AI 技术落地实践案例：一家建筑公司发票自动分流 91% 的三个月实录

原来每个月初，发票是怎么处理的？

客户在用的系统很典型：供应商发票进 Outlook 邮箱，文件存 OneDrive，审批走 ApprovalMax，记账在 Xero，Xero 每月锁账。每个月 26 日到次月 3 日是跨月窗口，发票集中到达，月初两三天可能压着 600 到 700 张。

QS 的工作是把每一张发票看一遍：属于哪个工地、哪类项目（住宅、商业、酒店、办公室，还是根本不是本公司的账单），有没有对应采购单（PO），该由哪位项目经理审批，然后手工提交进 ApprovalMax。酒店类项目还有合并账单，要跨多个文件夹核对。审批人和工地的对应关系不在任何文档里，在几个人的经验里。

7 月中旬客户方业务对接人在群里说的一句话，是这个项目的起点：“这两周的账单目前都是 AI 在识别，但还没有上传到系统，怕时间拖得太久会有遗漏。”她担心的不是识别，是断流。这句话我们当时没有完全听懂，一个月后才懂。

我们接进了什么？

原则是连接而不是替换：一个系统都没换，Agent 长在客户已有的工具之间。

• Outlook 监听：专用发票邮箱，Microsoft 365 里单独注册一个应用，只给读邮件权限，随时可撤销。
• 本地运行：Agent 跑在客户办公室的一台 Mac mini 上，用 OpenClaw 做调度，发票原件不离开客户环境。
• 识别与分类：OCR 加大模型提取供应商、发票号、日期、金额、GST、币种；按工地和项目类型归档到 OneDrive 对应目录；匹配 PO。
• 提交审批：符合条件的自动提交 ApprovalMax；识别失败或信息不全的进 Manual Review 目录，等人。
• 状态回写：每小时同步 ApprovalMax 审批状态到飞书多维表格，仪表盘分 Admin 版（含金额）和审批人版（不含金额）。
• 人留在三个地方：QS 处理 Manual Review；项目经理在 ApprovalMax 里审批；财务在 Xero 里付款和锁账。AI 不批、不付、不改账。

第一个月：问题不在识别率，在规则

7 月 21 日第一次量化统计，407 张候选发票，只有 63 张进入审批，完成率 15.5%。拆开看阻塞原因：规则不完善 173 张，PO、审批人或工地信息缺失 132 张，真正识别失败只有 12 张，不到 3%。

也就是说，模型读发票读得很好，读完不知道该交给谁。“这家供应商的发票归哪个工地”“这个项目的审批人是谁”“水电费算不算本公司的账”，这些都不在任何一张发票上，在客户的脑子里。

7 月 24 日到 25 日，我们围绕 377 张测试发票和客户反复对口径：11 张可以直接进 ApprovalMax，226 张被正确排除（不是发票，或不是本公司的），112 张等信息或规则，17 张是系统集成问题。人工抽样 117 张，7 张判断有误，抽样正确率约 94%。7 月 27 日把 111 张问题发票归成 7 类，让客户书面回答每一类怎么处理，工作流恢复自动运行。

发票到底有多少张？

8 月初的一周，发票总数这个最朴素的数字对不上了。7 月的记录总数从 369 张，找回 88 张附件后变成 460 张，再统计成 815 条记录，最后确认标准发票 517 张。同一批数据用另外两个模型独立复核，一个得到 515，一个得到 559。客户方问的四个问题，我们一时答不上来：到底收到了多少张，有没有漏票，自动处理了多少，减少了多少人工。

根因有两层。第一层是流程：识别、拆分、去重三步混在一条流水线里，任何一步出错，最终数字都会漂。第二层更具体：此前让 Agent“清理已经人工处理完的 6 月发票”，它按发票日期而不是邮件接收日期执行，把本该保留的 7 月发票也清掉了一部分。有备份，当天找回 33 张，但如果没有独立的对账通道，这件事可能永远发现不了。

改法是把总账做成独立的审计链：邮件总数、带附件邮件数、附件数、唯一附件数、已识别发票数、被清理数、误判数、重复数，逐层对账，每一层都能回答“少了的去哪了”。从那以后，仪表盘上多了“上一周期正式结果”和“当前周期进行中”两块，数字来源分开写清楚。

客户要的不是识别率，是不断流

8 月 4 日，客户反馈“发票数量明显变少、无票可做”。工程师的第一反应是继续优化识别规则，让更多发票自动通过。内部复核后发现理解偏了：客户要的是先保证业务不断流。AI 判断不了的发票，哪怕信息不全，也要有序分到对应的人手里，而不是等系统识别完善后才分发，更不能全部堆进一个 Manual Review 黑箱。

这是整个项目最重要的一次转向。之后的设计围绕“剩下的那部分怎么交给人”：

• 按原因分子目录：Manual Review 目录按阻塞原因拆分：无 PO、工地待定、科目待定、供应商映射缺失。
• 处理完标 Done：QS 在文件名后追加补充信息并标 Done，Agent 定时扫描回填、自动提交，然后打 Submitted 标记防止重复上传。
• 加急单独分类：电费、水费、市政费、保险、车辆维修、押金、通讯费，逾期成本高，优先进人工队列。
• 非本公司发票：同一集团其他实体、供应商发错的，用白名单和黑名单识别，直接排除。
• 重复查重：按供应商、发票号、金额三项组合查重。

8 月：全量校准

8 月下旬进入收口。人工复核队列从 300 多份降到 181，再到 110、81。8 月 28 日按自然月统计：775 份发票相关文档，181 份需人工介入（23%），594 份自动分流（77%）。8 月 30 日正式交付时的口径：8 月共处理 775 份，694 份由 AI 自动识别和分流，Manual Review 降至 81 份，自动分流比例 89.55%。

9 月 1 日按客户的会计周期（7 月 26 日到 8 月 25 日）重算：798 份文档，730 份自动分流，人工复核 68 份，91.48%。两个数字口径不同，都放在这里，是因为客户看的是会计月，我们内部看的是自然月，写案例的时候两个都要说清楚。

谁能看金额，谁不能？

仪表盘做了两版。Admin 版给老板和财务，含金额、按项目和审批人的分布；审批人版只看自己名下待办，不含金额。飞书多维表格的自定义角色里建了 Approver、Admin、AI Master 三个角色，Agent 自己用 AI Master 身份写数据，看不到不该看的。

平台的边界，AI 不越

9 月 1 日客户提出一个看起来很小的需求：把一批 7 月的发票日期改到 8 月，好让它们进入正确的会计月。ApprovalMax 的公开 API 允许改日期，但改完审批流程会重置；而 API 里没有 approve 接口，重置后的审批只能由有权限的审批人手动点。我们对 37 份符合条件的发票执行：19 份更新成功，9 份因为权限冲突（HTTP 409）跳过，9 份因为状态已变成 rejected 不再修改。

这里的选择是：不绕。既然平台不允许程序替人批，那就让人批。这一条后来写进了交付规则：凡是涉及审批、付款、对外承诺的动作，AI 准备、AI 核对，人最后一按。

三个月留下的四条教训

回头看，最贵的不是技术，是这四个判断。

• 只看识别率会走错方向：第一个月识别失败不到 3%，完成率却只有 15.5%。真正的工作量在规则和映射，这些要从客户的人身上问出来，问不出来的要设计成人工路径。
• 总账要有独立的审计链：自动化跑通了，但“到底收到多少张”答不上来，客户的信任会立刻回到零。识别、去重、统计要分层，每层能对账。
• AI 按字面执行指令：“清理已处理的 6 月发票”这句话，人听懂了，AI 按发票日期执行了。涉及删除的指令要先试跑，要有备份，要有第二个数据源交叉。
• 把过程讲给客户听：7 到 8 月团队投入很重，但客户在两个半月里只看到“还没拿到结果”。9 月 1 日的整改会定了三件事：从“功能做完”转向“业务跑通”；降低一线操作门槛，少用开放式提问，多用固定步骤和选择题；主动发现并闭环问题，而不是等客户反馈。

现在怎样了？

8 月 30 日技术阶段交付，9 月起进入优化期：修审批提醒重复发送、供应商归类误判、锁账后的日期调整，另外为客户一位管理者新配了一台设备上的智能体。季度效果 Review 约在客户实际用一段时间之后。

最好的验收不是数字。9 月初客户把我们介绍给了他们合作的建筑保险经纪，那是另一个“文档重、合规重”的行业。

证据边界：本文所有数字来自项目群聊记录与 9 月 2 日项目复盘文档，日期均已标注；91.48% 按客户会计周期统计，89.55% 按自然月统计，两者分母都包含非发票类文件。客户为新西兰建筑总承包商，已匿名；截图中的公司名与人名已裁除或遮盖，含金额的仪表盘未采用。