德国 E-Rechnung 强制令：2027 年 1 月 1 日前用自有系统开具结构化发票
从 2027 年 1 月 1 日起，2026 年营业额超过 80 万欧元的德国企业，不能再向另一家德国企业发送纸质或 PDF 发票。发票必须是结构化电子发票：一个按欧洲标准 EN 16931 构建的数据文件。从 2028 年 1 月 1 日起，门槛取消，这条规则适用于所有企业，只有少数范围很窄的例外。
对小公司来说，这只是一次软件更新。对发票出自自有计费系统、行业软件包或一套定制了十五年的 ERP 的公司来说，这是一个软件项目，而剩下的时间大约只有十三周。本文写给后一类公司。
法律怎么规定
定义见 § 14 UStG：电子发票是一种“die in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht”的发票（即以结构化电子格式开具、传输和接收，并能进行电子处理）。格式必须符合 2014/55/EU 号指令下的欧洲标准（实践中就是 EN 16931），或者由双方约定，前提是所需数据能被正确、完整地提取成与该标准兼容的形式。PDF 无论排版多整齐，都不算数。
这项义务覆盖双方均在德国设立的企业之间的供应。过渡规则见 § 27 Abs. 38 UStG：
- 2025 年和 2026 年发生的供应，仍可开具纸质发票，或在客户同意的情况下使用其他电子格式，只要发票在 2026 年 12 月 31 日之前发出。
- 2027 年发生的供应，在 2027 年 12 月 31 日之前享有同样的宽限，但前提是开票方上一个日历年度的总营业额不超过 80 万欧元。
- 不符合该标准的 EDI，在客户同意的情况下，可以继续用于 2027 年发生的供应，与企业规模无关。
有三个细节比看上去更要紧。
门槛按上一年的营业额计算。 您在 2027 年的处境取决于 2026 年的数字，而这个数字要到结账后才能确切知道。只要接近 80 万欧元，就按超过门槛来建设。
宽限以发送日期为界。 按字面理解，第一条过渡规则在 2026 年 12 月 31 日之后就不再覆盖纸质和 PDF 发票，即使对应的工作是在 2026 年完成的。如果您超过门槛且采用事后结算，那么在 1 月第一周为 12 月工作发出的发票，就已经必须是结构化的。请与您的税务顾问确认这一点，但不要把上线时间定在 1 月中旬。
有些发票不在范围内： 面向消费者的发票、跨境发票、含税金额不超过 250 欧元的小额发票、可视为发票的票据、Kleinunternehmer（小企业主）开具的发票，以及依据 § 4 Nr. 8 至 29 UStG 免税的供应。
我们没有看到任何推迟这些日期的法案。请按这些日期不变来规划。
接收义务 2025 年已经开始，开具才是新的部分
自 2025 年 1 月 1 日起，每家德国企业都必须能够接收电子发票。联邦财政部关于电子发票的常见问题解答对此说得很直白：“Für den Empfang einer elektronischen Rechnung genügt bereits ein E-Mail-Postfach.”有一个电子邮箱就够了。
请留意 § 14 本身的一句话：在电子发票义务适用的情况下，无需征得收票方同意。德国的企业客户不能拒收您的结构化发票。
开具则是另一回事。接收时，是工具去读别人的文件。开具时，您的系统就是作者：如果源头数据有错，链条后端没有人能修复，而一张没通过客户校验的发票就只能搁在那里收不到款。
哪些企业靠一次更新就能解决
直说：如果您是一家用 DATEV、lexoffice、sevDesk 或类似软件开票的小公司，格式由软件厂商提供。检查您的主数据（增值税号、客户地址、银行信息），打开这项功能，发一张测试发票。您不需要立项，也不需要找软件公司。
仍接近标准版本的主流 ERP 也大致如此：输出由厂商或您的实施伙伴提供，工作在于配置和测试。
本文其余部分写给发票出自自有代码，或出自已无人维护的代码的公司：
- 订阅平台、交易市场和公用事业中的计费引擎，以程序方式批量开具发票；
- 批发、建筑、物流或现场服务领域的行业软件，其厂商规模小、反应慢，或者已经不在了；
- 发票输出多年前就被改写成自定义打印程序、报表模板或月末邮件合并的 ERP。
格式：EN 16931、XRechnung 和 ZUGFeRD
EN 16931 是欧洲标准。它定义发票的语义模型（有哪些字段、各自含义、哪些必填，以及字段之间的业务规则），并将其绑定到两种 XML 语法：UBL 2.1 和 UN/CEFACT CII。
XRechnung 是建立在 EN 16931 之上的德国规范，由 KoSIT 维护：两种语法均可的纯 XML，公共机构要求使用，在企业之间同样有效。根据 KoSIT 的 XRechnung 页面，3.0 版自 2024 年 2 月 1 日起生效，至少有效到 2027 年 7 月 31 日。4.0 的预发布版已于 2026 年 9 月公布，正式版预计在 2027 年春季发布。您会以 3.0 上线，并在上线后第一年内升级。
ZUGFeRD 是一种混合格式：嵌入了 CII XML 的 PDF/A-3 文件。人读 PDF，机器读 XML。在法国，同一格式叫 Factur-X，两者在技术上完全一致。FeRD 于 2026 年 8 月 4 日发布了 2.5.2 版。ZUGFeRD 分为若干配置档（MINIMUM、BASIC WL、BASIC、EN 16931、EXTENDED），财政部的常见问题解答接受 2.0.1 及以上版本的 ZUGFeRD，“mit Ausnahme der Profile MINIMUM und BASIC-WL”（MINIMUM 和 BASIC-WL 配置档除外）。
在混合发票中，以 XML 为准。常见问题解答把结构化部分称为“führender Teil”，即主导部分。如果您的 PDF 和 XML 不一致，错的是 PDF。
对大多数德国 B2B 开票方来说，合理的默认选择是 EN 16931 配置档的 ZUGFeRD，这样仍靠肉眼看发票的客户可以照旧，再为公共机构和提出要求的客户提供 XRechnung。两者都应出自同一个内部发票对象，而不是两条代码路径。
系统里需要改什么
发票变成数据，而不是版面
很多老系统在打印时才生成发票：文本拼进模板，合计在报表里求和，增值税说明是一段写死的文字。这些在 EN 16931 面前都站不住。您需要一个持久保存、包含所有字段的发票对象，XML 和 PDF 都从它渲染出来。
通常缺失或出错的字段：
- 当事方数据。 带 ISO 国家代码的结构化地址，以及增值税号或税号。自由文本的地址块必须拆分。
- 供应日期或服务期间，要作为数据保存，而不是抬头里的一句话。
- 单位。 每个数量都需要一个 UN/ECE 第 20 号建议书中的代码（H87 表示件，KGM 表示千克，DAY 表示天）。“Stk.”和“pauschal”这类写法需要映射。
- 增值税。 每一行都带有增值税类别和税率。发票为每种类别与税率的组合各给出一项增值税汇总，合计必须在两位小数上精确相符。按行舍入增值税的系统会在这里出错。
- 免税和反向征收说明。 PDF 底部的那句话，要变成一个增值税类别代码加一个免税原因。
- 付款。 付款方式、IBAN 和付款条件都要结构化。
- 参考号。 客户的应付账款团队用来匹配的订单号或买方参考号。如果您从未保存过，现在就开始采集。
纯文本行（“按约定交付”）是常见的绊脚石。在结构化发票中，一行就是一个计费行，所以这类文字应该放进备注。
更正、贷项通知单和自开票
常见问题解答说得很明确：在电子发票义务适用的情况下，更正也必须是电子发票，并使用更正类型的发票。在 EN 16931 中，它通过编号和开具日期指回原发票，所以您的系统必须把这层关联作为数据保存下来。
注意用词。在德国增值税法里，“Gutschrift”是自开票发票，由客户按事先约定开具（§ 14 Abs. 2 UStG）。英语里说的贷项通知单（降价或取消）在德国属于更正。很多系统把两者用同一种单据类型处理。映射之前先把它们分开；如果您为供应商自开票，就把这些单据当作您的系统开具的发票来对待。
最终发票可以在附件中列出此前的分期付款，只要结构化部分引用了该附件；常见问题解答确认这一做法在 2027 年之后继续有效。
发出之前先校验
KoSIT 发布了一个开源校验器，用模式和 Schematron 规则检查 XML，并提供 XRechnung 的公开配置。它可以作为命令行工具、HTTP 守护进程或库来运行。把它放进发送路径：每张发票发出前都要校验，失败的进入一个由指定人员负责的队列，并写明是哪个字段违反了哪条规则。
对 ZUGFeRD，要按您所用配置档的规则校验嵌入的 XML，单独检查 PDF/A-3 容器，并确认 PDF 上显示的合计与 XML 一致。
传输
常见问题解答说，法律“sieht keinen bestimmten Weg vor”：没有规定任何渠道。附件形式的电子邮件可以，API、下载门户、集团内部的共享存储也可以，甚至（财政部自己举的例子）U 盘也行。德国国内 B2B 不要求使用 Peppol。
工程工作是按客户逐个进行的：一个收票地址、一种偏好格式，以及一份发往何处、发了什么的记录。发送失败后的重试，要用同一份单据和同一个发票号码。一笔供应出现两个号码，是税务问题，不是软件问题。
归档
至少结构化部分必须“unversehrt in seiner ursprünglichen Form”保存，即以原始形式完好保存，§ 14b UStG 规定保存期为自开具年度结束起八年。把您发出的原始字节连同哈希值一起保存。不要打算以后从数据库重新生成发票：到那时，数据和代码都已经变了。您收到的电子发票也是同样的道理。
2026 年 10 月至 12 月的计划
如果源数据状况尚可，十三周足够完成一次聚焦的开发，但不足以替换整个计费系统。
第 1 至 2 周：盘点与决策。 列出所有产生发票的地方，包括手工贷项通知单、项目最终发票，以及为某个大客户单独维护的电子表格。对照门槛核实 2026 年营业额。选定默认格式，并决定是自己开发生成器，还是把发票数据发送到电子发票服务商的 API。
第 2 至 4 周：数据差距分析。 拿三个月的真实发票，逐字段映射到 EN 16931。标出缺失的内容、必须改为代码的内容，以及计算方式不同的内容。项目的真实规模在这一步才显现出来。
第 4 至 9 周：开发。 发票对象、映射、XML 与 PDF/A-3 渲染、发送路径中的校验器、失败队列和归档。同时，有人负责清理主数据，并向客户收集收票地址。
第 9 至 11 周：回放与试点。 把最近三个月的发票全部用新的生成器跑一遍，逐张校验。然后找几家愿意配合的客户试点，问他们的系统能否读取这些文件。
第 11 至 13 周：冻结与运行手册。 12 月冻结变更。写清楚谁负责失败队列、更正如何开具，以及客户拒收发票时怎么办。1 月为 12 月工作开具的发票已经在范围内。
2027 年 1 月。 上线，并在第一个月末和第一次增值税申报期间每天盯着队列。
2027 年全年。 在 3.0 失效之前规划好 XRechnung 4.0 升级，并在 2028 年 1 月 1 日之前把门槛以下的集团公司也迁移过来。
如果起步晚了，要砍的是自动化程度，而不是输出的合规性：先把高频发票类型自动化，少见的单据在头几周通过电子发票工具手工发送。
从哪里获得帮助
我们负责在生成发票的系统与法律要求的格式之间搭建连接：数据模型变更、映射、校验、传输和归档，在您的代码库里、与您的团队一起完成。我们的电子发票集成服务介绍了这类项目如何开展；如果这项强制要求恰好落在 ERP 更换的过程中，请参阅 ERP 现代化。更完整的日程见我们的 2026 年欧盟数字合规指南。
我们是工程师，不是税务顾问：适用范围的问题属于您的 Steuerberater（税务顾问），我们按照他们的答复来构建。告诉我们您的发票目前由什么系统生成，以及每月大约发出多少张：请写信到 office@c9group.dev。