Kaufland结算单有了，买家要的销售发票为什么还是交不了？下一笔先补哪段流程

假设一笔Kaufland.de订单已经完成，平台后台也有月度结算文件。买家却发来一句很具体的话：“请把这笔订单的销售发票发给我们，抬头、地址和VAT信息要完整。”卖家打开后台，第一反应往往是把现成的结算单下载下来发过去。对方一看，回一句：这不是我们的采购发票。

Kaufland买家发票：订单、结算与开票责任

再翻ERP，找到供应商给自己的采购发票，发过去，还是不对。

这类问题看起来像“少了一张PDF”，其实常常是凭证链没有分清。平台结算单、上游采购发票、买家销售发票，甚至订单报告和付款记录，长得都像财务文件，证明的却是不同一段交易。真正要先解决的，是谁向买家销售、谁负责出具、哪一笔订单对应哪张票。

先把三种“发票”从一堆文件里拆出来

最容易混淆的是平台给卖家的费用文件。

Kaufland的支付流程里，平台负责处理顾客付款，并向卖家提供订单和配送信息；同时，平台会按照平台服务和佣金形成自己的账单或发票。这个文件的交易关系是“平台向卖家收什么费用”，不是“卖家向买家卖了什么”。它可以拿来核对佣金、平台费用和账户流水，却不能因为标题里写着Invoice，就自动变成买家的销售发票。

第二张是上游采购发票。中国工厂、贸易商或者海外供应商给卖家的采购单据，证明的是“供应商卖给卖家”。它能证明采购成本和进货关系，但买家需要的是“谁向我销售这件商品”的凭证。两张票的开票主体和交易对象本来就不同。

第三张才是本文真正要处理的东西：客户销售发票。正常的Kaufland订单模式下，平台明确要求卖家自己为终端顾客开具发票，并可以通过Seller Portal、接口或API把发票放到订单里。平台负责支付处理，不等于平台替卖家承担了这张销售凭证的全部责任。

所以，财务同事问“这张票在哪”，运营不要回答“后台有结算单”。应该先问一句：“买家要的到底是哪段交易？”

这句话很值钱。

先判断谁开：普通卖家模式，还是平台虚拟卖家模式

Kaufland这里有一个不能跳过的例外：所谓“平台虚拟卖家”或deemed supplier模式。

在适用这一模式的部分B2C交易中，Kaufland Global Marketplace会按欧盟增值税规则作为deemed supplier处理VAT，并向终端顾客发送订单发票。平台自己的说明也明确写着，这类订单的顾客发票由平台发送；同时，卖家仍然是顾客的合同伙伴，并继续承担产品责任和质保责任。

这就意味着，“买家要发票”不能机械地翻译成“卖家再开一张”。

先确认这笔订单是否落在deemed supplier范围。Kaufland目前公开说明的典型场景包括：非欧盟卖家从欧盟仓向欧盟顾客发货，以及从非欧盟仓直接向欧盟顾客发货且符合相应低价值条件的B2C交易。它还说明，2026年7月起IOSS针对第三国低价值包裹的原有安排发生变化。这里真正有用的不是记住一个旧规则，而是回到订单本身：卖家主体在哪里、货从哪个仓发、买家是不是B2C、这笔交易是否被平台按deemed supplier处理。

如果不是deemed supplier，正常流程就是卖家负责开票，并把票传到订单里。若是deemed supplier，卖家先查平台应当生成和发送的那张顾客发票是否存在；发现平台侧发票缺失、信息异常，再走平台支持流程，而不是自己同时造一张可能冲突的票。

如果企业使用ERP或API，也值得把这个判断变成系统字段，而不是靠财务人员凭感觉。Kaufland当前订单发票API的返回信息里已经有销售站点以及是否属于marketplace deemed supplier等字段。至少应让订单、销售站点、发票状态和这一判断能够回到同一条订单记录上。

还有一种情况是第三方开票软件或服务商代为生成。这个角色也不能和“平台帮你传了一个文件”混在一起。德国增值税法允许在符合条件时由受托第三方以企业名义、代表企业开具发票，但责任链不能因此消失。系统只是工具，服务商也只是受托方；最终要能回答的仍然是：这张发票以谁的名义开出，针对哪笔销售，谁负责保证内容正确。

再判断买家是谁：B2B和B2C不能用同一张模板硬套

买家类型一变，开票要求可能就变。

欧盟委员会对增值税开票的概括很清楚：B2B交易通常需要发票，而B2C并不是所有商品销售在欧盟层面都一律要求出具完整VAT发票；部分B2C情形和具体国家还会有自己的规则。也就是说，“买家主动要发票”和“当地法律对这笔交易是否强制开票”是两个问题。平台又可能有自己的运营要求，不能拿其中一个答案覆盖另一个。

