E-Invoicing & E-Reporting Explained: ZUGFeRD Invoices in Germany

1. Introduction: ZUGFeRD – The Hybrid E-Invoice Standard

ZUGFeRD (Zentraler User Guide des Forums elektronische Rechnung Deutschland) is a pivotal hybrid electronic invoicing format that integrates a human-readable PDF with machine-readable structured data (XML) within a single file. Co-developed by Germany and France (where it is known as Factur-X), it aligns with the European e-invoicing standard EN 16931 and EU Directive 2014/55/EU.

Its core purpose is to “bridge the gap between traditional PDF invoices and pure electronic data interchange (EDI),” allowing companies to modernize invoicing without forcing all trading partners onto complex new platforms. It serves both the business need for a familiar visual document and the automation/compliance need for structured data.

2. Core Definition, Purpose, and Historical Context

• Definition & Purpose: ZUGFeRD is a “cross-industry hybrid e-invoice format” consisting of a PDF/A-3 file (for human readability) and an embedded XML file (for IT systems). This dual format enables “recipients who are not ready for full automation can still read the PDF, while those with automated systems can process the XML data directly.” It aims to drive e-invoicing adoption by simplifying the transition for businesses, especially SMEs.
• Historical Background: Initiated in Germany around 2010-2014, ZUGFeRD 1.0 introduced the PDF+XML concept. Following the EU Directive 2014/55/EU and the creation of EN 16931 (2017), Germany and France collaborated to develop Factur-X (equivalent to ZUGFeRD 2.0+), aligning it with the EU standard.
• Relationship to Factur-X: ZUGFeRD and Factur-X are “two names for the same standard,” unified since version 2.1. Factur-X is the French branding, while ZUGFeRD is used in Germany and internationally. Both follow EN 16931 and the UN/CEFACT Cross Industry Invoice (CII) data model.

3. Technical Architecture: PDF + Embedded XML

The foundational concept of ZUGFeRD is its hybrid nature, leveraging the PDF/A-3 standard (ISO 19005-3) to embed an XML file within a visual PDF document.

• Hybrid Invoice Concept: A ZUGFeRD invoice is a “PDF/A-3 document with an embedded XML attachment… labeled as invoice data.” This allows for immediate human readability via the PDF, while software can extract the structured XML data from the same file.
• Role of PDF (PDF/A-3): The PDF provides the “legally relevant readable representation of the invoice.” PDF/A-3 ensures long-term preservation of the visual layout, critical for compliance with record-keeping rules. It’s what humans refer to and can be digitally signed for authenticity and integrity.
• Role of Embedded XML: The XML file (e.g., factur-x.xml) contains “structured invoice data in a standardized format,” based on the UN/CEFACT CII schema, one of the official syntaxes of EN 16931. It includes all key data points (buyer, seller, amounts, line items) for machine processing.
• Interaction and Conflict: The PDF and XML are “two views of the same invoice information” and are meant to mirror each other exactly. A crucial point: “In a well-implemented ZUGFeRD process, there should never be a conflict between the PDF and XML content.” Any discrepancy “creates ambiguity” and “would likely render the invoice non-compliant,” as “consistency is required by the standards and tax rules.”
• Validation & Integrity Controls: The standard provides validation artifacts (XML schemas, Schematron rules) to ensure technical soundness and arithmetic correctness. Digital signatures can further guarantee the file’s integrity and authenticity.

4. Relationship with EN 16931 and Profiles

ZUGFeRD 2.x (and Factur-X) is fully aligned with EN 16931, the EU standard for e-invoicing. This alignment is critical for pan-European acceptance and B2G (Business-to-Government) invoicing.

• Compatibility with EN 16931: ZUGFeRD 2.1 and above are “explicitly compatible with EN 16931,” including all mandated data fields and business rules. Its XML uses the UN/CEFACT CII schema, an approved EN 16931 syntax.
• ZUGFeRD Profiles: To cater to various use cases, ZUGFeRD defines profiles with increasing levels of detail:
  • MINIMUM: Essential information only, not EN 16931-compliant.
  • BASIC WL (without Line items): Header-level data, not EN-compliant for B2G.
  • BASIC: Includes line item data but may omit some rarer EN 16931 elements.
  • EN 16931 (COMFORT): “Includes all core information required by EN 16931,” making it suitable for public-sector invoicing or full B2B compliance.
  • EXTENDED: 100% EN 16931 content plus additional non-mandatory data for complex cases.
  • Compliance Note: Only the EN 16931 and Extended profiles are fully EN 16931-compliant. Smaller profiles “might fail strict compliance because they omit some required elements.”
• Differences vs. Pure EN 16931 XML: While an EN 16931-profile ZUGFeRD invoice contains the “same information as a standard EN 16931 XML file,” the key difference is ZUGFeRD’s inclusion of a human-readable PDF. ZUGFeRD’s XML uses CII syntax, while EN 16931 can also use UBL.
• Consequences for B2G: ZUGFeRD’s EN 16931 compliance means it can be used for B2G. France’s Chorus Pro platform accepts Factur-X. In Germany, the official B2G format is XRechnung (pure XML), but ZUGFeRD 2.2 offers an “XRechnung profile” allowing the generation of conformant XML. The delivery channel (e.g., Peppol network, portal upload) often remains critical for B2G.

5. Data Fields and VAT Compliance

ZUGFeRD/Factur-X invoices include all data expected on a compliant VAT invoice, structured within the XML and mirrored on the PDF.

• • Key Data Categories:Seller and Buyer Identification: Full names, addresses, contact info, and tax identifiers (VAT IDs). “These details are essential for VAT compliance.”
  • Invoice Header Data: Unique invoice number, date, currency, type, payment terms, and document totals (without VAT, total VAT, grand total). Many are “legally required.”
  • Line-Item Details: Item identifiers, product/service descriptions, quantity, unit price, line total, and relevant tax categories/rates.
  • VAT Details: Handled at both line and summary levels, including tax category codes, rates, and amounts. Critically, “ZUGFeRD includes a tax subtotal for each VAT rate category… ensuring that for each distinct tax rate or exemption on the invoice, the total taxable amount and tax amount are clearly stated.” Fields for VAT exemption reasons are also available.
  • Payment and Bank Details: IBAN, BIC, payment methods, and terms (optional but important for operations).
  • References: Purchase Order (PO) numbers, contract numbers, delivery notes, etc., allowing for automated matching.
  • Notes: Free-text fields for general comments or legal declarations.
• Mandatory vs. Optional & VAT Compliance: The EN 16931 profile clearly defines mandatory fields, mapping to legal VAT requirements (e.g., Germany’s §14 UStG). The “structured approach helps ensure VAT compliance” and aids “automated compliance checks.”

6. International Context and E-Invoicing Models

ZUGFeRD’s international use is growing, but it coexists with diverse national and regional e-invoicing models.

• Geographical Use:Germany (ZUGFeRD): Promoted nationally, and officially recognized for mandatory B2B e-invoicing starting 2025/2026 alongside XRechnung.
• France (Factur-X): Accepted on Chorus Pro for B2G since 2020. Designated as one of three permitted formats for the upcoming B2B mandate (2024-2026).
• Cross-Border (Intra-EU): Inherently suitable due to EN 16931 compliance, but acceptance depends on trading partner capabilities and familiarity.
  • Comparison with Other E-Invoicing Models:ZUGFeRD vs. Peppol BIS (Network Model):Format: Peppol BIS is pure XML (UBL), fully machine-readable but not human-readable directly. ZUGFeRD includes a PDF.
  • Transmission: Peppol uses a specialized network via certified access points. ZUGFeRD can be exchanged via ordinary methods (email).
  • Use Cases: Peppol is strong for cross-border B2G/B2B and multinational companies. ZUGFeRD is primarily B2B/B2G in FR/DE.
• Compliance & ViDA: Both are EN 16931-compliant. Peppol offers greater network governance. ZUGFeRD is a “decentralized, business-friendly approach,” while Peppol is “more centralized, network-based.”
  • ZUGFeRD vs. Clearance Models (CTC):Process Flow: Clearance requires government platform validation before delivery to the buyer. ZUGFeRD follows a post-audit model, going direct to buyer.
  • Format & Standards: Clearance models often use proprietary, country-specific formats (e.g., Italy’s FatturaPA, Mexico’s CFDI). ZUGFeRD uses an open, internationally aligned standard.
• Limitations: “In clearance countries, ZUGFeRD would only be used internally or as a supplementary format” and “is not itself a clearance platform or format.” It does not fulfill legal mandates in such regimes.
  • ZUGFeRD vs. Pure Structured XML (Without PDF):Human Readability: Pure XML/EDI is not human-readable without rendering. ZUGFeRD’s PDF provides immediate readability.
  • Automation: Both enable high automation. ZUGFeRD’s PDF does not inhibit automation but adds a human-friendly layer.
• Business Impact: ZUGFeRD is a “transition technology,” lowering barriers for SMEs and diverse supply chains. Pure XML works best when all parties are technologically ready.

VAT in the Digital Age (ViDA): ZUGFeRD, as an EN 16931-compliant format, “positions companies well for structured data requirements,” aligning with ViDA’s push for mandatory e-invoicing and digital reporting across the EU.

7. Legal and VAT Implications

ZUGFeRD, when properly implemented, fully supports legal VAT compliance by addressing the three pillars of e-invoicing.

• Authenticity of Origin: Verifiable supplier identity. Achieved via digital signatures on the PDF/A-3, secure transmission channels (EDI), or “business process controls.” ZUGFeRD itself “doesn’t mandate a specific method of authentication.”
• Integrity of Content: Ensuring content is unaltered. PDF/A-3 standard and digital signatures provide tamper evidence. Validation rules (Schematron) verify data consistency. “Companies should treat the XML and PDF as a single indivisible record.”
• Readability: The PDF component guarantees that the invoice “can be rendered or printed just like any conventional invoice,” addressing legal requirements for human readability and facilitating audits.
• Storage and Archiving: Critical legal obligation to store electronic invoices in their original format for retention periods (typically 6-10 years). “For ZUGFeRD invoices, this means you should archive the actual PDF file with the embedded XML intact.” Printing is insufficient.
• Evidence Value in VAT Audits: A properly stored and unaltered ZUGFeRD invoice is “as legally valid as a paper invoice.” The structured data “can actually enhance auditability” by allowing authorities to verify sums and compliance automatically.
  • Risk Areas and Common Misconceptions:”ZUGFeRD is automatically compliant”: Compliance requires proper implementation of tax regulations and controls.
  • “If the PDF looks right, the invoice is fine”: Critical to ensure XML matches PDF. Discrepancies can invalidate the invoice.
  • “Print and archive like paper”: Violates electronic archiving laws; the electronic file must be retained.
  • “ZUGFeRD fulfills all mandates”: Not a substitute for clearance models or specific local mandates. Always check local laws.
  • “ZUGFeRD’s PDF is digitally signed”: Signature is optional and separate from the format; don’t assume its presence.

8. Practical Implementation Considerations

Successful ZUGFeRD implementation requires a holistic approach encompassing technology, partner engagement, and governance.

