应付账款与发票智能体

先搞清楚你在自动化哪一种发票，因为两半的价钱不一样。

这个领域的公开基准数据难得地扎实。Ardent Partners 的应付账款指标研究给出：同业最佳约为每张发票 2.78 美元、周期 3.1 天，而全体采购方均值接近 10.89 美元、10.9 天；无接触处理率同业最佳约 49%，均值约 33%。这道落差有两种读法在这里要紧：

• 干净通道本来就便宜。一张对着未结采购订单到来、与收货记录相符、还能自己完成会计科目编码的发票，在一家成熟的公司里处理成本不过几美元，压根用不上模型——一条匹配规则加一个 ERP 集成就够了。再用智能体自动化它一遍，产出的是一个好看的无接触率数字和一笔很小的节省。
• 钱和天数都在例外里。3.1 天与 10.9 天之间的差距，并不是均匀摊在所有发票上的；它集中在少数卡住的那些身上。每卡住一天，就是一笔失掉的折扣、一通打给你团队的供应商电话，以及一分逾期付款的风险。

所以第一个设计决定与架构无关。把上个季度的发票拉出来，切成直通与例外两堆，分别算价。如果你的直通通道已经占了 80% 的量、只占 20% 的成本，那智能体应该整个待在另一边。

抽取只是入场券；三单匹配是一个数据问题，智能体读得再好也读不出来。

如今在结构化发票上的文档抽取已经足够好，字段准确率很少成为那道约束——解析方面的考量在面向 RAG 的文档解析里，而本页所有内容都假定你输出的是经过校验的 schema 而非自由文本，见结构化输出。把表头、合计与行项目从页面上取下来，是厂商拿来做演示的那部分。

会失手的是匹配。一次三单匹配需要三份单据彼此相符，而其中两份是别人产出的：

• 采购订单可能压根不存在。非订单类支出——服务、订阅、某人用一封邮件就下单的一次性采购——在结构上就无从匹配。读得再厉害，也变不出一张从来没开过的采购订单。
• 收货记录可能迟到。货已经到了，但没人在系统里确认收货，于是这张发票现在卡在一件仓库的活儿上，而不是一件应付账款的活儿上。
• 数量对不上也可能是合理的。分批交付、缺货补发、容差之内的价格变动，以及采购订单上从来没有的运费与税费行。

智能体的杠杆在匹配的上游，而且比匹配本身值钱：在受理时就识别出这张发票没有采购订单，趁记忆还新鲜把它路由给申请人；识别出卡点是缺一条收货记录，于是去追收货方而不是采购员；识别出差异，并说清是哪一行、差多少。这次重新框定——从"把发票匹配上"变成"点名缺的是哪份单据，然后去把它要来"——就是这份工作的全部；而正是同一个洞见，让采购与寻源智能体把功夫下在采购订单的上游而不是它本身。

先把例外的分类学建起来，再去建智能体。

"例外"不是一件事；而一个把它当成一件事的队列，正是应付账款团队总要留一个人专门决定"这该转给谁"的原因。先把上个季度的例外按根因归类——通常五到八个桶就装下了几乎全部的量——你会发现每一类都有不同的责任人和不同的处理路径：

• 没有采购订单 → 找申请人，问一句"这是订过的吗，走哪个预算"。
• 缺收货记录 → 找收货地点，要一个是／否确认。
• 容差之内的价格差异 → 按政策自动放行，不惊动人。
• 容差之外的价格差异 → 找采购员，并写明采购订单的哪一行、差额多少。
• 数量差异 → 先查是否分批交付，然后要么放行、要么短付。
• 疑似重复 → 交应付账款复核，绝不自动放行。
• 陌生供应商／新的银行账号 → 交供应商主数据管控，在证明之前一律按欺诈处理。

到这里，智能体的任务才算被良好定义：判定例外类型、去取回那一条缺失的事实、向恰好一个人问恰好一个问题，然后把闭环收上。这是一件结果可核查的任务，也就意味着你能评估它。"把这张发票处理掉"不是。

按"能不能撤回"设闸门，而不是按金额。

几乎所有应付账款审批矩阵都是按发票金额分档的，而对智能体来说这是错误的那根轴，因为金额与"错了还能不能挽回"并不相关。改按可挽回性给失败模式排序：

