科目表是你们的，规则是系统的：一条对账结果怎么变成金蝶认的会计分录

摘要：一条对账结果要变成金蝶认的会计分录，中间要过两道翻译：核算项目这棵树决定它归哪一类，转换规则表决定它进哪张单、落到哪个科目、符号是正还是负。这篇讲三级映射怎么搭、规则表为什么没有平台维度、币种税率与四个部门字段怎么配、自动出单四步会在哪四种情况下失败，以及快照冻结之后为什么改了口径也不用重跑历史。 关键词：核算项目、会计分录、科目映射、单据生成、核算维度、单据日期校验

一、单据推过去了，科目却对不上公司的账套

月底对完账，下一步是把结果推给 ERP。财务经理点生成单据，推过去一看分录上的科目编码：6001.01、6601.28。这两个编码在公司的科目表里找不到。

公司的科目表是财务部自己定的：管理费用下分市场推广费、平台服务费、仓储费，销售费用下分佣金、运费险，另有一批专用的税务科目。系统推过去的却是一套通用编码，谁都不完全对。

于是问题变成一句话：科目表是你们的，规则是系统的，这两样怎么不打架。 答案分两半：科目和核算维度最终按公司自己的口径走；而"哪类核算项目落到哪张单、哪个科目、符号正负"这个判断，可以沉淀成规则，让系统每次执行同一遍。

二、系统不出凭证，出的是单据与会计分录

对账系统不生成总账凭证。

它生成的是目标账套认的单据与会计分录。凭证与科目余额由 ERP 过账产生，对账确认本身也不产生会计凭证。

系统的口径写得很直白：应收类科目余额变动等于本期新增应收减本期收款（销售收款单核销），本系统不生成总账凭证，余额由金蝶过账产生。

落到操作上，转换环节产出的是应收单、费用应付单、收款单，单据上带会计分录，科目挂在分录行上。总账凭证是 ERP 拿着这些单据过账之后才有的。

搞混的后果很具体：财务查不到凭证；账务也会以为系统已经入账，实际上一分钱没记。

反过来说还有一层收益：正因为系统只负责把结果翻译成目标账套认的分录，公司自己的科目表才有全部决定权。 系统替公司记账，科目表就没有意义；系统只替公司翻译，科目表才是自己的。

这张流程图讲的是从对账数据走到会计凭证这条链路上各段的分工。系统负责"对账结果 → 单据 + 分录"这一段，再往后的凭证生成、科目余额和结账全在 ERP 侧。

三、三级映射：核算项目 → 规则表 → 会计分录

一条对账结果要变成会计分录，中间要过两道翻译：先定归哪一类，再定进哪张单。

核算项目这棵树，定的是"归哪一类"

核算项目是一棵三级的树，编码分三段。

类别层和子类层默认都是"其他"型，只有三级叶子必须显式设业务类型。 没设的那一行不进任何对账池——不报错、不告警，就是不进。费用类的叶子还必须挂在费用树下，树位置和业务类型要一致。

业务类型一共五类：主营收入（含退款退货，用负金额表达）、其他收入、订单费用（不含退款）、其他费用、其他（不进任何池）。

平台前缀已经定稿；旧的支付宝 ALIPAY.、亚马逊 AMAZON. 两套前缀已停用。

库里的规模是 272 项，其中三级叶子 250 个：订单费用 84、其他费用 70、其他收入 50、主营收入 44、其他 24。三级叶子里未设业务类型的是 0 个，值得当巡检项。另外，转换脚本引用的核算项目里有 1 个不在库存里，落库前得先补建，否则那一行出单取不到科目编码。

轻易云把核算项目与规则表做成配置即生效的两层，加一个业务场景不用动转换代码。

转换规则表，定的是"进哪张单"

规则表的业务来源是四元键：来源类型（收入主营 / 费用项 / 收入差异标签）× 核算项目（空串表示收入侧口径）× 金额类型（费用 / 收入 / 空）× 方向（正 / 负 / 空表示通用兜底）。数据库里的唯一键是五元，再加目标账套。作用域是计划号，不是维度。

命中顺序有明确规则：精确四元键优先，方向为空的通用规则兜底。

目标侧要配的字段就这么几项：目标账套、单据类型、单据类型名称、体行费用项目编码、符号、排序、是否启用。其中体行费用项目编码留空时，回退到核算项目上配置的科目编码。

这里有个最容易忽略的设计：规则表里没有平台维度。 同一条通用规则会同时命中多个平台，铺新规则前得先确认别的平台的转换脚本是不是也在消费同一个键。

转换脚本分收入与费用两类，严格分离，一次执行只处理一侧。加场景是加规则，不是改代码。 现有规则按平台分列是：速卖通 66、亚马逊 35、支付宝 29、京东 16-17、小红书 10、视频号 6。