• ERP and Billing System Implications: Systems must support PDF/A-3 + XML output. Upgrades, plugins, or third-party solutions may be needed. Ensure compatibility with the latest ZUGFeRD versions and plan for ongoing updates.
• Supplier Onboarding: For receiving ZUGFeRD, educate suppliers on capabilities and preferences, providing clear guidelines on required profiles and data. Be prepared to support less-technical suppliers (e.g., offering free tools or web forms).
• Customer Acceptance Challenges: For sending ZUGFeRD, customers can use the PDF even if not ready for XML automation. However, be flexible and ready to support other formats or channels if customers have specific requirements (e.g., portals, different profiles).
• Validation Tools: Utilize tools (e.g., Mustang library, FNFE-MPE online validator) to ensure invoices are “correct and compliant before they are sent or accepted,” catching errors like missing fields or calculation discrepancies.
• Governance and Controls: Update internal policies, integrate ZUGFeRD into workflows, manage digital certificates (if used), and monitor e-invoice processing success. Assign responsibility for staying current with standards and legal changes.
• Scalability in a Multinational Environment: ZUGFeRD is part of a broader e-invoicing strategy. Multinational companies often need to support multiple formats (ZUGFeRD, Peppol, FatturaPA, local clearance formats). Middleware or service providers can facilitate conversions and routing.
• Supplier/Customer Support and Change Management: Train staff (AR, AP, IT) on ZUGFeRD processes. Pilot implementation with a subset of partners and collect feedback. Plan for exceptions (e.g., non-ZUGFeRD invoices) during transition.

In conclusion, ZUGFeRD offers a pragmatic and robust solution for electronic invoicing, particularly in Germany and France, by balancing human readability with machine processability. Its alignment with EN 16931 positions companies well for evolving EU e-invoicing mandates, including ViDA. However, successful adoption hinges on careful implementation, ongoing validation, and a strategic understanding of its role within a diverse international e-invoicing landscape.

---

Article

ZUGFeRD Invoices Explained: A Comprehensive Guide for CFOs and Compliance Leaders

Introduction: ZUGFeRD (short for Zentraler User Guide des Forums elektronische Rechnung Deutschland) is a hybrid electronic invoicing format that combines a human-readable PDF invoice with machine-readable structured data (XML) in one file. Developed in Germany’s Forum for Electronic Invoicing (FeRD) with support from French counterparts, ZUGFeRD (known in France as Factur-X) aligns with the European e-invoicing standard EN 16931 and EU Directive 2014/55/EU. The following sections provide an end-to-end explanation of ZUGFeRD invoices – from definition and technical design to legal compliance and practical implementation – with a focus on accurate, up-to-date, and implementation-oriented details. Each section begins with a brief executive summary, followed by practical insights. [stripe.com], [invoicenavigator.eu] [ferd-net.de], [fnfe-mpe.org]

1. What Is a ZUGFeRD Invoice?

Executive Summary: ZUGFeRD is a standardized electronic invoice format that embeds structured data (XML) within a PDF document, making invoices both human-readable and machine-processable. Originating in Germany and developed in collaboration with France (Factur-X), it was created to meet business needs for efficient invoice exchange and processing while complying with European legal requirements for e-invoicing. [ferd-net.de], [invoicenavigator.eu]

Definition & Purpose: ZUGFeRD (the “Central User Guide of the Electronic Invoicing Forum Germany”) is a cross-industry hybrid e-invoice format. It consists of a PDF/A-3 file (which serves as the visual invoice for humans) with an embedded XML file (which contains the structured invoice data for IT systems). The combined file can be opened like a regular PDF invoice by people, but software can extract the XML to automate accounting entries. This dual format was designed to bridge the gap between traditional PDF invoices and pure electronic data interchange (EDI). It allows companies to modernize their invoicing processes without forcing all trading partners onto complex new platforms – recipients who are not ready for full automation can still read the PDF, while those with automated systems can process the XML data directly. [stripe.com] [stripe.com], [invoicenavigator.eu]

Historical Background: The ZUGFeRD initiative began in Germany with FeRD around 2010–2014, in response to growing interest in digital invoicing. ZUGFeRD 1.0 was released in 2014 as a national format, introducing the PDF+XML hybrid concept. In parallel, the EU adopted Directive 2014/55/EU on e-invoicing in public procurement, leading to the creation of EN 16931 (European Norm 16931) in 2017 as a common semantic data model for e-invoices. To harmonize standards, German and French authorities collaborated from 2015 onwards on a Franco-German hybrid format known as Factur-X in France and ZUGFeRD 2.0 in Germany. Factur-X 1.0 (equivalent to ZUGFeRD 2.0) was released in 2017–2018 as the first implementation of EN 16931’s core model in a hybrid PDF/XML invoice. Subsequent versions have expanded features and ensured compliance with the evolving standards: [stripe.com] [fnfe-mpe.org] [fnfe-mpe.org], [fnfe-mpe.org]

[stripe.com], [fnfe-mpe.org], [blog.seeburger.com], [fnfe-mpe.org], [zugferd.org]

Relationship to Factur‑X: ZUGFeRD and Factur-X are two names for the same standard. Since version 2.1, the specifications have been unified so that a ZUGFeRD 2.x invoice is identical to a Factur-X 1.x invoice. The format was co-developed by Germany and France to serve both markets – a true example of cross-border standardization. “Factur-X” is simply the French branding, used in contexts like France’s Chorus Pro platform, while “ZUGFeRD” is used in Germany and internationally. Both follow EN 16931 and the UN/CEFACT Cross Industry Invoice (CII) data model, with five defined profiles (from MINIMUM to EXTENDED) that vary the level of detail (see Section 4). The existence of ZUGFeRD/Factur-X underscores a key concept: hybrid invoicing, which aims to satisfy business needs (easy visual handling via PDF) and tax or automation needs (structured data for electronic processing) in one document. [fnfe-mpe.org], [fnfe-mpe.org] [fnfe-mpe.org], [fnfe-mpe.org]

Why ZUGFeRD Exists (Business vs. Tax Authority Needs): Traditional invoicing via paper or PDF meets the business need for a human-readable document but lacks structured data for automation. On the other hand, pure XML or EDI invoices meet the automation and tax compliance needs but are not human-friendly and often require specialized transmission channels or prior agreements. ZUGFeRD was created to offer the best of both: businesses get a familiar PDF invoice that can be emailed or stored, and simultaneously tax authorities or accounting systems get a compliant dataset aligned with legal requirements. In essence, ZUGFeRD exists to drive e-invoicing adoption by making it easy for companies (especially SMEs) to transition from manual invoicing to digital processes without alienating trading partners or requiring immediate use of centralized clearance platforms. It addresses both operational efficiency (through automation) and compliance (through standardized content), acting as a bridge between purely business-driven invoice exchange and government-driven e-invoice mandates. [stripe.com], [invoicenavigator.eu] [fnfe-mpe.org], [fnfe-mpe.org]

2. How a ZUGFeRD Invoice Works in Practice

Executive Summary: In practice, a ZUGFeRD invoice is created by the supplier’s billing system as a PDF/A-3 file with embedded XML data, sent via standard channels (such as email or EDI networks) to the customer. The customer can simply view the PDF for manual processing or extract the XML for automated booking in their accounting system. Tax authorities are generally not in the loop for B2B/B2C exchanges – ZUGFeRD operates on a post-audit model, meaning invoices are exchanged directly between supplier and buyer, and only made available to authorities if required (e.g. during tax audits). This contrasts with “clearance” systems where invoices go through government platforms in real time. [stripe.com]

Supplier’s Perspective – Issuing a ZUGFeRD Invoice: The supplier prepares an invoice in their ERP or invoicing software as usual, including all required fields (as detailed in Section 5). At the point of output, the system generates a PDF/A-3 invoice and attaches an XML file with the same invoice data inside the PDF container. The PDF portion looks like a standard invoice that can be printed or viewed on screen, while the XML portion is typically named something like “factur-x.xml” or “zugferd-invoice.xml” and isn’t visible on the printed page. This hybrid invoice file is then sent to the customer via the normal delivery method – often email (as an attachment) or through an EDI/business network. No special delivery infrastructure is strictly required; ZUGFeRD files can be exchanged just like PDFs. [zugferd.org]

Customer’s Perspective – Receiving & Processing: Upon receiving a ZUGFeRD invoice, the customer’s accounts payable (AP) team can open the PDF and immediately read the invoice as they would any PDF invoice. If the customer has an automated solution (such as an AP automation tool, an ERP module, or a custom script) that recognizes ZUGFeRD/Factur-X, the system can detect the embedded XML (some PDF readers show a paperclip indicating an attachment) and extract the structured data. This data can then be imported directly into the accounting or ERP system, populating fields like invoice number, dates, line items, amounts, and tax details automatically. This eliminates manual data entry, reducing errors and speeding up processing. If the customer does not have such capabilities, they can treat the file just as a regular PDF invoice – the presence of XML does not hinder traditional processing (the PDF is fully readable/printable on its own). [zugferd.org] [stripe.com]

How Accounting Systems Consume the Invoice: Modern accounting and ERP systems increasingly support the ZUGFeRD/Factur-X standard. For example, solutions from major vendors (SAP, Microsoft Dynamics, etc.) and many e-invoicing service providers can generate or import ZUGFeRD files. These systems parse the XML to retrieve all invoice elements (buyer, seller, tax amounts, line items, etc.) and apply business rules to validate and book the invoice. In many cases, the XML data corresponds to the EN 16931 fields, so it can map directly into the ERP’s invoice database (see Section 5 for field details). This streamlines “straight-through processing” – invoices can be approved and posted with minimal human intervention if they pass validation.

Role of Tax Authorities: Under the ZUGFeRD model, tax authorities do not automatically receive each invoice in real time. The exchange is business-to-business (B2B) or business-to-consumer (B2C), not routed through a government system. This is known as a post-audit system: compliance is ensured by keeping the invoices and relevant data available for tax audits and periodic reporting (e.g. VAT returns or SAF-T submissions) rather than by clearing each invoice through the tax authority upfront. Notably, in B2G (business-to-government) scenarios, if you’re invoicing a public sector client, you usually must follow that government’s mandated format or platform (for example, Germany mandates XRechnung XML for federal invoices, and France requires using its Chorus Pro platform) – ZUGFeRD can support B2G only if adapted to those requirements (see Section 7). [weka.de], [zugferd.org]

Business Exchange vs. Reporting vs. Clearance: It’s important to distinguish ZUGFeRD-based exchanges from other models of e-invoicing:

