将发票数据转换为符合国家规定的电子发票 XML 格式

如果您的公司在欧盟的任何地方向客户开具发票，那么您发送的不再仅仅是一份文件，而是一个数据文件。一系列国家法规将于2026年和2027年陆续生效，这些法规要求发票以结构化的XML格式进行交换，以便税务机关或客户的会计系统能够读取，而无需人工干预。

问题在于，虽然这一要求适用于整个欧盟，但各个国家的具体格式却有所不同。德国希望使用XRechnung或ZUGFeRD格式。法国接受Factur-X、UBL或CII格式。意大利已经使用了FatturaPA多年。波兰通过KSeF系统进行申报。比利时使用Peppol系统。所有这些系统都遵循相同的欧洲语义标准EN 16931，但它们以不同的方式实现这一标准。

因此，企业面临的挑战远不止于合规性。公司ERP系统生成的发票需要根据不同国家的要求进行重新格式化。现在收到的电子发票通常以XML格式发送，需要在导入数据库或会计系统之前进行转换。而且，即使企业已经按照一种合规格式生成发票，有时还会被要求提供另一种格式——例如，已经为XRechnung格式的企业，可能需要提供ZUGFeRD所使用的CII XML格式，或者一家意大利企业可能同时需要提供国内使用的FatturaPA格式和跨境使用的Peppol BIS格式。

这三个问题本质上都是同一个问题，只是源和目标位置互换了，这就是为什么它们需要一个统一的解决方案 数据映射解决方案 而不是使用三个独立的工具。

MapForce 可以将数据转换为 XML 格式，也可以将 XML 数据转换为其他格式

大多数电子发票产品只支持其供应商已经构建的格式。这在没有新的政策要求或客户提出不在支持列表中的格式需求时是可行的。但一旦出现这种情况，您就只能等待供应商的后续规划。

Altova MapForce 从另一个角度解决问题。它可以将您的原始发票数据映射到您导入的任何模式——无论是 UBL、CII、XRechnung、FatturaPA，还是明年发布的国家标准格式。数据映射的另一端会读取您已有的数据：

从企业资源规划 (ERP) 系统或会计系统中导出的 Excel 和 CSV 文件
数据库，包括支撑您账单系统的底层数据表
从API或其他应用程序获取的XML和JSON数据
使用 MapForce PDF 提取器，可以处理 PDF 格式的源文件
EDI，即电子数据交换，其中发票以EDIFACT或X12消息的格式进行传输

正是由于这种复杂性，这才能被归类为数据映射问题，而不是简单的转换问题。发票数据通常分散在不同的地方：一部分可能存在于企业资源规划（ERP）系统中，一部分可能存在于子公司维护的电子表格中，还有一部分可能存在于供应商提供的PDF文件中，此外，电子发票的XML格式还会根据不同的国家/地区而有所变化。

在MapForce中，数据映射项目是通过可视化方式构建的，因此，即使不懂编程的人，只要理解发票数据的结构，就可以创建映射项目，而无需编写代码。此外，为第二个国家构建映射项目所需的成本远低于第一个国家：因为您已经构建了与内部系统的映射，所以您只需复制该映射，替换为新的电子发票格式，并仅在两个格式实际不同的地方进行调整。您无需为每个国家/地区使用单独的工具。

各国家/地区的电子发票标准

以下是欧盟主要市场的现状。所有以下格式均符合 EN 16931 标准；不同之处在于，每个国家/地区接受的语法格式不同，以及发票需要经过的流程也不同。

