发票匹配智能体
我们设计、构建并部署一个 AI 智能体，读取供应商发票、调取对应的采购订单与送货单，逐行执行三方匹配——在任何款项进入付款批次前标记价格、数量与税务差异——而放款仍由人来审批。
一览
在款项流出前拦截超付与重复付款——拦下的每一令吉都是留住的现金，而不只是节省的时间——并清理拖累供应商的应付账款积压。
对多样供应商发票的视觉/OCR，以及跨三套系统的三方核对，但固定的提示链与「审批前只读」把自主性和评估门槛控制在有限范围内。
见效后会有什么改变
每份申请耗时
人工匹配一张发票
约 8–12 分钟
使用智能体
约 1–2 分钟复核
节省的时间
每张发票约节省 7–10 分钟——每月 500–800 张约合 60–100 小时。而它拦下的每一笔超付或重复付款都是留住的现金：在一本典型的应付账款账上，每周防住一次付款错误，就可能超过整月的 AI 成本。
为估算；实际时间与节省取决于发票数量、每张发票的行项目数，以及你的 PO/DO 数据有多干净。
阶段 1 · 界定
业务问题
马来西亚一家公司的应付账款（AP）团队通过电子邮件和邮寄收到供应商发票，随后必须将每张发票与其对应的采购订单、以及证明货物已到的送货单进行匹配。文员一天的大部分时间花在机械性工作上——录入发票、找到正确的采购订单、逐行核对价格与数量、核对 SST——而不是判断是否付款。这个过程缓慢，月末容易堵塞，而在压力下文员往往只看总额、放行各行，而这恰恰是超付与重复发票混进付款批次的方式。
阶段 2 · 梳理
当前的人工流程
- 01打开供应商发票（PDF、扫描件或邮件）
- 02手动录入表头及每一个行项目
- 03找到对应的采购订单与送货单
- 04对照两者核对每行的价格、数量与税额
- 05就任何差异向采购人或供应商追问
- 06之后才放行以供审批与付款
问题所在: 瓶颈在于跨三份文件逐行核对——这个缓慢重复的环节在月末会被走捷径，而走捷径正是超付或重复付款被支付出去的原因。
阶段 3 · 设计
智能体化流程
我们以 prompt-chaining（提示链）方式构建：每张发票都经过一条简短可靠的链路——读取发票 → 调取其 PO 与 DO → 逐行匹配 → 标记异常 → 组装可审批的资料包——只有当某一行确实无法核对时，智能体才会停下来询问人。
仅当某一行无法核对时才重新读取该行并重新调取源文件——否则持续推进。
看一个案件在智能体中逐步流转——它负责读取与比对；最终决定仍由人来做。
实际效果
在发票材料中
智能体标记出什么
- 供应商、PO 编号与币种在三份文件间一致
- 单价不符：开票 RM 12.00 vs PO RM 11.50（每件多 RM 0.50）
- 数量不符：开票 100 vs 送货单收到 96（少送 4 件）
- SST 税率与计算无误
每个标记都引用确切的文件、行与数字 · 由你的审批人放款 · 每张发票 AI 成本约 RM 0.40–0.90。
逐步流程
- 1
读取发票
智能体读取供应商发票——原生 PDF、扫描件或邮件图片——读取表头（供应商、发票号、日期、PO 引用、税额）与每一个行项目，并对扫描件和拍照文件使用视觉能力。
- 2
调取采购订单与送货单
它根据发票上的 PO 引用，从你的 ERP 或文档库调取对应的采购订单与送货单（收货单）——这两份是发票必须与之一致的权威源文件。
- 3
逐行三方匹配
它将每一发票行与 PO（约定价格与订购数量）和 DO（实际收货数量）核对：单价、订购 vs 收货 vs 开票数量、行金额与总额，以及 SST 处理方式。
- 4
评估并复核（循环）
当某行无法核对或置信度低时，它会先重新读取该行或重新调取源文件再定稿——从而在标记前确认那是真正的差异，而非读错。
- 5
标记异常并组装资料包
它生成一份可审批的资料包：已匹配的行、需要关注的两三处异常——每处都附带多付/少付的金额及其来源文件——以及暂缓或放行的建议。
- 6
交给人处理
你的应付账款审批人审阅异常并放行或暂缓付款。没有任何款项会被自动支付。
阶段 4 · 构建
我们如何用 Claude 构建
它基于你的实时 PO 与送货单数据工作——而非陈旧的导出文件——因此它对照的是真正订购和收到的内容，并在定稿前重新读取收货数量。它通过连接的工具写入一份结构化的匹配资料包，而不直接触碰你的付款批次，因此它能标记并提出建议，却绝不会自行放款——它提出的每一个异常都能追溯到其来源的确切文件、行与数字。
集成对接
- ERP / 应付账款系统（PO、发票、GRN）
- 文档库或应付账款收件箱
- 可选：供应商主数据与税务（SST / e-Invoice）参照
底层实现
- 模式：基于 Claude Agent SDK 的提示链——每个工具通过进程内 MCP 服务器提供；读取发票 → 调取 PO/DO → 匹配 → 标记 → 组装资料包。
- 上下文：发票及其实时 PO 与送货单记录每次运行都会载入——文本加上对扫描件的视觉识别——并在资料包定稿前重新读取收货数量，因此绝不会对照陈旧副本匹配。
- 工具：只读的 PO/DO/供应商主数据查询、视觉/OCR 行提取器、确定性行匹配器，以及一个仅向应付账款审阅队列追加结构化匹配资料包的写入工具——没有任何工具能触碰付款批次。
- 防护机制：对 ERP 采用最小权限且只读；智能体标记并提出建议，但无法放行、修改或安排付款；JSON 模式锁定输出；在任何内容入队前先运行重复发票检查（供应商 + 发票号 + 金额）。
- 不可信输入与 PDPA：发票文本被视为不可信（被篡改的 PDF 无法左右匹配），供应商银行信息、身份证/商业注册号与价格均按 PDPA 处理。
- 恢复与上报：当核对失败、缺少 PO/DO 或 OCR 置信度低时，它会重新读取或重新调取，然后把发票转入人工队列——绝不静默匹配，绝不臆测数字。
- 可观测性与审计：每次工具调用、调取到的源数字与每处异常都会留痕且可追溯，审批人的放行/暂缓对应记录于资料包上——一条适用于财务管控与外部审计的机器可读审计轨迹。
- 评估框架：一组真实历史发票的黄金集——含少送、价格蠕升、税务错误与已知重复——配合确定性行检查，并对模糊案例采用 LLM 作为评审，每次改动在接触实时付款批次前都做回归测试。
阶段 5 · 架构
单一模型还是多智能体？
三方匹配是顺序进行、共享同一案件上下文（发票及其两份源文件）的，因此一个完善配置的单一模型是正确选择——可靠、每张发票成本更低、也更易审计。
我们把多智能体设计（约 15 倍 token）留给真正并行、广度优先的工作——而非一个紧耦合的核对。
哪个模型做什么
读取并提取发票行（含扫描件）
对多样的真实供应商发票版式具备可靠的视觉与结构化提取能力。
跨文件三方匹配与推理
主力模型——中等成本下的强推理能力，处理绝大多数发票。
高频的行级与重复检查
对大量简单的行级与重复是/否检查最便宜、最快。
处理模糊 / 有争议的异常
仅在 Sonnet 对棘手核对标记低置信度时调用——占发票的一小部分。
成本估算
AI 用量——每张发票
发票 + PO/DO 上下文 + 推理 + 输出资料包，按 Claude Sonnet 的 token 费率
约 RM 0.40–0.90
AI 用量——每月 800 张发票
使用 Batch API 处理非紧急的夜间任务约可减半
约 RM 320–720 / 月
构建（一次性）
接入你的 ERP、文档库与应付账款队列约需数周；简短的需求梳理后我们给出固定报价
按集成范围报价
持续运营
相比每月防住的一笔超付或重复付款，成本很小
监控 + 支持
仅为估算，按约 1 美元兑 4.70 令吉以令吉显示；每 token 费率以 Anthropic 公布的定价为准（请核对最新数字）。实际 AI 用量取决于发票大小、行项目数量与每月业务量。
阶段 6 · 评估
我们如何衡量成效
- 先做确定性检查——价格匹配、数量匹配（订购/收货/开票）、税额与总额
- 自我验证——智能体在呈现前对照源文件复核每处异常
- 业务 KPI——每张发票的应付账款处理时间、异常拦截率、防住的超付、处理量
我们采用 Agent GPA 框架——Goal、Plan、Action，当前衡量智能体可靠性的标准——并结合人工基线来评估。 (reference)
设定基线
我们先在样本上测量你当前的三方匹配——每张发票耗时、两名文员得出相同结果的一致程度、以及有多少异常漏到付款环节。这个人工基线是衡量每个智能体指标的基准，因此提升是可证明的，而非假设。
我们测试什么——Goal · Plan · Action
匹配决定（对比资深应付账款文员）
在留出发票上，其匹配/暂缓决定与提出的异常与专家一致
必需检查全部执行
每一项规定检查都逐行执行——价格、数量、税额、重复——不遗漏
无无谓的循环
仅在某行确实未通过时才重新读取或重新调取，而非无端反复
行提取准确率
是否正确读取每一行——描述、数量、单价、税额？
异常召回率（拦截率）
黄金集中真实的不符，有多少被标记出来
误报率
多久会标记出实际上能核对上的行
无凭空捏造的数字
资料包中的每个金额都能追溯到某一源文件行
上线关卡
在智能体于历史发票黄金集（含少送、价格蠕升与已知重复）上超过人工基线并达到这些 GPA 目标之前，它不会接触任何实时付款批次。每次改动在上线前都要针对同一数据集做回归测试。
阶段 7 · 交付
我们如何交付
我们先在你真实的历史发票上做概念验证——包括不符与重复的案例——在接触实时付款批次前先证明可靠性。聚焦单一实体的落地只需数周。
常见问题
- 智能体会支付发票吗？
- 不会。它负责读取、匹配和标记，并组装一份可审批的资料包；由你的应付账款审批人放行或暂缓付款。它无权访问你的付款批次——对于流出的款项，人在环路中至关重要。
- 它如何处理 SST 与 e-Invoice / LHDN 的要求？
- 它在匹配过程中检查税务处理，并可交叉引用你的税务与 e-Invoice 字段，同时保留完整的审计轨迹，让任何已匹配的发票都能被还原。请将此视为你财务与合规团队的起点，而非税务或法律意见。
- 如果缺少采购订单或送货单怎么办？
- 它不会臆测。缺少 PO 或 DO 本身就是一处异常——智能体会带着现有的信息把发票转入人工队列，而不是对照一幅不完整的画面进行匹配。
- 部署需要多长时间？
- 针对单一实体或应付账款收件箱的概念验证通常只需数周；全面落地需要更长时间，主要是因为 ERP 集成和让应付账款团队适应，而不是 AI 本身。
案例基于真实的匿名合作，细节已作概括处理。Anchor Sprint 是 Anthropic Claude 合作伙伴网络成员——部署与落地伙伴，而非分销商。以上为一般信息，非法律或合规意见。