四、三个最容易配错的地方：币种、税率、部门字段

出单时最容易翻车的不是科目，而是这三种字段。

币种有三条来源。 单据币别默认人民币，也可按店铺配置的币别映射；本位币固定人民币，不跟单据币别走；外币单不传汇率，由 ERP 按汇率类型、币别和单据日期从汇率表带出——实测某日美元兑人民币带出的是 6.7809。汇率表没覆盖到那一天的币别，单据就保存失败、判失败，要手工补汇率后重推。

踩坑的形态是：把外币写进本位币字段，同时单据币别也设成同一个外币。 这会触发"原币、本位币币别一致但价税合计不等"的逐行强校验，报错看着像金额问题，实际是币种填反了。

税率不是一个数，是三个来源。 某平台费用行的税率是 0.13，亚马逊费用行的税率是 0，财务应收与暂估侧取供应链原值。0 也是一个值，不能当成"没填"。

采购部门则相反：必须显式置空，不传这个键，ERP 会默认带出"采购部"。

费用项目编码有三条取值链路。

注意是 6601.28，不是 6001.28。 前者是费用类科目段，口头常说错，写进配置就是一张挂错科目的单。平台费用项目另有一套辅助核算编码，编号从 01 到 38，由内置对照表、规则覆盖和界面可改共同决定。

五、自动出单四步与四种失败

自动出单分四步：取数，读收入或费用的对账结果明细；关联主数据与映射，把店铺上的组织、部门和单据转换规则接上；按业务逻辑生成目标账套的数据格式并落库；落库之后仍可改，也可重新生成。

轻易云在转换层按幂等键生成批次，同一范围不重复生成，点两次也只出一套单。

执行层的顺序是：建任务，幂等键是范围加脚本的哈希；进队列；跑沙箱；单事务落库；状态回写。同一个范围已经有批次在跑，直接拒绝。

单据自己有一个状态机：草稿 → 已确认 → 推送中 → 已推送或失败，失败可重置回草稿。只有已确认的能推。

单据日期不是随便取的。 费用类单据的业务日期是账期月末倒数第二天，财务应收合并单是账期月末，收款单与转账单是该笔流水的日期。日期取错，那张单会一直卡在"晚于今天"。

这三台引擎各管一段：拉取取数、推送送单、集成转换负责翻译。引擎只做搬运，搬过去的东西对不对，全看前面那两张表配没配准。

六、快照语义：改了口径为什么不用重跑历史

批次一旦生成，就是快照冻结。此后对账侧再变——重新对账、重新分摊——都不影响已生成的批次。系统也不做"来源已变更"的自动检测，想刷新只能删掉批次重新生成。

反直觉的地方在这儿：快照保护了历史，也意味着改了口径，历史批次不会自动跟着变。 好的一面是不用重跑历史，坏的一面是系统不会提醒你"这批已经过时了"。轻易云把快照、回读与配平串成一条链：改口径不用重跑历史，缺行少钱当场就变成失败。

还有两条硬规矩：重跑对账会清空全部体行结果，包括手工确认的痕迹。 已推送的批次禁止删除，系统会拦截，防止 ERP 重复入账。

编辑边界分三层，这一层不清楚，改数据就会改错地方。金额禁改是硬规定：改了会和账单行脱链，要调只能走"改账单、重新对账、重新生成"。

七、兜底防线：回读校验与配平

推送成功不等于账对了。推送之后必须回读这张单，校验分录行数加金额合计，容差 0.005；不一致就判失败，并写明"计划 N 行 / M 元，实转 X 行 / Y 元"。

0.005 只吸收小数位差，不吸收缺行。 实测里有过一批某欧洲站 2026-08 的转换：漏推 429.84 元，静默丢了两行、少 127.70 元，接口返回的是成功，账上却少了行。只看推送日志显示成功就确认，是错的。

配平还有一条不能松的等式：财务应收加费用应收（差额单）等于账单净额，差额必须 0.00。 费用侧同理，费用应付合计等于费用池净额，费用应收合计等于收入侧贡献净额。

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

合规、审计、风控靠的是同一样东西：每一个数字都有出处，每一次推送都有回执，每一次不平都有记录。 回读容差 0.005、配平差额 0.00、手工确认必填原因，就是内控要的证据链。

---

三条今天就能做的动作

第一条，把核算项目库里三级叶子的业务类型巡检一遍，确认没有一行落在"其他"型上——那些行不进任何对账池，也不报错。再对一下脚本引用的核算项目，看有没有不在库里的叶子要先补建。

第二条，挑一个平台，把费用项目编码的三条取值链路各拉一张单出来，对照看落到哪个科目。重点看费用应付单是不是落到 6601.28，亚马逊的费用应收单是不是走了 6001.02。

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

三条都是当天能做完的事，做完就知道这套映射到底贴在公司的科目表上，还是只是看起来像。