• Business Exchange (Post-Audit): This is the mode ZUGFeRD was built for. The invoice goes directly from supplier to customer, who then retains it for compliance. Any tax reporting (e.g. VAT returns or listings) is handled separately by summarizing invoice data to authorities. Most of Europe historically followed this model, with e-invoices simply kept and presented on request for audit.
• Real-Time Reporting: Some countries have systems where certain invoice data is reported to tax authorities in real time or near-real-time (e.g. Spain’s SII for VAT, or Hungary’s RTIR). Even in those cases, the invoice exchange between supplier and buyer can still use ZUGFeRD as the medium, while the required data is simultaneously sent to the tax authority through a different channel. ZUGFeRD’s XML makes it feasible to extract and transmit the needed fields to comply with such reporting mandates if integrated properly.
• Clearance Models: In clearance systems, the tax authority (or its platform) is in the loop for every invoice – typically the supplier must submit an invoice to a government portal which approves and forwards it to the buyer (examples include Italy’s SdI for FatturaPA, Turkey’s e-Fatura, many Latin American systems). In these cases, a **ZUGFeRD invoice is not sent directly to the buyer; instead, the official invoice must be in the mandated format (often a specific XML/JSON) and channel. ZUGFeRD is not itself a clearance platform or format – it’s meant for direct exchange. Therefore, in clearance countries, ZUGFeRD would only be used internally or as a supplementary format. For instance, a company in Italy might internally archive a ZUGFeRD copy of each invoice for its own records, but still has to issue the FatturaPA XML through the government portal to have a legally valid invoice. In pure clearance scenarios, the ZUGFeRD PDF/XML file would be considered a “courtesy copy” rather than the official tax invoice.

In summary, ZUGFeRD enables efficient B2B invoice exchange and processing without needing a central platform, but it remains compatible with emerging mandates by adhering to the EU’s standard invoice format. It allows businesses to meet their own and each other’s needs for fast, accurate invoice processing, while keeping the government satisfied through standard-compliant data that can be reported as needed.

3. PDF + Embedded XML: Technical Architecture

Executive Summary: ZUGFeRD is built on a “PDF plus XML” architecture: a PDF/A-3 file acts as a container that holds both a visually formatted invoice and an embedded XML file with the invoice data. This design is often called a “hybrid invoice”. The PDF is the human-readable representation of the invoice, whereas the XML carries structured data following the UN/CEFACT Cross Industry Invoice schema (conforming to EN 16931). The two components are intended to mirror each other’s content exactly. In case of any discrepancy, data integrity is compromised, so robust validation controls are crucial to ensure the PDF and XML match perfectly. [stripe.com] [blog.seeburger.com] [weka.de]

Hybrid Invoice Concept: The key innovation of ZUGFeRD/Factur-X is that it marries a traditional invoice format (PDF) with a data file. This is made possible by the PDF/A-3 standard (ISO 19005-3), which allows embedding arbitrary files into a PDF container. A ZUGFeRD invoice is essentially a PDF/A-3 document with an embedded XML attachment (commonly in UN/CEFACT XML format) labeled as invoice data. When you open a ZUGFeRD file in a standard PDF reader, you see the invoice as a nicely formatted PDF. Behind the scenes, however, the PDF contains an embedded “invoice.xml” file that software can retrieve. There is typically an indication in the PDF metadata (XMP) that it’s a ZUGFeRD/Factur-X invoice, and compatible readers or plugins can flag this (some PDF viewers show a paperclip icon or an attachment list). [stripe.com] [zugferd.org]

Role of the PDF (PDF/A-3): The PDF portion provides the legal readable representation of the invoice. PDF/A-3 is an archival format ensuring that the visual layout, text, and images of the invoice remain intact and accessible for years (critical for compliance with record-keeping rules). The PDF is what a human auditor or recipient can refer to for invoice details like supplier, buyer, line items, totals, etc., presented in a familiar layout. In many cases, the PDF can also be digitally signed (using an electronic signature) to guarantee the authenticity and integrity of the entire invoice file – this is a common practice to meet legal requirements for authenticity of origin and integrity of content in electronic invoicing (see Section 9).

Role of the Embedded XML: The XML file (often named factur-x.xml or zugferd-invoice.xml) contains the structured invoice data in a standardized format. ZUGFeRD’s XML is based on the UN/CEFACT Cross Industry Invoice (CII) schema, which is one of the two official syntaxes of EN 16931. It encapsulates all the key data points of the invoice (buyer, seller, invoice number/date, item details, tax amounts, etc.) in a machine-readable way. Because the XML schema follows EN 16931 semantics, any compliant system can interpret the data consistently. The PDF and XML are not two separate invoices – they are two views of the same invoice information. In a properly formed ZUGFeRD file, every data element on the PDF (e.g. total amount, VAT breakdown) is also present in the XML, and vice versa. The PDF may even be generated from the XML to ensure consistency. [stripe.com], [invoicenavigator.eu] [stripe.com]

Interaction Between PDF and XML: The PDF and XML are attached within one file but remain distinct components – changes to one do not automatically change the other. They are linked by PDF metadata: the PDF’s XMP metadata indicates it is a ZUGFeRD/Factur-X invoice and references the embedded XML file. Some PDF viewing/editing tools can display or extract the XML by accessing attachments. In general, the XML is intended for systems and the PDF for humans; the recipient’s software might pull the XML out for processing, while the PDF is used for human reference if needed. There is no dynamic “sync” between PDF and XML after issuance – they are static once created.

Legally Relevant Version in Case of Conflict: In a well-implemented ZUGFeRD process, there should never be a conflict between the PDF and XML content – they are meant to be identical. In fact, one of the key risks of a hybrid approach is the potential for discrepancies if the process isn’t well-controlled. If a mismatch does occur (for example, a total amount differs between PDF and XML), it creates ambiguity. In practice, this would likely render the invoice non-compliant because it violates the integrity of the invoice’s content. There is no explicit law dictating whether the PDF or XML “wins” in a discrepancy; however, consistency is required by the standards and tax rules. The best practice is to implement strict validation so that the invoice is not issued or accepted unless the two representations agree exactly. Under Germany’s principles of proper accounting (GoBD), for instance, the electronic record of an invoice must faithfully reflect the actual invoicing – if the PDF and XML differ, neither can be considered a true record of the transaction. Therefore, companies should ensure their ZUGFeRD generation tools and receiving systems include checks to prevent or detect any divergence (many solutions will flag or reject an invoice if, say, the sums in the XML don’t equal those displayed on the PDF). [weka.de] [zugferd.org]

Validation & Integrity Controls: The ZUGFeRD/Factur-X standard provides validation artifacts (XML schemas and Schematron rules for business rule checks) for each profile. These can be used to automatically validate that an invoice’s XML complies with the format and passes all core consistency checks (for example, verifying that line item totals add up to the invoice total). Companies implementing ZUGFeRD should use these validators (several open-source and commercial tools are available) to ensure that each generated invoice is technically sound and arithmetically correct. Additionally, if digital signatures are used, signature validation should be done to ensure the file wasn’t tampered with in transit. By combining format validation and optional signing, a ZUGFeRD invoice can achieve a high level of trust and integrity, comparable to other secure e-invoicing methods. [blog.seeburger.com] [traffiqx.net], [traffiqx.net]

4. ZUGFeRD vs EN 16931

Executive Summary: ZUGFeRD 2.x (and Factur‑X) are fully aligned with the European Norm EN 16931, which defines the core data model for e-invoices in the EU. In fact, ZUGFeRD 2.1 (released 2020) was declared “compliant with EN 16931” for use in public procurement across Europe. ZUGFeRD/Factur‑X introduces multiple profiles (Minimum, Basic WL, Basic, EN 16931, Extended) to cover different levels of detail, but only the EN 16931 profile (often called the “COMFORT” or standard profile) guarantees inclusion of all mandatory data elements defined by the EU standard. In practice, ZUGFeRD’s EN 16931 profile produces the same XML data content as a standard EN 16931 XML invoice, just packaged inside a PDF. This means ZUGFeRD invoices can satisfy public procurement (B2G) requirements as long as the correct profile is used, although some government platforms may require pure XML submission (XRechnung or UBL) instead of PDF (see below). [fnfe-mpe.org] [fnfe-mpe.org]

Compatibility with EN 16931: EN 16931-1:2017 is the European standard that lists the core invoice information required for B2G invoices in the EU. ZUGFeRD 2.0+ was built on this foundation. ZUGFeRD 2.1 and above are explicitly compatible with EN 16931, meaning they include all the data fields and business rules that the standard mandates. The ZUGFeRD XML uses the UN/CEFACT Cross Industry Invoice schema, which is one of the two approved syntaxes of EN 16931 (the other being UBL 2.1). Therefore, a ZUGFeRD invoice (when using the appropriate profile) inherently meets the European core invoice content requirements and uses an accepted syntax. For example, if a supplier issues a ZUGFeRD invoice in the “EN 16931” profile, the XML part will contain all mandatory Business Terms (BT-1 through BT-in, etc.) as defined by EN 16931, allowing it to be recognized as a compliant e-invoice in any EU public procurement process. This was a significant improvement over ZUGFeRD 1.0, which was not EN-compliant and therefore not acceptable for B2G invoicing – one reason ZUGFeRD 1.x saw limited official use until the 2.x series was released. [fnfe-mpe.org] [invoicenavigator.eu], [invoicenavigator.eu]

ZUGFeRD Profiles (BASIC, EN 16931/COMFORT, EXTENDED, etc.): To serve different use cases, ZUGFeRD/Factur-X defines a set of profiles which essentially are variants of the format with increasing levels of detail: [fnfe-mpe.org]

• MINIMUM: Contains only the essential information (very limited data, e.g. totals and parties). This corresponds to the bare minimum needed for an invoice, similar to what Chorus Pro’s minimum requirements are in France. It’s meant for micro-businesses or simple transactions, and it is not fully EN 16931-compliant. [fnfe-mpe.org]
• BASIC WL (Basic without Line items): Contains key information at the header level (seller, buyer, totals, taxes) but no line-item details. This might be used for summary invoices or cases where line item breakdown isn’t needed by the buyer. Not EN-compliant for B2G, since EN 16931 requires line item detail. [fnfe-mpe.org], [fnfe-mpe.org]
• BASIC: Contains Basic WL fields plus line item data (item descriptions, quantities, line amounts, etc.). This covers most fields that typical business partners need for automated processing of invoices, but it may omit some of the rarer data elements from EN 16931. (For instance, it might not include all possible tax detail scenarios or reference information.) [fnfe-mpe.org]
• EN 16931 (sometimes called COMFORT): This profile includes all core information required by EN 16931. It is the profile to use for any public-sector invoicing or standard B2B where full compliance is needed. In ZUGFeRD 2.x, this profile guarantees that if you populate all the fields, the invoice will meet the EU standard for content and structure (it’s essentially equivalent to a full XRechnung or Peppol BIS invoice in terms of data). [fnfe-mpe.org]
• EXTENDED: This profile includes 100% of the EN 16931 content plus additional, non-mandatory data for complex business cases. It is designed for sectors or transactions that require more information than the core standard covers. For example, it can include detailed delivery schedule information, multiple taxes or detailed allowance/charge breakdowns, or other supplemental data. The Extended profile is not needed for most invoices – it’s there to support advanced use cases (and as of early 2026, it continues to evolve, with the latest update adding support for sub-item structures like bundles or kits). [fnfe-mpe.org] [fnfe-mpe.org], [blog.seeburger.com]