|国家|要求的格式|它是什么|状态| |---|---|---|---| |法国|Factur-X、UBL 或 CII| Factur-X 是一种混合格式：它是一个 PDF/A-3 文件，其中嵌入了 XML 数据。 UBL 和 CII 都是纯 XML 格式。发票将通过一个经过批准的平台（PDP）进行处理。本地：电子发票。| 所有适用企业必须能够在2026年9月1日起接收电子发票。电子发票和电子报表：大型企业和创新型企业（ETI）从2026年9月开始；中小企业和微型企业从2027年9月开始。 |德国|XRechnung 或 ZUGFeRD 2.1+|XRechnung 是一种纯 XML 格式。 ZUGFeRD 是一种混合格式，它结合了 PDF/A-3 标准，并嵌入了 CII XML 数据。本地：电子发票。自2025年1月1日起，使用电子发票为强制要求。自2027年1月1日起，适用于年营业额超过80万欧元的企业；自2028年1月1日起，适用于所有企业。 | 意大利 | FatturaPA | 纯XML格式，通过SdI清算平台进行交换。本地：电子发票。| 实时。自2019年起，适用于国内企业间的B2B交易。 |波兰| KSeF结构化发票 | 一种通过KSeF平台提交的全国性XML格式发票。本地化后的发票，结构化呈现。| 实时。自2026年2月1日起，适用于最大的纳税人；自2026年4月1日起，适用于所有企业对企业的交易。 | ** 比利时 ** | Peppol BIS Billing 3.0 | 纯XML格式，通过Peppol网络进行交换，而非直接发送。 | 自2026年1月1日起生效 | | ** 英国 (UK) ** | 基于Peppol | 不属于欧盟的推广范围，采用不同的时间表。 | 尚未强制执行。已确认，将于2029年4月正式实施基于Peppol标准的企业对企业（B2B）电子交易规范

处理混合电子发票格式

与纯 XML 格式不同，ZUGFeRD 和 Factur-X 都是 PDF/A-3 文件，其中包含嵌入的 XML 格式发票作为附件。可见的页面仅供人工阅读参考；如果两者之间存在差异，则嵌入的 XML 格式数据才是最终有效的数据。

仅接收一份文件： 在这种情况下，请不要从PDF文件中提取数据，因为那样提取的将是副本，而不是实际的数据。请将附件和映射关系从XML文件中分离出来。开源的poppler-utils软件包可以通过一个命令完成此操作：

pdfdetach -list invoice.pdf # show embedded files

pdfdetach -saveall invoice.pdf # extract all attachments

附件名称会告知您所使用的规范：对于 ZUGFeRD 1.0，文件名为 ZUGFeRD-invoice.xml；对于 ZUGFeRD 2.x 和 Factur-X，文件名为 factur-x.xml；对于 XRechnung 参考规范，文件名为 xrechnung.xml。Poppler-utils 适用于 Windows、Linux 和 macOS。这一步骤可以很好地实现自动化，它是 FlowForce Server 任务的第一阶段，映射过程会在其后立即执行。

关于发送单一文件： MapForce 将 PDF 文件作为数据源进行读取，但不将其作为输出。因此，它生成的是用于填充 ZUGFeRD 或 Factur-X 文件的 XML 数据，而不是直接生成混合格式的 PDF 文件。容器文件的组装由您的 PDF 工具链完成。

需要注意的是，无论选择哪种方案，ZUGFeRD和Factur-X都定义了多种格式。在较低级别的格式中，嵌入的XML只包含头部信息，而详细的条目信息仍然保留在PDF文件中，软件无法读取。在决定如何配置映射关系之前，请务必确认您的客户或平台需要哪种格式。

创建电子发票

从您的系统向客户发送发票涉及四个不同的环节。这些环节往往被笼统地称为“电子发票”，这导致团队在项目进行过程中，常常会惊讶地发现他们的软件并没有实现他们期望的功能。不。

提取——从其当前存储位置提取发票数据，这些位置可能包括：ERP系统导出文件、数据库、电子表格或供应商提供的PDF文件
映射与转换——将数据重新组织成目标格式所定义的字段，并在转换过程中，将代码、日期和税收类别进行相应的转换
验证——在任何人尝试发送数据之前，确认结果是否符合预定义的结构
传输：可以通过 Peppol 网络、法国的 PDP（服务提供商）或国家平台（如 SdI 或 KSeF）进行传输

数据提取、映射和转换是数据映射任务，而MapForce正是执行这些任务，同时它还会检查输出结果是否符合目标模式，从而确保文件在输出之前结构正确。

超出这些范围的还有两点：一是EN 16931标准，它实现了XSD无法表达的业务规则，并通过Schematron验证器进行检查。欧盟免费发布这些规则集，并且通常情况下，物流平台在接收到这些规则集后会立即启用它们。此外，物流本身涉及网络连接和认证问题，需要使用Peppol访问点或经过批准的平台提供商。

