Kaufland年度销售汇总比账上收入高，别急着改账：先把这条差异桥搭起来

平台观察

2026-11-09

257

真正麻烦的不是多出来的这11万欧元，而是你不知道这两个数字究竟在数什么。

年底对账时，最容易让人紧张的场景之一，是Kaufland后台导出的年度销售汇总，和财务账上的收入数字对不上。

Kaufland年度销售报告与账务对账（原创专题配图）

Kaufland年度销售报告与账务对账

假设一个中国卖家拿到的年度汇总是128万欧元，账上收入却只有117万欧元。差了11万欧元，第一反应往往是：“是不是漏记收入了？要不要马上让会计改账？”

先别动账。

真正麻烦的不是多出来的这11万欧元，而是你不知道这两个数字究竟在数什么。只要一个按订单、付款或平台报表口径统计，另一个按企业自己的收入确认、税款、优惠、退款和账期分类记录，两个数字不同完全可能是正常的；反过来，如果同一批交易、同一主体、同一币种和同一期间已经对齐，仍然出现无法解释的差额，那才值得往“重复、漏记、主体错配”方向追。

所以这类问题，顺序很重要：先查报告口径，再查交易集，最后才让合格会计判断账务是否需要调整。

第一件事不是对数字，而是认清你拿的是什么报告

Kaufland的卖家后台并不是只有一种“销售数据”。

公开的Seller University目前把报告区分为销售报告和财务报告等不同用途。销售报告主要用于导出订单及订单状态、物流相关信息；财务报告则用于查看销售收益和账户变动。另有专门的“DAC7 Annual Submission”，用于查看相关申报年度已经提交给德国联邦中央税务局的数据。也就是说，文件都可能出现“Sales”“Revenue”“Report”之类的字样，但业务目的并不相同。

这一步看起来很琐碎，却经常是差异的起点。

拿到年度文件后，先在自己的对账表里固定六个信息：文件实际名称、卖家主体、销售站点、报告年度、原始币种、报告用途。不要只留一个“2025 Kaufland销售额.xlsx”的文件名。尤其是一个账号下面有多个销售市场时，必须知道这份数字到底对应哪个销售站点；如果几个市场原本就是不同币种，更不能先换成欧元再去倒推原始差异。

Kaufland公开资料也显示，不同销售站点原则上使用当地币种结算，捷克和波兰销售站点另有以欧元提取余额的安排。提现币种和订单原始币种不是一个概念。如果财务账又以人民币或欧元作为本位币，就更应该把“原币金额”和“换算后的入账金额”分开保存。

还有一个容易被忽略的分岔：你拿到的到底是不是依法报送用途的文件。

如果卖家后台中的文件明确是“DAC7 Annual Submission”，它和普通经营销售汇总就不是一回事。Kaufland目前公开页面确认，相关报告可以在Seller Portal的Reports > Request reports > DAC7 Annual Submission中按申报年度请求；页面同时明确说明其PStTG信息要求和适用范围。

如果你的主体并不适用这份依法报送文件，就不要为了“合规”两个字强行把普通销售汇总套进DAC7。该看什么文件，就看什么文件。

为什么同一年度、同一家店，平台数字和账上收入仍然可能不同

最常见的原因，其实不是平台算错，也不是财务漏账，而是同一个订单在不同系统里走到了不同的时间点和分类里。

一笔订单可能先付款，随后发货，再完成履约，之后又发生部分退款。到了12月31日附近，事情就更复杂：订单在上一年付款，下一年完成；或者上一年完成，下一年才发生退款。平台的经营汇总、财务分类账和企业自己的收入确认政策，如果采用不同的时点，就可能出现跨年差异。

因此，年度对账不能只拿两个年度合计数相减。

要把订单编号拉出来，至少同时看付款时间、订单完成或履约时间、取消或退款发生时间，并确认这些时间字段采用的时区和统计期间。对于12月末和1月初的订单，尤其要单独看。跨年退款不能因为发生在下一年，就从上一年的问题里消失；它只是换了一个需要解释的位置。