对中国卖家而言，最容易出错的是看到买家公司名，就直接套一份“欧洲B2B模板”。真正要核的是销售国家、卖家主体、货物发出地、买家身份以及VAT由谁承担。买家是企业，不代表一定要把买家VAT号填上；买家是个人，也不代表平台文件就能替代销售凭证。具体字段和税务处理必须跟交易类型一起判断。

以德国为例，德国《增值税法》对发票内容列得很具体。完整发票通常涉及销售方和买方名称、地址，销售方税号或VAT ID，开票日期，连续唯一的发票编号，商品数量和性质，交付日期，按税率拆分的金额，以及适用税率和税额等；某些跨境或特殊交易还会有额外要求。德国对向企业或非经营性法人等特定受票方出具发票，也有六个月的法定开具期限，但这并不意味着所有B2C订单都套用“六个月”。

更值得注意的是德国2025年开始的电子发票制度。2026年仍处在过渡期：德国境内企业之间的B2B交易正在逐步转向结构化电子发票；一般过渡到2026年底，上一年度营业额不超过80万欧元的开票方还可延长到2027年底。普通PDF在这套定义下并不等于结构化E-Rechnung。不过，德国官方也明确，真正的“境内企业”有特定定义；在德国注册增值税但没有德国固定机构的外国企业，可以在特定情况下说明自己为什么不适用德国境内B2B的电子发票义务。

这对中国卖家很重要：别看到“德国要E-Rechnung”，就把所有发票系统一夜之间改成某一种格式；也别看到“现在PDF还能用”，就认为任何买家都必须接受PDF。先把卖家主体和交易关系判清，再决定文件格式。

发票真正难开的时候，往往不是“开”，而是订单字段对不上

正常订单开票之前，建议把一笔订单锁成一个可追溯的小账本。至少要能在同一记录里找到订单号和销售站点、实际销售主体、发货仓、买家名称和地址、买家是否以企业身份采购及其VAT信息（如适用）、SKU和数量、商品售价、运费、优惠、币种、税务处理、退款或取消记录，以及当前是否已经上传过客户发票。

这里有一个很常见的坑：销售金额、平台结算金额和银行到账金额不是同一个数字。

平台负责收款后，结算文件里可能已经扣掉佣金、费用或其他项目；订单销售发票则要回到买卖双方之间的销售金额。不能拿“最终打到银行的钱”倒推出买家应付金额，也不能把平台佣金发票和商品销售金额拼在一起。

举个明确的假设。

假设某笔Kaufland.de订单商品含税价为119欧元，本文仅为演示而假定这笔销售全部适用德国19%的标准增值税，没有单独列运费，也没有优惠。按含税价倒算，净额是100欧元，增值税是19欧元，发票总额仍是119欧元。

如果平台结算后卖家实际可提取金额只有，例如100多欧元，那也不能因此把销售发票开成100多欧元。可提取余额是平台结算口径；119欧元是这个假设订单的买家销售金额。两张表分属两个不同的分母。

如果后来发生23.80欧元的部分退款，在仍按上述19%税率的纯演示假设下，对应减少的净额是20欧元，增值税减少3.80欧元，剩余销售额为95.20欧元，净额80欧元、增值税15.20欧元。真正处理时，不能只是把旧PDF删掉，再生成一张95.20欧元的新票，好像前一张从来没有存在过。德国官方规则对错误发票、更正以及税额变化分别有要求；更正文件还要能够和原始交易建立清晰关系。具体是红字、贷项、替换票还是其他形式，要根据销售国家和具体税务情形确认。

这也是为什么退款不是“客服做完退款就结束”。退款、部分退款、取消、退货和价格调整，只要改变了原销售凭证中的金额或交易事实，就应该回到发票链里检查：原票是什么、变化发生在哪一行、税额怎么变、买家拿到的更正文件是什么、内部账务是否同步。

国家不同，发票模板也不能只换个国家名

Kaufland当前的卖家资料已经把这个差异写得很直白。正常情况下，卖家对终端顾客负责开票；但在deemed supplier模式下由平台向顾客发送发票。对于语言，平台并没有要求所有订单的客户发票一律使用销售站点当地语言，但也提醒当地机关在检查时可能要求提供当地语言版本。

此外，平台还列出了销售站点的特殊发票要求。例如波兰发票需要包含卖家的BDO号码；捷克和斯洛伐克销售某些电子电气设备时，相关回收费用可能需要在发票中单独列示；法国某些电子电气设备和家具产品则涉及单独列示eco participation。

这些细节说明了一件很实际的事：ERP里那张“欧洲发票模板”如果只是把货币符号从欧元换成兹罗提、把国家代码换一下，迟早会出问题。

