账单行、订单行、ERP 应收单行：三个东西怎么对上号才算平

摘要：逐单看每笔都对平，汇总起来却差着一条。这不是对账引擎算错了，是粒度问题：账单行、供应链订单行、ERP 应收单行是三套互不相认的行，谁也没对上谁。这篇讲这三方靠哪个键连起来、为什么匹配必须带客户编码、整单轧差为什么是默认口径而分向只活在一个平台、暂估应收为什么只能下推不能新增，以及配平时那条差额必须为 0.00 的不变式和推完回读这道防线。 关键词：行级对账、双码匹配、三方核对、暂估应收、财务应收、应收单行、订单粒度

一、逐单都对平了，汇总却差着一条

一个收入对账计划做完，逐单点开，每一笔都写着对平：账单行金额和供应链订单行金额一致，业务订单号对得上，客户编码也对得上。

把计划里所有行加总，和账单净额一比，差着一条。

实测里见过两种形态。一批的批次缺口是 3,541.70 元，其中 3,443.70 和 98.00 两条：出差额单时把账单净额取了绝对值再乘符号，遇到净额为正的标签行，方向翻反；改成带符号直接入单，那个计划的转换总额 189,830.10 才对上。另一批更隐蔽，某平台版本只按差异标签和差异额判断、没判断对账结果，把 2 行失败行出成了正数差异单，批次虚增 1,359.40 元。

这屏界面里的每一行都对平，并不代表这一批平了。行级对账要回答的不是"单笔配不配平"，而是"行怎么汇成单、单怎么汇成批、批怎么对上净额"。

更麻烦的是，这类差经常在最后一步才冒出来：差异行已经归了类、单据已经推给财务，等月结做表时才发现不平。这时候要回头翻的是整批转换。

二、三方是哪三方，靠什么连起来

先把这三张行表摆清楚：

连接链只有一条：账单行按业务订单号命中供应链订单行，命中的行逐行带上 ERP 的单据内码与分录内码，再与 ERP 分录逐行钩稽。

金蝶侧的接入不是一个接口。账套里登记的是 8 个通道，2 个负责拉，6 个负责推。少一个拉通道，账单行接不到供应链；少一个推通道，暂估就下推不出去。

订单侧有三个号，长得像但不能混：

视频号那条链路用的内部订单号是仓库入库单号，不是平台订单号。脚本如果按"平台订单号等于内部订单号"写，匹配集就是空的，表现为大范围缺供应链。

业务订单号还是唯一能落到体行上的那个号。写错这一列，账上就会多出一批无法反查到订单的行。

匹配是双码硬约束：业务订单号加客户编码。订单号只在同一家店里唯一，跨店必须靠客户编码隔离。这就是为什么"按订单号匹配"在单店跑得通、上了多店就全线飘红。

这张图讲的就是双码为什么必须是双码：业务订单号负责把行找到，客户编码负责把行分对店。键这一层立不住，后面每一步汇总都在放大同一个错误。 轻易云把账单行、供应链行与 ERP 分录行用同一个业务订单号串起来，再用客户编码把店铺隔开。

三、整单轧差是默认口径，分向只活在一个平台

轧差有两套算法，但只有一套是现在的默认。

整单轧差（现行默认）：同一订单号在本期计划里的全部账单行合并成一个净额，与供应链侧合并净额比，全程不分正负。

分向不轧差：退货与结算分方向判，是亚马逊一家的遗留做法。老文档里整段"分向对账"已经降级为历史。

反直觉的地方正在这里：分向不是"另一种风格"，是某一家平台的历史包袱。新平台照抄分向，假差异会立刻暴增——每一笔退货都被当成反向单，而供应链侧根本没有对应的腿。

容差是零，严格相等。只有两处例外：某平台标签判定允许 0.01 元，某平台小额尾差档是 0 < 尾差 < 0.05 元。更宽松的旧口径早已废止，不能再拿它给差异做豁免。

差异只记承载行。 一个订单有多条体行时只有一条是承载行——净额为正归正、为负归负、为 0 取内码最小的那条；其余行标记为已并入，金额记 0，不出单。不这么定，计划里的差异合计会翻倍。

无单守卫。 过滤后找不到供应链行的订单，不能因为净额是 0 就判成功。唯一例外是"正负两腿都在、净额恰好抵消"的订单，记为已并入、金额 0、不出单。

现行差异标签码是三十多个业务码加一个兜底码（历史上是 23 个，已经演进过），失败类目前 6 个。转换规则按平台分列：速卖通 66 条、亚马逊 35 条、支付宝 29 条、京东 16 到 17 条、小红书 10 条、视频号 6 条。规则和账单对不上的平台，差异率会先变高。

平台、供应链、内部核算各占一角，中间靠一根轴连着。轴就是业务订单号，轴上承重的就是行。行级对账做的是把重量算准，不是把三个数比一比。

四、暂估只能下推，财务应收不能新增

在金蝶账套里，财务应收单不能直接新增。直接建单会被账套拒绝，报错写得很直白：立账类型财务应收单只能通过暂估应收下推。

这条约束决定了整条链路的形状：暂估应收是源头，财务应收是产物，转换层夹在中间。

下推是分录级的，不是单据级的。只传上游暂估单的分录内码，源单内码与单号置空。转换脚本必须逐行携带分录内码，缺了这一步，行为会退化成整单误推。实证里见过某平台漏推 617.98 元，另一平台多推 7,958.91 元。

一张 48.45 元的暂估应收单下推出财务应收单之后，账套自动写上钩稽四元组，并把上游的已核销金额从 0 反写成 48.45；下游单据删掉，上游钩稽自动回滚。

