Stripe Billing 发的是 PDF。2027 年起在德国那不算发票

Stripe Invoicing 与 Stripe Billing 生成的是 PDF。Stripe 自己的文档写得很清楚：不额外接入电子发票应用，这两个产品无法创建或发送电子发票，并把用户指向 App Marketplace 的合作方。对德国境内的 B2B 交易，这份 PDF 从 2027 年 1 月 1 日起（较大卖方）以及 2028 年 1 月 1 日起（其余所有企业）不再满足开具义务。

这个话题下的多数文章出自税务顾问，或出自卖格式转换器的厂商。这篇是从建设方的角度写的。它回答的问题不是"法律怎么规定"，而是工程团队在支付服务商周边究竟要建什么、哪些部分可以直接采购。这是工程指南，不是税务建议，税务判断仍由你的税务顾问负责。

究竟什么在什么时候改变

对软件团队真正重要的不是一个日期，而是一张矩阵。接收义务先于开具义务生效，而每个邻国解决传输问题的方式都不一样。

把法国那一行和德国那一行并排再读一遍。德国规定的是格式，渠道交由交易双方约定，因此电子邮件是合法的送达方式。法国规定的是网络。如果你的路线图把"电子发票"当成一个功能，范围就已经估错了：格式、传输和申报是三条独立的轴，每个国家分别设定。

哪些内容不在范围内

• B2C。面向消费者的发票不受德国强制要求约束。
• 小额发票。含税 250 欧元以下的发票以及车船票可以继续不结构化。
• 特定免税交易，即德国增值税法免税目录中的部分项目。

对典型的 B2B SaaS 而言，250 欧元的豁免与其说是宽松，不如说是陷阱。每月 49 欧元的坐席套餐在门槛之下，年度合同则不在，而自助升级会让客户在年中越过这条线。把"这张发票是否在范围内"编码成计费系统按单据求值的规则，胜过把它写成 wiki 里的一条政策。

为什么 PDF 不是电子发票

EN 16931 描述的不是一份文档，而是一个语义数据模型：一组业务术语，例如卖方增值税识别号、发票行净额、税种类别代码和付款到期日，每一项都有明确的基数以及一组必须成立的业务规则。当一个文件用两种许可的 XML 语法之一（UBL 或 UN/CEFACT CII）承载这个模型并通过规则校验时，它才是电子发票。

PDF 承载的是像素，最多再加一层文本。机器无法可靠判断第四行的"19%"是税率、折扣还是产品名称的一部分。区别就在这里。法律意义上的"机器可读"，指接收系统能够确定性地提取每一个必填字段，不依赖启发式，也不需要一个靠猜的 LLM。

有两个实现细节，发现得晚就各要一个版本来补。第一，并非每个 ZUGFeRD 配置文件都合格：MINIMUM 与 BASIC WL 不包含发票行，因此不满足德国要求，库的默认值设成 MINIMUM 就会产出一个看起来合规、实际不合规的文件。第二，在混合文件中结构化部分才是具有约束力的原件。如果 XML 写 1,190.00 欧元而渲染出的 PDF 写 1,180.00 欧元，以 XML 为准，客户系统入账的也是 XML。用生成 XML 的同一套数据结构去渲染 PDF，而不是走一套平行模板，是杜绝这类缺陷唯一可靠的做法。

德国的强制要求适用于奥地利、瑞士或美国的 SaaS 吗？

通常不适用，而这正是整个话题里最常被读错的一点。

德国的开具义务适用于双方均在德国设立的企业间交易，"设立"指在德国拥有注册地、实际管理机构或增值税意义上的常设机构。一家在德国没有常设机构的奥地利 GmbH 向柏林客户开票，不在开具义务范围内。这类服务通常本就适用反向征收，由德国客户承担增值税申报。

但有三点让"什么都不做"站不住脚：

1. 一个德国实体或常设机构会把你拉进来。许多外国集团都有一个，却忘了起决定作用的是开票实体，而不是母公司。
2. 接收与开具是两回事。只要你有德国实体，它就必须已经能处理结构化的供应商发票。那是应付账款与集成问题，不是计费问题。
3. 客户照样会提要求。一旦德国买方的应付账款流程改为结构化接收，外国供应商的 PDF 就变成需要人工处理、催办并最终延迟付款的例外。不结构化带来的商业成本，远早于法律成本出现。

如果你销往法国或比利时，同样的逻辑反过来成立：那里要求的是接入网络，而不是某种文件格式。我们不少客户从奥地利向德国及更远市场开票，正好落在法律答案与实务答案分岔的位置。这一模式更宽泛的版本，我们写在DACH SaaS 如何叠加应对 GDPR 与 AI 法案一文中。

