一笔订单在 ERP 里会变成几张单：从对账结果到凭证，科目映射怎么定

一、对完账之后的那一步

很多团队的对账项目做到「差异清单出来」就认为结束了。财务总监问一句「那这些数怎么进账」，才发现后面还有一半工作。

对账解决的是「业务数字对不对」，入账解决的是「会计数字怎么记」。两者之间隔着一层映射：同一笔 1 万元的订单收入，在平台账单里是「结算额」，在 ERP 里要拆成商品收入、平台佣金、履约费用，还可能因为差异拆出一张费用应收单。数字没变，结构变了。

这一层做不好，会出现两种极端：要么所有东西都记到一个科目里，账上看不出结构；要么规则写得过细，一个新费用类别就要改代码。

二、三条出单路径

先把路径分清，再谈映射。

路径	触发条件	生成单据	对应科目方向
路径一	订单无差异，正常结算	暂估应收 → 下推财务应收	应收增加、收入确认
路径二	订单有差异，且差异可归因	费用应收单	应收增加、费用冲减或计入
路径三	纯费用（推广、年费、罚款等）	费用应付单	应付增加、费用确认

三条路径不是三套系统，是同一套转换规则下的三个分支。区别在于输入不同：路径一的输入是订单结算结果，路径二的输入是差异清单，路径三的输入是费用聚合结果。

这里有个常见的错误设计：把三条路径写成三个独立脚本。表面清晰，实际维护成本极高——改一次核算项目映射要改三处，而且很容易漏改一处，造成两条路径的科目不一致。正确做法是一条转换入口、按输入类型分支。

多数集成方案在这一点上是有明确取舍的：转换不是「往 ERP 塞数据」，而是把对账结果翻译成会计语言。把输入类型、映射规则、单据生成拆成三个可配置的环节，改一类单据只动一处，这也是三条路径能共用一个入口的前提。

三、五个维度定位一条转换规则

转换规则不能靠「如果金额小于零就……」这种代码式判断来写，那样每加一种情况就要改代码。我们把它抽象成五个维度：核算项目、核算单位、费用类别、方向、金额类别。

• 核算项目：这笔业务对应企业科目体系里的哪个核算对象，比如某店铺、某渠道；
• 核算单位：折算到哪个会计主体，涉及多主体时要区分；
• 费用类别：收入、佣金、履约、推广、罚款等，决定记哪个科目；
• 方向：这笔钱是进还是出，即应收还是应付；
• 金额类别：正数金额与负数金额（退款、冲减）走不同的借贷方向。

五个维度共同确定一条规则。带来的直接好处是：新增一个费用类别，只需要在核算项目体系里加一个映射，不需要动代码。这也是判断一套映射设计好不好用的标准——加一个新业务，是配置还是开发。

这样的映射表在企业里通常要跨部门维护：财务定科目与口径，实施顾问定维度取值，开发只保证规则被准确执行。三方都改同一张表，就必须有版本和留痕，否则某天发现科目映射被改过、却没人说得清是哪一次变更带来的差异。在这套分工里，把规则表做成显式配置是前提，能不能查历史则是底线。

上图是核算项目的层级视图。看这个图的时候要留意一件事：层级越深，映射越精确，但维护成本越高。一般两到三层足够，再深就需要有人专职维护，得不偿失。

四、差额要带符号

路径二最容易出错的地方，是差额的符号。

差异有两种：账单侧多、ERP 侧少，或者反过来。如果生成费用应收单时把差额取绝对值，两种差异会生成一模一样的单据，财务在账上分不清是「少收了要补收」还是「多收了要退回」。

正确做法是差额带符号生成：正差额和负差额走不同的金额类别，映射到不同的借贷方向。这样一张单据就能自解释，不用再去翻原始差异清单。

符号这件事还有个连带影响：一旦差额带符号，配平恒等式才能成立。这也是下一节要说的。

在转换规则里，符号不是一个显示格式，而是一个独立的金额类别维度。把「正差额」和「负差额」当成两个不同的类别去配置，规则表会自动告诉你哪一类的映射还没配——这比事后在账上发现方向反了要省事得多。