税款、运费和优惠也是一样。

假设平台的年度经营汇总采用的是买家支付层面的金额，而企业账务按照自己的会计政策把某些税款单列、把某些运费放在其他科目、把卖家承担的优惠作为销售折减，那么平台数字自然可能高于账上收入。

但这里不能凭经验直接说“运费一定不算收入”“税款一定全部剔除”。真正应该做的是先确认平台报告这一列的定义，再看企业自己的会计政策如何分类。报告口径是事实问题，会计确认则是专业判断问题，两者不要混在一起。

费用也不能简单处理。

Kaufland公开说明，销售收益释放、账户变动以及月度费用等信息会出现在财务报告中；销售收益什么时候可用，也与订单履约状态有关。

所以，“平台年度销售汇总”与“最后实际提取到银行的钱”本来就不是同一个分母。更不能拿一个年度净放款数，直接去减一个年度报送或经营汇总，然后把差额叫作“少记收入”。

费用是费用，收入是收入；除非具体报告字段本身已经定义为扣费后的金额，否则不能因为一笔钱最终没有进入可用余额，就把它自动变成收入的减少项。

真正有用的对账，是把两边锁到同一批交易

处理这种差异，最有效的动作不是做一张“平台收入－财务收入”的大表，而是建立一个能够从订单一路追到年度汇总的交易集。

先以订单编号为主线，把属于这个主体、这个销售站点、这个年度的订单筛出来。订单有多次退款或状态变化时，不能只保留一个最终状态，要把影响金额的事件也留下。

然后把几个关键节点放到同一条线上：什么时候付款，什么时候完成，什么时候取消，什么时候发生退款，退款属于哪一个订单、哪一个年度。若一个订单跨年，单独打标。

做到这里，差异才开始变得有形。

接下来再建立一条“差异桥”。起点可以是已经确认定义的Kaufland年度经营汇总，向账务可比口径逐项调整：跨年时点差异放一类，退款和取消放一类，税款放一类，运费分类放一类，优惠放一类。平台费用则单独看它在报告中的定义和账务处理，不能默认当作收入抵减。

这条桥最重要的要求只有一个：每一项都必须能回到一批具体交易或一个明确的报告定义。

如果最后桥能闭合，说明两边虽然数字不同，但逻辑是一致的。

如果桥闭不上，剩下的才叫“未解释差异”。

一个匿名假设：128万欧元为什么可能对应117万欧元账务收入

下面只做方法演示，不对应任何真实卖家、税表、银行账户或客户数据。

假设某卖家的Kaufland年度经营汇总为128万欧元。为了便于演示，再假定这份经营汇总采用的是买家支付层面的毛额口径，包含相关税款和运费，且尚未扣除卖家承担的优惠；企业账上的收入则按照自己的既定会计政策，对税款、优惠和部分运费进行了单独分类，同时有一部分跨年时点差异。

经过同一订单集核对后，发现：

税款口径造成6.5万欧元差异；卖家承担的优惠为1.8万欧元；其中1.2万欧元运费按照该企业既定会计政策被单列到其他相关科目；另外1.5万欧元属于跨年和账期分类差异。

四项合计11万欧元。

于是：

128万欧元－6.5万欧元－1.8万欧元－1.2万欧元－1.5万欧元＝117万欧元。

这个例子的重点不是117万欧元“应该就是正确收入”，而是让人看到一件事：平台汇总比账上收入高，并不自动等于漏记了11万欧元。

反过来也一样。如果这11万欧元里面只有7万欧元能够解释，剩下4万欧元没有订单、没有退款、没有时间差、没有币种换算差，也找不到报告字段定义能够支持，那么就不能用“平台口径不同”四个字把它盖过去。

这时候才需要继续查。

差异桥闭不上，先分清是谁的问题

