对完之后呢：对账结果怎么变成金蝶、用友、SAP 里的单据
对完之后呢
摘要：对账做完，232 张单据躺在系统里，财务还要把它们变成金蝶、用友、SAP 里能过账的东西。这一步难在哪？不是接口难，是单据语义不同。本文讲清最常用的三段式落地路径、幂等为什么必须分单据设计、以及落地前必须确认的六件事。
关键词：ERP 集成、金蝶云星空对账、用友 ERP 对账、SAP 集成、暂估应收、集成转换、应付单、推送下推
对完账只是把问题换了个地方
某制造企业把电商对账做上系统后，第一个月就发现：账单导入了、差异也算出来了，可财务还是得手工在金蝶里录 40 多张单。录完之后还要逐张核对金额、逐张提交审核、逐张确认有没有入账。工作量比 Excel 时代还多了一层。
这不是个例。对账系统解决的是"算得准不准"，不解决"账进不进得去"。后者是另一件事，而且复杂度往往更高——因为它要同时迁就 ERP 的单据语义、主数据口径和审核流程。
目前对接的主流 ERP 是金蝶全系、用友、SAP。它们的接口都做得不错，难点从来不在能不能调通，而在落什么单、按什么粒度落、落了会不会重复。
三段式：最常用的落地路径
不论哪家 ERP，电商对账结果落到单据上，基本都归为三段：
| 段 | 对账结果 | 落到 ERP 的单据 | 为什么这么设计 |
|---|---|---|---|
| 收入段 | 暂估应收 / 收入对账确认结果 | 财务应收单 | 平台账单给的是"该收多少"，企业自己确认过的是"实际该收多少"，两者要分单 |
| 费用段 | 费用对账确认的各类费用 | 费用应付单、费用应收单 | 按费用项 × 账期汇总，同科目同类合并，减少单据数 |
| 资金段 | 平台提现、账户互转 | 收款单、银行转账单 | 反映的是资金实际到账，和收入费用分开走 |
三段的共同点是：都要有"确认"这一步。对账结果在系统里只是草稿，只有被人工确认过，才能生成转换批次，再由批次生成单据，最后才允许推送到 ERP。轻易云智能对账系统的集成中心就是按这三段来组织单据流向的，收入段、费用段、资金段各自成批、各自确认、各自推送。
这 164 条规则就是"费用项 → 单据类型 + 科目编码"的映射表。它的价值在于：把口径从 Excel 里搬出来，变成可维护的配置。以前这条映射写在财务的《差异录入规则.xlsx》里，改一次要找财务确认、通知开发、改表、发版；现在改一次规则只影响后续新批次，历史批次的口径原样冻结。
反直觉的一点：财务应收单不能直接建
这是整个集成里最容易被新手踩的坑。直觉上会想：对账结果确认了，直接在金蝶建一张财务应收单不就行了？
不行。金蝶云星空这类 ERP 的应收单有"立账类型"的概念，暂估账套下直接创建应收单会被服务端拒绝——不是权限问题，是单据状态机不允许。正确的路径是：先由企业对账确认产生暂估应收，再由暂估应收下推生成财务应收。
这张流程图里最该看的是那个"下推"动作。金额不是我们算出来的，是金蝶从暂估单上带出来的——这也是为什么这一段最容易出问题：只要暂估单本身错了，下推出来的财务应收一定错。对账结果和暂估单的勾稽关系，比推送逻辑重要得多。
另外补一个容易忽略的点：金蝶的应收单明细字段叫"应付单明细"（沿用了应付单模板的命名），而且它没有供应商字段，部门字段叫销售部门。这些"文档和实现不一致"的地方，是实施阶段最耗时的部分——因为要靠真实响应去反推字段名，光看对接文档会一直试错。
幂等：三种做法，一种最危险
"会不会重复推单"是财务最怕的事。同一批转换单据推送两次，在 ERP 里变成两套单据，账直接虚了。三种设计的危险程度完全不同：
| 设计 | 重复推送会怎样 | 危险度 |
|---|---|---|
| 服务端拒绝已下推单据 | 金蝶识别到暂估单已下推过，自动拒绝，天然幂等 | ✅ 最安全 |
| 带唯一单据编号字段 | 表头带防重字段，ERP 侧按该字段查重 | ⚠️ 依赖 ERP 是否真做了查重 |
| 只靠"人工确认过才推" | 没有服务端兜底，靠人不重复操作 | ❌ 最危险 |
问题就出在第三种。金蝶的费用应收单是直接创建的，没有幂等拦截。也就是说：只要人工点两次，ERP 里就会多两张单。
所以设计上必须有一道硬闸门：转换批次的状态机是"草稿 → 已确认 → 推送中 → 已推送 / 推送失败"，只有已确认的批次才允许发起推送，而且一次推送任务不允许并发重复入队。这道闸门的价值不在于防技术故障，而在于给财务一个"我能确定不会错"的按钮。
这张列表里每一行都带着批次号。同一账期重新对账一次，会生成新批次，不会覆盖旧批次。这一点很重要：如果口径改了要重算，历史结果必须留得住，否则"上个月的数去哪了"就没人答得上来了。
232 张单、934.57 万元——这个规模已经超出手工核对能兜住的范围了。但每张单都能反向追溯到「单据 → 转换批次 → 对账计划明细 → 原始账单行」，这是人工台账做不到的。
按单据类型拆通道，而不是按目标系统拆
轻易云集成中心的组织方式值得单独说一节。常见的做法是"金蝶一个连接器，用友一个连接器"，内部再按单据类型分支。这里的拆法更细：一个单据类型对一个推送通道，各自独立配置启用状态、模拟开关、消费的单据类型列表。
拆开的好处是故障隔离和灰度上线。费用应付单的映射规则写错了，收款单那条通道不受影响，可以单独停用、单独切回模拟模式重跑。集成成一个整体的话，一处配置错误就得整体停推。
这张明细视图是排查问题的第一现场：某个单据没推出去，先看这条通道声明消费了哪些单据类型，再看批次状态卡在哪一步。配置可见，是集成可维护的前提。
顺带说一个真实踩过的坑：推送失败的常见原因不是金额错，而是会话过期。ERP 侧的登录态有有效期，长批次推到一半可能中途失效，所以推送必须支持"从失败的那张继续"，而不是整批重来。
落地前必须确认的六件事
不管对接哪家 ERP，这六件事不确认清楚，后面一定返工：
- 单据类型对应关系。你的科目体系里，收入落在哪张单、费用落在哪张单、提现落在哪张单——先画出来，别让开发猜。
- 立账类型的约束。哪些单能直接建、哪些必须下推、哪些下推后不允许修改。
- 幂等手段。目标 ERP 哪些单据有服务端防重、哪些没有。没有的，必须靠人工闸门兜底。
- 主数据映射。客户、供应商、部门、物料、费用项目编码，缺哪个会导致单据推过去落到错误的主体。
- 审核流程。建完单是自动提交审核，还是要人工在 ERP 里点？谁负责？
- 失败处理。推送失败是整批回滚还是单张跳过？重试有没有上限？
这六件事写成一张表，实施顾问和财务各签一次字，比后面联调两周再返工划算得多。集成中心把这六件事落成配置项：消费哪些单据类型、幂等字段填哪个、默认组织和业务类型取什么值，全部可见可改，改完先切模拟模式验一遍，再切真实推送。
收尾：集成做得好不好，看的不是成功率
评估一套对账系统的 ERP 集成水平，行业里常看"推送成功率"。这个指标意义有限——成功率 99% 意味着每 100 张错 1 张，而那 1 张可能正是金额最大的那张。
更值得看的三个指标是：
- 可追溯率：任意一张 ERP 单据，能不能在 30 秒内倒推回原始账单行；
- 幂等覆盖率：没有服务端防重的单据类型，是否都有人工闸门兜底；
- 重跑成本：口径改一次，需要重推多少历史数据。
前两项决定这套系统能不能过内审，第三项决定它能不能用一年。
轻易云智能对账系统的集成中心按单据类型拆分通道，逐类配置、逐类可停、逐类可重跑，对接范围覆盖金蝶全系、用友与 SAP。技术上的事系统能扛，但单据怎么设计、科目怎么映射、谁来点确认——这三件事永远要财务和实施顾问一起签字才算完。