本文内容
德国 2027 年电子发票要求与 Stripe Billing
Stripe Billing 和 Stripe Invoicing 生成 PDF。Stripe 指引建议通过应用市场合作方生成和发送结构化发票。对于纳入德国境内 B2B 义务的交易，交易发生日期和开票方的法定上年营业额决定 PDF 过渡期何时结束。
这个话题下的多数文章出自税务顾问，或出自卖格式转换器的厂商。这篇是从建设方的角度写的。它回答的问题不是"法律怎么规定"，而是工程团队在支付服务商周边究竟要建什么、哪些部分可以直接采购。这是工程指南，不是税务建议，税务判断仍由你的税务顾问负责。
究竟什么在什么时候改变
对软件团队真正重要的不是一个日期，而是一张矩阵。接收义务先于开具义务生效，而每个邻国解决传输问题的方式都不一样。
| 司法辖区 | 日期 | 对计费系统意味着什么 |
|---|---|---|
| 德国 | 2025 年 1 月 1 日 | 每一家境内企业都必须能够接收并处理符合 EN 16931 的电子发票。没有过渡期，收件方也无权拒绝。 |
| 德国 | 至 2026 年 12 月 31 日 | 纸质发票仍然允许。PDF 仅在收件方同意时允许。 |
| 德国 | 2027 年 1 月 1 日 | 对于 2027 年纳入义务的德国境内 B2B 交易，2026 年法定营业额超过 80 万欧元的开票方通常必须开具结构化电子发票。营业额不超过 80 万欧元的开票方在 2027 年底前仍可使用纸质发票，或经收件方同意使用 PDF。经收件方同意的 EDI 另有过渡安排，也持续至 2027 年底。 |
| 德国 | 2028 年 1 月 1 日 | 营业额与 EDI 过渡安排结束。长期豁免仍然适用。 |
| 奥地利 | 当前 | 面向联邦政府必须使用结构化电子发票。欧盟委员会的国别说明记录为没有 B2B 强制要求。 |
| 法国 | 2026 年 9 月 1 日起 | 所有企业现已必须接收电子发票，大型与中型企业还必须开具电子发票；较小企业于 2027 年 9 月 1 日跟进。发票经获认证平台流转，而不是直接发给买方。 |
| 比利时 | 2026 年 1 月 1 日 | 境内 B2B 电子发票，构建在 Peppol 网络之上。 |
| 欧盟（ViDA） | 2030 年 7 月 1 日 | 欧盟内部 B2B 交易适用 EN 16931 电子发票与数字申报。 |
把法国那一行和德国那一行并排再读一遍。德国规定的是格式，渠道交由交易双方约定，因此电子邮件是合法的送达方式。法国规定的是网络。如果你的路线图把"电子发票"当成一个功能，范围就已经估错了：格式、传输和申报是三条独立的轴，每个国家分别设定。
哪些内容不在范围内
- B2C。面向消费者的发票不受德国强制要求约束。
- 小额发票。含税不超过 250 欧元的发票以及车船票可以继续不结构化。
- 特定免税交易，即德国增值税法免税目录中的部分项目。
- 小规模经营者增值税制度。适用德国 Kleinunternehmer 制度的经营者免于强制开具电子发票，但仍须能够接收。
对典型的 B2B SaaS 而言，250 欧元的豁免与其说是宽松，不如说是陷阱。每月 49 欧元的坐席套餐在门槛之下，年度合同则不在，而自助升级会让客户在年中越过这条线。把"这张发票是否在范围内"编码成计费系统按单据求值的规则，胜过把它写成 wiki 里的一条政策。
计费系统面对 2027 年大限，却没人负责？
梳理电子发票工作范围为什么 PDF 不是电子发票
EN 16931 描述的不是一份文档，而是一个语义数据模型：一组业务术语，例如卖方增值税识别号、发票行净额、税种类别代码和付款到期日，每一项都有明确的基数以及一组必须成立的业务规则。当一个文件用两种许可的 XML 语法之一（UBL 或 UN/CEFACT CII）承载这个模型并通过规则校验时，它才是电子发票。
PDF 承载的是像素，最多再加一层文本。机器无法可靠判断第四行的"19%"是税率、折扣还是产品名称的一部分。区别就在这里。法律意义上的"机器可读"，指接收系统能够确定性地提取每一个必填字段，不依赖启发式，也不需要一个靠猜的 LLM。
| 格式 | 它是什么 | SaaS 何时应当选它 |
|---|---|---|
| XRechnung | 纯 XML，EN 16931 的德国国别约束版。没有人类可读层。 | 公共部门买方，以及应付账款系统点名要求它的企业客户。 |
| ZUGFeRD / Factur-X | 内嵌 CII XML 的 PDF/A-3。一个文件，两类受众。 | 自助式 B2B 产品的务实默认选项，因为人类收件方仍然看得到一张发票。 |
| Peppol BIS Billing 3.0 | 一个 UBL 配置文件，外加带寻址与回执的投递网络。 | 销往比利时、北欧、新加坡、澳大利亚，或任何给你 Peppol 参与方标识的买方。 |
按目标市场和发票配置文件固定校验包。KoSIT 列明 XRechnung 3.0 至少有效至 2027 年 7 月 31 日。2026 年夏季的 3.0.2 修复包包含 1.6.3 校验器，XRechnung 4.0 仍为预发布版本。混合文件可查阅 FeRD 发布的 ZUGFeRD 2.5.2 / Factur-X 1.09.2。将校验器、规则集和配置文件的版本与校验结果一同保存。
有两个实现细节，发现得晚就各要一个版本来补。第一，并非每个 ZUGFeRD 配置文件都合格：MINIMUM 与 BASIC WL 不包含发票行，因此不满足德国要求，库的默认值设成 MINIMUM 就会产出一个看起来合规、实际不合规的文件。第二，在混合文件中结构化部分才是具有约束力的原件。如果 XML 写 1,190.00 欧元而渲染出的 PDF 写 1,180.00 欧元，以 XML 为准，客户系统入账的也是 XML。用生成 XML 的同一套数据结构去渲染 PDF，而不是走一套平行模板，是杜绝这类缺陷唯一可靠的做法。
德国的强制要求适用于奥地利、瑞士或美国的 SaaS 吗？
通常不适用，而这正是整个话题里最常被读错的一点。
判断德国义务时，应按具体交易核对双方的设立地。德国境内的增值税常设机构参与该交易时才计入。
但有三点让"什么都不做"站不住脚：
- 德国实体或参与交易的增值税常设机构可能使该交易纳入义务。
- 接收与开具是两回事。只要你有德国实体，它就必须已经能处理结构化的供应商发票。那是应付账款与集成问题，不是计费问题。
- 客户照样会提要求。一旦德国买方的应付账款流程改为结构化接收，外国供应商的 PDF 就变成需要人工处理、催办并最终延迟付款的例外。不结构化带来的商业成本，远早于法律成本出现。
如果你销往法国或比利时，同样的逻辑反过来成立：那里要求的是接入网络，而不是某种文件格式。我们不少客户从奥地利向德国及更远市场开票，正好落在法律答案与实务答案分岔的位置。这一模式更宽泛的版本，我们写在DACH SaaS 如何叠加应对 GDPR 与 AI 法案一文中。
Stripe 给了什么，没给什么
Stripe 在自己覆盖的部分做得很好。缺口是具体的，值得精确指出，而不是变成对平台的抱怨。
| 能力 | Stripe 现状 | 面向 2027 的技术栈需要什么 |
|---|---|---|
| 发票单据 | 托管的 PDF 与 HTML 页面 | EN 16931 XML，独立文件或内嵌于 PDF |
| 结构化电子发票 | 不原生生成，由 App Marketplace 合作方补足 | 由你掌控的生成器，出门之前先完成校验 |
| 税务判定 | Stripe Tax 计算税率并管理税务登记 | 把计算结果映射到 EN 16931 的税种类别代码与免税理由 |
| 发票编号 | 按账户连续编号，前缀可配置 | 能扛住贷记单、重试与多实体架构的编号方案，且缺号可解释 |
| 更正 | 作废、贷记单、退款 | 把每个 Stripe 事件映射到法律上正确的更正单据的成文对照表 |
| 保存 | 通过 API 访问发票对象 | 在法定保存期内由你掌控的、结构化原件的不可篡改归档 |
| 传输 | 电子邮件与托管链接 | 按目标国选择电子邮件、Peppol 或获认证平台 |
这张表里没有一条是在反对 Stripe。它反对的是"支付服务商就是合规主数据系统"这个假设。支付与开票是两个恰好共用一个数据库的产品。
格式是最小的一环：转换器不会替你建的四个系统
1. 能映射到 EN 16931 字段的税务判定
你的计费引擎早就在标准税率、低税率、反向征收、欧盟内部供应和一站式申报之间做判断。EN 16931 要求这个判断被表达为编码后的税种类别、税率、计税基础，以及对所有非标准税率项目提供机器可读的免税理由。转换器只能拿到你的系统交给它的东西。如果上游的判断是一条写着"反向征收"的自由文本备注，产出的就是一张结构合法、税务表述错误的发票，这是两种结果里最糟的一种：它通过校验，却过不了稽查。
2. 买方主数据与路由标识
结构化发票需要一个真实的买方：法定名称、注册地址、增值税识别号，对许多企业客户和公共部门买方还需要路由标识，例如 Leitweg-ID 或 Peppol 参与方标识。自助注册表单对这些信息都收集得不可靠。团队常在上线当天才发现，相当一部分 B2B 客户记录的公司名字段里填的是个人姓名，增值税号也从未校验过。今天在结算流程中校验增值税识别号、把路由标识设为企业套餐的必填项，是两周的改动；到 2026 年 12 月再做，就是一个数据迁移项目。
3. 结构化原件的不可篡改归档
XML 是法律原件，因此需要在法定期限内原样、机器可读地保存的就是 XML。依据《德国增值税法》第 14b 条，八年增值税保存期从开票当年的年末起算。"东西在 Stripe 里"不是归档，而是一个你无法掌控其生命周期的第三方 API。可行的做法是：启用版本控制与对象锁定保留策略的对象存储、写入时记录的内容哈希，以及一份把发票号映射到存储键的索引。除此之外还需要一份书面流程说明，覆盖发票如何创建、校验、发送、存储与更正。稽查人员会先读这份文档，再读你的代码。
4. 更正生命周期
保留原件，并将每份更正文件与其关联。适用电子发票义务时，请按相应发票类型开具结构化更正文件。计税基础变动与更正错误发票信息的处理方式可能不同。
2025 年的 BMF 文件把校验变成了流水线要求
德国财政部 2025 年 10 月 15 日的第二份适用文件，把电子发票的缺陷分成三类。在工程团队看来，这与其说是税务指引，不如说是一份校验闸门的规格说明。
| 错误类别 | 含义 | 后果 |
|---|---|---|
| 格式错误 | 文件语法无效，或必填字段无法被完整提取。 | 它根本不算电子发票，只能算普通发票，在大限之后即意味着义务未履行。 |
| 业务规则错误 | 语法成立，但违反了 EN 16931 的某条业务规则。 | 仍然是电子发票，但存在缺陷，需要更正。 |
| 内容错误 | 涉税内容有误：税率、服务描述、供应日期。 | 收件方的进项税抵扣面临风险。 |
技术含义很直接。在发送之前用 EN 16931 业务规则校验每一份单据，遇到格式错误和业务规则错误就阻断，并把内容错误引入人工队列，因为没有任何校验器能发现它们。把校验当作出站闸门而不是监控看板，决定了缺陷是被队列拦住，还是被客户的税务部门发现。这与我们在软件质量保障项目中坚持的纪律一致：检查要放在路径上，而不是旁边。
"团队为 XML 做预算，然后被归档和贷记单打个措手不及。格式只是一次库调用。更正生命周期是一台状态机，得有人负责它未来八年。"
基于 Stripe 的计费技术栈参考架构
- 计费事件。把 Stripe webhook 消费进你自己的持久事件日志。绝不要把支付服务商当作会计记录的权威来源。
- 发票数据模型。把这些事件投影为一个规范化的发票实体，显式承载 EN 16931 的每一个必填术语，包括买方标识与编码后的税务处理。这个模型才是你真正的交付物，PDF 不是。
- 编号与不可篡改。在单据定稿的那一刻由唯一写入方分配发票号，此后记录只追加不修改。
- 渲染。用同一个模型一步生成 XML 与人类可读版本，使二者不可能出现偏差。
- 校验闸门。执行 schema 校验加业务规则校验。失败即阻断。校验结果与单据一并留存。
- 传输。按目的地选择通道：德国用邮件附件，比利时和北欧用 Peppol 接入点，法国用获认证平台。把传输放在接口之后，新增一个国家就只是新增一个适配器，而不是一套新代码库。
- 归档与对账。把结构化原件连同哈希写入锁定存储，并按计划把归档与账本对账。没人对账的归档只是一个假设，不是控制措施。
这份清单里大约四分之一可以直接采购，其余是你的领域模型，也正是工作被法定期限赶着做时技术债堆积的地方。
自建、采购还是外挂
| 选项 | 适合的场景 | 仍然留给你的部分 |
|---|---|---|
| Stripe App Marketplace 合作方应用 | 发票量低、单一国家、标准税务处理、发票本就在 Stripe 内生成 | 主数据质量、归档归属、更正映射 |
| 带 API 的电子发票 SaaS | 多个国家、中等体量，希望格式与传输一并解决 | 从你的领域模型到对方 schema 的映射层，以及在受监管路径上的供应商依赖 |
| Peppol 接入点服务商 | 实行网络强制的国家、拥有参与方标识的企业客户 | 格式生成以及传输之上的全部环节 |
| 自建发票层 | 计费逻辑本就是差异化能力：按用量定价、市场平台、分账、多实体集团 | 随 EN 16931 与各国配置文件演进而持续进行的符合性工作 |
对多数 B2B SaaS 公司，诚实的默认答案是混合方案：采购格式生成与传输，自建发票数据模型、校验闸门与归档。这个划分遵循的是与其他任何定制软件与成品软件之间的取舍相同的逻辑。买下通用件，掌握业务逻辑真正触及的那部分。当年我们把机构级债券分析平台从零做到企业级可用时，同样的原则成立：受监管的输出，可信度不会超过生成它的模型。
我们在计费流水线里见过的八种失效模式
- 两个权威来源。PDF 由模板渲染，XML 由数据库构建。一个版本之内就会出现偏差。
- 默认 MINIMUM 配置文件。库的默认值产出一个能通过 ZUGFeRD 校验、却不满足法定要求的文件。
- 在错误层级上取整。EN 16931 业务规则会检查行合计、税额小计与单据总额是否一致。按行取整与按单据取整方式不同就会破坏规则。
- 一张单据里混合税率。19% 的许可与 7% 的项目打包在一起，需要按类别给出正确的税额小计，而不是一个混合税率。
- 未经校验的买方数据。缺失的增值税识别号、公司名字段里的个人姓名，都在上线当天才被发现。
- 删除而不是作废。把错误发票直接删掉的客服流程，正好摧毁了不可篡改所要求的审计轨迹。
- 测试数据占用生产编号。一次烧掉 4,000 个发票号的压测，会留下三年后没人能解释的缺号。
- 没有出站校验。错误最终在客户的应付账款系统里暴露，那是成本最高的一种探测器。
一份 90 天计划
- 第 1 至 2 周，界定范围。按法律实体判定是否落入开具义务，按客户分层判定小额豁免是否适用。产出是一页纸的结论，不是一份备忘录。
- 第 3 至 4 周，数据盘点。统计有多少 B2B 客户记录带有已校验的增值税识别号、法定名称和完整地址。这个数字对进度的影响大于任何技术选择。
- 第 5 至 7 周，模型与映射。定义发票实体，把每一种 Stripe 事件类型映射到发票或更正单据，并把税务逻辑映射到 EN 16931 类别代码。
- 第 8 至 10 周，生成与校验。从模型生成 ZUGFeRD，接好校验闸门，并把过去十二个月的发票全部跑一遍作为回测。历史数据上的失败率才是真正的就绪指标。
- 第 11 至 12 周，归档与流程说明。搭建带哈希与对账的锁定存储，并趁决策还新鲜时写好流程文档。
- 之后，按国家做传输。只为确有要求的市场增加 Peppol 或获认证平台。
十二周的前提是有人对决策负责。缺了这个人，工作会卡在第三周，这也是企业为一段有边界的合规项目引入兼职 CTO而不是为此招人的常见原因。
四个值得纠正的误解
- "发票号必须连续无缺号。"德国增值税法要求的是为识别发票而一次性分配的连续编号。法律并不强制号段毫无缺口。缺号确实会在稽查中引来提问，所以要记录缺号的原因。
- "内嵌 XML 的 PDF 是权宜之计。"ZUGFeRD 是一等公民级的合规格式。PDF 容器不是问题，不带结构化数据的 PDF 才是。
- "德国需要 Peppol。"德国规定的是格式，不是渠道。电子邮件就够了。需要 Peppol 是因为你卖给谁，而不是因为德国法律。
- "我们的财务软件会处理。"它处理的是它自己开出的发票。由你的产品、在你的计费引擎里、按你自己的号段生成的发票，归你负责。
Stripe 与电子发票常见问题
Stripe 能发送 XRechnung 或 ZUGFeRD 发票吗？
2027 年之后德国还能用 PDF 发票吗？
奥地利或瑞士公司必须开具德国电子发票吗？
B2B SaaS 应该选哪种格式？
ZUGFeRD 的 MINIMUM 与 BASIC WL 配置文件算数吗？
在德国用电子邮件送达电子发票可以吗？
电子发票必须保存多久？
这需要多少工程量？
最终思考
Stripe 是一家带有开票便利功能的支付服务商，不是合规主数据系统，它自己也这么说。把 2027 年的期限当成它本来的样子：一个推动力，促使你给计费领域一个真正的数据模型、一道校验闸门、一份你掌控的归档，以及一个有人负责的更正生命周期。买下 XML 与网络，自建模型。按这个顺序推进的团队，最终会拥有一套计费系统，下一个强制要求只是换个适配器，而不是重写。