• 重复付款——通常可挽回。供应商那边挂着一笔贷项，你去要回来，代价是占用的营运资金和一点难堪。用供应商、金额、日期与发票号的模糊匹配去发现它，并记住重复最常见的入口是不同渠道：同一张发票既发了邮件又寄了纸质件，或者改了个参考号重新提交一次。
• 付给了错误的主体——通常不可挽回。应付账款里的商务邮件诈骗，绝大多数是一次供应商银行账号变更，以一封看着挺像回事、抬头也挺像回事的邮件到来。这是最要紧的那道控制，而它不是一道 AI 控制：供应商主数据上的银行账号变更，必须通过带外渠道、对着一个你早就掌握的号码去核实，而智能体绝不能有权写那个字段。
• 为从未收到的东西付了钱——部分可挽回；这也正是三单匹配里"收货"那一半存在的全部理由。

实操规则是：当三份单据彼此相符、供应商是老关系、且银行账号自上一次成功付款以来未变时，智能体可以放行这笔付款。任何触及供应商主数据的动作、任何对新收款人的首次付款、任何银行账号变更，一律交给人并配一道核实步骤——不论金额多少，因为那张 4,000 美元的"试水发票"恰恰就是欺诈收款人被建立起来的方式。这是环境权限那条论证的具体形态：把智能体的写权限限定在付款批次上，绝不给到它背后的主数据。

每一次放行还必须是幂等的。一个对超时的 ERP 调用做重试的智能体，刚刚发明了一笔重复付款；幂等键与重试语义就该放在幂等与重试所说的位置上，而在这个领域里，一次被重放的写入是真金白银的损失，不是多出来的一行记录。

让智能体去提议科目编码，让人工的覆盖去教它。

总账科目编码、成本中心归属与税务处理，才是智能体真正胜过规则引擎的地方，因为信号是文本的、依据是历史的：这个供应商、这条描述、这位申请人，过去 340 次都是这么编的。有两件事能让它在实践中跑得起来。

带着置信度去提议，低于阈值就弃答。一个自信的错误科目比一个空白科目更糟，因为它能活过复核，到期末结账时才浮出水面。智能体应该返回它的建议、它所依据的先例，以及一个诚实的置信度——低于那条线时路由给人，而不是猜。校准这个问题是不确定性与校准的主题，而同一条"弃答胜过自信错答"的原则也驱动着数据与分析智能体。

把每一次人工覆盖都当作标注数据。一位会计重编了某张发票的科目，其实是在告诉你：先例错了，或者政策变了；把改前、改后与这张发票的特征都记下来，你就有了一套不断长大、且收集成本为零的评估集。按供应商统计的覆盖率也是你手上最好的早期预警信号：某个供应商的编码忽然频繁需要更正，说明它在开票方式上改了点什么。

审计轨迹要精细到字段级。财务审计师的问题不是"这是不是 AI 干的"，而是"这条编码是谁批的、依据是什么、我能不能看到审批当时那张发票的原样"——留存与证据方面的要求在审计轨迹里，而应付账款是少数几个真的会有外部审计师去读这些记录的智能体领域之一。

量每张发票成本与例外周期时间。绝不要只量无接触率。

无接触率是每家厂商都会报的指标，也是这个领域里最容易在什么正事都没干的情况下被推高的一个，因为它的分母在你手上。把范围收窄到"前二十大供应商的、有采购订单的发票"，这个比率立刻跳上去；例外并没有消失，它们只是离开了这次测量。请把它与那些没法一起被做手脚的数字并排上报：

• 全负荷的每张发票成本，把智能体自身的 token 与平台开销也算进去，对着你启用智能体之前的基线看。基准数据就是用这个单位表述的，所以你能把自己摆到 2.78 美元与 10.89 美元之间，而不是摆在一个百分比旁边。
• 周期时间的 p50 与 p90，不是均值。应付账款的痛是一种尾部现象：中位数那张发票从来就不是问题。
• 按根因分类的例外率及其趋势。如果"没有采购订单"占了你例外的 40%，那价值最高的改动是一条采购政策，而不是一个更好的模型。
• 按供应商统计的一次通过率。正是这个数字把一项应付账款指标变成一场与供应商的对话，而持久的收益也在这里——一个把自己发票格式修好的供应商，是把那类例外永久消除了，而不是把它自动化了。
• 拦下与漏过的重复付款、错付笔数，用计数并附上金额来上报。一次被拦下的银行账号欺诈，可能超过一整年的处理成本节省——而这也正是你该用来陈述投资回报的方式，见衡量智能体投资回报。

延伸阅读：金融场景智能体，包含对账在内的更大财务面；采购与寻源智能体，同一条工作流的上游那一半；审批与确认的交互设计，怎么设计一道人真的会去读的闸门；以及人在回路，这道闸门该摆在哪儿。