平台代收的那 30 元配送费：过手负债怎么记

摘要：平台替商家代收了一笔 30 元的配送费，这笔钱最后要交给物流承运方，不是商家的收入。可不少店铺把它并进了主营业务收入，收入和销项一起抬高，月底再靠调整分录拉回来。这篇讲过手负债：代收代付的钱路过你的账该怎么记、运费的三个归宿怎么分、代收项在核算项目里为什么要单独占一个位置，以及代扣的税为什么不算这一类。 关键词：过手负债、代收代付、其他应付款、代收配送费、运费核算、核算项目

一、账单上多出来的那一行，不是多出来的收入

先看一个具体的数。京东 2026-07 账期的结算账单里，除了货款行，还单列着一行"代收配送费"，金额 30.00 元。

这 30 元商家一分没收到。平台先收着，等货送到、账单走完，再从结算款里扣走转给承运方。这笔钱在商家的账上，只是走了一段路。

可财务拿到账单的第一眼，很容易把它当成"这一单多收了 30 块"。于是代收配送费被并进主营业务收入，月底一算，收入比实际卖出去的多，销项也跟着多。更麻烦的是这 30 元最后以什么形态留在表上，往往说不清楚——挂应收账款挂着，挂着挂着就忘了它压根没结。

原始账单管理里，账单类型分得很细：结算、资金流水、营销对账各是一类，每条账单挂着所属店铺和解析进度。代收项就藏在结算账单的某几行里，不主动拆开，它永远是一串混在货款里的数字。

二、判定只有一条：这笔钱最终不属于你

代收代付这类钱，会计上有个名字，叫过手负债。翻成白话：钱从你账上路过，你替别人保管一段，最后再交出去。

判定标准只有一条——这笔钱最终不属于商家。不属于，就既不是你的收入，也不是你的成本，是你的负债。

分录很朴素：借 应收账款，贷 其他应付款—代收代付。翻成白话：钱进来了，先记一笔"我替人保管着"；对方该拿走了，这笔保管就结束。

关键词是"最终不属于"这四个字：钱是"暂时经过你的账"，还是"最终就是你的钱"，一字之差，分到的科目完全不同。

这里有个反直觉的地方，也是实务里最常翻车的地方：钱确实进了你的账户，账单也确实在你手里，凭什么不算收入？ 常识在这里失效，是因为常识默认"钱到我账上就是我的"。但会计认的不是钱有没有流过账户，而是这笔钱最终归谁、有没有对应的商品或服务交付给你。代收的那 30 元，对应的服务是物流商送的货，不是你卖的商品。你既没提供商品，也没提供服务，这 30 元凭什么能算你的收入？

把代收配送费并进收入，等于收入和销项一起虚增，还得多交一档增值税。

判定流程其实就三步：先问这笔钱是谁付的（买家、商家，还是平台自己贴钱）；再问它有没有经过你的账；最后问它最终交给谁。三步都答得出来，科目就定了。这一步不花多少时间，却决定了后面记的是收入还是负债。这个判断值得在系统里固化：轻易云把"每一行是什么性质"做成解析环节的配置，财务改口径时改一处就行，不用等到月底的分录里再找补。

三、运费有三个归宿，先问谁付的

运费是最容易记乱的一类。同一个"运费"字样，在账单上可能对应完全不同的性质。分三种情况：

三种归宿里，只有第一种可以进主营业务收入，而且不拆——买家付的运费已经包含在订单总价里，它是商品价格的一部分，硬拆出来单列没有意义。

第二种是商家自己承担的成本：平台从结算款里直接扣，账上就该是销售费用。京东一个账期走应付的费用项有 9 类，佣金、交易服务费、商品保险服务费、运费保险服务费、随单送的京豆都在里头。运费保险服务费（编码 YFBXFWF）走费用侧，跟代收配送费是两回事。

第三种才是过手负债。很多财务把第二种和第三种混在一起，是因为它们在账单上都表现为"平台帮我要了笔运费"，但钱的流向完全不同：一种是从你的结算款里扣走，一种是先进你的账、再从你的账里转出去。

还有一个连带容易混的：随单送的京豆（编码 SDSDJD）是营销费用，不是运费类。它是送出去的成本，不是物流费。这两个词经常被装进同一个"运费"篮子，月底做费用率分析时才发现口径不对。

四、代收项要配独立的核算项目，不能复用主营收入码

判定完之后还有一件技术活：这一行代收，在系统里得落到一个独立的核算项目上。京东这边用的是 JDPOP.SHIPPING，名字就叫代收配送费。

为什么不能拿现成的主营收入码凑一下？因为核算项目就是汇总的口径。一旦复用了收入码，这条 30 元在汇总报表里就是一笔收入，跟真货款分不出来。解析的时候省事，月底做收入分析、做费用率、做店铺排行时全部要回头返工。

