采购订单、收货和发票分别正确，不代表三者放在一起仍正确。企业常见问题是分批到货、单位换算、价格调整、税率差异、退货未回写或发票跨订单，人工只能在月底集中追差。
先建立可匹配的业务对象
至少需要采购订单号、供应商主体、物料编码、订单行、单位、数量、含税/未税价格、收货批次、发票号码和红字/退货关系。公司名和物料名称只能辅助，不能替代稳定 ID。
计算层先做确定性匹配
| 核对项 | 规则示例 | 异常去向 |
|---|---|---|
| 主体 | 订单供应商与发票销售方一致 | 采购/财务核验 |
| 数量 | 发票累计数量不超过已收货与容差 | 仓库/采购 |
| 单价 | 命中订单价或有效变更价 | 采购审批 |
| 税额 | 税率与含税口径一致 | 财务 |
| 重复 | 发票代码号码与金额未重复入账 | 财务 |
| 状态 | 订单、收货、退货未作废 | 对应系统 Owner |
公式、累计和容差必须由确定性引擎执行。Agent 不能因为差异“看起来合理”就自动放行。
Agent 负责解释和协同
当规则命中异常时，Agent 可以读取订单变更、收货备注、审批和沟通证据，形成差异说明：差多少、可能原因、缺什么资料、该找谁。证据不足时提出补问，不把可能原因写成事实。
同一发票的多条差异聚合成一个处置任务，避免采购、仓库和财务分别收到重复提醒。责任人处理后，Agent 回读订单、入库、退货、发票和审批状态，再重新运行匹配规则。
类似的确定性与解释分工，可参考电商订单资金发货怎么对账和报价数字为什么不能交给大模型算。
付款动作必须独立授权
三单匹配通过，只代表满足一组核对条件，不等于 Agent 可以自动付款。付款还可能受预算、账期、资金计划、争议和审批约束。平台应把“核对通过”和“批准付款”作为两个独立动作。
试点验收看自动匹配率、错误放行、重复发票拦截、差异处理时间、责任人完整率和回读一致性。需要连接采购、仓储、财务与审批系统，可继续了解财务岗位解决方案和定制开发。
一张发票可能对应多张订单
实际业务既有一张订单分批收货、分批开票，也有一张发票汇总多张订单。匹配引擎要支持一对多、多对一和部分匹配，并确保累计数量与金额不重复占用。弱键只能生成候选组合，不能因为总金额恰好相同就自动定案。
红字发票、退货和作废记录要沿原关系冲销，不能当作一笔独立的负数业务简单相加。
容差是业务规则，不是系统放水
数量、金额或税额容差应按物料、供应商、合同或采购类型配置，并有批准人和生效期。容差内可以进入快速确认或自动核对，超出范围转人工。不能为了提高自动匹配率不断放宽阈值。
证据缺失与业务差异分开
没有找到收货单，可能是尚未收货、单据未同步或匹配键缺失；这和“实际收货数量不足”不是同一种问题。前者交给系统或数据责任人，后者交给仓库和采购。分类错误会让业务人员替技术故障背锅。
建立供应商与内部两侧视图
对外沟通前，先检查内部是否漏收货、漏审批或录错税率。确认属于供应商差异后，再生成带订单行、收货批次和发票明细的沟通草稿，由采购或财务确认发送。处理结果写回原异常，并设复查日期。
上线后按供应商、物料和差异原因观察趋势。某类差异持续集中，可能需要修采购规则或系统映射，而不是继续增加人工核对队列。