Stripe 给了什么，没给什么

Stripe 在自己覆盖的部分做得很好。缺口是具体的，值得精确指出，而不是变成对平台的抱怨。

这张表里没有一条是在反对 Stripe。它反对的是"支付服务商就是合规主数据系统"这个假设。支付与开票是两个恰好共用一个数据库的产品。

格式是最小的一环：转换器不会替你建的四个系统

1. 能映射到 EN 16931 字段的税务判定

你的计费引擎早就在标准税率、低税率、反向征收、欧盟内部供应和一站式申报之间做判断。EN 16931 要求这个判断被表达为编码后的税种类别、税率、计税基础，以及对所有非标准税率项目提供机器可读的免税理由。转换器只能拿到你的系统交给它的东西。如果上游的判断是一条写着"反向征收"的自由文本备注，产出的就是一张结构合法、税务表述错误的发票，这是两种结果里最糟的一种：它通过校验，却过不了稽查。

2. 买方主数据与路由标识

结构化发票需要一个真实的买方：法定名称、注册地址、增值税识别号，对许多企业客户和公共部门买方还需要路由标识，例如 Leitweg-ID 或 Peppol 参与方标识。自助注册表单对这些信息都收集得不可靠。团队常在上线当天才发现，相当一部分 B2B 客户记录的公司名字段里填的是个人姓名，增值税号也从未校验过。今天在结算流程中校验增值税识别号、把路由标识设为企业套餐的必填项，是两周的改动；到 2026 年 12 月再做，就是一个数据迁移项目。

3. 结构化原件的不可篡改归档

XML 是法律原件，因此需要在法定期限内原样、机器可读地保存的就是 XML。在德国，2025 年起开具或收到的发票适用八年保存期。"东西在 Stripe 里"不是归档，而是一个你无法掌控其生命周期的第三方 API。可行的做法是：启用版本控制与对象锁定保留策略的对象存储、写入时记录的内容哈希，以及一份把发票号映射到存储键的索引。除此之外还需要一份书面流程说明，覆盖发票如何创建、校验、发送、存储与更正。稽查人员会先读这份文档，再读你的代码。

4. 更正生命周期

订阅制产品与一次性销售的差别就在这里，绝大部分工程量也落在这里。按比例计费、周期中途换套餐、催缴重试、部分退款、余额抵扣和币种变更都会产生财务事件，这些事件必须变成更正单据，而不是对原单据的修改。在不可篡改的原则下，你作废并重开，而不是覆盖。退款不等于自动生成贷记单，被丢弃的草稿也不同于已作废的发票。把这套映射写成一台状态机，每个 Stripe 事件类型占一行，是整个项目产出的最有价值的产物。

2025 年的 BMF 文件把校验变成了流水线要求

德国财政部 2025 年 10 月 15 日的第二份适用文件，把电子发票的缺陷分成三类。在工程团队看来，这与其说是税务指引，不如说是一份校验闸门的规格说明。

技术含义很直接。在发送之前用 EN 16931 业务规则校验每一份单据，遇到格式错误和业务规则错误就阻断，并把内容错误引入人工队列，因为没有任何校验器能发现它们。把校验当作出站闸门而不是监控看板，决定了缺陷是被队列拦住，还是被客户的税务部门发现。这与我们在软件质量保障项目中坚持的纪律一致：检查要放在路径上，而不是旁边。

"团队为 XML 做预算，然后被归档和贷记单打个措手不及。格式只是一次库调用。更正生命周期是一台状态机，得有人负责它未来八年。"

基于 Stripe 的计费技术栈参考架构

1. 计费事件。把 Stripe webhook 消费进你自己的持久事件日志。绝不要把支付服务商当作会计记录的权威来源。
2. 发票数据模型。把这些事件投影为一个规范化的发票实体，显式承载 EN 16931 的每一个必填术语，包括买方标识与编码后的税务处理。这个模型才是你真正的交付物，PDF 不是。
3. 编号与不可篡改。在单据定稿的那一刻由唯一写入方分配发票号，此后记录只追加不修改。
4. 渲染。用同一个模型一步生成 XML 与人类可读版本，使二者不可能出现偏差。
5. 校验闸门。执行 schema 校验加业务规则校验。失败即阻断。校验结果与单据一并留存。
6. 传输。按目的地选择通道：德国用邮件附件，比利时和北欧用 Peppol 接入点，法国用获认证平台。把传输放在接口之后，新增一个国家就只是新增一个适配器，而不是一套新代码库。
7. 归档与对账。把结构化原件连同哈希写入锁定存储，并按计划把归档与账本对账。没人对账的归档只是一个假设，不是控制措施。

