结算净额不是收入：GMV、成交额、回款和收入到底差在哪

摘要：同一笔生意，财务手里能报出四个数：GMV、成交额、结算净额、银行回款。前两个说的是「卖了多少」，第三个是「平台认账该给你多少」，第四个是「银行实际给了你多少」——四个数没有一个是收入。这篇讲这四个口径各自在算什么、账单净额含税与收入不含税之间隔着哪些必须逐项勾稽的项、对账环节靠哪条恒等式把差异锁死，以及财务最常犯的三个口径错误。 关键词：结算净额、GMV、成交额、回款、收入确认、价税分离、账单勾稽

一、四个数同时在流通，谁也不是收入

老板问财务：这个月 GMV 报了多少？

财务报了一个数。老板接着问：银行到账多少？

又是另一个数。老板再问：那这个月到底赚了多少？

财务翻开报表，第三个数。

这三个数没有一个是错的，但它们回答的是三个不同的问题。问题不在谁算错了，在于这三个数根本不是同一个口径。

这五个口径对应四类人：运营报 GMV，平台账单给结算净额，出纳报回款，利润表给收入。四个人说的都是真话，四个人手里的数互相打架。

财务第一件要做的事，不是挑一个「最准」的数当收入，而是认清楚每个数后面挂的用途。GMV 做经营分析，成交额做转化，结算净额跟平台对账，回款核银行余额，收入做报表和申报。用途不同，口径就得不同；硬把其中一个当成「公司的收入」，往下所有的分析都会跟着歪。

二、结算净额是一层层减出来的，不是一个数

平台账单上给你的那个数，是平台从你的货款里一层层扣出来的。扣什么、加什么，顺序基本固定：

结算净额 = 收入 − 平台佣金与费用 − 退款 + 平台补贴 − 代扣税

这行式子是骨架，它告诉你结算净额由哪几项构成。做差异归因时它最有用：账单净额对不上，先问是佣金变了、退款多了、补贴少了，还是代扣税变了。

它也是一条倒推链：钱是从收入里一层层减出来的。但账单金额是含税的，收入是不含税的，所以这条链在做金额勾稽时要把税单独拆出来看。式子用来定位差额由哪几项构成，不用来倒推收入。

看一个实证。亚马逊美国 2026-08 的收入计划，收入 415,289.82 元，订单费 126,077.88 元。原来那张手工表把费用全部堆在费用侧，合计 126,367.37 元。系统没有收下这个总数，而是拆成订单费 126,077.88 元加费用计划 289.49 元，两项相加正好 126,367.37 元，分毫不差。

差在哪？差在每一分钱都有名字。手工表只有一个费用合计，出了事你不知道该找谁；系统把它分成订单费和费用计划两笔——前者随订单发生，后者是账单级的独立费用——核查路径完全不同。

这也是「净额」这个词最容易被误读的地方。净额听着像一个合计数，实际是减法做完之后的余额，不是另一个口径的总额。

这张报表的结构值得财务看两眼：行数、收入合计、费用合计、净额四个数字并排，最下面还有正数合计和负数合计两级汇总。正数那一列是收入侧，负数那一列是费用侧，两列相加才是净额。看报表的顺序应该是先看两列合计，最后才看净额——只盯净额，你不知道是收入少了还是费用多了。

核算项目这一层，其实是财务口径的落点。每个项目对应一个归集口径，收入类、费用类分开归，汇总的时候正数合计与负数合计自然分开。轻易云把这层归集作为唯一的口径入口，报表上的每一个数都能反查回它是由哪些单据、按哪条规则聚合出来的。

三、账单净额含税，收入不含税，中间隔着一整张税表

平台账单上的金额，一律是含税的。结算净额也含税。而收入不含税。

所以账单净额和收入之间的差额不是零，是：税 + 佣金 + 费用 + 退款 + 补贴。这五项必须逐项勾稽，不能拿净额倒推收入。

换算公式很简单：不含税 = 含税 ÷ (1 + 税率)。

这里有件常被搞混的事：对账阶段不做价税分离。原因有两个。一是账单原币就是含税的，拆税反而多引入一层舍入差异；二是对账要回答的是「平台认账给我的钱和我记的数一不一样」，这是金额相等的问题，不是发票问题。价税分离放在收入和费用的入账环节做，那里才有发票、有税率、有纳税义务发生的时间点。

顺序也就定了：先在含税口径下把账对平，再在入账环节做价税分离。反过来做，一边对账一边拆税，你会攒出一堆拆出来的差异，而且极难定位。

最容易出的事故在这里：拿结算净额申报增值税。结算净额比收入小，佣金、税费、退款都扣掉了，拿它当收入，等于少计收入，也少计销项。