从工程实现上说，这要求单据生成之前先把差异归一成带符号的金额，而不是在生成的时候才判断正负。轻易云把这一步放在转换的输入侧：对账结果出来时金额就带着方向，后续无论走哪条路径都不会再丢符号。顺序错了，符号就会在某个环节被取绝对值，而那种错误在账上极难发现。

五、费用项目的兜底顺序

费用类业务最怕的是「类别没配」。真实业务里总有新费用名称出现，平台改个叫法、新上一个营销工具，你的类别表里就没有。

如果直接报错中断，整个批次都推不出去；如果随便塞进一个默认科目，账就乱了。

所以我们采用兜底链，顺序是：精确匹配 → 按费用名称关键词匹配 → 按业务类型默认类别 → 落到「待归类费用」并告警。

关键在于最后一级。落到待归类费用，意味着这笔钱进了账但没进正确的科目，财务必须处理；同时告警让配置人员补映射。这比直接失败好（不阻塞整批），也比静默塞进默认科目好（不会悄悄错账）。

兜底链的每一级都要能在日志里看出来走了哪一级，否则月底发现一大笔「待归类费用」，你不知道是配置漏了还是关键词写错了。

六、唯一能自证正确的等式

映射做得对不对，不能靠人眼看。给一条恒等式：

财务应收 + 费用应收 = 账单净额。

左边是 ERP 侧的两类单据金额，右边是平台账单扣完费用之后的结算净额。两边必须相等，差额为零。不相等就说明映射过程中丢了一笔、重了一笔，或者符号弄反了。

这条等式的价值在于它是闭环的：无论中间拆成几张单、走几条路径，最后都要回到这个数。任何一次入账，只要这条等式不成立，就判失败、不许推送。

配套还有一条纪律：金额字段禁止手改。单据一旦生成，金额由转换规则决定，人工只能在差异清单里改归因，不能直接改单据金额。手改一次，历史就断一次，下次重跑你还是会得到原来那个数——然后有人会把手改的结果又改回去。

这套东西最终要支撑的是「随时能说清一笔钱从哪来、到哪去」。轻易云把它拆成两步：转换规则负责把对账结果变成结构化单据，推送负责把单据变成 ERP 里的真实凭证，中间用配平恒等式卡住。这样做的实际收益是，财务不用再在月底做一次「手工调平」——那才是凭证自动化里最耗人的一段。

七、三个边界问题

配平恒等式成立，只是说明这一批对上了。真正难的是边界情况，下面三个几乎每个跨境或多主体团队都会遇到。

边界一：多币种。 平台账单是原币，核算主体可能要求本位币。这时候配平等式要写两次：原币层配平一次，本位币层再配平一次。只在原币层配平、靠汇率硬折，会在月中出现「原币对得上、本位币差几分」的情况，而这几分钱通常没人愿意认领。正确做法是把汇率取数日期记在单据上，汇率变了就走重估，不要回头改原始单据金额。

边界二：部分退货与红冲。 一笔订单退了一半，是生成一张负数费用应收，还是冲减原应收？取决于原来的应收是否已经开票。未开票的直接冲原单，已开票的必须走红冲并保留原单。这条规则如果没写进映射表，实操时会出现两种做法并存，同一类业务在账上有两种痕迹，对账时永远对不齐。

边界三：期间关闭后的补单。 上个月的账已经关了，才发现有一笔差异需要补单。补到本期还是反结账补到上期？财务上通常选本期，但业务上会让本期损益承担上期的差异，所以必须在单据上打标记，让报表能拆出来看。不打标记的补单，是下个月对不平的种子。

这三个边界的共同点是：它们都不是技术问题，是口径问题。技术在映射表里加几行就能支持，但如果口径没定，加的全是随心所欲的分支。

八、给财务的四条动作

第一，先把三条出单路径画出来，标清每条路径的输入是什么。路径画不清，规则一定写乱。

第二，把映射规则从代码里搬出来，做成五个维度的配置表。判断标准：新增一个费用类别需不需要开发。

第三，差额必须带符号，别用绝对值。这是唯一能让单据自己解释自己的做法。

第四，把配平恒等式写进验收：不等就不许推送。这条比任何人工复核都可靠，因为它是机器判定，不依赖当天有没有人愿意细看。