规矩有三条：代收项在解析环节就把性质定死，不许事后猜；代收项不参与收入合计，但可以和收入同批出单，保持独立体行；代收项的余额在期末必须有去向——要么已经转给承运方，要么还挂在其他应付款上，不能凭空消失。

这不是多此一举。亚马逊一个费用计划里挂着 14 个核算项目，合计 220,386.75 元，跟手工汇总分毫不差。分毫不差的背后，不是月底有人归类，是每个项目在解析层就已经把性质定死了。代收项要用同一套办法。

值当，回报在后面几个月。轻易云把这件事提前到解析环节：每一行账单在落库之前就被归到一个确定的核算项目上，主营收入、代收代付、费用、资金动作各走各的码。以后换个人接手，也不用再问这条 30 元当初算什么。

五、一个账期等式，看这笔钱站在哪一边

把 2026-07 那个账期的计划头等式摆出来：

104,451.49 = 货款 108,545.03 − 货款支出 4,123.54 + 代收配送费 30.00

等式右边三项各归各的：货款是收入，货款支出是支出项，代收配送费是过手负债。三项加总等于计划头合计 104,451.49 元。

注意代收配送费在这个等式里的位置：它被单列出来，不进收入合计，可它又是计划头合计里的一分子。这就意味着它既不能被漏掉——漏了计划头对不上；也不能被混进收入——混了收入虚高。放在哪都不舒服的位置，正是过手负债该待的位置。

一条订单在体行层面会摊成四栏金额：收入、订单费、供应钱、差异。代收项作为一个独立体行走，挂自己的核算项目、进自己的金额栏，不去挤收入栏。系统把这条规矩执行到位，人就不必在月底回头猜这笔钱当初是什么性质。

六、代扣的税不是代收代付，别混在一张表上

相邻的一类最容易混：平台代扣的税。

代扣的税是代扣代缴负债。钱同样是路过你的账，但它最终交给税务部门，性质是"替国家收"，不是"替物流商收"。分录上一字之差——贷 其他应付款—代收代付，还是贷 应交税费—代扣代缴——在报表上却分得清清楚楚：前者是经营性往来，后者是税。

处理上也有区别：代扣税不确认收入，也不进费用，只做税金对平校验。有对账差异挂着的时候，其中一项就叫代扣税金，金额 37,952.80 元，这一项只参与对平，不入收入。

在系统里，这两类靠的是各自的核算项目：代收代付是一类，代扣代缴是另一类，两个码不共用。轻易云把它们在解析环节就分开定死，汇总时自然各归各位——代扣税不进收入，代收项也不进收入。

支付宝那一套三张表更能说明问题：聚合结算账单里既有天猫商家提现，也有平台代收；账户流水账单里是费用应付明细；余利宝明细是申购、赎回和余额宝收益。聚合结算里的"平台代收"，落到账上就是其他应付款；余利宝的申购赎回是资金动作，既不是收入也不是代收代付。三张表要一起看，才拼得出一笔钱完整的去向。

账单类型分得越细，代收项越不容易被漏掉。

七、三个坑，和一张自查表

第一坑，代收项并进收入，前面讲过的那笔虚增就出在这里。

第二坑，代收项进了费用。费用虚增、毛利被压低，负债端还挂着一笔没人去结的应付。

第三坑，净额对账时扣两次。先在账单侧扣了一次，生成凭证时又扣一次。每笔差得不多，但每个账期都错一点，攒到季度末就是一笔说不清的账。

自查表很短，三列就够：

表里每一行都要落到一个核算项目上：代收项配独立码，不并进收入合计。费用侧分摊的尾差容差是 0.01，超过就判该组分摊失败，不要手工抹平。

还有一类边界要说明白：同一笔运费，个别平台的合同里既约定平台代收、又在结算单里扣回，这到底算代收代付还是费用抵扣，各家平台合同写法不同，准则上也没有一个统一答案。这类要由财务负责人拍板，并且把结论写成书面口径附在合同后面，别让它在每个月的手工调整里现编。

把这套口径硬在流程里，和靠人记在脑子里，是两种完全不同的状态。行业里电商财务的做法大致分成四类：还在用表格手工对的、走部分自动化的、用 ERP 加部分自动化的、真正把口径写进系统里的。差别不在工具贵不贵，在于口径是每次靠人回忆，还是每次由系统执行。落到最后那种做法上：代收项配独立核算项目，性质在解析环节定死，出单时保持独立体行，报表上单列不并入收入。系统不替财务做判断，只保证同一个问题每次得到同一个答案。

---

三条可以今天就做的动作

第一，把这个月账单里的非货款行全部拉出来，一行一行写上归宿。通常也就十几行，半天足够。

第二，在核算项目里查一遍代收代付类的项，确认它们既没复用主营收入码，也没被并进收入合计。

第三，跟业务方对一次口径：运费、运费险、平台代收的配送费、随单送的京豆，分别归谁、记在哪。这四个词最容易混，写在纸上贴给客服和运营，比口头讲三遍管用。