这份清单里大约四分之一可以直接采购，其余是你的领域模型，也正是工作被法定期限赶着做时技术债堆积的地方。

自建、采购还是外挂

对多数 B2B SaaS 公司，诚实的默认答案是混合方案：采购格式生成与传输，自建发票数据模型、校验闸门与归档。这个划分遵循的是与其他任何定制软件与成品软件之间的取舍相同的逻辑。买下通用件，掌握业务逻辑真正触及的那部分。当年我们把机构级债券分析平台从零做到企业级可用时，同样的原则成立：受监管的输出，可信度不会超过生成它的模型。

我们在计费流水线里见过的八种失效模式

1. 两个权威来源。PDF 由模板渲染，XML 由数据库构建。一个版本之内就会出现偏差。
2. 默认 MINIMUM 配置文件。库的默认值产出一个能通过 ZUGFeRD 校验、却不满足法定要求的文件。
3. 在错误层级上取整。EN 16931 业务规则会检查行合计、税额小计与单据总额是否一致。按行取整与按单据取整方式不同就会破坏规则。
4. 一张单据里混合税率。19% 的许可与 7% 的项目打包在一起，需要按类别给出正确的税额小计，而不是一个混合税率。
5. 未经校验的买方数据。缺失的增值税识别号、公司名字段里的个人姓名，都在上线当天才被发现。
6. 删除而不是作废。把错误发票直接删掉的客服流程，正好摧毁了不可篡改所要求的审计轨迹。
7. 测试数据占用生产编号。一次烧掉 4,000 个发票号的压测，会留下三年后没人能解释的缺号。
8. 没有出站校验。错误最终在客户的应付账款系统里暴露，那是成本最高的一种探测器。

一份 90 天计划

1. 第 1 至 2 周，界定范围。按法律实体判定是否落入开具义务，按客户分层判定小额豁免是否适用。产出是一页纸的结论，不是一份备忘录。
2. 第 3 至 4 周，数据盘点。统计有多少 B2B 客户记录带有已校验的增值税识别号、法定名称和完整地址。这个数字对进度的影响大于任何技术选择。
3. 第 5 至 7 周，模型与映射。定义发票实体，把每一种 Stripe 事件类型映射到发票或更正单据，并把税务逻辑映射到 EN 16931 类别代码。
4. 第 8 至 10 周，生成与校验。从模型生成 ZUGFeRD，接好校验闸门，并把过去十二个月的发票全部跑一遍作为回测。历史数据上的失败率才是真正的就绪指标。
5. 第 11 至 12 周，归档与流程说明。搭建带哈希与对账的锁定存储，并趁决策还新鲜时写好流程文档。
6. 之后，按国家做传输。只为确有要求的市场增加 Peppol 或获认证平台。

十二周的前提是有人对决策负责。缺了这个人，工作会卡在第三周，这也是企业为一段有边界的合规项目引入兼职 CTO而不是为此招人的常见原因。

四个值得纠正的误解

• "发票号必须连续无缺号。"德国增值税法要求的是为识别发票而一次性分配的连续编号。法律并不强制号段毫无缺口。缺号确实会在稽查中引来提问，所以要记录缺号的原因。
• "内嵌 XML 的 PDF 是权宜之计。"ZUGFeRD 是一等公民级的合规格式。PDF 容器不是问题，不带结构化数据的 PDF 才是。
• "德国需要 Peppol。"德国规定的是格式，不是渠道。电子邮件就够了。需要 Peppol 是因为你卖给谁，而不是因为德国法律。
• "我们的财务软件会处理。"它处理的是它自己开出的发票。由你的产品、在你的计费引擎里、按你自己的号段生成的发票，归你负责。

主要来源

• 德国联邦财政部，关于强制电子发票的第二份适用文件，2025 年 10 月 15 日
• 德国联邦财政部，自 2025 年 1 月 1 日起强制电子发票的常见问题
• 德国增值税法第 14 条，发票开具与连续编号要求
• Stripe，德国的强制电子发票
• Stripe，通过 App Marketplace 合作方发送电子发票
• FeRD，ZUGFeRD 版本与配置文件常见问题
• 欧盟委员会电子发票国别说明，奥地利
• 欧盟委员会电子发票国别说明，法国
• 欧盟委员会，数字时代的增值税（ViDA）