更稳妥的做法，是把模板拆成“共同字段”和“国家/交易条件字段”。共同字段负责订单、主体、买家、商品、金额和发票编号的完整性；国家字段负责税率、免税或反向征税说明、特殊环保费用、语言以及电子发票格式等。这样换销售站点时，变的是规则层，不是每次人工重做一张票。

买家已经催了，下一张到底先补哪一段？

如果今天就有一张Kaufland买家发票卡住，不建议先问“有没有会开欧洲发票的软件”。先看卡在哪一段。

第一种：根本没有销售发票。 先补“出具责任”和“数据入口”。确认这笔订单不是deemed supplier，再确定由卖家或受托第三方以卖家名义开具；然后把订单字段和适用税务规则接起来。对于正常模式，平台已经提供订单发票上传位置，缺票本身也可能触发Invoice类顾客Ticket。

第二种：发票已经生成，但买家拿不到。 这时先修“传递”，不要重做“税务判断”。检查发票是否真的上传到对应订单、销售站点是否匹配、ERP上传是否成功、买家看到的是否还是旧版本。平台当前支持在订单详情中上传顾客发票，也支持通过接口或API提供。文件存在于财务电脑里，不等于已经到达买家。

第三种：买家能看到发票，但说公司名、地址、VAT信息或金额不对。 先修“字段和规则”。不要为了让买家满意，直接在PDF里手改税率或抬头。把订单原始数据、买家提交的信息、税务登记信息和开票逻辑重新对一遍。如果是金额变动，还要一起检查退款、更正和账务。

第四种：订单属于deemed supplier，却没有平台应发送的顾客发票。 先确认订单标识和适用模式，再让平台支持团队处理。Kaufland当前帮助资料也明确建议，涉及deemed supplier模式的发票问题可以交由其一级客服进一步处理。此时卖家自己再造一张销售发票，可能把原本清晰的责任关系弄复杂。

第五种：旧票已经开了，后来发生退款或信息错误。 先找原票号，再做更正链。尤其不要让ERP只保留“最新版本PDF”，却把旧票、退款金额和更正原因都覆盖掉。德国税法要求发票及相关凭证保持可追溯，德国现行增值税规则下发票保存期限为八年；对于电子发票，结构化部分也要按要求保持原始完整性。其他销售国家的保存年限和细节不能照搬德国。

还有一个容易混淆的时间点：平台客服时限和税法开票期限不是一回事。Kaufland的一般顾客Ticket要求卖家在48个工作小时内回复；西班牙销售站点对发票或未经授权扣款的问询又有5个工作日的特殊回复规则。这些是平台客服处理时钟。德国B2B发票六个月的规定，则是税法层面的开票义务。一个是“收到买家问询后多久回应”，一个是“法律上何时必须开票”，不能拿其中一个替代另一个。

真正该修的，往往是“开票触发器”

如果同一类订单每次都要财务人工找文件，问题就已经不是一张发票了，而是流程设计。

比较实用的改法，是让订单完成某个节点后自动生成“待开票任务”，但生成前必须先读取销售站点、卖家主体、买家类型、发货仓和税务条件。生成后再做一次金额校验：商品行合计、运费、折扣、税额和订单总额能否互相解释。上传成功后，订单状态再从“已生成”变成“已提供给买家”。如果之后发生退款，则自动进入“待更正”而不是继续保持“已完成”。

对于多站点卖家，还可以把发票验收标准写得非常简单：运营负责确认订单事实，财务或税务负责人确认税务处理，系统负责编号、金额和文件留痕，客服负责把买家的请求及时接住。谁都可以看到这张票，但不应该出现“大家都以为别人已经开了”的空档。

这套责任链也解释了为什么“平台有文件”从来不是一个充分答案。Kaufland平台可以提供月度结算、订单数据和发票上传机制，也可能在特定deemed supplier订单里直接向买家发送发票；但卖家仍然需要知道自己在哪一种交易模式里，以及自己需要验收哪一份凭证。

如果团队正在把同一套欧洲业务复制到更多本土平台，ESG跨境的入驻支持、前置资料预审和专席对接，更适合放在开店前把主体、资料和渠道条件理清的阶段。至于具体订单的销售发票，还是要回到实际销售国家、买家类型和平台交易模式来判断，不能用一个平台的模板替代另一个平台的税务责任。

下一笔订单真正值得补的，不是“再找一个开票工具”，而是先把这四个问题锁死：谁向买家销售、谁负责出具、哪条订单数据作为开票依据、出现退款或更正后由谁把凭证链接回原单。

这四个答案一旦在系统里对上，买家再来一句“发票在哪里”，处理的就只是一项正常工作，而不是财务、运营和平台客服之间来回传文件。

声明：本文系作者独立观点，不代表ESG跨境立场。文中涉及的平台规则、费率及出海政策具有时效性，实际运营请以平台官方最新公布为准。如有版权争议、内容勘误或业务交流，欢迎随时与我们联系。