--- title: "Stripe Billing 与 2027 年电子发票强制要求" canonical: https://wavect.io/zh/blog/stripe-billing-e-invoicing-2027/ language: zh description: "Stripe Billing 发送的是 PDF，不是 EN 16931 电子发票。德国 2027 年大限前，B2B SaaS 需要自建数据模型、校验闸门、归档与更正流程。" image: "https://wavect.io/img/blog/headers/header_stripe-billing-e-invoicing-2027.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 分钟 阅读 · 2026年8月4日 最近审核 2026年8月4日 [**下一篇**](/zh/blog/validate-b2b-saas-idea-dach/) # Stripe Billing 发的是 PDF。2027 年起在德国那不算发票 要点速览 Stripe Invoicing 与 Stripe Billing 生成的是 PDF，Stripe 自己的文档也写明：不额外接入电子发票应用，二者无法创建或发送电子发票。对德国境内 B2B 交易，PDF 从 2027 年 1 月 1 日起不再满足开具义务（适用于 2026 年营业额超过 80 万欧元的卖方），2028 年 1 月 1 日起适用于所有企业；而接收 EN 16931 电子发票的义务自 2025 年 1 月 1 日起已经生效。转换成 ZUGFeRD 或 XRechnung 是可以直接采购的一步，真正的工程量在别处：把税务判定映射到 EN 16931 的税种类别代码、校验买方主数据与路由标识、在八年保存期内不可篡改地归档结构化原件，以及用作废重开而非删除的更正生命周期。德国的义务仅覆盖买卖双方均在德国设立的交易，因此在德国没有常设机构的奥地利或瑞士卖方不受开具义务约束，但德国买方越来越期望收到结构化发票。德国规定格式却不限定传输渠道，法国要求经认证平台，比利时基于 Peppol，因此传输层应当放在接口之后。 Stripe Invoicing 与 Stripe Billing 生成的是 PDF。Stripe 自己的文档写得很清楚：不额外接入电子发票应用，这两个产品无法创建或发送电子发票，并把用户指向 App Marketplace 的合作方。对德国境内的 B2B 交易，这份 PDF 从 2027 年 1 月 1 日起（较大卖方）以及 2028 年 1 月 1 日起（其余所有企业）不再满足开具义务。 这个话题下的多数文章出自税务顾问，或出自卖格式转换器的厂商。这篇是从建设方的角度写的。它回答的问题不是"法律怎么规定"，而是**工程团队在支付服务商周边究竟要建什么、哪些部分可以直接采购**。这是工程指南，不是税务建议，税务判断仍由你的税务顾问负责。 **先给答案：**文件格式是整个问题里最便宜的一环。把 Stripe 发票转换成 ZUGFeRD 或 XRechnung 是已经解决、可以采购的一步。转换器不会替你解决的是：映射到 EN 16931 字段的正确税务判定、干净的买方主数据、结构化原件的不可篡改归档，以及作废重开而非删除的更正生命周期。预算要花在这四个系统上，而不是 XML 上。 ## 究竟什么在什么时候改变 对软件团队真正重要的不是一个日期，而是一张矩阵。接收义务先于开具义务生效，而每个邻国解决传输问题的方式都不一样。 | 司法辖区 | 日期 | 对计费系统意味着什么 | | --- | --- | --- | | 德国 | 2025 年 1 月 1 日 | 每一家境内企业都必须能够**接收并处理**符合 EN 16931 的电子发票。没有过渡期，收件方也无权拒绝。 | | 德国 | 至 2026 年 12 月 31 日 | 纸质发票仍然允许。PDF 仅在收件方同意时允许。 | | 德国 | 2027 年 1 月 1 日 | 2026 年总营业额超过 80 万欧元的卖方，境内 B2B 必须**开具**结构化电子发票。 | | 德国 | 2028 年 1 月 1 日 | 营业额豁免取消。小额门槛以上的每一张境内 B2B 发票都必须结构化。 | | 奥地利 | 当前 | 面向联邦政府必须使用结构化电子发票。欧盟委员会的国别说明记录为**没有 B2B 强制要求**，也没有已排期的计划。 | | 法国 | 2026 年 9 月起 | 所有企业先具备接收能力，随后分阶段强制开具。发票必须经由获认证的私营平台流转，而不是直接发给买方。 | | 比利时 | 2026 年 1 月 1 日 | 境内 B2B 电子发票，构建在 Peppol 网络之上。 | | 欧盟（ViDA） | 2030 年 7 月 1 日 | 欧盟内部 B2B 交易适用 EN 16931 电子发票与数字申报。 | 把法国那一行和德国那一行并排再读一遍。德国规定的是*格式*，渠道交由交易双方约定，因此电子邮件是合法的送达方式。法国规定的是*网络*。如果你的路线图把"电子发票"当成一个功能，范围就已经估错了：格式、传输和申报是三条独立的轴，每个国家分别设定。 ### 哪些内容不在范围内 - **B2C。** 面向消费者的发票不受德国强制要求约束。 - **小额发票。** 含税 250 欧元以下的发票以及车船票可以继续不结构化。 - **特定免税交易** ，即德国增值税法免税目录中的部分项目。 对典型的 B2B SaaS 而言，250 欧元的豁免与其说是宽松，不如说是陷阱。每月 49 欧元的坐席套餐在门槛之下，年度合同则不在，而自助升级会让客户在年中越过这条线。把"这张发票是否在范围内"编码成计费系统按单据求值的规则，胜过把它写成 wiki 里的一条政策。 ## 为什么 PDF 不是电子发票 EN 16931 描述的不是一份文档，而是一个**语义数据模型**：一组业务术语，例如卖方增值税识别号、发票行净额、税种类别代码和付款到期日，每一项都有明确的基数以及一组必须成立的业务规则。当一个文件用两种许可的 XML 语法之一（UBL 或 UN/CEFACT CII）承载这个模型并通过规则校验时，它才是电子发票。 PDF 承载的是像素，最多再加一层文本。机器无法可靠判断第四行的"19%"是税率、折扣还是产品名称的一部分。区别就在这里。法律意义上的"机器可读"，指接收系统能够确定性地提取每一个必填字段，不依赖启发式，也不需要一个靠猜的 [LLM](/zh/glossary/llm/) 。 | 格式 | 它是什么 | SaaS 何时应当选它 | | --- | --- | --- | | XRechnung | 纯 XML，EN 16931 的德国国别约束版。没有人类可读层。 | 公共部门买方，以及应付账款系统点名要求它的企业客户。 | | ZUGFeRD / Factur-X | 内嵌 CII XML 的 PDF/A-3。一个文件，两类受众。 | 自助式 B2B 产品的务实默认选项，因为人类收件方仍然看得到一张发票。 | | Peppol BIS Billing 3.0 | 一个 UBL 配置文件，外加带寻址与回执的投递网络。 | 销往比利时、北欧、新加坡、澳大利亚，或任何给你 Peppol 参与方标识的买方。 | 有两个实现细节，发现得晚就各要一个版本来补。第一，**并非每个 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 法案](/zh/blog/gdpr-ai-act-stacking-dach-saas/) 一文中。 ## 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。在德国，2025 年起开具或收到的发票适用八年保存期。"东西在 Stripe 里"不是归档，而是一个你无法掌控其生命周期的第三方 [API](/zh/glossary/api/) 。可行的做法是：启用版本控制与对象锁定保留策略的对象存储、写入时记录的内容哈希，以及一份把发票号映射到存储键的索引。除此之外还需要一份书面流程说明，覆盖发票如何创建、校验、发送、存储与更正。稽查人员会先读这份文档，再读你的代码。 ### 4. 更正生命周期 订阅制产品与一次性销售的差别就在这里，绝大部分工程量也落在这里。按比例计费、周期中途换套餐、催缴重试、部分退款、余额抵扣和币种变更都会产生财务事件，这些事件必须变成更正单据，而不是对原单据的修改。在不可篡改的原则下，你作废并重开，而不是覆盖。退款不等于自动生成贷记单，被丢弃的草稿也不同于已作废的发票。把这套映射写成一台状态机，每个 Stripe 事件类型占一行，是整个项目产出的最有价值的产物。 ## 2025 年的 BMF 文件把校验变成了流水线要求 德国财政部 2025 年 10 月 15 日的第二份适用文件，把电子发票的缺陷分成三类。在工程团队看来，这与其说是税务指引，不如说是一份校验闸门的规格说明。 | 错误类别 | 含义 | 后果 | | --- | --- | --- | | 格式错误 | 文件语法无效，或必填字段无法被完整提取。 | 它根本不算电子发票，只能算普通发票，在大限之后即意味着义务未履行。 | | 业务规则错误 | 语法成立，但违反了 EN 16931 的某条业务规则。 | 仍然是电子发票，但存在缺陷，需要更正。 | | 内容错误 | 涉税内容有误：税率、服务描述、供应日期。 | 收件方的进项税抵扣面临风险。 | 技术含义很直接。在发送**之前**用 EN 16931 业务规则校验每一份单据，遇到格式错误和业务规则错误就阻断，并把内容错误引入人工队列，因为没有任何校验器能发现它们。把校验当作出站闸门而不是监控看板，决定了缺陷是被队列拦住，还是被客户的税务部门发现。这与我们在 [软件质量保障](/zh/services/software-quality-assurance/) 项目中坚持的纪律一致：检查要放在路径上，而不是旁边。 ![Kevin Riedl](/img/team/kevin.webp) "团队为 XML 做预算，然后被归档和贷记单打个措手不及。格式只是一次库调用。更正生命周期是一台状态机，得有人负责它未来八年。" ## 基于 Stripe 的计费技术栈参考架构 1. **计费事件。** 把 Stripe webhook 消费进你自己的持久事件日志。绝不要把支付服务商当作会计记录的权威来源。 2. **发票数据模型。** 把这些事件投影为一个规范化的发票实体，显式承载 EN 16931 的每一个必填术语，包括买方标识与编码后的税务处理。这个模型才是你真正的交付物，PDF 不是。 3. **编号与不可篡改。** 在单据定稿的那一刻由唯一写入方分配发票号，此后记录只追加不修改。 4. **渲染。** 用同一个模型一步生成 XML 与人类可读版本，使二者不可能出现偏差。 5. **校验闸门。** 执行 schema 校验加业务规则校验。失败即阻断。校验结果与单据一并留存。 6. **传输。** 按目的地选择通道：德国用邮件附件，比利时和北欧用 Peppol 接入点，法国用获认证平台。把传输放在接口之后，新增一个国家就只是新增一个适配器，而不是一套新代码库。 7. **归档与对账。** 把结构化原件连同哈希写入锁定存储，并按计划把归档与账本对账。没人对账的归档只是一个假设，不是控制措施。 这份清单里大约四分之一可以直接采购，其余是你的领域模型，也正是工作被法定期限赶着做时 [技术债](/zh/glossary/technical-debt/) 堆积的地方。 ## 自建、采购还是外挂 | 选项 | 适合的场景 | 仍然留给你的部分 | | --- | --- | --- | | Stripe App Marketplace 合作方应用 | 发票量低、单一国家、标准税务处理、发票本就在 Stripe 内生成 | 主数据质量、归档归属、更正映射 | | 带 API 的电子发票 SaaS | 多个国家、中等体量，希望格式与传输一并解决 | 从你的领域模型到对方 schema 的映射层，以及在受监管路径上的供应商依赖 | | Peppol 接入点服务商 | 实行网络强制的国家、拥有参与方标识的企业客户 | 格式生成以及传输之上的全部环节 | | 自建发票层 | 计费逻辑本就是差异化能力：按用量定价、市场平台、分账、多实体集团 | 随 EN 16931 与各国配置文件演进而持续进行的符合性工作 | 对多数 B2B SaaS 公司，诚实的默认答案是混合方案：采购格式生成与传输，自建发票数据模型、校验闸门与归档。这个划分遵循的是与其他任何 [定制软件与成品软件之间的取舍](/zh/software-development-guide/custom-software-vs-off-the-shelf/) 相同的逻辑。买下通用件，掌握业务逻辑真正触及的那部分。当年我们把机构级 [债券分析平台](/zh/case-studies/bond-analytics/) 从零做到企业级可用时，同样的原则成立：受监管的输出，可信度不会超过生成它的模型。 ## 我们在计费流水线里见过的八种失效模式 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](/zh/services/fractional-cto/) 而不是为此招人的常见原因。 ## 四个值得纠正的误解 - **"发票号必须连续无缺号。"** 德国增值税法要求的是为识别发票而一次性分配的连续编号。法律并不强制号段毫无缺口。缺号确实会在稽查中引来提问，所以要记录缺号的原因。 - **"内嵌 XML 的 PDF 是权宜之计。"** ZUGFeRD 是一等公民级的合规格式。PDF 容器不是问题， *不带* 结构化数据的 PDF 才是。 - **"德国需要 Peppol。"** 德国规定的是格式，不是渠道。电子邮件就够了。需要 Peppol 是因为你卖给谁，而不是因为德国法律。 - **"我们的财务软件会处理。"** 它处理的是它自己开出的发票。由你的产品、在你的计费引擎里、按你自己的号段生成的发票，归你负责。 ## Stripe 与电子发票常见问题 ### Stripe 能发送 XRechnung 或 ZUGFeRD 发票吗？ 单靠自身不能。Stripe 文档写明，Stripe Billing 与 Stripe Invoicing 在不接入电子发票应用的情况下无法创建或发送电子发票，并引导用户使用 App Marketplace 合作方。Stripe 生成的是 PDF，而 PDF 不是 EN 16931 意义上的结构化电子发票。 ### 2027 年之后德国还能用 PDF 发票吗？ 对境内 B2B 交易，它不再满足开具义务：2026 年营业额超过 80 万欧元的卖方自 2027 年 1 月 1 日起，其余企业自 2028 年 1 月 1 日起。面向消费者的发票、含税 250 欧元以下的发票以及特定免税交易仍在强制范围之外。 ### 奥地利或瑞士公司必须开具德国电子发票吗？ 德国的开具义务覆盖买卖双方均在德国设立的交易，即在德国拥有注册地、实际管理机构或增值税常设机构。没有此类设立的公司不在范围内。德国子公司或常设机构则在范围内，而且无论卖方位于何处，德国买方都越来越期望收到结构化发票。 ### B2B SaaS 应该选哪种格式？ ZUGFeRD 的 EN 16931 或更高配置文件是务实的默认选项，因为一个文件同时服务机器与人。买方或公共部门点名要求时用 XRechnung；买方给出参与方标识、或目标国实行网络强制时用 Peppol BIS Billing 3.0。 ### ZUGFeRD 的 MINIMUM 与 BASIC WL 配置文件算数吗？ 不算。两者都不含发票行数据，因此不满足德国对合规电子发票的要求。请从 BASIC 配置文件起步或更高，并对输出做校验，而不是信任库的默认值。 ### 在德国用电子邮件送达电子发票可以吗？ 可以。德国规定格式，并把传输渠道留给合同双方，因此通过电子邮件发送 XML 或 ZUGFeRD 文件即可。法国要求经由获认证平台传输，比利时基于 Peppol，所以渠道决策取决于目标国。 ### 电子发票必须保存多久？ 在德国，2025 年起开具或收到的发票适用八年保存期。结构化部分是具有法律约束力的原件，因此 XML 必须原样、机器可读地保存，并配有一份书面的开票流程说明。 ### 这需要多少工程量？ 对采购格式生成与传输的单一国家 SaaS，发票模型、校验闸门、归档与更正映射通常需要一个专注的季度。多实体集团、按用量定价、市场平台以及糟糕的客户主数据都会显著拉长周期。把历史发票跑一遍校验闸门，是诚实估算规模最快的办法。 ## 最终思考 Stripe 是一家带有开票便利功能的支付服务商，不是合规主数据系统，它自己也这么说。把 2027 年的期限当成它本来的样子：一个推动力，促使你给计费领域一个真正的数据模型、一道校验闸门、一份你掌控的归档，以及一个有人负责的更正生命周期。买下 XML 与网络，自建模型。按这个顺序推进的团队，最终会拥有一套计费系统，下一个强制要求只是换个适配器，而不是重写。 ## 主要来源 - [德国联邦财政部，关于强制电子发票的第二份适用文件，2025 年 10 月 15 日](https://www.bundesfinanzministerium.de/Content/DE/Downloads/BMF_Schreiben/Steuerarten/Umsatzsteuer/Umsatzsteuer-Anwendungserlass/2025-10-15-einfuehrung-obligatorische-e-rechnung.pdf?__blob=publicationFile&v=5) - [德国联邦财政部，自 2025 年 1 月 1 日起强制电子发票的常见问题](https://www.bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html) - [德国增值税法第 14 条，发票开具与连续编号要求](https://www.gesetze-im-internet.de/ustg_1980/__14.html) - [Stripe，德国的强制电子发票](https://stripe.com/resources/more/e-invoice-in-germany) - [Stripe，通过 App Marketplace 合作方发送电子发票](https://stripe.com/guides/send-e-invoices-on-stripe-billing-through-app-marketplace-partners) - [FeRD，ZUGFeRD 版本与配置文件常见问题](https://www.ferd-net.de/standards/zugferd-faq) - [欧盟委员会电子发票国别说明，奥地利](https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eInvoicing+in+Austria) - [欧盟委员会电子发票国别说明，法国](https://ec.europa.eu/digital-building-blocks/sites/display/DIGITAL/eInvoicing+in+France) - [欧盟委员会，数字时代的增值税（ViDA）](https://taxation-customs.ec.europa.eu/taxation/vat/vat-digital-age-vida_en) ## 你可能也喜欢.. [**DACH SaaS 如何叠加应对 GDPR 与 AI 法案** 相互重叠的欧盟法规最终如何落到一个产品团队身上，以及如何排定工程工作的顺序。](/zh/blog/gdpr-ai-act-stacking-dach-saas/) [**定制软件与成品软件** 把自建、采购还是混合的决策，用在技术栈中受监管的那一部分。](/zh/software-development-guide/custom-software-vs-off-the-shelf/) AI 治理与监管 ## 继续浏览此集群 负责任采用 AI 所需的安全、政策、合规与运营控制。 [从核心文章开始**5 人创业团队的 EU AI Act 成本**](/zh/blog/eu-ai-act-compliance-cost-startup/) - [面向 LLM 的假名化网关：提示词真的脱离 GDPR 适用范围了吗？](/zh/blog/llm-pseudonymization-gateway-gdpr-2026/) - [Semantica 评测 2026：它能解释每一次 AI 智能体决策吗？](/zh/blog/semantica-ai-agent-decision-provenance/) - [AI 智能体合同签署：eIDAS QES 集成指南](/zh/blog/ai-agent-eidas-signature-integration/) - [Terafab：从硅片到轨道的 AI 堆栈由谁控制？](/zh/blog/terafab-vertical-integration-ai-stack/) - [AI 能制造病毒吗？斯坦福研究真正证明了什么](/zh/blog/ai-designed-viruses-stanford-biosecurity/) 只收重要内容 ## 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 分钟 阅读 · 2026年8月4日 最近审核 2026年8月4日 [**下一篇**](/zh/blog/validate-b2b-saas-idea-dach/) 邮件订阅新文章 × × 通过邮件获取新文章 我们发布时给你一封简短邮件。免费，不做跟踪。 ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/stripe-billing-e-invoicing-2027/#webpage", "@type": "WebPage", "dateModified": "2026-08-04", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-04", "url": "https://wavect.io/zh/blog/stripe-billing-e-invoicing-2027/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Stripe Invoicing 与 Stripe Billing 生成的是 PDF，Stripe 自己的文档也写明：不额外接入电子发票应用，二者无法创建或发送电子发票。对德国境内 B2B 交易，PDF 从 2027 年 1 月 1 日起不再满足开具义务（适用于 2026 年营业额超过 80 万欧元的卖方），2028 年 1 月 1 日起适用于所有企业；而接收 EN 16931 电子发票的义务自 2025 年 1 月 1 日起已经生效。转换成 ZUGFeRD 或 XRechnung 是可以直接采购的一步，真正的工程量在别处：把税务判定映射到 EN 16931 的税种类别代码、校验买方主数据与路由标识、在八年保存期内不可篡改地归档结构化原件，以及用作废重开而非删除的更正生命周期。德国的义务仅覆盖买卖双方均在德国设立的交易，因此在德国没有常设机构的奥地利或瑞士卖方不受开具义务约束，但德国买方越来越期望收到结构化发票。德国规定格式却不限定传输渠道，法国要求经认证平台，比利时基于 Peppol，因此传输层应当放在接口之后。", "articleBody": " 博客概览/商业与监管/AI 治理与监管 Stripe Billing 发的是 PDF。2027 年起在德国那不算发票 要点速览 Stripe Invoicing 与 Stripe Billing 生成的是 PDF，Stripe 自己的文档也写明：不额外接入电子发票应用，二者无法创建或发送电子发票。对德国境内 B2B 交易，PDF 从 2027 年 1 月 1 日起不再满足开具义务（适用于 2026 年营业额超过 80 万欧元的卖方），2028 年 1 月 1 日起适用于所有企业；而接收 EN 16931 电子发票的义务自 2025 年 1 月 1 日起已经生效。转换成 ZUGFeRD 或 XRechnung 是可以直接采购的一步，真正的工程量在别处：把税务判定映射到 EN 16931 的税种类别代码、校验买方主数据与路由标识、在八年保存期内不可篡改地归档结构化原件，以及用作废重开而非删除的更正生命周期。德国的义务仅覆盖买卖双方均在德国设立的交易，因此在德国没有常设机构的奥地利或瑞士卖方不受开具义务约束，但德国买方越来越期望收到结构化发票。德国规定格式却不限定传输渠道，法国要求经认证平台，比利时基于 Peppol，因此传输层应当放在接口之后。 Stripe Invoicing 与 Stripe Billing 生成的是 PDF。Stripe 自己的文档写得很清楚：不额外接入电子发票应用，这两个产品无法创建或发送电子发票，并把用户指向 App Marketplace 的合作方。对德国境内的 B2B 交易，这份 PDF 从 2027 年 1 月 1 日起（较大卖方）以及 2028 年 1 月 1 日起（其余所有企业）不再满足开具义务。 这个话题下的多数文章出自税务顾问，或出自卖格式转换器的厂商。这篇是从建设方的角度写的。它回答的问题不是\"法律怎么规定\"，而是工程团队在支付服务商周边究竟要建什么、哪些部分可以直接采购。这是工程指南，不是税务建议，税务判断仍由你的税务顾问负责。 先给答案：文件格式是整个问题里最便宜的一环。把 Stripe 发票转换成 ZUGFeRD 或 XRechnung 是已经解决、可以采购的一步。转换器不会替你解决的是：映射到 EN 16931 字段的正确税务判定、干净的买方主数据、结构化原件的不可篡改归档，以及作废重开而非删除的更正生命周期。预算要花在这四个系统上，而不是 XML 上。 究竟什么在什么时候改变 对软件团队真正重要的不是一个日期，而是一张矩阵。接收义务先于开具义务生效，而每个邻国解决传输问题的方式都不一样。 司法辖区日期对计费系统意味着什么 德国2025 年 1 月 1 日每一家境内企业都必须能够接收并处理符合 EN 16931 的电子发票。没有过渡期，收件方也无权拒绝。 德国至 2026 年 12 月 31 日纸质发票仍然允许。PDF 仅在收件方同意时允许。 德国2027 年 1 月 1 日2026 年总营业额超过 80 万欧元的卖方，境内 B2B 必须开具结构化电子发票。 德国2028 年 1 月 1 日营业额豁免取消。小额门槛以上的每一张境内 B2B 发票都必须结构化。 奥地利当前面向联邦政府必须使用结构化电子发票。欧盟委员会的国别说明记录为没有 B2B 强制要求，也没有已排期的计划。 法国2026 年 9 月起所有企业先具备接收能力，随后分阶段强制开具。发票必须经由获认证的私营平台流转，而不是直接发给买方。 比利时2026 年 1 月 1 日境内 B2B 电子发票，构建在 Peppol 网络之上。 欧盟（ViDA）2030 年 7 月 1 日欧盟内部 B2B 交易适用 EN 16931 电子发票与数字申报。 把法国那一行和德国那一行并排再读一遍。德国规定的是格式，渠道交由交易双方约定，因此电子邮件是合法的送达方式。法国规定的是网络。如果你的路线图把\"电子发票\"当成一个功能，范围就已经估错了：格式、传输和申报是三条独立的轴，每个国家分别设定。 哪些内容不在范围内 B2C。面向消费者的发票不受德国强制要求约束。 小额发票。含税 250 欧元以下的发票以及车船票可以继续不结构化。 特定免税交易，即德国增值税法免税目录中的部分项目。 对典型的 B2B SaaS 而言，250 欧元的豁免与其说是宽松，不如说是陷阱。每月 49 欧元的坐席套餐在门槛之下，年度合同则不在，而自助升级会让客户在年中越过这条线。把\"这张发票是否在范围内\"编码成计费系统按单据求值的规则，胜过把它写成 wiki 里的一条政策。 为什么 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 参与方标识的买方。 有两个实现细节，发现得晚就各要一个版本来补。第一，并非每个 ZUGFeRD 配置文件都合格：MINIMUM 与 BASIC WL 不包含发票行，因此不满足德国要求，库的默认值设成 MINIMUM 就会产出一个看起来合规、实际不合规的文件。第二，在混合文件中结构化部分才是具有约束力的原件。如果 XML 写 1,190.00 欧元而渲染出的 PDF 写 1,180.00 欧元，以 XML 为准，客户系统入账的也是 XML。用生成 XML 的同一套数据结构去渲染 PDF，而不是走一套平行模板，是杜绝这类缺陷唯一可靠的做法。 德国的强制要求适用于奥地利、瑞士或美国的 SaaS 吗？ 通常不适用，而这正是整个话题里最常被读错的一点。 德国的开具义务适用于双方均在德国设立的企业间交易，\"设立\"指在德国拥有注册地、实际管理机构或增值税意义上的常设机构。一家在德国没有常设机构的奥地利 GmbH 向柏林客户开票，不在开具义务范围内。这类服务通常本就适用反向征收，由德国客户承担增值税申报。 但有三点让\"什么都不做\"站不住脚： 一个德国实体或常设机构会把你拉进来。许多外国集团都有一个，却忘了起决定作用的是开票实体，而不是母公司。 接收与开具是两回事。只要你有德国实体，它就必须已经能处理结构化的供应商发票。那是应付账款与集成问题，不是计费问题。 客户照样会提要求。一旦德国买方的应付账款流程改为结构化接收，外国供应商的 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。在德国，2025 年起开具或收到的发票适用八年保存期。\"东西在 Stripe 里\"不是归档，而是一个你无法掌控其生命周期的第三方 API。可行的做法是：启用版本控制与对象锁定保留策略的对象存储、写入时记录的内容哈希，以及一份把发票号映射到存储键的索引。除此之外还需要一份书面流程说明，覆盖发票如何创建、校验、发送、存储与更正。稽查人员会先读这份文档，再读你的代码。 4. 更正生命周期 订阅制产品与一次性销售的差别就在这里，绝大部分工程量也落在这里。按比例计费、周期中途换套餐、催缴重试、部分退款、余额抵扣和币种变更都会产生财务事件，这些事件必须变成更正单据，而不是对原单据的修改。在不可篡改的原则下，你作废并重开，而不是覆盖。退款不等于自动生成贷记单，被丢弃的草稿也不同于已作废的发票。把这套映射写成一台状态机，每个 Stripe 事件类型占一行，是整个项目产出的最有价值的产物。 2025 年的 BMF 文件把校验变成了流水线要求 德国财政部 2025 年 10 月 15 日的第二份适用文件，把电子发票的缺陷分成三类。在工程团队看来，这与其说是税务指引，不如说是一份校验闸门的规格说明。 错误类别含义后果 格式错误文件语法无效，或必填字段无法被完整提取。它根本不算电子发票，只能算普通发票，在大限之后即意味着义务未履行。 业务规则错误语法成立，但违反了 EN 16931 的某条业务规则。仍然是电子发票，但存在缺陷，需要更正。 内容错误涉税内容有误：税率、服务描述、供应日期。收件方的进项税抵扣面临风险。 技术含义很直接。在发送之前用 EN 16931 业务规则校验每一份单据，遇到格式错误和业务规则错误就阻断，并把内容错误引入人工队列，因为没有任何校验器能发现它们。把校验当作出站闸门而", "articleSection": "商业与法律", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-08-04", "datePublished": "2026-08-04", "description": "Stripe Invoicing 与 Stripe Billing 生成的是 PDF，Stripe 自己的文档也写明：不额外接入电子发票应用，二者无法创建或发送电子发票。对德国境内 B2B 交易，PDF 从 2027 年 1 月 1 日起不再满足开具义务（适用于 2026 年营业额超过 80 万欧元的卖方），2028 年 1 月 1 日起适用于所有企业；而接收 EN 16931 电子发票的义务自 2025 年 1 月 1 日起已经生效。转换成 ZUGFeRD 或 XRechnung 是可以直接采购的一步，真正的工程量在别处：把税务判定映射到 EN 16931 的税种类别代码、校验买方主数据与路由标识、在八年保存期内不可篡改地归档结构化原件，以及用作废重开而非删除的更正生命周期。德国的义务仅覆盖买卖双方均在德国设立的交易，因此在德国没有常设机构的奥地利或瑞士卖方不受开具义务约束，但德国买方越来越期望收到结构化发票。德国规定格式却不限定传输渠道，法国要求经认证平台，比利时基于 Peppol，因此传输层应当放在接口之后。", "headline": "Stripe Billing 与 2027 年电子发票", "image": "https://wavect.io/img/blog/headers/header_stripe-billing-e-invoicing-2027.svg", "inLanguage": "zh", "keywords": "电子发票, SaaS 计费", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/stripe-billing-e-invoicing-2027/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/stripe-billing-e-invoicing-2027/", "wordCount": 688 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/business-regulation/", "name": "商业与监管", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/ai-governance/", "name": "AI 治理与监管", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/stripe-billing-e-invoicing-2027/", "name": "Stripe Billing 与 2027 年电子发票强制要求 | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "单靠自身不能。Stripe 文档写明，Stripe Billing 与 Stripe Invoicing 在不接入电子发票应用的情况下无法创建或发送电子发票，并引导用户使用 App Marketplace 合作方。Stripe 生成的是 PDF，而 PDF 不是 EN 16931 意义上的结构化电子发票。" }, "name": "Stripe 能发送 XRechnung 或 ZUGFeRD 发票吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "对境内 B2B 交易，它不再满足开具义务：2026 年营业额超过 80 万欧元的卖方自 2027 年 1 月 1 日起，其余企业自 2028 年 1 月 1 日起。面向消费者的发票、含税 250 欧元以下的发票以及特定免税交易仍在强制范围之外。" }, "name": "2027 年之后德国还能用 PDF 发票吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "德国的开具义务覆盖买卖双方均在德国设立的交易，即在德国拥有注册地、实际管理机构或增值税常设机构。没有此类设立的公司不在范围内。德国子公司或常设机构则在范围内，而且无论卖方位于何处，德国买方都越来越期望收到结构化发票。" }, "name": "奥地利或瑞士公司必须开具德国电子发票吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "ZUGFeRD 的 EN 16931 或更高配置文件是务实的默认选项，因为一个文件同时服务机器与人。买方或公共部门点名要求时用 XRechnung；买方给出参与方标识、或目标国实行网络强制时用 Peppol BIS Billing 3.0。" }, "name": "B2B SaaS 应该选哪种格式？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不算。两者都不含发票行数据，因此不满足德国对合规电子发票的要求。请从 BASIC 配置文件起步或更高，并对输出做校验，而不是信任库的默认值。" }, "name": "ZUGFeRD 的 MINIMUM 与 BASIC WL 配置文件算数吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "可以。德国规定格式，并把传输渠道留给合同双方，因此通过电子邮件发送 XML 或 ZUGFeRD 文件即可。法国要求经由获认证平台传输，比利时基于 Peppol，所以渠道决策取决于目标国。" }, "name": "在德国用电子邮件送达电子发票可以吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "在德国，2025 年起开具或收到的发票适用八年保存期。结构化部分是具有法律约束力的原件，因此 XML 必须原样、机器可读地保存，并配有一份书面的开票流程说明。" }, "name": "电子发票必须保存多久？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "对采购格式生成与传输的单一国家 SaaS，发票模型、校验闸门、归档与更正映射通常需要一个专注的季度。多实体集团、按用量定价、市场平台以及糟糕的客户主数据都会显著拉长周期。把历史发票跑一遍校验闸门，是诚实估算规模最快的办法。" }, "name": "这需要多少工程量？" } ] } ```