电子发票对接：为不是为此而生的系统接上 Peppol、XRechnung、ZUGFeRD 与 Factur-X

买一套电子发票产品很容易。问题几乎从来不在产品，而在那套开了十二年、负责出发票的订单管理系统，在没人写过文档的定价逻辑，以及在发票号码来自一个 2019 年离职的人写的存储过程这件事上。

我们做的是连接件：把贵司实际在跑的系统，接到法规要求的那一端。结构化发票生成、校验、网络传输、进项处理和归档，全部嵌进现有系统，而不是把它换掉。

各国强制要求及生效时间

欧洲正在按国别时间表把 PDF 发票改成结构化、机器可读的发票，为欧盟数字时代增值税（ViDA）方案的统一做铺垫。当前真正驱动项目的日期：

德国：接收结构化电子发票自 2025 年 1 月 1 日起已属强制。开具方面，上一年度营业额超过 80 万欧元的企业自 2027 年 1 月 1 日起强制，其余企业自 2028 年 1 月 1 日起强制。实务中的格式是 XRechnung（纯 XML）和 ZUGFeRD 2.x（内嵌 XML 的混合式 PDF），两者均符合 EN 16931。
法国：接收，以及大型和中型企业的开具，自 2026 年 9 月 1 日起；中小企业开具自 2027 年 9 月 1 日起。传输通过注册平台完成，通用混合格式为 Factur-X。
比利时：B2B 电子发票经 Peppol 强制传输，自 2026 年 1 月 1 日起；计划 2028 年引入五角模型的电子报送。
波兰：KSeF 国家清算平台，有自己的 XML schema 和自己的时间表。
意大利：SdI 与 FatturaPA，2019 年起运行，至今仍是欧盟最严格的清算模式。
西班牙：Verifactu 与 Crea y Crece 开票义务正在推进，同时并行的还有地区性的 TicketBAI 系统。

如果贵司同时向其中几个国家销售，这不是几个项目，而是一套架构加若干国家适配器。把它当成一套架构来做，和不这么做，差别就是一次集成和五次集成的差别。

项目通常栽在哪里

发票数据不是标准要的那个形状。 EN 16931 要求的很多字段，多数系统从来没采集过：规范的买方参考号、按税率而非按行项目的增值税拆分、结构化的付款条件、来自受控词表的计量单位代码。工程量在于用现有数据确定性地重建这些字段，而且要对今后开出的每一张发票都成立。

校验失败是事后才知道的。 一张被拒的发票就是一笔收不回的钱。校验必须在传输之前跑，对照当前 schema 和当前国别业务规则，失败要推到能处理它的人面前，而不是写进日志文件。

进项比销项难。 所有人都在规划怎么开票，却忘了从接收义务生效那天起，就必须接受所有供应商、任意合规格式的结构化发票，并且要在没人逐张打开的情况下进到应付账款流程里。

编号与幂等。 重试、网络超时、平台故障都是常态。同一张发票用两个号码发出去，那是税务问题，不是软件问题。这件事必须一开始就做对。

我们做什么

评估与格式决策

一段短期投入，通常一到两周：看清贵司发票实际是怎么产生的、哪些强制要求会落到您头上、什么时候落，以及现实可选项有哪些。交付物是一份书面建议，需要哪些格式、Peppol 接入走服务商还是自建接入点、源系统必须改什么、成本多少。

有时结论是标准产品加一个小适配器就够了。与其收您六个月的费用，我们宁愿在第一周就把这话说出来。

发票生成与字段映射

我们建设从贵司源数据到目标语法的映射层（EN 16931 下的 UBL 与 CII、XRechnung、ZUGFeRD 2.x、Factur-X、FatturaPA、KSeF XML），并把字段推导规则写成文档，让审计师和财务同事都看得懂。源系统根本提供不了某个必填字段的，我们会早点说，并设计出采集方式，而不是编一个默认值。

传输前校验

Schema 校验、Schematron 业务规则和国别专项检查，全部在数据离开公司之前跑完。失败项进入有人负责的队列，提示写明哪个字段违反了哪条规则，而不是甩一段堆栈。

网络接入

Peppol 接入点连接，走成熟服务商还是自建，取决于业务量和您需要多大控制权。清算模式国家我们直接对接国家平台（KSeF、SdI、法国 PDP 生态），包括这些平台各搞各的证书与认证处理。

