首屏结论：电商订单、资金、发货可以自动对账，但“大模型逐行算账”是错误架构。正确分工是：数据层保存平台、ERP/WMS、支付、银行和财务原始事实；确定性规则引擎做逐单匹配、金额勾稽、跨期与完整性校验；Agent 只处理异常解释、补证、协同、规则草稿和已授权动作。终态必须是差异在源系统中被修正并回读验证，不是生成一张差异表。
先分清：总额对平和逐单对平不是一回事
一笔平台结算可能汇总多张订单、退款、佣金、运费和调整项，再以一笔金额进入银行。总额碰巧一致，并不能证明每个子订单、包裹和退款都正确。
最小对账对象至少包括：平台主单与子单、支付事件、结算明细、退款事件、ERP 原始订单、WMS 出库/退货入库、包裹与运单、银行流水、财务凭证，以及它们之间的身份映射。做跨境业务时，还要处理币种、汇率、跨账期和多支付渠道；可结合跨境电商 ERP 与平台怎么打通理解数据链，再用支付聚合接入的 5 个坑检查资金入口。
一张架构决策表：什么交给谁
| 能力 | 数据/规则层 | Agent | 人工审核 |
|---|---|---|---|
| 记录去重、字段标准化、控制总额 | 负责 | 不负责 | 复核规则与异常批次 |
| 1:1、1:N、N:1、限定 N:N 匹配 | 负责，可复算 | 解释匹配路径 | 处理弱候选 |
| 应收、退款、费用与差额计算 | 负责，使用定点数和版本公式 | 解释差额来源 | 审批口径变化 |
| 异常分类与责任路由 | 硬规则先分级 | 读上下文、组织工单 | 裁定边界案例 |
| 修改业务或财务状态 | 权限、幂等、事务和门禁 | 调用已授权动作 | 高风险动作批准 |
| 新规则上线 | 回测、版本、灰度 | 生成规则草稿与测试样本 | 审批发布 |
这个边界很重要：Agent 可以说清“为什么差 12 元”，但计算式、参与原始行、规则版本必须由系统给出，不能由模型临场心算。
自动对账的 8 步执行链
- 采集原始事实：优先 API、Webhook、SFTP，其次标准文件；RPA 只补没有接口的最后一公里。每批保留来源、时间、记录数、控制总额和原文 hash。
- 完整性门禁：时间范围不全、分页漏取、文件重复或控制总额不一致时，整批暂停，不产出“假平”结果。
- 标准化与桥接：状态、费用码、币种、时区和 SKU 统一，但原字段不覆盖；建立主单、子单、支付、退款、出库、结算、银行和凭证的映射。
- 确定性匹配：先用唯一强键，再做限定范围的一对多、多对一和组合匹配。弱键只能生成候选，不能自动定案。
- 差异分类：识别已发货未结算、已结算无有效发货、应收与实收不一致、退款未退货入库、重复事件、状态冲突和晚到未到期。
- 异常编排：Agent 汇总原始证据与计算式，解释可能根因，找到责任部门，追问缺失材料，并生成最小动作建议。
- 受控执行：低风险动作可自动重拉、重算、补映射、打标签、触发既有同步或创建调整草稿；真实退款、改库存、删单、冲销凭证必须审批。
- 写后回读：动作执行后重新读取源系统。只有订单、资金、发货和财务对象达到目标状态，异常才关闭；回读失败即标记未知或人工接管。
三类异常应该怎么收口
已发货未收款：先确认发货是否有效、是否仍在正常结算窗口，再查结算明细和平台状态。终态可能是补结算已到账，也可能是发货事实被纠正；“已催平台”不是终态。
平台已退款但仓库未退货入库：资金退款和实物退货是两个对象。系统需分别回读退款、物流、收货和库存状态，不能因钱已退就自动增加库存。
金额不一致：展示参与计算的订单行、优惠承担方、退款、佣金、运费和调账明细。财务确认后生成调整草稿，审批写入，再回读凭证和源业务状态。
首期落地边界
如果企业只需要把平台结算汇总入账，现有 ERP 或财务工具通常更合适，不必为了“有 Agent”重做一套。真正值得做的是多平台、不同 ERP/WMS、异常跨部门且长期没人关单的场景。
首期只选一个平台、一个 ERP/WMS 和一个财务终点，用两个完整结算周期跑只读平行账。验收至少看数据完整率、自动匹配精确率、异常召回率、误修率、写后验证率和异常账龄；自动匹配率高，不等于准确。
需要设计跨系统执行链时，可参考AI 工作流自动化的 6 个场景和AI Agent 项目验收清单。行业场景可继续查看零售电商解决方案，整体建设路径见企业 AI 落地五项工程。