这个边界得靠流程守，不能靠记得牢。行业里通常的做法是备一份口径说明，写清楚「对账用含税、申报用不含税、结算净额不进申报底稿」，并且出底稿时把这张表放在手边。准则上这类取舍最终要由财务负责人拍板，但至少得有个书面结论，别每个月靠人记。

四、回款是现金口径，收入是权责发生口径

回款比结算净额还要再走一步：

回款 = 结算净额 − 提现或转账手续费

比手续费更麻烦的是时点。平台认账、平台结算、商家提现、银行到账，这四个时点不是同一个。跨月的订单，钱在年前扣、开年后到账，这种事每个月都在发生。

拿银行回款当收入，时点和金额双错。时点上，年前下的单在年后回款，收入该落在年前；金额上，提现手续费、平台代扣税压根不是收入减少，是从收入旁边走掉的钱。

老话怎么说来着：结算净额是现金口径，收入是权责发生口径。 现金口径看「钱到没到」，权责发生口径看「活儿干没干」。两个都对，只是服务的目的完全不同——一个管现金流，一个管利润和税。

在轻易云里，回款这条链和收入这条链是分开的：对账核的是账跟账，回款核的是账跟钱。到账那一步只用来判断钱少了还是没找对，不用来确认收入。

五、对账的锚点：一条恒等式，差额必须 0.00

真正把几个口径串起来的，是这一条：

财务应收单 + 费用应收单（带符号）= 账单净额，差额必须 0.00

意思是：平台账单上该给你的钱，拆成「该记收入的」和「该记费用的」两部分，合起来必须正好等于账单净额，一分不差。费用那边带符号，所以是加法，不是减法。

锚点定在这里的好处是，它比的是「账跟账」，不比「账跟现金」，也不比「账跟发票」。这个月平台该给你的钱，拆完了必须等于账单净额；钱什么时候到、票什么时候开、税什么时候申报，是另外几条时间轴上的事，不在这里纠缠。

实证：费用计划 14 项，合计 220,386.75 元，与手工合计差 0。差 0 不是凑出来的，是每一条费用都找到了自己归属的核算项目。

费用侧的处理是三步：聚合、分摊、确认。

第一步聚合，把账单上散落的费用项归成核算项目；第二步分摊，把账单级的费用按规则摊到具体订单，让每一笔订单都带上自己的费用；第三步确认，确认过才算数。这三步的输出，就是恒等式左边那个「费用应收单（带符号）」。

这 12 张单据里，11 张已推送，1 张含异常体行。那 1 张不是系统坏了，是恒等式在这张单据上没闭合——通常是一行费用没挂上核算项目，或者符号反了。把它单独挑出来查，比把 12 张单据的总额翻一遍找差额快得多。

在轻易云里，这条恒等式被固化成了转换前的校验：差额不是 0 的单据不往下推，推送前先把问题行指出来。财务看到的是「哪张单据、哪一行、差多少」，不是一个悬在总数上的差。

六、三个最常犯的错，和一个反直觉的结论

这三个错误的共同点，是把某个时点的某个数当成了整个经营周期唯一的答案。

一个反直觉的结论：到账最多的那个月，不一定是赚得最多的那个月。

常识在这里失效了。常识默认「钱到了就是收入」，可电商的钱在路上要走三段：平台认账、平台结算、商家提现到账。每一段都会改时点，也会改金额。大促当月到账多，往往是因为上一批账期的钱集中打了过来；也可能到账反而少，因为平台把结算往后推了。

所以别用回款的同比、环比去判断经营好坏。经营看收入和费用，回款只回答一件事：钱有没有安全到账。

看板该有的样子就是把口径分列：收入一列、费用一列、净额一列，谁都能看清这个月的经营结果长什么样，而不是只剩一个到账数。在核算项目汇总和经营看板里，这几个口径是分列存的，不存在哪个数被悄悄换成另一个数。

七、今天就能做的三件事

第一件，画一张口径对照表。 把 GMV、成交额、结算净额、回款、收入五个数各写一行：定义、数据来源、谁在用、能不能进利润表。贴进财务共享目录，下次开会有人混用，直接指表。一天能做完，而且能挡掉后面很多争论。

第二件，把恒等式写进月度检查表。 格式就一行：财务应收单 + 费用应收单（带符号）− 账单净额 = 0.00。每月对完账填一次，差额不是 0 就填上单据号。填过一次单据号，就知道该去查哪张单，而不是从一堆报表里找。

第三件，先锁申报口径。 跟财务负责人确认一次：增值税申报基数用不含税收入，结算净额只留在对账和现金流口径里。这类口径最终由财务负责人拍板，但结论得落到纸上，别每个月靠人记。