京东费用转换 17 条差异录入 规则

摘要：京东 POP 店铺月结时，结算资金表和账户流水里躺着十几种费用项——佣金、交易服务费、联盟扣款、先行赔付……它们该进金蝶的哪张单、按什么口径合并、哪些干脆不出单？本文把财务手工 Excel 里的「17 条差异录入规则」逐条拆开：结算资金表 2 项费用应收 + 8 项合并费用应付，账户流水 4 项费用应付 + 2 项费用应收 + 1 条企业站提现收款单，并给出每一条的金额验算、出单粒度和踩坑记录。

关键词：京东费用转换、17 条差异录入、规则、费用应付单、费用应收单、企业站提现、金蝶云星空

月底结账，京东账单里的钱都去哪了？

做京东 POP 的财务都经历过这一幕：月底从商家后台导出两份文件——一份「结算资金表」，按订单编号归集；一份「账户流水」，按商户订单号归集。两份文件加起来二十来个费用列，有收有支。老板只问一个问题：这些钱，金蝶里该长成什么样？

手工时代的答案是一张 Excel：《天猫，京东，抖音，拼多多差异录入规则.xlsx》。京东这个 sheet 里，财务用合并单元格圈出了哪些列合并出费用应付单、哪些列出费用应收单、哪一列单独出收款单。数一遍，正好 17 条规则。这篇文章就把这 17 条规则讲透：每一条管什么费用项、出什么单、金额怎么算，以及系统落地时踩过的坑。

先搞懂一个前提：费用侧为什么「跳过对账直接出单」

收入侧的对账大家都很熟：账单金额 vs 供应链订单，逐单勾稽。但费用侧不一样——费用出单需要的只是账单行的核算项目、金额方向、业务单号，这三样在账单解析落库时就已经定型了。

所以费用转换的正确姿势是流水级直查：不经过对账聚合层，直接按「单据类型 × 费用项」从账单行成单。这不是偷懒，是避坑——历史上佣金差 9.60 元、商品保险差 1.24 元的偏差，全是翻页和聚合层引入的二次误差 [来源：京东 POP 2026 年 6 月批次验算记录]。

上图是系统里的转换规则列表。每一条规则对应一个「费用项 → 单据类型 + 费用项目编码」的映射，京东 POP 的 17 条费用规则只是其中一小部分——同一套机制还承载着抖店、支付宝、亚马逊、拼多多的规则，合计 164 条。

17 条规则全景：两张表、三种单据

结算资金表的 10 条（按订单编号归集）

以 2026 年 6 月某户外品牌京东旗舰店真实数据为例 [来源：财务手工差异录入规则 Excel 逐格解读]：

两个要点：

• 2 项费用应收：代收配送费、小额打款费用退还，都是收入方向，出正数费用应收单。
• 8 项合并费用应付：注意是收支双向全量——佣金不只有支出 −13,691.53，还有收入方向的 1,755.14（退佣），都要进单。8 项轧差合计 −23,315.65，与 Excel 合计列分毫不差，这就是验算锚点。

账户流水的 7 条（按商户订单号归集）

这里最容易理解错的是赔付两项：先行赔付、直赔退款代扣明明是支出，为什么出「应收单」？因为这两项是平台先赔给消费者、再向商家追偿的性质，财务口径要挂对京东的应收——所以支出方向转成负数应收，净额 −4,191.76。

「不出单」也是规则。货款、商家结算款、售后服务单三项不出单，但绝不意味着可以忽略：商家结算款 196,794.05 是账账勾稽的锚点（财务应收 − 费用应付净额 = 商家结算款），售后服务单不出单是用户白纸黑字确认的口径，防止后来人「顺手补上」。

落地细节：一张单长什么样

17 条规则回答「出什么单」，接下来是「怎么出」。

出单粒度：单据类型 × 费用项 × 账期 = 一张单。也就是说 6 月的佣金出一张费用应付单、交易服务费再出一张，每个费用项目一张单，好核算；体行按业务单号一条分录，同费用项同单号跨日期合并金额，无单号的合并一条。单张分录超 3000 行拆多张，同属一个批次。

关键字段口径：

• 客户 22000003 / 供应商 91000003 / 归属部门 220102（国内自营组）/ 费用承担部门 1201（品牌部）——按店铺主数据映射取值，缺维护回落实值；
• 费用项目编码：应收单统一 6001.01；应付单按核算项目映射——佣金 6601.28、交易服务费 6601.30、卖家返还运费 6601.23、保险费类 6601.33、京豆 6601.15、联盟 6601.14、违约金/逆向保价 6601.31，缺映射回退 6601.28；
• 体行数量按金额方向取 1 或 −1，含税单价 = 流水金额绝对值，税率 0.13，体行必须带原始线上订单号；
• 表头业务日期 = 账期月末倒数第二天（0904 客户确认版）；销售收款单例外，一笔流水一张单、业务日期 = 该笔流水日期。