Crucially, the EN 16931 profile and (by definition) the Extended profile are EN 16931-compliant, while the smaller profiles (Basic, etc.) might fail strict compliance because they omit some required elements. For example, the Basic profiles are suitable for many B2B exchanges but are not sufficient for B2G mandates where all EN 16931 mandatory fields must be present. In fact, major companies have started disallowing the smallest profiles – for instance, Siemens Germany requires that suppliers do not use “MINIMUM” or “BASIC WL” profiles, insisting on full EN-compliant data when sending invoices to them. [fnfe-mpe.org] [siemens.com]

Differences vs. Pure EN 16931 XML (UBL or CII without PDF): In terms of data content, an EN 16931-profile ZUGFeRD invoice contains the same information as a standard EN 16931 XML file in UBL or CII format – there is no difference in the core semantics or mandatory fields. The difference lies in the packaging and usage:

• A pure EN 16931 XML (such as an XRechnung in XML form or a Peppol BIS file) is only machine-readable, whereas ZUGFeRD adds a human-readable PDF copy of that data. This adds a small overhead in file size and a need for PDF software, but offers immediate readability.
• ZUGFeRD is currently limited to the UN/CEFACT CII syntax for the XML, whereas EN 16931 can be implemented in either CII or UBL. This means ZUGFeRD’s structured data will look like a CII file, not a UBL file. In practice this is a minor technical detail; both syntaxes are allowed under EN 16931. [weka.de]

Consequences for Public Procurement (B2G) and Compliance: Because ZUGFeRD’s EN 16931 profile adheres to the EU core standard, it can be used to meet B2G invoicing requirements – in theory, any contracting authority required to accept EN 16931 invoices could accept a ZUGFeRD invoice if they have the means to extract the XML. In France, for example, the government’s Chorus Pro platform has accepted Factur-X (ZUGFeRD) hybrid invoices since 2018 for B2G transactions. In Germany, however, the official B2G format is XRechnung, which is a flavor of EN 16931 in pure XML. German federal platforms historically did not accept PDF files by email; instead, suppliers had to upload an XML (XRechnung) or send via Peppol. To bridge this, ZUGFeRD 2.1.1 introduced the “XRechnung profile”, essentially allowing companies to create a ZUGFeRD file where the embedded XML is an XRechnung-compliant XML, and even send just that XML without PDF if needed. In fact, ZUGFeRD 2.2’s XRechnung profile is a pure XML (no PDF) specifically for German public-sector use. [blog.seeburger.com] [weka.de], [weka.de] [weka.de]

When dealing with public procurement, the key is to use the correct profile and transmission method. For instance, a business can generate an invoice using ZUGFeRD’s EN 16931 profile (or XRechnung profile) to ensure the content is compliant, but they might still need to deliver it via a specific channel (such as uploading to a portal or sending over Peppol network) rather than emailing a PDF, depending on the law. As EU governments standardize e-invoicing, having a format that is EN 16931-compliant (like ZUGFeRD) helps companies reuse the same invoice data for both private and public sector customers, simply changing the delivery method or removing the PDF if necessary. [zugferd.org]

5. Data Fields Included in a ZUGFeRD Invoice

Executive Summary: ZUGFeRD/Factur-X invoices carry all the information you would expect on a compliant VAT invoice, organized into the XML’s structured fields and mirrored on the PDF. Key data groups include Seller and Buyer details, Invoice header information (like dates and totals), Line item details, VAT breakdowns, Payment instructions, Reference documents, and Miscellaneous notes. All VAT-required elements (e.g. invoice date, unique number, supplier’s VAT ID, taxable amounts, tax rates, etc.) are mandatory in the relevant profiles, ensuring the invoice meets tax compliance needs. ZUGFeRD’s EN 16931 profile contains about 130+ standardized data fields (Business Terms BT-1 through BT-BG/BT-***) covering all core invoice information. Lower profiles (Basic/Minimum) use a subset of these fields (with many optional fields omitted), while the Extended profile adds further optional fields for specific use cases. Below is an overview of the main data categories in a typical EN 16931-compliant ZUGFeRD invoice, with notes on mandatory elements and compliance considerations: [traffiqx.net], [traffiqx.net]

• Seller and Buyer Identification: Includes the full name and address of the supplier (seller) and the customer (buyer), and contact information. ZUGFeRD also accommodates tax identifiers for both parties (e.g. the supplier’s VAT registration number, and the buyer’s VAT ID if applicable). In B2B EU invoices, the buyer’s VAT ID is required for cross-border transactions or where reverse charge is applied. These details are essential for VAT compliance – tax laws (e.g. Section 14 UStG in Germany) mandate identification of both parties on every invoice. The XML has dedicated elements for these (e.g., BT-27 Buyer name, BT-40 Seller VAT ID, etc.), and they are marked mandatory in EN 16931. [traffiqx.net], [stripe.com] [traffiqx.net]
• Invoice Header Data: Key invoice-wide information appears both on the PDF and in the XML header. This includes the Invoice number (a unique sequential number), Invoice date, Invoice type (e.g. credit note or debit invoice indicator), Currency code, and sometimes Language code. If relevant, the payment due date and payment terms (e.g. “Payable within 30 days”) are included, usually as optional fields or in the extended profile. Document totals are provided, such as the total invoice amount without VAT, total VAT amount, and grand total with VAT (EN 16931’s BT-109, BT-112, BT-115). Many of these header fields are legally required: for instance, an invoice must have an issue date and unique number, and the total amounts and VAT amounts must be clearly stated for VAT assessment. [traffiqx.net] [traffiqx.net], [traffiqx.net]
• Line-Item Details: ZUGFeRD’s XML contains a section for each invoice line item (under the SupplyChainTradeLineItem in CII XML). For each line, it includes fields like a line item identifier/position number, product or service name/description, quantity and unit of measure, unit price, line total, and relevant tax category and rate for that line. The type of item (goods vs services) can be indicated by dates or references (e.g. a delivery date or service period for each line). The PDF will typically show a table of line items with these details. At least a description of the goods/services, the quantity, and the charge (price) are mandatory parts of an invoice under VAT law, and thus are required in the EN 16931 profile’s line data. ZUGFeRD supports additional line-level fields (especially in Extended profile) like item identifiers or global trade item numbers, commodity codes, origin country, discount or allowance per line, etc., which can be included when needed. [traffiqx.net]
• VAT Details (Tax Rates, Categories, Amounts): A critical part of any invoice is the VAT (or other tax) breakdown. ZUGFeRD handles this at both the line level and summary level. Each line item in the XML carries a tax category code (standard rate, reduced rate, zero, exempt, etc.) and the tax rate percentage applied. The line’s tax amount can be calculated or stated. In the summary section of the invoice, ZUGFeRD includes a tax subtotal for each VAT rate category (e.g. total taxable base and total VAT amount at 20%, 10%, 0%, etc.) as well as the grand total VAT. This corresponds to EN 16931 requirements for BG-23 “VAT breakdown”, ensuring that for each distinct tax rate or exemption on the invoice, the total taxable amount and tax amount are clearly stated. If certain items are tax-exempt or subject to reverse charge, the invoice must include a reference to the legal basis for the exemption – ZUGFeRD provides fields for specifying VAT exemption reason codes or text. For example, an intra-community supply might use a code like “E” and a reference to the EU VAT Directive article. The presence of structured VAT data and codes is crucial for compliance: it ensures that the tax amounts can be automatically validated and that the invoice meets the “content of invoice” requirements of VAT laws (no different from a paper invoice, which must show tax rate and amount or exemption reason). [traffiqx.net]
• Payment and Bank Details: ZUGFeRD can convey payment information such as payment terms, payment due date, and banking details. Typical elements include the seller’s bank account number (IBAN) and bank identifier (e.g., BIC or SWIFT code), the payment method (bank transfer, credit card, direct debit, etc.), and any specific payment terms/discounts (e.g. 2% discount if paid within 10 days). While bank account details and payment terms are not strictly mandated by VAT law, they are operationally important for B2B invoices to facilitate payment. The XML has fields for IBAN (BT-84), payment account holder name, bank name, etc., and for payment terms (due date, late payment penalties, etc.). These are usually optional fields in the standard: companies include them to help the buyer know how to pay and when.
• References (PO Numbers, etc.): Business processes often require referencing other documents. ZUGFeRD supports numerous reference fields: common examples are Purchase Order (PO) numbers or reference IDs (EN 16931 BT-13 is “Purchase Order reference” in the invoice header), contract numbers, sales order or delivery note numbers, customer account numbers, and even reference to preceding invoices or credit notes (for instance, a credit note will reference the original invoice number it relates to). Some references can be mandatory in practice: e.g., many large companies require their PO number to appear on the invoice for acceptance (while not a tax law requirement, it’s often a contractual/business requirement). The EN 16931 model includes fields for these (under “Buyer Reference”, “Project Reference”, etc.), and ZUGFeRD’s XML maps to those (as seen in the Siemens guidelines, which specify the XML paths for PO and other references). In the PDF, these typically appear in the invoice header or in line item descriptions (for line-level references like contract or delivery note per line). Providing these references in structured form allows receivers to automate matching of invoices to orders and goods receipt, speeding up approval. [siemens.com]
• Notes and Additional Information: ZUGFeRD provides flexible sections for any free-text notes or special instructions. For example, there are fields for an invoice note (BT-22) which can carry general comments or legal declarations, and for line-item notes (BT-127) for extra description per line. These can be used to include information like payment instructions, marketing messages, or any legal wording required (such as a note about self-billing, or a statement for tax exemption reason if not using a code). While much of the invoice data is structured, it’s understood that some information may remain unstructured; ZUGFeRD’s design accounts for this by allowing such notes. However, companies should be careful to only put non-critical information in free text notes – if something is required for tax or process purposes, it should go into a structured field when possible (for example, don’t hide the VAT registration number or an invoice total in a textual note; those belong in dedicated fields).

Mandatory vs. Optional & VAT Compliance: The EN 16931 profile of ZUGFeRD clearly defines which fields are mandatory (for compliance) and which are optional. Many fields map to the legal requirements for VAT invoices. For instance, all of the items listed in Germany’s VAT law (§14 UStG) – seller and customer name/address, invoice date, unique invoice number, description/quantity of goods, delivery date, net amount, tax rate, VAT amount, and seller’s VAT ID – are mandatory fields in the standard ZUGFeRD profiles. Other fields like purchase order number, payment due date, or bank details are generally optional (they may be business-required but not tax-required). ZUGFeRD’s conformance to EN 16931 means that if you use the full EN 16931 profile, all the information needed for a VAT-compliant invoice is included and explicitly tagged in the XML. This structured approach helps ensure VAT compliance: for example, the presence of the VAT breakdown with rates and amounts helps demonstrate “accuracy of VAT calculation” to tax authorities, and the inclusion of mandatory identifiers (like VAT IDs and invoice dates/numbers) ensures the invoice meets legal standards for deductibility of VAT. Furthermore, having these elements in a structured format aids automated compliance checks – e.g., verifying that VAT totals match the sum of line taxes, that a VAT ID is valid in format, etc., which reduces errors that could lead to audits or rejected invoices. [traffiqx.net], [stripe.com] [traffiqx.net], [traffiqx.net]