进项处理

接收、校验供应商发票并归一成统一的内部表示，在有采购订单和收货记录的场合做匹配，然后送进贵司应付账款流程。项目回报通常就出在这里，因为它省掉的是那些从来没人统计过的手工录入。

归档与审计留痕

以合规形式和期限存储原始结构化文件，满足德国 GoBD、意大利 conservazione sostitutiva 或您所在地的同等规则，并且检索路径是实测过的，不是假定可用的。

我们对接的系统

SAP ECC 与 S/4HANA、Microsoft Dynamics 365 与 Business Central、Odoo、NetSuite、Sage、Infor、Xero、DATEV 接口，以及最常见的那一类，自研或被大幅改造过、支撑着整个业务运转、不可能为了一项法规就换掉的系统。我们用 .NET、Java、PHP、Python、Node.js，遇上更老的技术栈也照做。

如果贵司跑的是电商平台、订阅平台或计费引擎，由程序批量开票，那正是我们擅长的场景：发票由您的代码生成，合规就必须住在您的代码里。

我们不做什么

我们不卖开票软件，也不是财务软件公司。如果贵司是小企业，只想要一个能开出合规发票的工具，直接买一个，DATEV、sevDesk、Lexware 以及另外十几家做得很好，价格只是集成项目的零头。

来找我们的场景是：发票由贵司已有的系统产生；多个国家的规则必须并存；或者单量大到必须无人值守地跑下去。

项目怎么推进

评估，一到两周，固定价，产出书面建议和带成本的方案。

开发，第一个国家通常六到十二周，取决于源数据有多干净。我们在贵司仓库、贵司分支策略、贵司团队里工作，并留下测试。

试点，用真实发票对一小批交易对手发送，与现有流程并行，直到失败率降到该有的水平。

切换与支持，失败队列有人监控、有人负责，一直陪到第一个月末结账和第一次增值税申报，真正要紧的问题正是在那时候浮出来。

我们遵循的标准

EN 16931 及其语法绑定（UBL 2.1、UN/CEFACT CII）、Peppol BIS Billing 3.0 与 Peppol 传输基础设施、XRechnung 与 KoSIT 校验器、ZUGFeRD 2.x 与 Factur-X 配置文件、FatturaPA、KSeF，以及正在塑造 2030 年之后格局的 ViDA 提案。

常见问题

德国的电子发票义务具体什么时候落到我们头上？

接收义务自 2025 年 1 月 1 日起适用于所有德国企业。开具义务：上一年度营业额超过 80 万欧元的自 2027 年 1 月 1 日起，其余自 2028 年 1 月 1 日起。该义务覆盖境内 B2B 交易；跨境和 B2C 开票的处理方式不同，值得与税务顾问确认。

XRechnung 和 ZUGFeRD 有什么区别？

XRechnung 是纯 XML，由德国公共部门定义，向公共机构开票时强制使用。ZUGFeRD 2.x 是混合式：一份 PDF/A-3 文件，内部嵌入同样的结构化数据，人看 PDF，机器读 XML。两者都符合 EN 16931。德国商业 B2B 实践更偏向 ZUGFeRD，多数买方两种都收。

我们需要自建 Peppol 接入点吗？

通常不需要。多数企业通过现有接入点服务商接入，更便宜也更快。自建适合业务量大、需要控制传输层，或者本身要向他人提供开票服务的情况。

你们能和我们现有的电子发票供应商配合吗？

可以，而且这往往是正确的分工：供应商负责传输和网络成员资格，我们负责贵司系统与其 API 之间的一切，映射、校验、重试、失败处理和对账。

校验不通过的发票会怎样？

进入队列，附一段可读说明，写明哪个字段违反了哪条规则。这个队列我们是刻意设计的，因为上线后头几个月它是系统里使用最频繁的部分，做得不好就会把一个合规项目变成一项永久的手工作业。

你们怎么避免同一张发票发两次？

用一个由发票身份派生的稳定幂等键，贯穿每一次重试，再加一份传输日志作为“发过什么”的唯一权威。任何重试都复用原标识，不生成新的。

开始行动

告诉我们贵司向哪些国家开票、每月大约多少张、今天由什么系统产生。我们会告诉您哪些强制要求会落到您头上、先后顺序如何，以及这件事是一个连接件还是一个项目。

联系我们，预约一次电子发票就绪度评估。