当 PDF 与 XML 不一致：混合格式电子发票中隐藏的风险

以 ZUGFeRD 为例，PDF 和 XML 共同构成一张混合格式电子发票。PDF 提供直观、可读的发票视图，XML 则以结构化格式承载发票数据。按照规范，两者应当表达相同的发票信息。但在实际业务流程中，两者出现偏差并不一定是某个重大错误导致的。很多时候，问题恰恰来自流程中的一些“小修改”。例如： 

只修改了 PDF，没有同步更新 

XML 发票发送前，工作人员可能对 PDF 进行了最后调整，例如修改服务描述、付款条件或开票地址。如果 XML 没有同步重新生成，两者就可能出现差异。 

PDF 和 XML 由不同流程生成 

在一些系统环境中，PDF 由文档或输出管理系统生成，而 XML 则来自另一套数据映射或转换流程。一旦字段映射出现问题，金额、税率、地址或发票行项目等信息就可能不一致。 

发送前的临时修改没有同步到结构化数据 

发票在审批、更正或模板调整过程中发生变化，也可能导致最终生成的 PDF 与 XML 内容不一致。 

严格来说，这种情况不应发生。ZUGFeRD 对 PDF 与 XML 的一致性有明确要求。如果两者表达的信息不同，这已经不是一个简单的版式问题，而是需要在发票验证和业务流程中被识别和处理的问题。

这里需要特别注意一个关键点：对于电子发票的自动化处理，XML 才是核心数据来源。 德国电子发票相关要求也明确强调，电子发票需要以能够进行电子处理的结构化格式创建、发送和接收。普通 PDF 本身并不满足这一要求。因此，ZUGFeRD 并不是简单地“在 PDF 里附加一个 XML”。两者承担的是不同的角色： 

• PDF： 方便人员查看、理解和核对发票 
• XML： 为系统提供结构化、机器可读的发票数据 

对于企业的应付账款流程而言，PDF 可以作为人工查看的参考，但真正用于数据提取、验证和系统处理的，应当是 XML。

问题在于，很多企业虽然已经收到结构化电子发票，却仍然按照传统 PDF 发票的方式处理。例如：打开 PDF → OCR 识别 → 提取发票信息 → 进入 ERP。这实际上把一张已经具备机器可读数据的电子发票，又重新变成了一项图像识别任务。这样做不仅增加了不必要的处理环节，也可能带来新的错误。金额、税率、地址和发票行项目等信息都可能在 OCR 过程中被误读，从而增加人工审核和异常处理的工作量。而原本已经存在于 XML 中的结构化数据，却没有被充分利用。 

更合理的方式是：读取 XML → 验证发票数据 → 匹配业务信息 → 进入审批及后续流程 → 传递至 ERP。

PDF 则作为可视化文件保留，在员工需要查看发票内容时提供直观参考。

这也是企业在部署电子发票时值得进一步思考的问题：接收到一张合规的电子发票，只是流程的开始。真正决定电子发票能否创造业务价值的，是它进入企业系统之后发生了什么。理想的接收流程应该能够直接读取 XML 数据，对发票进行技术和业务验证，并根据业务规则完成后续处理，包括：发票数据验证、与采购订单、供应商等业务数据匹配、审核与审批、异常识别与人工处理、ERP 过账以及全流程状态跟踪与管理。 

在这一过程中，人工不再需要先“把发票变成系统能读懂的数据”，因为 XML 本身已经提供了结构化数据。这也是电子发票从“满足合规要求”走向“真正实现流程自动化”的关键一步。

对于企业而言，混合格式电子发票带来的价值，并不只是让 PDF 和 XML 同时存在。更重要的是，企业能否真正利用 XML 中已经存在的结构化数据，让发票进入后续业务流程。 

SEEBURGER Purchase-to-Pay 正是在这一环节进一步延伸电子发票的价值。通过发票接收、工作流、任务管理、后处理和报表等功能，企业可以对发票进入系统后的整个处理过程进行统一管理，并将相关流程与 SAP 等核心业务系统连接起来。这样，一张合规的电子发票不再只是“收到了一份文件”，而是能够直接进入企业的业务流程：接收 → 验证 → 匹配 → 审批 → 异常处理 → 过账。最终，企业获得的不只是电子发票合规能力，而是一套更加可视、可控、可自动化的发票接收与处理流程。 

所以，当企业开始使用混合格式电子发票时，除了关注“这张发票是否合规”，也值得多问一步：PDF 和 XML 是否一致？系统真正读取的是哪一份？因为电子发票的价值，不只是让发票变成数字文件，而是让其中的数据真正进入并驱动业务流程。