如果想走系统化这条路，可以考虑轻易云智能对账系统的集成转换能力：transform_rules 表承载「费用项 → 单据 + 编码」映射，转换脚本按上面的粒度成批生成单据，一次任务串行产出收入 + 费用两个批次。

上图是集成转换的完整流程：对账确认 → 转换批次 → 人工确认 CONFIRMED → 推送金蝶。注意中间那道人工确认闸门——费用应收单（YSD02_SYS）是直接创建，金蝶侧没有幂等拦截，重复推送会生成重复单，所以只有人工确认过的批次才允许推送。

实操验算：66 张单，与手工 Excel 全量一致

规则落成脚本后，用 2026 年 6 月真实数据跑了基线批次：66 张单（费用应收 21 / 费用应付 42 / 销售收款 3），无一行对不上 [来源：2026-08-27 实施与验算记录]：

某电商集团用轻易云的转换批次模块处理同类场景，从导入账单到 66 张单据验算一致，全程不到一天——其中大半时间花在口径确认，而不是写脚本。

但这个批次不是一次跑成的，中间抓出两个典型 bug，值得每个 ERP 实施警惕：

1. 翻页漏行：结算表 11,559 行只有 2,472 个不同的交易时间戳，按单字段排序 + skip 翻页，在 2,000 行分页边界上同时间戳的记录会漏/重。修复方法很朴素：排序键加 id 决胜。
2. 时区错挂账期：2 笔联盟扣款（共 71.50 元）发生在北京时间 6 月 1 日凌晨 4 点，代码经 UTC 换算取月，错挂到 5 月账期。修复：按 CSV 墙钟年月直取账期，并顺手审计了其余 9 张账单行表，确认存量零错挂。

上图是全局转换单据列表。每一张单都能反向追溯：单据 → 转换批次 → 对账计划明细 → 原始账单行，批次号格式 TFB-YYYYMMDD-NNNN，全链路可回放。

规则不是化石：17 → 16 → 17 的演进

最后说一个反直觉的事实：这 17 条规则落地一个月内，构成变了两次，总数又回到 17。

• 2026-09-01（CR-1）：代收配送费改挂 MAIN_INCOME，进收入对账池随订单出财务应收单，费用应收单剔除它——17 条变 16 条，费用应收基线从 −3,932.76 变为 −3,982.76（209 − 378.70 − 3,813.06）。
• 2026-09-09（CR-11 / CR-12 同日反转）：客户上午裁定恢复代收配送费出费用应收单，下午又裁定回滚。同一天两次反转，基线来回切换——这件事的教训是：规则版本和基线数字必须绑定记录，否则验收时永远对不上。
• 2026-09-11（v1.5.0）：账户流水里的「消费订单」补进费用应付范围，应付 12 项变 13 项——总数又回到 17 条，但已经是「3 应收 + 13 应付 + 1 收款」的新构成。

所以「17 条」不是一个静态数字，而是一套可演进、可验算、可回退的规则体系：每次变更冻结旧脚本快照、新批次用新口径、基线数字随版本更新。做实施时，拿到任何一份「差异录入规则」，第一件事不是开发，而是像本文这样把合并单元格逐格读出来、用合计数验算——历史上就有过把合并出单误读成「10 项不出单」的事故，整份规则文档作废重来 [来源：2026-08-27 问题复盘记录]。

单据生成只是上半场，推送给金蝶是下半场。上图的集成中心按单据类型分配 handler：财务应收单必须 Push 下推（暂估模式账套直接建单会被金蝶拒绝），费用应收/应付/收款单走 Save → Submit → Audit。批次状态机 DRAFT → CONFIRMED → PUSHING → PUSHED/FAILED，FAILED 可退回重来——这套闸门设计的核心目的只有一个：宁可不推，不推错单。

收尾：把 17 条规则变成可执行的资产

回到开篇的问题。京东 POP 费用转换的全部秘密，就这 17 条规则：结算表 2 应收 + 8 应付，流水表 4 应付 + 2 应收 + 1 收款，外加三个「不出单」的勾稽锚点。真正难的不是记住它们，而是三件事：逐格验算（每条规则都有合计数兜底）、粒度正确（费用项 × 账期一张单，体行按业务单号）、版本可追（规则演进与基线数字绑定）。

轻易云的转换批次把这三件事做成了默认动作：批次生成即验算、unmatched 不静默、脚本快照可回退。规则从 Excel 搬进系统的那一刻，它才从「某个财务脑子里的经验」变成「全公司可复用的资产」。