下推还要分两类，出的是两种不同的单：

子集单只允许分录级下推。脚本如果把它判断成整单覆盖，要直接判失败。

命中集有三级兜底：对账脚本回传的行内码集合，按业务订单号直查供应链，最后是合并单号兜底。转换层禁止再叠分向过滤，分向已经废弃，叠上去会把已经命中的行二次筛掉。

还有一条：单行命中必须显式返回命中行集合。否则兜底取全集时，物料明细会把整单里还没结算的商品也聚进财务应收单，既虚增当期金额，又会在下期重复出单。

轻易云在转换层把下推与出单拆开，先算清命中集再动账，出错时能定位到是匹配没命中，还是下推写错了。

五、配平不变式：差额必须 0.00

财务应收（暂估下推主单）加费用应收（差额单）等于账单净额，差额必须 0.00。

费用侧同理：费用应付合计等于费用池净额，费用应收合计等于收入侧贡献净额。

差额单的算法只有一种：账单净额（收入金额带符号合计）减已下推金额，带符号直接入单。禁止再乘一次规则符号，禁止取绝对值。差额为 0 不出单；正数出蓝字费用应收，负数出红字。第一节那个 3,541.70 元的缺口就出在这里。

有两条例外必须说清楚。极速退款、仅退款这类正负双腿的，不并成一张单轧平，而是正腿负腿各出各单；已并入的行金额记 0，不参与这条不变式。

反直觉的一条：单据合计等于计划合计，不等于配平。 差额单方向错的时候，两边可能同时错，而且错得很整齐——总额一致，比对不出一处差异。

实证上这条等式可以逐组验：

• 速卖通 9 月：收入侧 828 个体行，单据合计 25,365.73 与成功行净额完全相等、偏差 0；费用侧 488 张单（42 张应付 14,386.05、446 张收款单 139,887.68），46 个核算项目与币种组合逐组配平、偏差 0。
• 小红书 9 月：4 张单，应付 323.88、应付 601.63、应付 89.04、红字应收 −37；应付合计 1,014.55 等于费用池净额，红字 −37 等于收入侧贡献。
• 视频号 9 月：3 张应付单合计 424.15 等于费用聚合净额；收入侧财务应收单 28,535.30 加费用应收红字 −60，等于体行合计 28,475.30，差额 0.00。

集成中心管的是三台引擎分别跑拉取、推送与转换。但引擎只负责搬运，搬过去的东西对不对，取决于键立没立住、口径有没有写成规则。

六、推完必须回读：0.005 只吸收小数位差

出单粒度。 应收、应付都是核算项目乘账期出一张单。带业务订单号的行逐条成分录，不带订单号的按费用项加承担部门合并成一行。单张分录超过 3000 行要拆单，拆单只切片不改金额，片内合计之和必须等于组装金额。收入合并单全月合并一张，表头不带订单号、订单号放体行，并记录合并了多少个订单——有一批合并单收了 531 个订单。

主数据四件套缺一即失败。 往来单位类型、往来单位编码、费用承担部门、币别，缺任一项单据判失败，并点名缺的是哪个键。但缺件分三级：

第三条最阴险：费用池是 0 而不是报错，账面上看着干干净净，等月底才发现少了一整类费用。

这一层是整条链路里最容易省、也最不该省的一步。轻易云把出单和回读绑成同一步，缺行和少钱当场变成一次失败，而不是拖到月结才被发现。

费用项目编码有三条取值链路：费用应收单一般取 6001.01，亚马逊固定取 6001.02；费用应付单按店铺配置、规则、核算项目一路取，最后兜底 6601.28。注意是 6601.28，费用类科目段，口头常常说成 6001.28。

币别有三条来源：单据币别默认人民币；本位币固定人民币，不跟单据币别走；外币单不传汇率，由 ERP 按汇率类型乘币别乘单据日期从汇率表带出，实测 6.7809。

推送成功之后必须把单据回读一遍，校验分录行数加金额合计，容差 0.005。不一致就置失败，并写明"计划 N 行 / M 元，实转 X 行 / Y 元"。

0.005 只吸收小数位差，不吸收缺行。 少推两行、少 429.84 元，金额上完全可能落在容差里，也完全可能不落在——所以行数必须和金额一起校验。

实证里有一批某欧洲站 2026-08 的转换，漏推 429.84 元，静默丢了两行、少 127.70 元，接口返回的是成功，账上却少了行。只看推送日志显示成功就确认，是错的。

还有一批可以当闭合检查的样本：45 张单，1 张合并财务应收单（786 个体行、103,792.07 元、合并了 531 个订单）、34 张营销券、8 张补差价、2 张红字，1 加 34 加 8 加 2 等于 45，双向闭合。

七、今天就能做的三条动作

第一条，把这个月所有失败行按差异标签码拉一张清单，标出哪些是缺供应链、哪些是金额不一致、哪些是只有赠品供应链。三十多个业务码不分类看就是一团，分类之后能看出哪一类在涨。

第二条，抽一个平台，手工重算一次差额单：账单净额带符号合计，减已下推金额，看是不是 0.00。成本不到一小时，一次就能验出方向错、行漏、符号错这三类问题。如果不是 0.00，先看差额单是不是取了绝对值。

第三条，在推送流程里加一条回读校验，把"计划 N 行 / M 元，实转 X 行 / Y 元"写进失败信息，拿上个月的批次跑一遍，看有没有缺行。

行级对账的难处从来不是算，是把三套互不相认的行用同一个键串起来，再把串起来的东西按同一个口径汇总。键立住了，账才平；回读做完了，账才敢用。