如果未解释差异还存在，建议把问题拆成三条线，而不是让平台、运营和财务互相甩锅。

第一条线找Kaufland。

需要确认的是报告本身：这个文件究竟是什么报告，统计对象是什么，金额是毛额还是某种扣除后的口径，统计依据是订单、付款、完成还是其他事件，退款和优惠如何进入年度数字，币种是什么，以及如果发现报告数据本身有误，平台当前提供什么核验或更正路径、有什么时限。

这里不要先告诉客服“你们多算了4万欧元”。应该先问定义。

因为如果报告定义本身与你的账务分录不同，平台并没有“算错”；如果报告定义明确与你看到的实际交易不一致，才进入平台侧数据问题。

Kaufland公开页面目前能确认Seller Portal存在销售报告、财务报告和DAC7年度申报等不同报告，也能确认相关报告的基本用途；但公开资料没有把每一个卖家账户实际下载文件的全部列名、每种异常情况下的账户级纠错按钮和具体处理时限全部公开。因此，这些账户级细节不能靠文章猜。

第二条线查自己的分类账。

把未解释差异逐笔回到订单，不要只看总账科目。最值得检查的是：有没有同一订单被ERP重复导入，有没有某批订单根本没有进入收入账，有没有把另一个销售站点的订单放进来，有没有把退款记到了不同年度，有没有把平台原币转换成本位币时用了不同汇率口径。

尤其要注意“主体错配”。

如果同一个Kaufland账户涉及不同法人、不同税务主体或不同销售市场，汇总表看起来都是Kaufland销售额，但财务账未必应该全部进同一本账。主体错配一旦出现，单纯调一个收入科目反而可能把问题越改越复杂。

第三条线留给合格会计专业判断。

哪些金额构成这个主体的收入，哪些属于税款或其他代收项目，运费在本企业会计政策下如何分类，跨年退款怎样处理，以及最终是否需要账务调整，这些不是平台运营人员靠一个报表截图就能决定的。

所以正确的问题不是“会计能不能把117万改成128万”，而是：“在交易事实和报告定义都已经核清之后，哪一个数字才符合这个主体适用的会计处理？”

这两句话，看似只差一点，实际方向完全不同。

DAC7要单独看，不能把它当成“平台收入证明”

如果你拿到的年度文件确实是Kaufland的DAC7 Annual Submission，就应该把它单独放在另一条轨道上。

Kaufland目前公开说明，卖家可以在Seller Portal查看相应申报年度提交给德国联邦中央税务局的数据，并在后台请求DAC7年度申报报告；其公开页面还明确列出欧盟总部TIN以及其他欧盟税务居民信息等要求。

德国现行《平台税收透明法》（PStTG）则进一步规定了需要报告的信息。对符合条件的实体卖家，报告信息包括名称、地址、税务识别号、增值税识别号、商业登记信息等，同时还涉及平台扣留或收取的费用、佣金或税款，以及按季度统计的相关报酬和交易数量。法律还规定，报酬应按照实际支付或记入的币种报告，并按照相应季度归集。

这恰恰说明，DAC7数字不能被简单理解成“年度GMV”，也不能直接理解成“应税利润”。

欧盟委员会对DAC7的解释也很明确：DAC7把报告义务放在平台运营方，并没有新设一种针对卖家的税，也没有规定卖家收入究竟按照什么税率征税；卖家的收入税仍然按照所在成员国既有税收规则处理。

德国PStTG还规定，相关平台报告原则上应在次年1月31日前提交；如果平台发现已经提交的数据不正确或不完整，法律要求平台在知悉后及时补报、更正或补充。卖家端真正需要关注的，是自己收到或能够查看的报告数据是否与实际主体、税务身份和交易事实一致，而不是把这个日期理解成“卖家可以在1月31日前自行改账”。

因此，DAC7报告、Kaufland经营销售汇总和企业财务账，完全可能是三个不同层次的数据。

把三个东西硬压成一个数字，才是年度对账最危险的做法。