在开始规划工作范围之前，了解这些界限在哪里，是区分一个周密的计划和一个突如其来的意外的关键。

实际应用案例：将PDF文件转换为XML格式的电子发票

财务团队经常会遇到这个问题：账单系统只生成PDF格式的账单，或者来自使用不同软件的子公司发来的账单，现在他们需要将这些账单转换成XRechnung格式，并离开办公楼去处理。

在了解映射关系之前，需要明白一个关键点：EN 16931 是一种语义模型，它定义了发票必须包含的内容，而不是XML文件的具体格式。有两种语法可以实现这个模型，分别是UBL和CII。符合标准的电子发票可以采用这两种语法中的任何一种，并遵循该标准的规则。因此，不存在名为“EN 16931文件”的文件类型。而是存在基于XML的UBL发票以及符合该标准的CII发票。

XRechnung 格式支持两种语法，因此这两种方式都是实现相同要求的两种有效途径。UBL 规范由 OASIS 免费发布，CII D16B 规范由 UN/CEFACT 发布，您可以使用 MapForce 中的 XML 模式管理器快速安装它们。

以下示例针对的是一种基于XML的UBL电子发票。

我们使用了 MapForce PDF 提取器，用于定义以下规则：从PDF文件中提取数据发票。这会创建一个模板，作为源组件，我们将它映射到目标UBL模式。MapForce会读取模式中的结构，因此目标树会显示该格式所定义的精确元素，而不是一个通用的XML结构。我们已经开始了 Altova AI （这是一个可选的增值订阅服务），它可以自动建立PDF文件和UBL发票XML模式之间的关联，但您也可以手动进行关联。

并非所有目标字段都与源字段存在直接对应关系。有些字段可以直接映射，而另一些则需要进行计算或转换，还有一些值在源数据中根本不存在。

MapForce 包含一个丰富的函数库，可用于处理各种数据转换场景：包括对计算结果进行算术运算和四舍五入，对字符串进行处理，例如重新格式化日期，并将单个地址字段拆分为街道、城市、邮政编码和国家/地区，以及用于处理源数据中未包含的值的常量和查找功能。

一旦映射功能生成了有效的文件，其主要优势在于它能够持续生成这些文件。将其指向下个月的出口数据，转换过程将保持不变。将其编译用于MapForce Server，并使用FlowForce Server进行定时执行，即可在数据到达时自动进行转换并生成发票。

接收电子发票

这种义务是双向的。自2025年1月起，德国要求企业能够接收结构化的电子发票，而从2026年9月起，法国的企业也必须如此。信息传递的方向是单向的：

接收——文件通过您的接入点、PDP（数据包传输网）或国家级平台到达
映射与转换——将接收到的XML数据重新组织成您的ERP系统、数据库或会计系统所期望的格式
导入——将数据写入系统，以便系统能够实际使用这些数据

再次强调，这项工作正是 MapForce 的强项，并且借助 MapForce Server 和 FlowForce Server，整个工作流程可以实现完全自动化。

MapForce 在电子发票领域的具体优势

一个工具，而非针对每个方向分别使用不同的工具。 无论是将数据导出到国家标准格式，导入到您的数据库，还是将一种符合标准的格式转换为另一种符合标准的格式，它们都属于同一种数据映射方式。
任务会按照预定的时间安排到来。 已经保存的配置方案是一种资产，您可以在下一个时间点继续使用，而不是一个需要重复执行的项目。
准确性是设计时就应该考虑的，而不是事后才去发现。 在数据映射过程中，确保字段和代码列表的正确性至关重要，这能避免文件被退回。而被退回的发票意味着付款延迟，以及需要进行人工调查。
数据映射关系可以进行审查。 当审计人员询问某个税额是如何计算出来的时，答案会是一个易于理解的图表。

• 它运行在您自己的基础设施上。 账单包含商业和个人数据。MapForce 在您的计算机上处理这些数据，而 MapForce Server 和 FlowForce Server 则运行在您控制的服务器上。

尝试在您自己的发票数据上进行测试

最快的方法是选择一个实际的出口单据和一个目标数据结构，然后进行映射。如果这种转换方法在一个单据上能够正常工作，那么它就能适用于整个批次的数据。

您可以下载 MapForce 的免费 30 天试用版，以便开始使用。