6. Use of ZUGFeRD in an International Context

Executive Summary: ZUGFeRD/Factur-X is primarily used in Germany and France, but as an EN 16931-compliant format it can be used for cross-border invoices across the EU and beyond, provided trading partners agree. It is especially useful in Franco-German trade and is one of the accepted formats in France’s e-invoicing system. However, its adoption outside these core regions remains limited, as some countries have their own mandated formats (e.g., Italy, Poland, many Latin American countries) or prefer network-based standards like Peppol. In clearance or real-time reporting countries, ZUGFeRD is not a substitute for required local formats, though companies might use it for their internal processes or for B2B exchanges alongside fulfilling government mandates. For purely intra-EU B2B transactions, ZUGFeRD can be a convenient compliant format, but its acceptance depends on trading partner capabilities. [invoicenavigator.eu], [invoicenavigator.eu] [fnfe-mpe.org], [fnfe-mpe.org]

Current Geographical Use and Acceptance: Today, ZUGFeRD/Factur-X is most established in Germany and France:

• Germany (ZUGFeRD): ZUGFeRD has been promoted as a national standard for B2B and B2C invoicing. While not historically mandated for private sector, it gained traction as a voluntary format for companies seeking efficiency. Starting from January 2025, Germany is introducing mandatory e-invoicing (phased rollout through 2025–2028), and has formally recognized ZUGFeRD (v2.0 and above) as an acceptable electronic format alongside XRechnung. German businesses will need to be able to receive e-invoices by 2025 and issue them by 2026/27, so ZUGFeRD is expected to see broader use domestically as an officially sanctioned format for B2B. Many German software providers and networks support ZUGFeRD, and early adopters include companies in industries like automotive, manufacturing, and financing. For example, some multinational companies in Germany have begun requiring suppliers to use ZUGFeRD or XRechnung for e-invoicing (Siemens AG’s procurement arm, for instance, adopted a platform in 2025 to handle invoices via these formats). [blog.seeburger.com] [siemens.com], [siemens.com]
• France (Factur-X): France has made electronic invoicing mandatory for B2G (business-to-government) since 2020, and Factur-X (which is the same as ZUGFeRD 2.x) is accepted on the government’s Chorus Pro platform for supplier invoices to the public sector. Looking forward, France’s B2B e-invoicing mandate (the “2024 réforme de la facture électronique”) designates Factur-X as one of the three permitted formats for domestic B2B e-invoice exchange starting 2024 (along with pure UBL and CII XML). This means all French companies and certified platforms must be able to receive Factur-X invoices. As a result, many French software vendors and large companies have implemented Factur-X support. For example, the French government reports that Factur-X is widely implemented by over 100+ service providers and is expected to handle a large share of B2B invoices, especially among SMEs once the mandate is in effect. [fnfe-mpe.org], [fnfe-mpe.org]

Cross-Border (Intra-EU) Use: Since ZUGFeRD/Factur-X conforms to the EU standard, it is inherently suitable for cross-border e-invoicing within the EU. A ZUGFeRD invoice using the EN 16931 profile should contain all information needed by any EU buyer’s system or for VAT purposes in any member state. This makes it a strong candidate for intra-EU B2B invoicing. In practice, however, cross-border e-invoicing in the EU is often facilitated by the Peppol network using the UBL-based BIS 3.0 format (see Section 8). Outside of France/Germany, many European businesses and public administrations are more familiar with pure UBL or local standards than with ZUGFeRD. Nonetheless, nothing prevents two trading partners in different countries from using ZUGFeRD by mutual agreement. For example, a German company could send a ZUGFeRD invoice to a partner in Spain: the Spanish buyer could extract the XML and even convert it to the Spanish format (if needed for local systems), since the data mappings are standardized.

Interoperability with Other National Formats: One challenge in the international use of ZUGFeRD is the variety of national e-invoicing regimes:

• Peppol BIS (used in many countries, especially for cross-border and B2G in Northern Europe) relies on a different approach – a network and a pure XML format. ZUGFeRD invoices are not natively part of Peppol, but the XML data (CII) in a ZUGFeRD file could technically be converted to the Peppol UBL format if necessary. [invoicenavigator.eu], [invoicenavigator.eu]
• Italy (FatturaPA): Italy mandates clearance e-invoicing – all invoices must be sent in a specific XML format (FatturaPA) via the government’s SdI platform. ZUGFeRD is not used for compliance in Italy; an Italian company has to issue FatturaPA XML. However, an Italian business could internally generate a ZUGFeRD version for its archive or even send a ZUGFeRD PDF as a courtesy copy to a customer, but this copy would not replace the official FatturaPA transmitted to the government. Likewise, if a German company uses ZUGFeRD to invoice an Italian customer, that invoice would be treated as a normal B2B invoice from abroad – the Italian buyer would still need to report it to their tax authority via the esterometro (or as of 2022, via FatturaPA) for VAT purposes. Thus, in clearance countries like Italy, ZUGFeRD might be used in B2B exchanges, but it doesn’t fulfill the clearance obligations – additional steps or conversions are required. [invoicenavigator.eu]
• Similar limitations apply in other clearance or real-time reporting countries: e.g., Turkey, Mexico, Brazil, India and others have national e-invoice schemas and clearance portals. A ZUGFeRD invoice would not be accepted by those tax authorities directly. Multinational companies operating in such countries need to comply with local formats (often via local tools or providers) – ZUGFeRD could still be used for internal processes or parallel workflows, but it is generally not the primary invoice format in those jurisdictions due to legal requirements.

Suitability for Extra-EU Invoicing: Outside the EU, ZUGFeRD is not yet a widely known standard, but it has been recognized in some contexts. For example, organizations like the United Nations CEFACT have promoted cross-industry XML standards (like CII) which ZUGFeRD uses. Some countries without strict e-invoicing rules might accept ZUGFeRD invoices simply as PDF invoices. However, adoption in regions like North America or Asia-Pacific has been minimal; those regions often rely on PDFs or other EDI/XML standards (like ANSI X12 in the US) for electronic trade. In summary, ZUGFeRD’s international use is growing but still mainly centered in Europe – it is a strong solution for companies operating in EU countries that allow PDF/XML hybrid invoices (or as a bridge format for conversion), but it must be complemented by other formats in countries with different e-invoicing frameworks.

Limitations in Clearance/CTC Regimes: As noted, ZUGFeRD is not a one-size-fits-all for global compliance. In Continuous Transaction Control (CTC) or clearance systems, where invoices or their data must go to the tax authority in real time (examples: Italy, Poland’s new KSeF in 2026, many Latin American countries, etc.), ZUGFeRD cannot by itself meet the legal mandate. Governments typically stipulate their own format and transmission method. Companies in those jurisdictions might still use ZUGFeRD internally to reap process benefits – for instance, generating a ZUGFeRD invoice for their own records and using the XML to feed the government system – but the actual official invoice that counts for tax purposes will be the one in the mandated format (XML/JSON) that was reported. Moreover, some clearance systems explicitly require electronic signatures or government authentication, which is outside the scope of ZUGFeRD. Therefore, while ZUGFeRD improves B2B exchange, it doesn’t replace compliance steps in such countries. [invoicenavigator.eu]

Interaction with Other EU Standards: ZUGFeRD coexists with other formats like Peppol BIS and XRechnung. In practice, a multinational company might need to support multiple formats: for example, use ZUGFeRD/Factur-X for France and Germany, Peppol BIS (UBL) for countries that prefer or mandate Peppol (e.g., Netherlands, Norway, Austria for B2G, etc.), and FatturaPA for Italy. Fortunately, since these formats share a common semantic model (EN 16931), conversion between them is feasible. Tools exist to translate between CII (as used in ZUGFeRD) and UBL, etc., although sometimes with limitations. [invoicenavigator.eu], [invoicenavigator.eu] [zugferd.org]

In conclusion, ZUGFeRD is most beneficial in countries and contexts that permit direct B2B e-invoicing without a mandated central clearance platform. It shines as a pan-European B2B format when both supplier and buyer agree to use it, and it is particularly significant in the Franco-German market. In strictly controlled e-invoicing jurisdictions, it plays more of a supporting role rather than being the primary compliance format.

7. Interaction with Tax Authorities

Executive Summary: ZUGFeRD invoices are generally not sent directly to tax authorities; they are exchanged between supplier and buyer, with tax authorities accessing them only as needed (e.g., for audits or periodic reporting). In B2B and B2C scenarios, a ZUGFeRD invoice is treated like any other invoice from a tax perspective – the obligation is on the businesses to ensure the invoice meets legal requirements and is stored properly for potential audits. In B2G (Business-to-Government) transactions, or under mandatory e-invoicing regimes, businesses may need to send the invoice’s XML data via official platforms (like XRechnung via Peppol in Germany, or Factur-X via Chorus Pro in France) instead of emailing the PDF. ZUGFeRD supports these use cases through its standardization (EN 16931 compliance and reference profiles) but is itself a format, not a transmission network or government portal. [traffiqx.net], [zugferd.org]

B2B and B2C Use – Post-Audit Compliance: For typical business-to-business invoices, ZUGFeRD does not require any direct tax authority submission at the time of transaction. The supplier sends the invoice to the buyer, and both are responsible for keeping it in their records. Tax authorities are “downstream” consumers of the data: companies will use the information from those invoices in VAT returns and must present the invoices during a tax audit or on request. In the EU’s post-audit control model (applicable in countries without real-time invoice clearance), maintaining the electronic invoice in a tamper-proof archive is crucial for compliance. ZUGFeRD facilitates this by using PDF/A-3 (an archival format) and by allowing digital signatures for authenticity. But importantly, just using ZUGFeRD doesn’t automatically mean the tax authority sees the invoice – there’s no built-in government communication. It’s up to the business to ensure authenticity of origin and integrity of each invoice (through mechanisms like digital signatures or reliable internal controls) and to report taxes accurately from the invoice data. ZUGFeRD’s structured data can help automate VAT reporting, but companies still need appropriate processes or tools to extract and report that data to tax authorities as required (for example, populating VAT return forms or SAF-T files). [zugferd.org]

Use in B2G (Business-to-Government) scenarios: When invoicing public entities, countries typically mandate specific formats and channels. ZUGFeRD/Factur-X was designed to be B2G-capable by conforming to EN 16931, but the actual process depends on national rules:

• In Germany, since 2020 the federal government requires suppliers to send e-invoices (for contracts above €1k) as XRechnung XML via its portals or the Peppol network. A ZUGFeRD invoice with just an emailed PDF would not meet this requirement. However, with ZUGFeRD 2.2’s XRechnung profile, a supplier can generate a file that contains an XRechnung-conformant XML. In practice, the supplier would typically upload that XML (or send via Peppol), rather than the PDF, to the government platform (since the government doesn’t need the PDF). Thus ZUGFeRD can be used as the internal format to produce the necessary XML for B2G. Some regional authorities in Germany have accepted PDF invoices with embedded XML in the past, but the trend is now firmly toward using official XML channels. [zugferd.org], [zugferd.org] [weka.de]
• In France, since 2020 all large suppliers must invoice the public sector via the Chorus Pro platform. Factur-X (ZUGFeRD) is one of the accepted formats on Chorus Pro – the platform can ingest the PDF and parse the embedded XML. This made it convenient for suppliers who were already using Factur-X for B2B to also fulfill B2G obligations. The upcoming French 2024–2026 B2B mandate will similarly route invoices through either a central public platform or certified private platforms, meaning that even B2B invoices will indirectly involve the tax authority (which will receive the data). Factur-X will remain a supported format in this framework, but businesses will likely send the files through the platform network rather than directly via email. Thus, while ZUGFeRD/Factur-X provides the format, the transmission to tax authorities is handled by external systems in the case of B2G or B2B mandates. [fnfe-mpe.org] [fnfe-mpe.org], [fnfe-mpe.org]

B2C Use: Consumer invoices don’t usually fall under e-invoicing mandates, but companies can still use ZUGFeRD for B2C in Germany/France. For example, a utility company could send a ZUGFeRD invoice to a consumer: the consumer will just open the PDF as a normal bill, while the utility’s internal systems can use the XML for reconciliation. There is typically no direct tax authority interaction for B2C invoices beyond normal record-keeping. One point to note is that if a consumer receives an e-invoice (even as a PDF), the business must still ensure compliance with data protection and archiving laws. In practice, many businesses might opt for simpler PDFs for B2C, since the value of structured data is mostly on the recipient side (and consumers don’t have accounting systems to import XML). ZUGFeRD is more impactful in B2B and B2G contexts where the receiver can use the data.

Audits and Post-Audit Controls: Under post-audit regimes (like the current systems in most EU countries), tax auditors often require businesses to present invoices (input and output) for verification of VAT declarations. If you use ZUGFeRD, you must ensure you can still readily provide human-readable invoices to auditors – with ZUGFeRD, the PDF component ensures readability is never an issue (a printed ZUGFeRD PDF looks like a regular invoice). Auditors may also request the electronic file itself to verify its integrity and data. Because ZUGFeRD invoices are typically archived in electronic form, they can be delivered to auditors in digital format, who can then use tools to extract the XML data if they wish to perform automated audits or cross-check calculations. This can actually facilitate audits: for example, an auditor could run a tool across a sample of ZUGFeRD invoices to verify that tax amounts were correctly calculated and reported. From a legal standpoint, ZUGFeRD invoices meet the requirements of authenticity, integrity, and readability as long as proper procedures are in place. Authenticity and integrity are ensured either by business controls or by digital signatures (ZUGFeRD doesn’t mandate a specific method, leaving it to companies to choose how to comply with their country’s rules, such as Germany’s GoBD or France’s archiving laws). Readability is inherently provided by the PDF/A-3 component.

Differences vs Clearance/CTC Models: In contrast, in clearance or Continuous Transaction Control (CTC) systems, tax authorities receive invoice data in real time, often even before the buyer does. ZUGFeRD does not operate this way. Therefore, if you’re in a country with a clearance model, using ZUGFeRD alone will not fulfill your obligation to report or clear invoices with the government. You would need to send the required data through the official channel in the mandated format. For instance, in India, e-invoices must be generated through the government portal (which returns a signed JSON and QR code); an Indian supplier could still produce a ZUGFeRD invoice for their own use, but that PDF/XML would be supplementary and not the regulatory invoice. Companies must be careful not to assume that just because they use ZUGFeRD, they’ve met all compliance needs in every jurisdiction – always align with local e-invoicing laws. That said, in countries moving from post-audit to clearance models, ZUGFeRD can serve as an internal format feeding into the clearance system or as the format for any parallel B2B exchange outside the government system.

8. ZUGFeRD vs Other E‑Invoicing Models

Executive Summary: ZUGFeRD/Factur-X’s hybrid approach can be contrasted with other prominent e-invoicing models: (a) the Peppol BIS cross-border network model, (b) clearance models as seen in countries like Italy or Mexico, and (c) purely structured XML/EDI invoices without human-readable content. Each model has its strengths and weaknesses: ZUGFeRD’s strength is its flexibility and ease of adoption (because of the PDF), whereas network and clearance models can offer greater control or automation but require more complex infrastructure. From a business perspective, ZUGFeRD is user-friendly for both senders and receivers. From a compliance and control perspective, clearance models provide real-time oversight to tax authorities. In terms of automation, pure structured formats (like Peppol’s UBL over networks, or clearance systems) can achieve end-to-end automation but may exclude those without technical capability – whereas ZUGFeRD offers a balanced solution to enable automation while maintaining human readability. Considering VAT in the Digital Age (ViDA), which pushes for mandatory e-invoicing across the EU, ZUGFeRD (as an EN 16931-compliant format) positions companies well for structured data requirements, but additional mechanisms may be needed for real-time reporting to authorities. [invoicenavigator.eu], [invoicenavigator.eu]

8.1. ZUGFeRD vs. Peppol BIS (Network Model): Peppol is both a set of e-invoicing standards (the BIS 3.0 format based on UBL) and an international delivery network. It contrasts with ZUGFeRD in several ways:

• Format: Peppol BIS invoices are pure XML (UBL) without any PDF. This means they are fully machine-readable but not directly human-readable without a viewer or conversion. ZUGFeRD includes a PDF, so it’s immediately human-friendly. [invoicenavigator.eu]
• Transmission: Peppol requires connecting through certified access points on a network that routes invoices between senders and receivers globally. ZUGFeRD, in contrast, can be exchanged via ordinary methods (email, etc.) without a specialized network. While Peppol ensures secure delivery and interoperability across borders, it may require onboarding to a service provider or network – a potential barrier for some smaller companies. ZUGFeRD’s ease of use (just sending a PDF file) can be simpler for businesses that do not want to invest in new transmission infrastructure.
• Primary Use Cases: Peppol BIS is widely used for B2G e-invoicing in the EU and increasingly for B2B in cross-border situations; it’s mandated or encouraged in many countries for public procurement and preferred for multinational companies dealing with many trading partners. ZUGFeRD is primarily used in B2B contexts (and also B2G in FR/DE) where a hybrid approach is beneficial. For cross-border trade, Peppol’s broad adoption in ~30 countries makes it a strong choice, but ZUGFeRD can still be used especially when one party is in Germany/France or both agree on it. [invoicenavigator.eu], [invoicenavigator.eu]
• Business Impact: From a business perspective, ZUGFeRD offers more flexibility for recipients who may not be technically ready – they see a familiar PDF. Peppol, however, can deliver the invoice straight into the recipient’s system if they are connected, providing a fully automated end-to-end flow. The choice may come down to trading partner preferences: many multinational companies support both methods. In fact, Germany’s e-invoicing guidance allows either EN 16931 UBL (Peppol/XRechnung) or ZUGFeRD’s CII for B2B/B2G, giving flexibility. [zugferd.org]
• Compliance & ViDA: Both formats are EN 16931-compliant, so they meet European invoice content rules. Peppol’s model inherently provides an additional layer of security and governance because the network can ensure only authorized, validated invoices are exchanged (and trace their delivery). ZUGFeRD relies on the trading partners’ own controls, though it can be just as compliant if managed properly. Under the upcoming ViDA rules (which aim for pan-EU e-invoicing and reporting), both Peppol and ZUGFeRD are expected to play roles. Peppol is a likely backbone for transmitting invoices or VAT reports cross-border. ZUGFeRD’s compliance with EN 16931 means that invoices in this format contain all required data for Digital Reporting, but companies might still need to send that data to tax authorities in real-time. In summary, ZUGFeRD is a more decentralized, business-friendly approach, while Peppol is a more centralized, network-based approach to achieving similar goals of electronic invoice exchange and automation.

8.2. ZUGFeRD vs. Clearance Models: Clearance e-invoicing models (also known as Continuous Transaction Controls) are those where the tax authority is an intermediary in the invoicing process. Examples: Italy’s SdI system for FatturaPA, Turkey’s e-Fatura, Mexico’s CFDI, Brazil’s NF-e, upcoming Poland KSeF, etc. Key differences:

• Process Flow: In clearance systems, the supplier must transmit the invoice (or its data) to a government platform first, which validates and sometimes stamps it with an authorization code. Only then is the invoice delivered to the buyer (either by the platform or by the supplier after clearance). With ZUGFeRD (post-audit model), the invoice goes straight to the buyer, and the tax authority might see it only later (or not at all, aside from VAT return data).
• Format & Standards: Clearance models often use proprietary or country-specific formats (for instance, Italy’s FatturaPA XML is an older national standard not aligned with EN 16931, and Mexico’s CFDI is an XML specific to their requirements). ZUGFeRD’s format is an open standard aligned with an international model (CII/EN 16931) and isn’t tied to one country’s platform. This means ZUGFeRD is more globally interoperable in theory, but it’s not directly accepted into these clearance platforms without conversion. [invoicenavigator.eu]
• Business Impact: Clearance systems significantly alter the invoicing process and often require investment in integration with government systems or using service providers. They offer governments timely data to fight tax fraud, but for businesses they can introduce complexity, potential delays, and dependency on the government’s IT infrastructure. ZUGFeRD was created largely as a response against moving to full clearance in environments like Germany – it aims to improve efficiency without government intervention in every transaction. For businesses, ZUGFeRD might be seen as lower overhead (no need to maintain continuous connections to authorities) and more in line with traditional processes (send invoice to your customer as you normally would, just in a better format). On the other hand, clearance provides assurance that the invoice is tax-authorized, which can simplify compliance in high-VAT-fraud environments.
• Compliance & Control: In clearance regimes, compliance is enforced by the tax authority in real time (invoices not cleared by the platform are not legal). This virtually guarantees authenticity and integrity (since the government often digitally signs the cleared invoice) and gives tax authorities immediate access to data. ZUGFeRD relies on companies’ own compliance controls and later audits – which requires trust that companies implement things correctly. Countries with serious VAT fraud issues tend to prefer clearance for this reason. However, as the EU moves towards Digital Reporting Requirements (DRR) under ViDA, even traditionally post-audit countries like Germany and France are introducing some real-time reporting (e.g., sending data to tax authorities right after invoice issuance). In such a future, a ZUGFeRD invoice could be used for the business exchange, while an automated “submission” of its data to a tax portal happens in parallel. This hybrid approach may become common: ZUGFeRD for the invoice itself, plus a separate channel to report the data to tax – combining the business-friendly nature of ZUGFeRD with the compliance of clearance.

8.3. ZUGFeRD vs. Pure Structured XML (Without PDF): Long before ZUGFeRD, many companies (especially large multinationals) exchanged invoices purely as structured data – examples include XML invoices (cXML, UBL, etc.) or traditional EDI (EDIFACT). These contain no human-readable part; the sender transmits data from system to system, and usually the receiver uses an automated process or a service provider to translate that data into a readable format if needed. Key points of comparison:

• Human Readability: The obvious difference is that a pure XML or EDI invoice is not human-readable in its raw form. It must be rendered by software to be understood by people. This is fine in environments where all players have compatible systems (e.g., automotive or retail supply chains using EDI for decades). ZUGFeRD’s inclusion of a PDF means that even smaller business partners or auditors can easily read the invoice without special tools – a significant advantage in heterogeneous markets.
• Automation: Both pure XML and ZUGFeRD’s XML enable high levels of automation. In fact, ZUGFeRD’s XML content can be just as rich as any standalone XML invoice (especially in the EN 16931 or Extended profiles). One advantage of pure XML is a slightly simpler technical workflow – one file to handle, rather than a PDF container – and no risk of discrepancy between dual components. On the other hand, the presence of PDF in ZUGFeRD does not inhibit automation; it simply adds a parallel human-friendly layer. In practice, if a company is capable of sending and receiving pure XML invoices with all trading partners, ZUGFeRD’s benefit diminishes. But that scenario is rare outside of structured EDI networks.
• Business Considerations: ZUGFeRD is often described as a transition technology: it allows companies to move toward fully structured invoicing without stranding business partners who aren’t there yet. A pure XML approach works best when both supplier and buyer (and their systems) are ready for it. If not, the sender might send XML that the receiver cannot easily use – leading to fallback to PDFs, defeats the purpose. Therefore, ZUGFeRD’s hybrid approach can accelerate digital adoption by lowering barriers. It’s particularly helpful for SMEs who may lack EDI capabilities; they can send a ZUGFeRD invoice via email and know that large customers can process the XML, while small customers can open the PDF. In contrast, a purely structured invoice often requires sending via web portals or forcing the buyer to use specific import tools.
• ViDA and the Future: The EU’s goal under VAT in the Digital Age is to make structured e-invoices the default for tax purposes. In the long run, one can envision a move towards purely structured invoices across the board, possibly with EU-wide interoperability (e.g., using Peppol or similar networks). In that world, pure XML/EDI will be the norm, potentially making the PDF component less necessary. However, given the diversity of company sizes and digital maturity, hybrid models like ZUGFeRD will likely remain relevant during the transition. They ensure that even as we mandate structured data, we don’t lose the simplicity of a PDF for end-users. Therefore, ZUGFeRD can be seen as a pragmatic solution fitting into the ViDA vision by providing EN 16931 data now, while still easing the user experience. In a fully realized CTC/real-time reporting future, ZUGFeRD might evolve (or be used in tandem with reporting systems) to continue serving businesses that need a human-readable invoice copy.

Strengths & Weaknesses Summary: From a business perspective, ZUGFeRD’s major strength is its versatility and ease of adoption – it works with simple technologies (email, PDF readers) and doesn’t force trading partners onto new portals, making it easier to roll out across a diverse supply chain. Its weakness in comparison to other models is that it doesn’t inherently provide a delivery network or tax clearance – those need separate solutions if required. From a compliance perspective, ZUGFeRD meets content requirements (EN 16931 compliance), but clearance models have the edge in satisfying tax authorities’ real-time reporting needs. From an automation standpoint, ZUGFeRD and pure XML are similar (since ZUGFeRD is a structured XML invoice at its core) – both enable high automation; however, purely structured invoices and Peppol networks might achieve a more seamless integration in fully digitized environments, while ZUGFeRD offers a mix of automation with manual fallback. In terms of ViDA readiness, any EN 16931-compliant format – whether ZUGFeRD, UBL/Peppol, or CTC-compliant XML – will help companies prepare for the upcoming changes. Notably, ZUGFeRD/Factur-X is explicitly designed to comply with the EU’s definition of an electronic invoice (structured data, not just image) which aligns with ViDA’s direction. Companies using ZUGFeRD are positioning themselves to meet future requirements, though they should stay attentive to potential needs for connecting with government systems as digital compliance evolves. [invoicenavigator.eu], [invoicenavigator.eu] [eclear.com], [eclear.com]

9. Legal and VAT Implications

Executive Summary: Using ZUGFeRD does not exempt companies from standard VAT invoice requirements – rather, it provides a robust way to meet them, as long as proper controls are in place. Authenticity of origin, integrity of content, and readability are the three pillars of EU (and local) e-invoice law, all of which can be satisfied with ZUGFeRD: Authenticity can be ensured via digital signatures or secure transmission, integrity is supported by the standardized format and optional encryption/signature, and readability is guaranteed by the PDF/A-3 visual layer. Electronic archiving and auditability are crucial: a ZUGFeRD invoice should be stored in its original electronic form (not just printed) to retain legal value. When implemented correctly, ZUGFeRD invoices hold the same evidentiary value in VAT audits as traditional invoices, with the added benefit of structured data for verification. Common pitfalls to avoid include failing to maintain the electronic originals, neglecting to ensure the PDF and XML contents match, or assuming that ZUGFeRD alone fulfills all compliance obligations in jurisdictions that have additional e-invoicing mandates. [zugferd.org]

Authenticity of Origin: Tax regulations require that an invoice’s origin (i.e., the identity of the supplier) is verifiable and trustworthy. In a paper world, this might be ensured by the company’s letterhead or stamp; in e-invoicing, typical solutions include using digital signatures or secure transmission channels. ZUGFeRD invoices can be digitally signed at the PDF level, which effectively covers the entire content (including the embedded XML) with a tamper-evident seal. Alternatively, businesses might ensure authenticity through EDI agreements or via sending invoices through secure, controlled systems (for example, an EDI network or a secure email system). It’s important to note that ZUGFeRD as a format doesn’t mandate a specific method of authentication – it provides the container for the data, but companies must decide how to secure it. In Germany, the GoBD guidelines allow relying on business process controls to ensure authenticity and integrity, rather than requiring a digital signature. This means if your procurement and accounting processes are well-documented and prevent unauthorized invoice manipulation, that can suffice. Each company should document how they ensure that only valid invoices (from real suppliers) enter their system – whether by using technical measures (signatures, EDI, or platform controls) or process measures (manual verification steps). ZUGFeRD can accommodate these methods (e.g., you can apply an electronic signature to the PDF/A-3 file if desired), but it’s up to you to implement them. [zugferd.org]

Integrity of Content: The requirement for integrity means the invoice content must not be altered undetectably. With ZUGFeRD, integrity is supported by the format and potential use of signatures. The PDF/A-3 standard ensures the file is self-contained (embedded files and data are part of the PDF structure), and if a digital signature is applied to the PDF, any change to either the visible content or the embedded XML would break the signature. Even without a digital signature, a robust implementation will include hashing and validation of the XML data. The ZUGFeRD/Factur-X standard provides official Schematron rules and XML schemas to validate that the data is consistent (ensuring, for instance, totals in the XML are correct and match line items). Many software solutions (like the open-source Mustangproject or others) offer built-in validation to check the invoice’s consistency and conformity. From a compliance standpoint, companies should treat the XML and PDF as a single indivisible record – you should archive the ZUGFeRD file exactly as issued/received, and avoid any post-issuance modifications. If an error is found, the correct approach is to issue a credit note or corrected invoice rather than trying to edit the XML or PDF after the fact. Maintaining integrity also means ensuring the PDF and XML are synchronized at issuance (as noted earlier, a mismatch between them would violate integrity and could lead to rejection of the invoice in an e-invoicing system or questions in an audit). [traffiqx.net], [traffiqx.net] [weka.de], [traffiqx.net]

Readability: One of the fears around e-invoicing is losing the human-readable form of the invoice. ZUGFeRD directly addresses this by keeping a PDF representation as part of the invoice file. The PDF can be rendered or printed just like any conventional invoice, preserving the familiar look and content. This is important for practical reasons (e.g., a human can easily verify details, or a small trader can use the invoice without special software) and for legal ones. EU member states often have rules about invoices being “readable” and sometimes require that the human-readable and machine-readable content correspond. As discussed, in ZUGFeRD the PDF is the legally relevant representation that humans rely on, and because it’s PDF/A-3, it’s suited for long-term archiving (ensuring that even years later, the invoice can be opened exactly as originally seen). It’s wise for senders to design the PDF layout clearly (some even include a Factur-X/ZUGFeRD logo on the PDF to signal the format, though not required). In the event of an audit or dispute, having that PDF means you can show the invoice in an immediately understandable form. [fnfe-mpe.org]

Storage and Archiving Requirements: A critical legal obligation is that electronic invoices must be stored in their original format for the required retention period (typically 6 to 10 years, depending on country). For ZUGFeRD invoices, this means you should archive the actual PDF file with the embedded XML intact. Printing the PDF and saving that on paper is not sufficient, because you would lose the XML data – regulators consider that a loss of the original electronic form. For example, German tax authorities (GoBD) explicitly require that if an invoice was received or issued in electronic form, it must be stored electronically in that form, with all its content (including metadata) unchanged. Ensure your archiving solution preserves the PDF/A-3 file and that you have backups. The PDF/A format helps because it is made for long-term preservation (it restricts certain features to keep files accessible over time). Also, if you use digital signatures, you may need to store those and possibly timestamp them or re-sign before certificates expire to maintain their validity over the years. [zugferd.org]

Evidence Value in VAT Audits: When it comes to audits, a ZUGFeRD invoice, if properly stored and unchanged since issuance, is as legally valid as a paper invoice. Auditors in countries like France and Germany are increasingly familiar with hybrid invoices. The structured data can actually enhance auditability – for instance, authorities could use software to automatically verify sums, VAT rates, or cross-check that mandatory fields are present. ZUGFeRD’s compliance with EN 16931 means it contains all the data an auditor would expect to see per the EU standard. However, the company must also provide any associated evidence of authenticity and integrity. If you rely on process controls, your audit documentation (Verfahrensdokumentation in Germany) should describe how invoices are handled securely. If using digital signatures or electronic seals, you may need to demonstrate how these are managed and how you verify incoming signed invoices. The bottom line is that a ZUGFeRD invoice will be considered valid for VAT purposes if it contains the required info and if you have ensured it’s from who it purports to be from and hasn’t been altered – this is no different from requirements on other e-invoices or even paper invoices. [zugferd.org]

Risk Areas and Common Misconceptions:

• “ZUGFeRD is automatically compliant just by being PDF+XML” – Misconception: In reality, compliance isn’t just about format. While ZUGFeRD can contain all needed data, companies must still follow tax regulations and guidelines (for example, German companies using ZUGFeRD still must follow the GoBD rules on electronic record-keeping). The format is an enabler, but organizations need to implement it correctly with the right data and controls. [zugferd.org]
• “If the PDF looks right, the invoice is fine” – Risk: You must ensure the XML matches the PDF exactly. A discrepancy (even a minor one like a rounding difference or an update to one part but not the other) can lead to serious issues: it might cause the invoice to fail automated validation or even be considered invalid. Always use tools to validate that the XML and PDF content are synchronized. [weka.de]
• “We can just print and archive ZUGFeRD invoices like paper” – Misconception: Printing destroys the structured data. If you issue or receive a ZUGFeRD invoice, you must keep the electronic file. Converting it to paper or a simple image breaks the chain of integrity and may violate e-archiving laws.
• “Using ZUGFeRD means we don’t need to worry about e-invoicing mandates” – Misconception: In countries implementing clearance or specific e-invoice mandates, using ZUGFeRD is not a substitute for complying with those. For example, from 2025 Germany requires structured e-invoices, but you still need to ensure you’re using at least ZUGFeRD 2.x and delivering it in acceptable ways (no just sending a plain PDF). In Italy, ZUGFeRD is irrelevant for satisfying the official mandate (you’d still need FatturaPA). So always align ZUGFeRD usage with local law (often it will be one option, but not the only one, and sometimes not sufficient alone). [weka.de], [traffiqx.net]
• “ZUGFeRD’s PDF is digitally signed, so it’s legal” – Risk: Not all ZUGFeRD invoices are signed; signature is optional and separate from the format. If you require signatures for compliance, ensure your solution applies them. Conversely, some might think a signed PDF is needed for every invoice – that’s not true everywhere (many countries accept unsigned e-invoices if other controls are in place). Know your compliance method for authenticity (signature, EDI agreement, or controls) and implement accordingly.

In summary, ZUGFeRD can fully support legal VAT compliance – it provides all necessary data fields and a means to ensure readability and integrity. But it must be used as part of a well-designed process (including secure transmission, validation, and proper archiving). When done right, a ZUGFeRD invoice is a legally robust document that stands up in audits, while also delivering business automation benefits.

10. Practical Implementation Considerations

Executive Summary: Implementing ZUGFeRD in a multinational company requires careful planning across systems, people, and partners. Key considerations include upgrading or configuring your ERP/financial systems to generate and read ZUGFeRD invoices, ensuring your supplier and customer onboarding processes address this format, using validation tools and controls to maintain data quality, and setting up proper governance for updates and compliance. In practice, many large companies integrate ZUGFeRD support via software modules or external providers, run pilot programs with selected partners, and gradually scale up usage. They also remain ready to handle other formats where needed, as part of a multi-format strategy for different countries.

ERP and Billing System Implications: To generate ZUGFeRD invoices, your ERP or invoicing software must support the PDF/A-3 + XML output. Many modern systems do: for example, SAP has offerings and add-ons for ZUGFeRD/Factur-X, and numerous third-party libraries (like the open-source Mustang project) allow creation of these files in custom solutions. Check whether your current software version supports ZUGFeRD 2.x (and which profiles). Upgrades or plug-ins may be needed. Similarly, for accounts payable, configure your ERP or accounting software to import ZUGFeRD invoices. This might involve installing a patch or using a scanning/EDI solution capable of reading PDF attachments. If your company uses a centralized invoicing platform or outsourcing (e.g. using a service like Basware, Tungsten, or others), discuss with them about enabling Factur-X/ZUGFeRD support. In some cases, implementing ZUGFeRD is as simple as turning on a feature in the software; in others, it may require an IT project to map invoice data to the standard’s fields. Pay attention to version compatibility – e.g., ensure the solution supports the latest versions (2.2, 2.3, 2.4 etc.) so you benefit from updates (like new code lists or profiles). Also, coordinate with your IT on how ZUGFeRD updates will be applied: the format evolves (there are multiple updates per year to incorporate new VAT codes, etc.), so you may need a maintenance plan to update schemas or software patches regularly. [zugferd.org], [blog.seeburger.com]

Supplier Onboarding: If you plan to receive ZUGFeRD invoices from suppliers, you may need an education and onboarding campaign. Communicate with your suppliers about your capability and preference to receive electronic invoices in this format. As seen with Siemens and other large firms in Germany, some companies have started informing suppliers that from 2025 onward they will only accept EN 16931-compliant e-invoices (like ZUGFeRD or XRechnung), not old PDF or paper invoices. In your communications, provide guidelines on the required profile and data (for example, if you need line items, tell suppliers not to use the “Minimum” profile). Be prepared to support some suppliers who may not have the technical means – this could involve pointing them to free tools or portals that can generate ZUGFeRD invoices from their data, or even offering a web invoice form they can fill (which then produces a ZUGFeRD file). A phased approach is wise: start with willing or major suppliers in Germany/France first, then expand to others. Monitor the incoming e-invoices for compliance; use a validator to give suppliers quick feedback if their files are not conforming (e.g., missing fields or failing schema rules), so they can correct issues early. Over time, aim to integrate the majority of your supply base to send you structured invoices, as this will drastically cut down manual entry. [siemens.com]

Customer Acceptance Challenges: If you are a supplier looking to send ZUGFeRD invoices to your clients, consider their readiness. The good news is that even if a customer is not actively asking for ZUGFeRD, they can still receive your file and simply use it as a normal PDF. The embedded XML will not hinder them – at worst, they’ll ignore it. However, some customers might have specific invoicing requirements: e.g., if a customer uses a procurement portal or EDI network, they may ask you to submit invoices through that system (possibly in a different format). In such cases, you may need to support multiple formats in parallel. When dealing with public sector clients, make sure you’re using the proper channel (for example, sending via the official platform in the required format – which could mean extracting the XML from ZUGFeRD and submitting it). For private sector clients, proactively highlighting that you offer ZUGFeRD e-invoices could be a value-add – especially for clients in Germany or France who are moving to mandatory e-invoicing, as it helps them comply. Nonetheless, always validate if the customer has any e-invoicing guidelines. Some might require a specific profile or flavor of ZUGFeRD; for instance, a company might insist on the EN 16931 profile to ensure all data is present, or even a profile like “XRechnung” if they treat it as a universal format for all invoices. Being flexible is key: maintain an ability to produce standard PDFs or other formats until all customers are ready to accept ZUGFeRD.

Validation Tools: Utilize available tools to ensure your ZUGFeRD invoices are correct and compliant before they are sent or accepted. The open-source Mustang library (Java) and its command-line tool can validate ZUGFeRD/Factur-X files against the official schema and schematron rules. The French forum (FNFE-MPE) provides an online validator, and there are others (e.g., from the ZUGFeRD Community, or commercial solutions). Make use of these to catch errors like missing mandatory fields, calculation discrepancies, or invalid code values. For incoming invoices, consider integrating a validation step in your workflow so that an invalid invoice doesn’t silently get posted. Additionally, test your processes with sample invoices in all profiles you intend to use – the official ZUGFeRD/Factur-X documentation comes with example files for Minimum, Basic, EN 16931, etc., which you can use to verify your software. [zugferd.org]

Governance and Controls: As with any financial process change, proper governance is essential. Update your internal policies and documentation to cover electronic invoice handling (for compliance, again think of frameworks like GoBD, which require documented procedures for electronic documents). Incorporate ZUGFeRD into your invoice approval and verification workflows – e.g., how do you handle disputes on an e-invoice, how do you ensure the XML isn’t altered, etc. If you implement digital signatures on outgoing invoices, manage the certificates and make sure recipients know how to verify them (or consider using advanced signatures if legally required). Put in place a monitoring mechanism for the success of e-invoice processing: e.g., track the percentage of invoices auto-processed vs those requiring human intervention, and analyze any failures (was a field missing? a format issue? a supplier using the wrong profile?) so you can take corrective action. Also, assign responsibility to keep an eye on standards updates and legal changes. For instance, EN 16931 code lists update twice a year (which can introduce new VAT codes or slight changes), and national e-invoicing regulations are evolving rapidly. Ensure someone on your team, or a service provider, keeps your implementation up-to-date (the ZUGFeRD format version archive is updated regularly). [zugferd.org] [blog.seeburger.com], [blog.seeburger.com]

Scalability in a Multinational Environment: Multinational companies will likely deal with multiple e-invoicing requirements. ZUGFeRD can be one piece of a broader e-invoicing strategy. For example, you might use ZUGFeRD/Factur-X for your European operations (especially in Germany and France where it’s becoming essential), but also maintain capabilities for Peppol (for other EU countries), FatturaPA (for Italy), various clearance systems (for countries like Turkey, India, Mexico, etc.), and possibly PDF/EDI for any remaining cases. One approach is to use middleware or an e-invoicing service provider that can take an invoice from your ERP in a single format (say, you produce everything as ZUGFeRD internally) and then convert/rout it to the appropriate format/channel per country. Since ZUGFeRD’s data is standard, it can serve as a source to generate, for instance, a pure UBL invoice or a local XML with minimal transformation. Conversely, if you receive different formats from partners, you might convert them into ZUGFeRD for internal consistency. For scalability, ensure that whatever solution you choose can handle the volumes and variations in your business (multiple languages, multiple tax regimes, high line-item counts, etc.). Performance-wise, ZUGFeRD files are larger than pure XML (due to the PDF content), but are still usually small enough (a few hundred kilobytes) – just be mindful of email size limits especially if you include many attachments or have very large invoices (Siemens, for example, sets a 15 MB email limit for invoices and requires only one invoice per email). [zugferd.org] [siemens.com]

Supplier/Customer Support and Change Management: Internally, you will need to train your staff (accounts receivable, accounts payable, IT support) on the new process. They should understand how to open and check a ZUGFeRD invoice (e.g., how to view the embedded XML if needed, perhaps using a specialized viewer) and how to respond if something goes wrong (e.g., if a business partner says they cannot open your invoice, your team should know how to guide them – often it’s just “open it in Adobe Reader or a PDF tool” since it’s a PDF/A file). It’s also wise to pilot the implementation: for instance, select a small number of invoices or a subset of partners to start exchanging ZUGFeRD invoices with, and iron out any issues before scaling up. Many companies start with domestic invoices in Germany/France first, then expand to cross-border use. Collect feedback from your trading partners – some may have preferences or may alert you to issues (like “we couldn’t see the XML” or “your invoice failed our validation because of X”). This feedback loop will help improve your deployment. [zugferd.org]

In terms of controls, consider integrating automated checks: for outgoing invoices, ensure your system logs confirmation that the XML was successfully embedded and valid. For incoming, consider using a “fallback” if a ZUGFeRD XML fails – e.g., if the XML is malformed, at least you have the PDF to manually enter, but you might then reach out to the supplier to fix their process. Also plan for exceptions: not all invoices you deal with will be ZUGFeRD. You may still get some paper or plain PDFs from smaller partners (especially in the transition period up to the mandate deadlines); you might need a scanning/OCR solution for those, or a small supplier portal to key them in. Over time, as mandates kick in, the volume of true electronic invoices will increase.

Finally, keep in mind that e-invoicing is not just an IT project, but a business change. Engage your Finance, Tax, and Compliance teams from the start. Align ZUGFeRD implementation with compliance strategy – for instance, confirming that using ZUGFeRD meets your country’s requirements for e-invoices (maybe with your tax advisors’ input). Audit and tax teams will also want to know how to retrieve invoices and data for their purposes. By taking a holistic approach – technology enablement, partner outreach, compliance checks, and employee training – you can successfully deploy ZUGFeRD/Factur-X and enjoy its benefits in efficiency and accuracy, all while staying on the right side of global e-invoicing mandates.

---

---