E-Invoicing & E-Reporting Explained: Factur-X in France

Comprehensive Overview of Factur X, its Compliance, and Strategic Implications

This briefing document provides a detailed review of Factur X, a Franco-German hybrid e-invoicing standard, based on the provided sources. It covers its origins, technical specifications, relationship with European standards and legal frameworks, operational considerations, and strategic implications for businesses navigating the evolving e-invoicing landscape.

1. Introduction to Factur X

Factur X is a hybrid e-invoicing standard that combines a human-readable PDF with an embedded machine-readable XML file. Developed through a joint Franco-German initiative, its primary objective is to encourage broad adoption of electronic invoicing, particularly among Small and Medium Enterprises (SMEs), by offering an “added-value” invoice format that automates processing while remaining accessible for users without advanced systems. It aims to bridge the gap between traditional paper/PDF invoices and fully structured XML models.

Key Facts:

Origin: Emerged in 2017 as a collaborative project between France (FNFE-MPE) and Germany (FeRD), building on Germany’s prior ZUGFeRD format.
Dual Nature: A Factur X file is “two things in one: (a) a PDF/A-3 document that can be viewed/printed like any invoice PDF, and (b) an embedded XML file that contains the invoice data in structured form.”
Purpose: To “encourage broad adoption of electronic invoicing, especially among small and medium enterprises (SMEs) that traditionally relied on paper or PDF invoices.”
Not a New Standard: Factur X “is not a new semantic standard or legal regime. All of the information carried in a Factur X invoice is defined by existing standards and laws, not by Factur X itself.” It acts as a container for existing semantic data.

2. Legal and Standardization Context

Factur X was developed within the framework of two critical European legal and standardization efforts:

EU VAT Directive 2006/112/EC (Article 226): This directive specifies the content requirements for a valid VAT invoice. Factur X, by implementing EN 16931, “is grounded in VAT law (covering all Article 226 elements).”
Directive 2014/55/EU on e-invoicing in public procurement: This mandated a European e-invoice standard (EN 16931) for B2G transactions. Factur X is described as “a carrier” of the EN 16931 standard, embedding an EN 16931-compliant XML file within a PDF. This makes Factur X a compliant format under the EU public procurement e-invoicing framework when the appropriate profile is used.

Relationship with EN 16931:

Carrier, not Modifier: Factur X “does not alter or replace EN 16931’s content rules – it strictly uses them.” The embedded XML follows the EN 16931 semantic data model, meaning “all the data fields defined by EN 16931… are present as XML elements in a Factur X invoice.”
Syntax: Factur X uses the UN/CEFACT “Cross Industry Invoice” (CII) XML schema as the syntax for its embedded XML, which is one of the approved syntaxes for EN 16931.
Semantic Compliance vs. Hybrid Format: It’s crucial to differentiate these. “Semantic compliance means that an invoice’s content meets the requirements and definitions of the EN 16931 standard… regardless of how the invoice is physically represented.” Factur X’s hybrid format is “one way to represent those semantics,” designed to be user-friendly without compromising semantic fidelity.

Profiles – The Key to Compliance: Factur X defines a set of five profiles that dictate the level of data content in the embedded XML:

MINIMUM: Basic header data and totals; no line item details. Not EN 16931-compliant.
BASIC WL (Without Lines): Extends Minimum with more header data but still no line items. Not EN 16931-compliant.
BASIC (with Lines): Includes core line item details but may omit some optional EN 16931 fields. Not EN 16931-compliant.
EN 16931 (Comfort): Corresponds to the full set of information in EN 16931. Fully EN 16931-compliant.
EXTENDED: Contains all EN 16931 data plus additional fields for industry-specific or national requirements. If implemented correctly, it covers EN 16931 (as a superset).

Crucial Insight: “compliance depends on profile selection, not the file itself.” Just having a “Factur X” file does not guarantee EN 16931 or VAT compliance; the chosen profile and the accuracy of the data within it determine the compliance level.

3. Technical Structure and Validation

A Factur X file is technically a PDF/A-3 document (an ISO standard for long-term archiving) with the invoice XML embedded as an associated file attachment. Metadata within the PDF helps identify and extract the XML.

Validation Layers: Factur X employs multiple layers of validation to ensure correctness and trustworthiness:

PDF/A compliance check: Verifies the PDF portion meets PDF/A-3 standards (important for archiving).
XML schema validation: The embedded XML must be well-formed and valid against the appropriate XSD schema for its declared profile (e.g., Basic WL XSD).
Semantic/business rule validation: Schematron rules, provided per profile, check conditions like correct totals and mandatory information presence according to EN 16931.
Consistency check (optional/manual): Ensuring the human-readable PDF content matches the XML data. While not automatically enforced by the spec, it’s a best practice.

Human-readable vs. Machine-readable Roles:

PDF: Serves as the human-readable presentation layer, familiar for visual verification, manual checks, and dispute resolution.
XML: The machine-readable layer, enabling automation for accounting systems, VAT calculation, and reporting.
Separation of Presentation and Semantic Truth: The XML is considered the “definitive record of the invoice’s data values,” or the “source of truth,” with the PDF being a rendered view. This allows for flexible presentation without altering the core data.

4. Relationship with PEPPOL

PEPPOL (Pan-European Public Procurement Online) is an interoperability network focused on machine-to-machine exchange of electronic documents.

Limited Direct Compatibility: Factur X is generally not directly compatible with the PEPPOL network as a primary invoice document. PEPPOL primarily operates with pure XML syntaxes (like UBL or UN/CEFACT CII) conforming to the PEPPOL BIS Billing 3.0 CIUS.
PEPPOL’s Pure XML Preference: PEPPOL prioritizes automation, network efficiency, and a single source of truth (the XML). Embedding a PDF would complicate processing, add data overhead, and introduce potential discrepancies between visual and structured data. PEPPOL guidelines explicitly advise against attaching duplicate PDF invoice images.
Data Alignment: While Factur X files are not directly sent via PEPPOL, they share the underlying EN 16931 semantic model. This means that “data-wise, a Factur X invoice and a PEPPOL BIS invoice convey the same info.” Conversion from Factur X’s XML to PEPPOL’s UBL (or CII) is feasible.

5. Impact on EU E-Invoicing Mandates and ViDA

Factur X plays a specific role in the evolving EU e-invoicing landscape, particularly with the “VAT in the Digital Age” (ViDA) initiative.

E-Invoicing Mandates (B2G/B2B):

B2G: Factur X (at its EN 16931 profile) meets the requirements of Directive 2014/55/EU for B2G e-invoicing. It is explicitly accepted in national portals in countries like France (Chorus Pro) and Germany (as ZUGFeRD). However, many other EU countries prefer pure XML (e.g., via PEPPOL).
B2B: Factur X is recognized as a compliant format in emerging B2B mandates in France and Germany. However, some clearance-centric systems (like Italy’s FatturaPA) require pure XML formats.

Relationship with Clearance and Reporting Systems:

Factur X “is not a clearance or reporting mechanism” itself. These regimes require timely submission of structured invoice data to tax authorities. While Factur X carries the necessary data, the PDF component is generally ignored or stripped by tax authorities in such systems.
“Factur X on its own does not meet the requirements of clearance/reporting mandates, which revolve around timely submission of structured data to tax authorities.”

ViDA (VAT in the Digital Age):

EN 16931 is Central: ViDA’s core mandate is for all B2B invoices (initially cross-border) to be EN 16931-compliant structured electronic invoices. The legislation (new Article 218) “enshrines EN 16931 as the benchmark for what counts as an e-invoice after 2027.”
Factur X’s Transitional Role: Factur X can serve as a “useful transitional role” by allowing businesses to generate EN 16931-compliant XML while retaining a familiar PDF for user acceptance. This acts as a bridge between traditional and fully digital practices.
Limitations for Real-time Reporting: For near real-time digital reporting requirements, “the PDF part is extraneous to compliance: it’s ‘allowed’ but not necessary under the new regime.” The PDF adds technical overhead (file size, complexity) and does not directly support the interactive loops of clearance systems.

6. Other Formats and Long-Term Convergence

ZUGFeRD: “Factur X” and “ZUGFeRD” are identical data formats, with ZUGFeRD being the German name. An invoice in one is by definition an invoice in the other.
EDI and Legacy Formats: Factur X does not replace traditional EDI (e.g., EDIFACT) but serves a similar goal for different communities. Semantic alignment between EDI and EN 16931 is possible through mappings, but legacy systems face practical constraints. Factur X can be seen as a more accessible form of EDI.
Convergence Expectations: The EU is moving towards “universal semantic compliance (everyone using EN 16931 core) and streamlined syntactic choices.” Factur X has positioned itself within this trajectory by adhering to EN 16931 from the start. In the long term, the need for the PDF layer may diminish as pure data exchange becomes the norm, though it could persist for specific use cases (e.g., archiving, B2C).

7. Key Limitations and Common Misunderstandings

Several critical misconceptions surround Factur X that businesses must be aware of:

Factur X ≠ VAT compliance guarantee: “Using the Factur X format does not automatically guarantee that an invoice complies with all VAT legal requirements.” Errors in data input or omissions of legally required details (e.g., “Reverse charge” phrase) will result in a non-compliant invoice, regardless of the format.
Factur X ≠ EN 16931 compliant by default: Only the EN 16931 (Comfort) profile and properly configured Extended profiles provide full EN 16931 semantic compliance. Lower profiles (Minimum, Basic WL, Basic) are subsets and do not meet the full standard. “Confusing ‘Factur X’ generally with ‘EN 16931 compliance’ is dangerous.”
Factur X ≠ clearance or reporting mechanism: Factur X is an invoice format, not a transmission system. It does not automatically send data to tax authorities or fulfill real-time reporting obligations.
PDF readability ≠ legal or semantic compliance: “Just because the invoice looks correct to the eye, this does not guarantee that it meets all legal and semantic requirements.” Discrepancies between the PDF and XML, or missing structured data, can lead to compliance issues despite visual appeal. The XML is the “source of truth.”
Risks of incorrect compliance claims: Misinterpreting Factur X capabilities can lead to invoice rejections, payment delays, and penalties. Businesses must ensure precise use of terms, validate outputs rigorously, and stay informed on legal and technical updates.

8. Strategic Takeaways for Businesses

Businesses should approach Factur X strategically, recognizing its benefits as a transitional and hybrid solution, rather than an ultimate end state.

When it Makes Sense:
Dealing with partners of mixed technological maturity (offering both human-readable and machine-readable options).
Future-proofing invoices for upcoming mandates by embedding standard data now, without alienating current processes.
Strengthening archiving and audit processes due to PDF/A-3 and structured data.
Facilitating B2G compliance in countries where it’s accepted.
Unifying cross-border invoices within regions that support it (e.g., France/Germany).
Benefits for Tax Control and Audit: Factur X can “strengthen tax control and auditability” by providing structured data for automated analysis and a legible PDF for human review. This facilitates compliance checks and improves data quality.
Implications for ERP, Archiving, and Controls: Implementing Factur X often requires ERP upgrades to capture complete data, updates to archiving policies (to preserve Factur X files), and new internal controls (e.g., automated validation against purchase orders).
EN 16931 Readiness is Foundational: Regardless of format choice, “the ability to produce and handle EN 16931-compliant invoice data is the foundational requirement.” Businesses must align their internal data practices with EN 16931’s semantic model to ensure long-term compliance with evolving mandates like ViDA.
Factur X as a Transition, Not an End State: Factur X is a valuable “bridge” from unstructured to structured invoicing. While its PDF layer may become less critical as full automation progresses under ViDA, it remains useful for SMEs, for archiving, and for scenarios where visual invoices are needed. Businesses should leverage Factur X to smooth their journey to fully digital VAT, while simultaneously planning for a future where pure data exchange will dominate.

ARTICLE

Table of Contents

What is Factur‑X?
1.1 Origin and policy objectives
1.2 Joint Franco‑German standardisation background
1.3 Legal and standardisation context
1.4 Positioning relative to EN 16931 and Directive 2014/55/EU
1.5 What Factur‑X is and is not
1.6 Why Factur‑X exists alongside pure XML models
What does Factur‑X include?
2.1 Hybrid invoice concept (PDF + embedded XML)
2.2 Embedded EN 16931 semantic model
2.3 Technical structure (PDF/A‑3 with XML attachment)
2.4 Validation layers
2.5 Human‑readable vs machine‑readable roles
2.6 Separation between presentation and semantic truth
Factur‑X profiles and their legal‑technical meaning
3.1 Purpose of profiles
3.2 Overview of profiles (Minimum, Basic WL, Basic, EN 16931, Extended)
3.3 Which profiles are EN 16931‑compliant
3.4 Which profiles are not EN 16931‑compliant
3.5 Why compliance depends on profile selection, not the file itself
Relationship with EN 16931
4.1 Factur‑X as a carrier of EN 16931 semantics
4.2 Semantic compliance vs hybrid format
4.3 Why Factur‑X does not modify EN 16931
4.4 Limits of extensions and additional data elements
4.5 Alignment with CEN rules and CIUS constraints
Relationship with Article 226 of Directive 2006/112/EC
5.1 Mapping of Article 226 VAT invoice elements to EN 16931 / Factur‑X data
5.2 Where Factur‑X goes beyond VAT law
5.3 Where VAT law goes beyond Factur‑X
5.4 Legal primacy of VAT law over standards and formats

5A. Reconciling VAT law, EN 16931, and Factur‑X: roles and perspectives
5A.1 Legal perspective (VAT Directive)
5A.2 Semantic perspective (EN 16931 standard)
5A.3 File/document perspective (Factur‑X format)
5A.4 Operational perspective (exchange, archiving, controls)
5A.5 Why “Factur‑X compliant” vs “EN 16931 compliant” vs “VAT‑compliant” are not interchangeable
5A.6 Risks of false or partial compliance assumptions

Relationship with PEPPOL
6.1 Whether and how Factur‑X relates to PEPPOL
6.2 Why PEPPOL primarily operates with pure XML syntaxes
6.3 Interoperability considerations
6.4 Legal vs transport roles
6.5 Limitations of Factur‑X in PEPPOL environments
Impact on EU e‑Invoicing mandates
7.1 Use of Factur‑X in B2G and B2B contexts
7.2 Relationship with clearance and reporting systems
7.3 When Factur‑X is accepted vs when structured XML is required
7.4 High‑level EU context (avoiding country-specific deep dives)
Impact of ViDA (VAT in the Digital Age)
8.1 Why EN 16931 – not Factur‑X – is central to ViDA
8.2 Role of Factur‑X in transition scenarios
8.3 Limitations for near real‑time digital reporting
8.4 Expected future relevance under ViDA
EDI and legacy formats
9.1 Relationship between Factur‑X and traditional EDI
9.2 Possibility and limits of semantic alignment
9.3 Practical constraints in legacy environments
Commercial invoicing models
10.1 Neutrality of Factur‑X toward business models
10.2 Applicability to self‑billing, triggered invoices, platform‑generated invoices
10.3 Emphasis on invoice content rather than process
Other hybrid formats and alignment
11.1 Relationship with ZUGFeRD
11.2 Differences between national implementations
11.3 Interoperability risks
11.4 Long‑term convergence expectations
Key limitations and common misunderstandings
12.1 Factur‑X ≠ VAT compliance guarantee
12.2 Factur‑X ≠ EN 16931 compliant by default
12.3 Factur‑X ≠ clearance or reporting mechanism
12.4 PDF readability ≠ legal or semantic compliance
12.5 Risks of incorrect compliance claims
Strategic takeaways for businesses
13.1 When Factur‑X makes strategic sense
13.2 Benefits and limits for tax control and audit
13.3 Implications for ERP systems, archiving, and controls
13.4 Why EN 16931 readiness remains foundational
13.5 Factur‑X as a transition and hybrid solution, not an end state

What is Factur‑X?

1.1 Origin and policy objectives: Factur‑X is a Franco–German e-invoicing standard developed to meet the dual policy goals of economic digitalization and VAT compliance. It emerged in 2017 as a collaborative project between France and Germany, aligning with EU efforts to harmonize e-invoicing. By combining human-readable and machine-readable invoice forms, Factur‑X aims to encourage broad adoption of electronic invoicing, especially among small and medium enterprises (SMEs) that traditionally relied on paper or PDF invoices. The policy objective is to offer an “added-value” invoice format that automates processing where possible, yet remains accessible for users without advanced systems. This aligns with the EU’s push (in Directive 2014/55/EU) for a common e-invoice standard to reduce complexity and barriers in cross-border trade. [fnfe-mpe.org], [ec.europa.eu] [fnfe-mpe.org], [fnfe-mpe.org] [fnfe-mpe.org] [ec.europa.eu], [ec.europa.eu]

1.2 Joint Franco‑German standardisation background: Factur‑X was born of a joint standardization initiative by France’s FNFE-MPE and Germany’s FeRD forums, building on prior German experience with the “ZUGFeRD” format. The two countries collaborated to create a single hybrid invoice schema acceptable in both jurisdictions, rather than divergent national standards. This ten-year collaboration (2014–2024) culminated in a fully unified format: in fact, “Factur‑X is the same standard as ZUGFeRD” (the German name for it). The first public release (Factur‑X 1.0 / ZUGFeRD 2.0 in late 2017) coincided with the publication of the European e-invoicing semantic data model (EN 16931) and was explicitly the first implementation of that European Standard. The joint effort ensured that France and Germany’s e-invoice requirements converged on one format, rather than adding new fragmentation. This binational approach was driven by policy goals: both governments sought a format suitable for domestic B2B, B2G (business-to-government) invoicing, and cross-border use, to simplify compliance for businesses operating in the internal market. [fnfe-mpe.org] [ec.europa.eu], [ec.europa.eu]

1.3 Legal and standardisation context: Factur‑X was developed in the context of two key European legal frameworks: the EU VAT Directive 2006/112/EC (which lays down what information an invoice must contain) and Directive 2014/55/EU on e-invoicing in public procurement. Directive 2014/55/EU mandated the creation of a European e-invoice standard to solve the problem of many non-interoperable national invoice formats. In response, CEN (the European standards body) produced EN 16931-1:2017, a semantic data model specifying the core information elements an invoice should have, consistent with VAT law. The same process yielded a list of permissible syntaxes (technical formats) for conformant invoices. Factur‑X sits exactly at the intersection of these legal and technical streams: it adopts the EN 16931 core data model (ensuring all legally required invoice data are present) and uses one of the approved syntaxes (the UN/CEFACT Cross-Industry Invoice XML) packaged inside a PDF/A-3 file. Thus, Factur‑X’s design ensures that an invoice can comply with VAT content requirements and the European standard, while remaining in a familiar PDF format for ease of use. It complements the EU public procurement mandate by providing a format that contracting authorities in the EU can accept under Directive 2014/55/EU (since Factur‑X’s XML part is an EN 16931-compliant invoice). In summary, Factur‑X arose from the need to reconcile law, standards and interoperability: it is grounded in VAT law (covering all Article 226 elements), realized through the European standard, and intended to operate across borders and systems smoothly. [ec.europa.eu], [ec.europa.eu] [ec.europa.eu] [eur-lex.europa.eu] [fnfe-mpe.org], [eur-lex.europa.eu]

1.4 Positioning relative to EN 16931 and Directive 2014/55/EU: Factur‑X is best described as “a carrier” of the EN 16931 European invoice standard, rather than a separate standard. It implements EN 16931’s semantic model in a specific way: by embedding an EN 16931-compliant XML file into a PDF container. Notably, Factur‑X does not alter or replace EN 16931’s content rules – it strictly uses them. For example, if EN 16931 mandates certain data elements (like seller name, tax amounts, etc.), Factur‑X invoices must include those in the XML to be considered at the EN 16931 profile level. Directive 2014/55/EU required all EU public bodies to accept invoices conforming to EN 16931 by April 2019. Factur‑X was designed to facilitate this: a supplier can send a Factur‑X invoice to a public entity, and the authority can extract the XML and validate it against EN 16931 requirements. In other words, Factur‑X positions itself as a compliant format under the EU public procurement e-invoicing framework, on par with “pure” XML invoices. It exists alongside pure-XML models (like invoices in UBL or UN/CEFACT XML alone) as an alternative encoding of the same core information. Factur‑X’s value-add relative to pure XML is that it bundles a human-readable PDF for easy viewing or paper processes, without sacrificing the structured data needed for automation. The format does not contradict any aspect of Directive 2014/55/EU; in fact, that Directive explicitly aimed for technology-neutrality and only insisted that invoices be machine-readable and follow a common semantic model. Factur‑X meets these criteria: the machine-readable part (XML) adheres to the common semantic standard, and the PDF part is a neutral addition (indeed, Recital 7 of Directive 2014/55/EU warns that a mere image is not an e-invoice, but Factur‑X’s PDF is accompanied by structured data, so it is a compliant e-invoice). In summary, Factur‑X’s role is as an implementation of the EU standard: it leverages EN 16931 for content and was shaped by the policy context of Directive 2014/55/EU. [fnfe-mpe.org], [fnfe-mpe.org] [fnfe-mpe.org] [ec.europa.eu], [ec.europa.eu] [ec.europa.eu]

1.5 What Factur‑X is and is not: Factur‑X is a format specification for electronic invoices – specifically a hybrid file format. It is not a new semantic standard or legal regime. All of the information carried in a Factur‑X invoice is defined by existing standards and laws, not by Factur‑X itself. In essence, Factur‑X is two things in one: (a) a PDF/A-3 document that can be viewed/printed like any invoice PDF, and (b) an embedded XML file that contains the invoice data in structured form. Factur‑X does not introduce new invoice content requirements beyond what’s in EN 16931 or national law; it simply provides a container for those. It is also not an exchange protocol or platform – for instance, Factur‑X does not dictate how invoices are transmitted (email, portal, PEPPOL network, etc.), it only defines the file’s internal structure. Moreover, using Factur‑X is not a guarantee of VAT compliance by itself (one must still meet all substantive tax requirements – see Section 12) and not a replacement for mandated reporting if a tax authority requires invoice data to be transmitted in real-time (Factur‑X is an invoice format, not a reporting system per se). In short, Factur‑X is a standards-based hybrid invoice format implementing EN 16931 in PDF+XML form; it is not a separate data standard, not an automatic compliance tool, and not a communication network or process. Think of Factur‑X as a vehicle: it carries legally and semantically defined invoice content, but it doesn’t create the content or drive itself – businesses must still populate it correctly and use appropriate channels to send it. [fnfe-mpe.org]

1.6 Why Factur‑X exists alongside “pure XML” models: Factur‑X was conceived to fill a practical gap between traditional invoices (PDF/paper) and fully structured XML invoices. Pure XML e-invoice models (like those used in EDI or in some B2G systems) offer excellent automation but lack human readability and are harder for small businesses to adopt. Factur‑X exists to bridge this gap. It allows a supplier to produce a single file that serves both purposes: for the supplier and buyer’s accounting systems, there is a structured XML invoice (machine-processable); for humans (e.g. an accounting clerk or a small business owner), there is a familiar PDF rendering of the invoice. This hybrid approach encourages adoption by companies “at different stages of automation maturity” – companies that are not ready to handle pure XML can still use/approve the PDF, while those with advanced tools can automate the XML data import. In policy terms, Factur‑X coexists with pure syntaxes because policy-makers recognized that requiring 100% XML exchanges might be too burdensome for many businesses in the short term. Recital 5 of Directive 2014/55/EU even noted that existing national e-invoice formats could continue in parallel with the European standard as long as they don’t conflict. Factur‑X is an embodiment of that idea: it doesn’t force users to abandon PDFs. It “meets suppliers and buyers where they are” – a seller can upgrade their invoicing gradually, embedding whatever structured data they are capable of producing, while the buyer still receives a legible invoice. The existence of Factur‑X alongside pure-XML models is also explained by interoperability strategy: some networks (like PEPPOL) or mandates prefer pure XML (for efficiency in automated hubs), but in domestic or bilateral exchanges, a PDF-based format can be more practical. Factur‑X gives an option in such cases to stay conformant with standards without forsaking the PDF. In summary, Factur‑X exists alongside pure XML formats to provide a more user-friendly and incremental path to full e-invoicing, ensuring no stakeholder is left behind in the digital transition. [fnfe-mpe.org], [fnfe-mpe.org] [fnfe-mpe.org] [ec.europa.eu]

What does Factur‑X include?

2.1 Hybrid invoice concept (PDF + embedded XML): Factur‑X embodies the “hybrid invoice” concept: a single invoice document that is both human-readable and machine-readable. In practice, this means a Factur‑X file is a PDF with an XML invoice embedded inside it. The PDF portion can be opened and viewed or printed like any standard invoice (showing layout, logos, line items, totals, etc.), fulfilling the need for a human-friendly representation. The embedded XML portion carries the same invoice data in a structured format that software can parse automatically. Crucially, both parts travel together as one file, so the recipient is assured that the human-readable invoice and the structured data correspond to each other (they are two views of one invoice). This hybrid approach was innovative when introduced; Factur‑X (and its twin ZUGFeRD in Germany) was the first implementation of the EU’s semantic invoice standard in a hybrid PDF/XML form. The concept builds on the PDF/A-3 standard, which for the first time (in 2012) allowed PDFs to carry attachments. Factur‑X uses that capability to attach the invoice XML inside the PDF container. The policy logic behind the hybrid model is to maximize adoption: by providing a user-friendly PDF, it removes barriers for companies who might otherwise resist purely electronic (XML) invoices, while still advancing digitalisation by including structured data. In summary, Factur‑X includes the full content of an invoice twice – once as a PDF image and once as structured data – leveraging the strengths of each medium. [fnfe-mpe.org]

2.2 Embedded EN 16931 semantic model: The XML embedded within a Factur‑X file isn’t arbitrary or proprietary; it follows the EN 16931 semantic data model – the European core specification for e-invoice data. In other words, all the data fields defined by EN 16931 (invoice number, dates, amounts, VAT details, addresses, line item details, etc.) are present as XML elements in a Factur‑X invoice. Factur‑X uses the UN/CEFACT “Cross Industry Invoice” (CII) XML schema as the syntax to represent these elements. Importantly, Factur‑X’s embedded XML can be “complete or not” depending on the chosen profile – meaning it might include the full set of EN 16931 core data or only a subset (profiles are discussed in Section 3). But at maximum (the EN 16931 profile), the XML contains all the information that the European Norm prescribes for a compliant invoice. Because of this, the structured content of a Factur‑X invoice can be validated against the EN 16931 standard’s requirements. In practical terms, that means Factur‑X invoices can be checked with the same validation artifacts (like XSD schemas and Schematron rules) that CEN provides for EN 16931 compliance. By embedding EN 16931 semantics, Factur‑X ensures that using the format will satisfy the data needs of both VAT law (which demands certain key elements) and the EU standard (which adds further harmonized details). The XML portion is the authoritative semantic layer – it carries structured representations of each invoicing business term (BT) defined by EN 16931. For example, Article 226 of the VAT Directive requires an invoice to show the “quantity and nature of goods” and the “VAT amount payable”; in Factur‑X, those appear as specific XML elements (like <cbc:InvoicedQuantity>, <cbc:TaxTotal> etc., aligned to EN 16931 business terms for quantity and VAT total). Thus, Factur‑X’s XML is essentially an EN 16931 invoice instance, embedded in a PDF shell. The inclusion of the EN 16931 model is what qualifies Factur‑X as a compliant format under EU e-invoicing standards and what allows it to “talk” to other systems – a Factur‑X invoice can be parsed by any tool that understands EN 16931-compliant XML, yielding the standard data points needed for accounts payable automation and tax control. [fnfe-mpe.org], [fnfe-mpe.org] [fnfe-mpe.org] [ec.europa.eu] [eur-lex.europa.eu], [eur-lex.europa.eu]

2.3 Technical structure (PDF/A‑3 with XML attachment): Technically, a Factur‑X file relies on the PDF/A‑3 format (ISO 19005-3) as the base. PDF/A‑3 is a PDF variant for long-term archiving that permits embedding of arbitrary files. In a Factur‑X PDF, the invoice XML is embedded as an associated file attachment. There is also a small piece of metadata in the PDF (an XMP metadata extension schema) that identifies the attachment as an invoice data file, typically with a specific name (like “factur-x.xml” or similar) and MIME type (application/xml). This metadata helps software recognize and extract the XML. The structure can be summarized as: a PDF file containing all visual elements of the invoice (text, tables, etc.), plus one attached XML file in UN/CEFACT CII format representing the invoice data, plus metadata linking the two. The PDF part must conform to PDF/A-3 (level B or A) standards – for example, it must embed fonts and not use certain dynamic features – ensuring it’s self-contained and stable for archiving. The XML part must conform to the defined schema for the chosen profile (Factur‑X defines separate XML Schema Definition files for each profile: Minimum, BASIC WL, Basic, EN 16931, Extended). Each profile also has an associated Schematron (for business rule validation). Thus, one can validate a Factur‑X file on multiple layers: (1) check that the PDF meets PDF/A-3 criteria, (2) extract the XML and check it against the XSD for the profile, and (3) apply Schematron rules (which enforce semantic constraints from EN 16931 or profile-specific rules). The attachment mechanism in PDF/A-3 is standard: the XML is stored within the PDF’s file structure (often compressed) and can be opened or saved using PDF reader software (some PDF readers now expose the embedded file in an attachments pane). To comply with Factur‑X spec, the PDF’s metadata should include a reference (an AF Relationship key) marking the XML as an “Data” file or similar, and a schema identifier indicating the profile/version of Factur‑X used. In summary, Factur‑X’s technical structure is a single PDF/A-3 file encapsulating an XML invoice, linked via metadata. This allows one file to serve dual roles and be handled by both PDF-oriented tools and XML-oriented tools. [fnfe-mpe.org]

2.4 Validation layers: Because Factur‑X combines different components, multiple layers of validation apply to ensure a Factur‑X invoice is correct and trustworthy. These layers include:

PDF/A compliance check: The PDF portion should be valid PDF/A-3 (for example, contain the correct metadata and no disallowed content). PDF validators can check conformance. Adhering to PDF/A-3 is important for legal** archiving** (many jurisdictions require that electronic invoices be stored in a stable format like PDF/A).
XML schema validation: The embedded XML must be well-formed and valid against the appropriate XSD schema. As noted, Factur‑X provides five XSDs corresponding to the five profiles. If an invoice is declared as “Basic WL” profile, for instance, it must pass the Basic WL XSD validation (which would ensure required elements for that profile are present and correctly structured). [fnfe-mpe.org]
Semantic/business rule validation: Beyond raw schema, invoices must obey the business rules defined in EN 16931 and any profile or usage specifications. Schematron rules (also provided per profile in the Factur‑X specs) check conditions like: totals summing up, mandatory information presence depending on tax category, etc. Additionally, EN 16931 has a list of core rules (like “if an exemption code is used, an explanatory text must be provided”, etc.). A Factur‑X invoice using the EN 16931 profile should pass all the EN 16931 core rules (since it’s meant to be fully compliant). Profiles with reduced content (e.g. Minimum) would have a reduced set of rules to meet (and some EN 16931 rules intentionally relaxed due to missing data fields in that profile). [fnfe-mpe.org]
Consistency check between PDF and XML (optional/manual): One important aspect of hybrid invoices is ensuring the human-readable PDF content matches the XML data (so that a user reviewing the PDF sees the same numbers and info that a system would process from the XML). Factur‑X specification itself doesn’t mandate an automated cross-check, but it implicitly expects that the PDF rendering was generated from the XML data (or vice versa). In practice, discrepancies can occur if not careful, so as a best practice companies ensure consistency. If there is a signed PDF or any legal reliance on the visual layout, consistency becomes a de facto requirement. (Some implementations include an XML checksum or reference in the PDF to detect tampering or mismatches).

These validation layers collectively create a high assurance that a “Factur‑X invoice” is correct in format and content. For example, an accounting system that ingests Factur‑X can automate these checks: verify the PDF’s integrity, extract and validate the XML data, and flag any errors (like a missing VAT ID or a total mismatch). The French and German forums maintain reference validation tools aligned with the profiles. We note that each profile having its own XSD and Schematron is explicitly part of the Factur‑X 1.0.8 release – meaning validation is tailored to profile-specific data requirements. In summary, Factur‑X includes robust validation at the file level, syntax level, and business rule level, to ensure legal and semantic correctness of the invoice. One consequence is that a valid Factur‑X invoice (especially at EN 16931 profile) can give both parties confidence that it meets the formal requirements of an invoice, since many of those requirements are automatically checked via these layers. [fnfe-mpe.org]

2.5 Human-readable vs machine-readable roles: In a Factur‑X invoice, the human-readable PDF and the machine-readable XML each have distinct but complementary roles. The PDF portion’s role is to serve as the presentation of the invoice – it’s what a person sees. It contains all the invoice information in a layout (often mirroring a traditional paper invoice format), with potentially logos, formatting, and sometimes an “affixed Factur‑X profile logo” indicating that structured data is included. This human-readable part is crucial for business scenarios like a small supplier who wants to visually verify the invoice, or a recipient who needs to check details manually or archive a human-legible copy. It also aids in dispute resolution – if there’s a discrepancy or an automation fails, the parties can refer to the PDF to discuss and resolve issues in a familiar format. On the other hand, the machine-readable XML’s role is to enable process automation and data exchange. Systems can read the XML to automatically book invoices, match them to orders, compute VAT, generate accounting entries, or report data to tax authorities. The XML eliminates manual data entry and interpretation errors, since it encodes each invoice element in a structured way (e.g. <Invoice><Seller><VATNumber>…). In essence, the PDF is for people; the XML is for systems. Factur‑X leverages this duality: for example, a vendor can send a Factur‑X invoice to a customer; the customer’s automated workflow might import the XML into an ERP system (machine-to-machine), while an accountant in the customer’s company might open the same file in a PDF viewer to inspect or approve it (human check). Both are looking at “the same invoice” just via different mediums. It’s worth noting that Factur‑X explicitly prioritizes including all necessary invoice info in the XML (so no critical data is only in the PDF but not in data, which would break automation). Conversely, the PDF can contain things like a company’s branding or sector-specific notes that don’t affect data processing – these appear visually but often also have a place in the XML (e.g. a note in the PDF could correspond to a <Note> element in XML). As long as the content is synchronized, there’s no conflict between the two representations. To summarize, Factur‑X divides the invoice into two parallel representations: the PDF ensures human interpretability and business practice continuity, while the XML ensures semantic precision and automation. This separation of presentation and data “truth” is deliberate, reflecting the idea that presentation can vary (you could style the PDF differently) but the semantic truth of the invoice lies in the structured data. [fnfe-mpe.org] [fnfe-mpe.org], [fnfe-mpe.org]

2.6 Separation between presentation and semantic truth: A key principle in Factur‑X (and indeed in modern e-invoicing) is the decoupling of how an invoice looks from what the invoice means. Factur‑X enforces a separation between the presentation layer (the PDF content) and the semantic layer (the XML data). Ideally, these two are consistent, but if differences exist, the question arises: which is the “source of truth”? In a well-formed Factur‑X, the XML is considered the definitive record of the invoice’s data values, whereas the PDF is a rendered view. The reason is that the XML holds the structured values that can be validated and processed. For instance, the PDF might display “€100.00” as the total, but the XML will have a <cbc:LegalMonetaryTotal><cbc:PayableAmount currencyID=”EUR”>100.00</cbc:PayableAmount></cbc:LegalMonetaryTotal>. If these differ, it means there’s an error in generation or tampering. The specification’s intent is that such discrepancies should not occur – the PDF should be generated from the XML data or vice versa, ensuring that the semantic content is mirrored exactly in the human-readable content. In practice, companies implementing Factur‑X will usually generate the XML from their billing system, then produce a PDF using that same data (often via an XSLT stylesheet or template) to guarantee consistency. Factur‑X provides profile logos (small icons) that can optionally be placed on the PDF to signal which profile of data is included, but those are purely visual cues. From a legal perspective, some countries might treat the PDF as the original invoice (especially if signed) and the XML as a supporting representation, while others (or contractual agreements) might stipulate the XML is the official invoice data. Factur‑X itself doesn’t dictate this; however, EU law (Directive 2010/45/EU, which amended the VAT Directive) allows electronic invoices in any format as long as integrity and authenticity are guaranteed and the required content is present. Factur‑X can fulfill those, and many users consider the XML content as the authoritative dataset for compliance purposes because it can be rigorously validated. On the operational side, mixing presentation with data can cause confusion – for example, the Swedish PEPPOL authority (SFTI) explicitly warns not to attach an invoice’s PDF image alongside the XML in standard e-invoices, because it forces receivers to reconcile two versions and invites misunderstandings. This underscores that duplication of content must be handled carefully: in Factur‑X the two versions are inseparable parts of one file, so it avoids the scenario of an XML and a separate external PDF getting out of sync, but the principle remains that any divergence could “modify the understanding of the invoice” and require extra validation. Therefore, best practice and implicit guidance in Factur‑X is to treat the XML as the single source of truth for the data (the “semantic truth”) and treat the PDF as a formatted visualization of that truth. The presentation (PDF) is deliberately separated so that it can be changed (e.g., translated labels, different layout) without altering the fundamental invoice data, and conversely the data can be consumed without regard to how it was presented visually. This separation enforces clarity in roles: the PDF is for readability and record-keeping, while the XML is for compliance, automation, and audit. As long as both contain the same substantive information, having them together in Factur‑X offers the best of both worlds. But users must remember: pretty PDF formatting alone doesn’t ensure an invoice is valid if the underlying data is wrong; what matters is that the required data elements are correctly captured (that’s the semantic compliance), which Factur‑X’s XML is designed to ensure. The PDF’s presence is an added convenience, not a substitute for correct data. (We will revisit in Section 12 how over-reliance on the PDF can be misleading if one assumes it guarantees compliance.) [sfti.se] [fnfe-mpe.org]

Factur‑X profiles and their legal‑technical meaning

3.1 Purpose of profiles: Factur‑X defines a set of “profiles” (levels) of invoice data content to accommodate different use cases and capabilities. The purpose of having profiles is to guide businesses on how much data to include in the XML, according to their needs and technical capacity, while still conforming to a standard structure. Not all invoices are equally complex: a micro-business might only provide minimal info (totals, parties, tax amount) whereas a large company’s invoice might have full line-level breakdowns and references. By establishing profiles ranging from very light to fully detailed, Factur‑X enables a stepwise approach to semantic invoicing. Each profile corresponds to a defined subset of the EN 16931 data model, with increasing completeness. The legal-technical rationale here is twofold: (1) ensure that even a “minimal” e-invoice still includes whatever data is legally mandatory, and (2) allow optional data that are not legally required but useful for automation to be added in higher profiles. Profiles effectively create interoperability tiers – a receiver can immediately know, from the profile, how much information to expect in the XML. This also ties into validation: each profile has its own validation rules (so an invoice using a lower profile is not penalized for omitting data that that profile doesn’t require). From a legal perspective, profiles are significant because only the higher profiles meet the full EU standard (EN 16931) and thus satisfy all public procurement requirements. Lower profiles might be used for simpler invoices (where perhaps not all EN 16931 elements are needed or available), but those invoices would not be “EN 16931-compliant” in the strict sense; they might still be perfectly VAT-compliant if they contain all legally required fields, but perhaps not all the extra fields that EN 16931 defines. In summary, profiles serve as a technical convenience and compliance spectrum: they help small businesses start with basic e-invoices (lower profiles) and scale up to fully standardized e-invoices (EN 16931 profile) as they grow or as required by trading partners or mandates. They also facilitate interoperability by labeling invoices – for example, a system can read the profile and know whether to expect line-item details or not. The existence of profiles is a pragmatic recognition that “one size fits all” is not realistic immediately, and it prevents the imposition of unnecessary complexity on those who don’t need it, while still providing a path to richer data when needed. [fnfe-mpe.org]

3.2 Overview of profiles (Minimum, Basic WL, Basic, EN 16931, Extended): Factur‑X 1.0 defines five profiles of increasing richness. In summary, these are: [fnfe-mpe.org]

MINIMUM: This is the most basic profile, containing only the minimum invoice information required in certain contexts (specifically, it was aligned with the minimal requirements of the French Chorus Pro B2G portal). It covers essentially the invoice header data and totals, with no line item details. In practice, MINIMUM includes fields like invoice ID, dates, seller/buyer identification, total amount, VAT amount, etc., just enough for a simple invoice verification or manual capture akin to OCR of a paper invoice. It’s comparable to what an “OCR header data capture” would yield. This profile ensures even the smallest suppliers can produce a compliant e-invoice structure without having to provide every line detail (for example, a simplified invoice or a flat-fee service invoice might use this). However, it omits itemized data, so it is not EN 16931-compliant (which expects line level detail). It’s mostly intended for cases where a full breakdown is unnecessary or unavailable but a structured invoice is still desired. [fnfe-mpe.org]
BASIC WL (Basic Without Lines): This profile extends the Minimum by including most required or useful information at the document (header) level, but still “Without Lines” (WL). BASIC WL provides all key invoice totals and allowances, tax breakdowns per rate, etc., that buyers typically need for processing, except it does not include the individual line items. It’s meant for use cases like summary invoices or where line-level detail isn’t needed by the buyer for automation (maybe the buyer only cares about the total and tax). BASIC WL ensures that, aside from line specifics, the rest of the invoice data (like payment terms, references, tax point date, etc.) can be structured. It’s a stepping stone for businesses who can supply header data but not line-by-line structured data. Since EN 16931 inherently includes line items in its core model, BASIC WL is not fully EN 16931-compliant either, but it’s closer, covering the “envelope” information. [fnfe-mpe.org]
BASIC (with Lines): This profile takes BASIC WL and adds core line item details. That means each invoice line’s description, quantity, price, and line-level amounts are included. BASIC profile is essentially the first profile that contains an itemized invoice. However, it might still be a subset of all possible data – for example, it likely includes the necessary line data and invoice totals, but perhaps not every optional field like payment banking details or extended references. The Factur‑X specification describes BASIC as containing “the core line information required or useful for buyers for automation”. This suggests BASIC is designed to meet typical procurement needs: the buyer can reconcile line items with purchase orders or deliveries because they are present. BASIC profile may approach EN 16931 compliance, but not fully, depending on exactly which fields are omitted. (It might exclude some less common data that EN 16931 would allow/expect, but all legally vital and most process-important fields are there.) BASIC is likely adequate for many B2B transactions where full compliance isn’t mandated but efficiency is wanted. [fnfe-mpe.org]
EN 16931 (also called COMFORT in some contexts): This profile corresponds to the full set of invoice information in the European Norm EN 16931. Using this profile means the invoice XML contains all mandatory and optional core elements defined by EN 16931-1. In other words, an invoice at this profile should be completely compliant with the European standard’s semantic model and rules. It includes detailed data such as payment instructions, order references, item classifications, and so forth, in addition to everything from the BASIC profile. An EN 16931-profile Factur‑X invoice can be considered a “fully standardized” electronic invoice – it has all the data needed to meet public procurement standards and to satisfy Article 226 requirements (with structured fields for each). This profile is the one to use if interoperability and compliance are paramount (e.g., sending an invoice to a government entity under Directive 2014/55/EU, or ensuring readiness for future mandates). Factur‑X at this profile essentially mirrors a standard EN 16931 UBL or CII invoice, just packaged in a PDF. [fnfe-mpe.org] [ec.europa.eu]
EXTENDED: The Extended profile is intended for invoices that require additional data beyond the EN 16931 core. This could include industry-specific information, national requirements not in the core standard, or other details agreed bilaterally. In Factur‑X 1.0, the Extended profile was initially “under construction”, and subsequent updates (Factur‑X 1.0.6/1.0.8) have refined it. Extended contains all EN 16931 data (just like the EN 16931 profile) plus some extra fields or sections. For example, Extended might allow additional invoice line sub-details, or new data groups for things like transport information, or other tax information required in certain regimes (the Factur‑X 1.0.8 update mentions sub-line items for kits/bundles added for Extended to meet French/German fiscal needs). Essentially, Extended is a superset for broader use cases. However, by going beyond the core, it may not be strictly conformant to EN 16931 (the extra elements are not defined in the core standard). Such additions must typically be integrated in a way that doesn’t break receivers’ ability to process core data (often by using defined extension mechanisms in the XML standard). Factur‑X notes that Extended profile is designed to accommodate reforms like forthcoming continuous transaction controls (CTC) in France or specific German requirements. We can also infer that within Extended, there may be subsets like “EXTENDED-CTC-FR” for the French specific needs and others. [fnfe-mpe.org] [fnfe-mpe.org], [fnfe-mpe.org]

To summarize profile usage: Minimum and Basic WL are lightweight and might omit lines (suitable for simpler invoices or phases), Basic adds lines (suitable for most commercial invoices where moderate detail suffices), EN 16931 profile is the full compliance level meeting the European standard, and Extended goes further for specialized needs. Profiles thus let Factur‑X handle everything from a simplified invoice to a comprehensive one in a controlled way. [fnfe-mpe.org]

3.3 Which profiles are EN 16931‑compliant: Out of the above, the EN 16931 profile (sometimes called “Comfort” in ZUGFeRD documentation) is explicitly designed to be EN 16931-compliant. An invoice in this profile includes all the mandatory core elements and adheres to the syntax and rules of the standard, so it is effectively an EN 16931 conformant invoice embedded in a PDF. Extended profile invoices also include the full EN 16931 core dataset (and then some). If implemented correctly, an Extended profile invoice will contain at least all EN 16931-required information, meaning it covers EN 16931. However, because it has additional data beyond the standard, one might say it is “EN 16931 compliant plus extra.” The core parts of an Extended invoice should pass EN 16931 validation (with perhaps a need to ignore or strip out the extra parts during validation). Indeed, Factur‑X Extended is meant to be based on EN 16931 and remain backward compatible with it – for instance, Factur-X 1.0.8 uses an updated UN/CEFACT schema D22B but still ensures backward compatibility with earlier D16B (which was aligned to EN16931:2017). In practice, both the “EN 16931” profile and the Extended profile can produce invoices meeting the European standard’s requirements, with Extended including extras that a receiver might ignore if not needed. On the other hand, the lower profiles (Minimum, BASIC WL, BASIC) are not EN 16931-compliant invoices because by design they leave out some of the core elements or violate some cardinality rules of EN 16931. For example, EN 16931 expects at least one line item with certain details; a MINIMUM or BASIC-WL profile invoice might not have line items in the XML, so it does not fulfill the standard’s model for a full invoice. Similarly, EN 16931 defines certain data as mandatory (like invoice total amounts, tax details per rate, buyer’s reference if needed by process) – the lower profiles might not include some optional-but-important fields at all. Thus, only when using the full EN 16931 profile (or Extended, which includes it) can a Factur‑X invoice be considered fully EN 16931-compliant. This distinction is crucial: if a business needs to comply with an official e-invoicing requirement (like a B2G mandate referencing EN 16931), they must use at least the EN 16931 profile of Factur‑X. Using a lesser profile would result in an invoice that might be legally acceptable (if it still contains the legally required fields) but not conformant to the European standard that, for instance, a government platform expects. In summary, EN 16931 profile = compliant, Extended profile = compliant (with extra data), while Basic and below = not compliant with EN 16931. They provide structured data but not the complete set defined by the norm. [fnfe-mpe.org]

3.4 Which profiles are not EN 16931‑compliant: As indicated, the Minimum, BASIC WL, and BASIC profiles fall short of full EN 16931 compliance. They are subsets:

MINIMUM profile lacks line item detail and many of the informational elements that EN 16931 considers core (like at least one line with price, and possibly missing things like buyer’s reference, payment means, etc. which EN 16931 has as optional elements but often needed in practice). It is geared towards a simplified invoice scenario and thus by itself does not satisfy the complete semantic model of EN 16931. It’s not intended for cross-border or public sector e-invoicing where EN 16931 is required; rather, it’s for cases where a very basic e-invoice is enough (often accompanied by manual steps).
BASIC WL (Without Lines) is closer but still omits line items, which are a fundamental part of the EN 16931 model (EN 16931 assumes an invoice can have 1..n line items, where details like quantity, unit price, and line amount reside). A BASIC WL invoice would violate that assumption by having 0 line items and just summary info. Hence, it’s not conformant to EN 16931. It might be acceptable for certain summary invoice uses, but not for a scenario that demands EN compliance.
BASIC (with lines) is a partial implementation of EN 16931. It actually does contain line items, so at first glance it comes much closer to compliance. The key difference is likely that BASIC might not include all optional elements that EN 16931 defines. For example, EN 16931 includes data like “Buyer’s purchase order reference” (optional BT-13), “Deliver to address” (if different from buyer), “Payment terms”, etc. Possibly the BASIC profile does not require all of those to be present; it might prioritize only what most buyers absolutely need. Also, EN 16931 has some corner-case data (like detailed allowance charge reasons, multiple tax subtotals for mixed VAT scenarios, etc.) which BASIC might simplify. Therefore, while a BASIC profile invoice might pass many of the core checks, it cannot be guaranteed to meet every requirement or rule of EN 16931, especially those for completeness. It is therefore not formally EN 16931-compliant. It is, however, closer to compliance than Minimum or Basic WL – you could say BASIC is a “core invoice” but not the full “core invoice plus all extended elements” that EN expects for universal interoperability.

From a legal-technical standpoint, using a non-compliant profile means the invoice should not be labelled or assumed to meet the European standard. It’s important because some might misconstrue that if it’s Factur‑X, it’s automatically the EU standard – but as we see, only certain profiles truly fulfill that. The specification explicitly notes, for instance, that only the “EN 16931” profile corresponds to all information in the European Norm, implying the others do not. In practice, an invoice in Minimum or Basic profiles might still meet basic VAT law if it includes the required fields from Article 226 (for example, a Basic-WL could still list total amount, tax amount, parties, which covers many legal requirements), but it wouldn’t meet the additional completeness and structured detail that EN 16931-standard e-invoices have. [fnfe-mpe.org]

3.5 Why compliance depends on profile selection, not the file itself: This is a critical point – just because you have a “Factur‑X” file does not inherently tell you if it’s fully compliant with EN 16931 or all legal requirements. The compliance level is determined by the profile used. Factur‑X is essentially a container format that can carry varying amounts of data. If one chooses a lower profile, the resulting invoice will intentionally omit some data that EN 16931 (and possibly VAT law in certain scenarios) would expect. Conversely, choosing the EN 16931 profile ensures the file carries the complete data set. The mere presence of a Factur‑X logo or the .pdf file doesn’t guarantee anything about content completeness – only the profile tag does. This is why in Factur‑X metadata, the profile is clearly indicated (often by a specific URI or code in the XML or PDF metadata), and often service providers will mark the PDF with a small badge for the profile. For example, an invoice might explicitly indicate “Profile: BASIC” within its XML metadata; a processing system reading that knows it should not assume all EN 16931 fields are there. If the system requires a fully standardized invoice, it would reject a BASIC profile as insufficient.

From a standards perspective, this design was chosen to maximize flexibility. It allows phased adoption (someone can start at Basic and later move to EN 16931 profile as they upgrade their systems). But it does mean one cannot say “We use Factur‑X, therefore we comply with the EU e-invoice standard” without specifying which profile. If the profile is not EN 16931 or higher, that statement would be false. Thus, compliance with EN 16931 (semantic standard) depends on using the appropriate profile (EN 16931 or Extended) and populating it correctly, not simply on using the Factur‑X format in general. Similarly, VAT compliance might depend on including certain data that some profiles don’t include by default. For instance, suppose a VAT law requires an invoice to show a tax representative’s VAT number if the supplier is abroad (as per Article 226(15)). If a business were to use the “Minimum” profile, it might not have a dedicated field for that (just as a hypothetical – likely that field could be included even in Minimum via references, but you get the idea). That invoice could then be legally non-compliant even though it’s a Factur‑X file. The remedy would be: either use a richer profile or include that info in an existing field (like an additional note) – but the clean solution is to use the correct profile that has a structured place for it. [vatupdate.com]

In summary, the profile essentially dictates the compliance scope: Factur‑X files at low profiles are only partially compliant with the full standard (and only guarantee minimal legal compliance), whereas at the full profile they are fully compliant. Thus, saying “Factur‑X is EN 16931 compliant” is only true if the invoice is specifically in the EN 16931 profile of Factur‑X. Users must select the profile based on the compliance needed: if you need to adhere to EU standard and B2G requirements, use EN 16931 profile; if you just want some basic structure for convenience, you might opt for Basic or Minimum, understanding the limitations. The Factur‑X specification itself emphasizes profiles to prevent miscommunication – so that the receiver knows how to treat the invoice data. It avoids a scenario where a sender omits data thinking it optional, and the receiver expecting full data per EN 16931 gets an unpleasant surprise. By clearly flagging the profile, Factur‑X ensures that responsibilities and expectations are clear: compliance is a choice of profile. [fnfe-mpe.org]

Relationship with EN 16931

4.1 Factur‑X as a carrier of EN 16931 semantics: Factur‑X’s relationship to EN 16931 can be succinctly described as that of a carrier or container. EN 16931-1:2017 is the European Standard that defines what data an e-invoice should contain (the “core elements” and business terms), but it doesn’t prescribe exactly how that data must be formatted in a file – that’s handled by syntaxes. Factur‑X takes EN 16931’s semantic content and carries it within a hybrid file format. In fact, Factur‑X bills itself as “the first implementation of the European Semantic Standard EN 16931”. This means that if you peel away the PDF wrapping, the structured data inside a Factur‑X invoice corresponds directly to EN 16931-defined elements. For example, EN 16931 defines an element BT-24 “Invoice Total Amount with VAT”. In a Factur‑X (EN 16931 profile) XML, you will find exactly that amount in the corresponding tag (in UN/CEFACT CII XML it might be <TotalInvoiceAmount> under the applicable aggregate) – which is the same conceptual data as BT-24 of the standard. Essentially, Factur‑X uses EN 16931 as its blueprint for the XML content. It does not alter definitions; if EN 16931 says an invoice can include Payment Instructions, Factur‑X provides a place for it in XML. If EN 16931 says an element is mandatory (e.g. an Invoice Number), Factur‑X requires it in relevant profiles. Thus, Factur‑X acts as a delivery vehicle for the EN 16931 semantics, ensuring that the structured information in every compliant Factur‑X invoice is interpretable in the same way as any EN 16931 invoice. For this reason, one can convert a Factur‑X XML to another EN 16931-compliant format (like UBL XML) with straightforward mappings, since the underlying data fields have the same meaning (thanks to adherence to the standard). In summary, Factur‑X’s XML is basically EN 16931 data in a UN/CEFACT XML syntax, packaged in a PDF. It carries the standard’s content faithfully. By doing so, Factur‑X ensures that it remains interoperable: a system or validator built for EN 16931 (say one used for PEPPOL or by a government) will recognize the data in a Factur‑X file (provided the XML is extracted) as valid invoice data per the European standard. The PDF aspect doesn’t affect the semantic content – it’s just embedding. Therefore, Factur‑X’s core relationship to EN 16931 is that of strict alignment and containment: Factur‑X = EN 16931 semantics + packaging. [fnfe-mpe.org]

4.2 Semantic compliance vs hybrid format: It is important to distinguish between semantic compliance and the format (syntactic) choice. Semantic compliance means that an invoice’s content meets the requirements and definitions of the EN 16931 standard: the right data elements are present, and the business rules are respected, regardless of how the invoice is physically represented. A hybrid format like Factur‑X is one way to represent those semantics, mixing a human-readable part with the machine-readable part. One could also represent the same semantics in a purely XML format (like an XML file sent via web service) or even in an EDIFACT message with appropriate mapping. The format is just the vessel, whereas semantic compliance is about the integrity and completeness of the information. Factur‑X demonstrates that you can be semantically compliant while using a hybrid format: the XML inside ensures semantic compliance, and the PDF is an extra. The presence of a PDF in the file does not change the semantics; it’s orthogonal. Conversely, one can use a pure XML format and still not be semantically compliant if that XML is missing required info or using a non-standard structure. The EU Directive 2014/55/EU explicitly called out the need for semantic interoperability as distinct from syntactic interoperability. Factur‑X addresses semantic interoperability by embedding the standardized data model (thus preserving meaning unambiguously), and it addresses one aspect of syntactic interoperability by using an accepted syntax (UN/CEFACT XML). However, as a hybrid, Factur‑X went a step further to incorporate a second syntax (PDF for presentation). From a compliance perspective: a Factur‑X invoice could be semantically compliant (all required data is there and correct) but one might ask if the hybrid nature adds any compliance burden. Typically, it doesn’t – as long as the XML is correct, the existence of the PDF doesn’t break compliance. It’s akin to carrying an “extra copy” of the invoice (the visual copy) with the official structured one. Provided the two copies match, semantic compliance is assured by the structured copy. One nuance: semantic compliance deals with meaning and content, whereas the hybrid format deals with usability. Factur‑X ensures semantic compliance is achievable without sacrificing readability. It’s also worth noting that Factur‑X did not attempt to change the semantics; for example, it did not create new data fields just for PDF or anything – it stuck to EN 16931’s semantics. Thus, using Factur‑X versus using, say, a pure UBL invoice, does not change what the invoice conveys – only how it’s packaged. In summary, an organization could be semantically compliant with EN 16931 (i.e., “speaking the same data language”) whether they use Factur‑X or another syntax. Factur‑X’s hybrid format is simply one implementation choice, and it doesn’t compromise semantic compliance; on the contrary, it was designed to maintain it. The key message is: one must ensure semantic compliance first (the invoice actually contains all the core information, structured correctly); the choice of a hybrid or pure format is secondary and should serve operational needs. Factur‑X happened to serve the need of combining human and machine needs in one format, all while keeping semantic fidelity to EN 16931. [ec.europa.eu] [eur-lex.europa.eu]

4.3 Why Factur‑X does not modify EN 16931: Factur‑X was explicitly engineered not to be a divergent standard, but to piggyback on EN 16931. It does not modify the EN 16931 data model; instead, it implements it. There are multiple reasons for this approach. First, EN 16931 was the result of a broad consensus process across Europe, involving industries, governments, and providers – it represents the agreed set of core invoice information. Deviating from it would defeat the purpose of interoperability and legal alignment. Thus, Factur‑X, being a Franco-German initiative aligning with EU goals, deliberately stuck to the EN 16931 definitions so that any invoice data field in Factur‑X is directly traceable to a corresponding field in EN 16931 (or an extension, in the Extended profile, that doesn’t override the core fields). For instance, Factur‑X uses the UN/CEFACT CII D16B schema in version 1.0, which was one of the two approved syntaxes for EN 16931. That schema was itself crafted to fulfill the EN 16931 semantic requirements. So Factur‑X’s XML is inherently following the standard’s structure (all the way down to element names and cardinalities defined by the CII syntax). Additionally, Factur‑X’s updates track EN 16931’s updates: e.g., Factur‑X 1.0.8 / ZUGFeRD 2.4 was “fully aligned” with the biannual update of EN 16931, meaning when CEN updated code lists or rules in the standard, Factur‑X incorporated those changes to remain consistent. This shows a commitment not to fork away from EN but to mirror it. Factur‑X does introduce the notion of profiles (which EN 16931 by itself doesn’t define, aside from the concept of Core Invoice Usage Specifications (CIUS) which are subsets for specific use). But profiles like Minimum or Basic are essentially subsets of EN 16931, not new semantics. They omit certain EN fields for simplicity, but they don’t redefine fields. And at the top profile, Factur‑X includes everything EN 16931 does. So one can say Factur‑X stays within the EN 16931 semantic framework. It doesn’t, for example, rename data elements or change their meaning, nor does it require any data that would violate EN 16931’s rules (except in Extended where additional data is added, but even then it tries to do so in a controlled way). [eur-lex.europa.eu] [fnfe-mpe.org]

Another angle: the Directive 2014/55/EU and EN 16931 require that usage specifications (like CIUS or extensions) must not contradict the core standard – they can only restrict or add optional info, but cannot alter meaning of core elements. Factur‑X honors this by never modifying what a core element represents. If EN 16931 says BT-7 (Buyer VAT ID) is required in certain cases, Factur‑X ensures there is a place for it and that rule is applied; it doesn’t rename BT-7 or treat it differently. Factur‑X’s guideline document supplements EN 16931 documentation rather than replacing it. Users of Factur‑X are even referred to read the EN 16931 documentation in parallel. This all underscores that Factur‑X’s creators see the format as strictly conformant to the standard, not a separate standard. In practical terms, this non-modification is why a Factur‑X invoice can be processed by any tool built for EN 16931 CII invoices – the tool wouldn’t need to know any “Factur‑X specifics” besides how to extract the XML from PDF. The data inside is regular EN 16931 content. [docs.peppol.eu] [fnfe-mpe.org]

In summary, Factur‑X does not modify EN 16931 because its very purpose is to implement EN 16931 faithfully while adding a PDF layer. Deviating from EN 16931 would break its acceptance and interoperability, so instead Factur‑X stays fully within EN 16931’s semantic boundaries, making only pragmatic allowances (like profiles) that omit some content when appropriate but do not alter the core set. One could say Factur‑X is a “presentation wrapper” around EN 16931 data, not a new data standard itself.

4.4 Limits of extensions and additional data elements: While Factur‑X at the EN 16931 profile covers the standardized core, the Extended profile and possible custom usage do allow additional data elements beyond the core. However, these extensions are limited in scope and must respect certain constraints to avoid interoperability problems. The European standard EN 16931 permits extensions in a controlled way – specifically, through the concept of an “Extension” element in the XML syntaxes or via defined CIUS (Core Invoice Usage Specifications) that add requirements or optional elements for particular sectors or countries, as long as they do not conflict with the core. Factur‑X’s Extended profile is essentially one such extension mechanism: it adds “some additional invoice data” on top of the core. The limits of these extensions are that they should not interfere with core processing. For example, if an Extended profile invoice includes extra information (say, detailed delivery schedule data or sub-line breakdowns for a bundle item), that extra info should be in places that systems not aware of them can safely ignore. In practice, that might mean using the Additional Supporting Documents section (where you can attach further references or data) or adding new elements in the structured format that are outside the scope that standard validators check. In UN/CEFACT CII, one could include additional binary attachments, or use defined extension nodes to carry custom data. Factur‑X 1.0.8 mentions addition of “sub-line management for subtotal lines or kit components” to meet some domestic needs. This is an example of extension – they expanded the format to handle something not originally in EN 16931. The limit here is that any receiver not specifically updated for that might not process those sub-lines, though it wouldn’t break the reading of the rest (the main lines and totals would still make sense). Another limit is that any extension must still comply with VAT law – e.g., you could add extra descriptive fields, but you cannot use an extension to exclude a legally required piece or to contradict something (e.g., you shouldn’t modify tax amounts via an extension in a way that conflicts with core calculations). [fnfe-mpe.org]

Moreover, when an extension becomes widely needed, the expectation is that it should eventually be standardized or at least documented in a CIUS. For instance, Germany’s XRechnung (a CIUS of EN 16931) and France’s upcoming CTC requirements might define certain additional data or code usages – Factur‑X’s Extended profile is tailored to accommodate those by providing a superset that still “complies with the European Norm EN 16931” but has room for extras. Those extras are often tagged or contextual so that if a recipient doesn’t understand them, they can ignore them without loss of required info. One risk with extensions is fragmentation – if everyone adds proprietary fields, interoperability suffers. The Factur‑X approach mitigates this by centralizing extension usage in the Extended profile and even subdividing that into known “reference profiles” for specific contexts (they mention “EXTENDED-CTC-FR” for France’s needs). This ensures that even extensions are implemented in a standardized way for those use cases, rather than arbitrary per user. [fnfe-mpe.org]

In summary, Factur‑X allows additional data through its Extended profile primarily, but places limits: all core EN 16931 data must still be present (Extended is a superset, not a different set); the extra elements must not contradict or obscure the core (so core remains trustworthy); and ideally the extra elements follow known specifications if they are meant for wider use (like a national CIUS). If an extension is outside any standard, it risks not being used by the receiver and thus provides no mutual benefit (or worse, causing confusion). Thus, the Factur‑X community fosters aligning extensions with actual public requirements (like those from French tax authorities or German finance ministry as noted). The limit of additional data elements can be summed up as: they can extend, but not break, the standard. They are essentially optional layers that specific parties can use, but they must maintain backward compatibility with EN 16931 so that ignoring them still leaves a valid EN 16931 invoice. [fnfe-mpe.org]

4.5 Alignment with CEN rules and CIUS constraints: CEN (the European Committee for Standardization) set forth not only the base standard EN 16931 but also guidelines for implementing it in specific contexts (Core Invoice Usage Specifications, or CIUS, and Extensions). A CIUS is essentially an allowed customization of EN 16931 for a particular use case, typically by restriction (removing optional elements, fixing certain code values, etc., to meet national or industry requirements). Factur‑X supports CIUS implementation: for example, the XRechnung format mandated in German public procurement is a CIUS of EN 16931. Factur‑X is designed such that it can carry an XRechnung-compliant invoice in its XML portion – indeed, Factur‑X 1.0.8 explicitly mentions that both Factur‑X and ZUGFeRD “allow the use of reference profiles, such as XRECHNUNG for Germany”. This means that Factur‑X’s XML can include or be marked with the specific ProfileID/CustomizationID that indicates XRechnung, and the data should then obey XRechnung’s stricter rules. The Factur‑X PDF doesn’t impede that; it’s just an envelope. So alignment with CEN rules: Factur‑X follows the rules that a CIUS or extension must not conflict with the core. If a CIUS says “these elements are mandatory and those code values from the standard list must be used,” a Factur‑X invoice for that CIUS will reflect that. The profile concept in Factur‑X is somewhat analogous to a CIUS: e.g., “Factur‑X EN 16931 profile” is basically the core invoice (like a baseline CIUS for general use), and then “Factur‑X Extended-CTC-FR” might be considered a CIUS for French Continuous Transaction Controls, etc. The key is that Factur‑X’s structure is compatible with these constraints. It uses the same data model, so applying a CIUS (which is essentially a set of additional constraints or clarifications on EN 16931) to a Factur‑X invoice is natural. [docs.peppol.eu] [fnfe-mpe.org]

Also, the mention that each profile has its own Schematron which will be updated according to EN 16931 validation artefacts indicates alignment – whenever EN 16931’s official validation (maintained by CEN/TC 434) changes, Factur‑X adjusts its validation rules. This shows an ongoing compliance with CEN’s work. [fnfe-mpe.org]

In terms of operational alignment, some countries required a specific format (like UBL for XRechnung). Germany initially did not accept PDF-based hybrid for B2G (they wanted XML via channels), but the fact that Factur‑X technically can carry an XRechnung means it’s aligning with that content, if not the delivery mechanism. Meanwhile, in France, Factur‑X is endorsed as a format for B2G (Chorus Pro accepted Factur‑X PDFs) and upcoming B2B. That itself became formalized in an AFNOR (French standard body) specification XP ZUG… which is aligned with Factur‑X. So Factur‑X’s existence in official context shows it respects the national CIUS while packaging it conveniently. E.g., a Factur‑X invoice to French government could include the mandatory Chorus Pro fields (which are basically EN 16931 plus mandatory Purchase Order reference sometimes); Factur‑X’s Minimum profile was even defined by “minimum info required on Chorus Pro” – illustrating how profiles map to usage constraints. [fnfe-mpe.org]

Thus, Factur‑X did not try to override any CEN or CIUS decisions; rather it adapted to them. The German XRechnung (a CIUS) and the French core invoice model are both implementable in Factur‑X. Indeed, Factur‑X 1.0.8 mentions that Factur‑X is compatible with “reference profiles” like XRechnung and also defines one for French needs. This means Factur‑X is essentially hosting CIUS-defined data sets, not inventing new ones. [fnfe-mpe.org]

To sum up, Factur‑X aligns with CEN and CIUS rules by: (a) strictly following EN 16931 for core data, (b) allowing restriction or specialization where needed for CIUS (which is often implemented by Schematron or specific profile selection), and (c) providing fields or extension mechanisms to include any extra data that a national spec might require (like certain reporting elements), while making sure the core remains intact and backward compatible. This ensures that using Factur‑X does not exempt one from any national e-invoicing requirements – one still adheres to those, just using Factur‑X as the carrier. In other words, Factur‑X essentially says: “Whatever your CIUS or rules are, I can package an invoice that meets them, plus I’ll give you a PDF for convenience.” But it will not break the common standard, thus remaining within the CEN framework. [fnfe-mpe.org]

Relationship with Article 226 of Directive 2006/112/EC

5.1 Mapping of Article 226 VAT invoice elements to EN 16931 / Factur‑X data: Article 226 of the EU VAT Directive (2006/112/EC) lists the details that must appear on a VAT invoice for it to be valid for VAT purposes. There are 15 points, including: the date of issue, a unique invoice number, the supplier’s VAT number, the customer’s VAT number (in certain cases), full name and address of supplier and customer, description/quantity of goods or services, the date of supply if different, the taxable amount per rate, any discounts, the VAT rate, the VAT amount payable, and in special cases certain mentions like “Reverse charge” or “Self-billing” or references to VAT exemption provisions. EN 16931’s semantic model was explicitly designed to cover these legal requirements: Recital 23 of Directive 2014/55/EU emphasizes that the European e-invoice standard “should be consistent with” the elements required by VAT Directive Article 226. Consequently, each Article 226 element maps to one or more data fields in EN 16931, and thus to fields in a Factur‑X invoice. [vatupdate.com], [vatupdate.com] [ec.europa.eu]

For example:

Article 226(1) “the date of issue” is captured in EN 16931 as Business Term (BT) “Invoice Issue Date”; in Factur‑X’s XML this appears in a date element (in CII it’s <ExchangedDocument/IssueDateTime>). It will also appear on the PDF as the invoice date. [eur-lex.europa.eu]
Article 226(2) “a sequential number… which uniquely identifies the invoice” corresponds to EN 16931’s Invoice Number (BT-1). Factur‑X XML has an element for the invoice ID, and the PDF would display the invoice number. [eur-lex.europa.eu]
Article 226(3) and (4) require the supplier’s and customer’s VAT identification numbers. EN 16931 includes these as Seller VAT Identifier (BT-31) and Buyer VAT Identifier (BT-48). In Factur‑X, those are present in the XML (under the Party identification segments), and typically also printed on the PDF. [eur-lex.europa.eu], [eur-lex.europa.eu]
Article 226(5) name and address of supplier and customer correspond to EN 16931 BT-27, 28 (Seller name, address) and BT-44, 45 (Buyer name, address). Factur‑X carries these in structured form (address lines, city, country code, etc.) and the PDF shows the addresses. [eur-lex.europa.eu]
Article 226(6) description and quantity of goods/services map to the invoice line level in EN 16931: each invoice line has a BT-130 (Item name/description) and BT-129 (Invoiced quantity), etc. Factur‑X includes line item sections in its XML for these, and the PDF lists them in the invoice table. [eur-lex.europa.eu]
Article 226(7) the date of supply if it’s different from issue date – EN 16931 provides a field at invoice or line level (BT-72, “Actual delivery date”, for example). Factur‑X XML will have an element for delivery or service date when applicable, satisfying this requirement. [eur-lex.europa.eu]
Article 226(8) and (9) taxable amount per rate, and VAT rate – EN 16931 includes a breakdown by VAT category: each invoice has tax subtotal entries (BT-115 Taxable amount, BT-118 VAT amount for each tax category, BT-119 Tax rate). Factur‑X XML has a section for Tax Total and tax breakdown (in CII, within <SupplyChainTradeTransaction>), so one can enumerate each VAT rate’s base and amount. These correspond exactly to Article 226’s requirement to show the breakdown per rate. The PDF usually shows a tax summary table as well. [eur-lex.europa.eu], [eur-lex.europa.eu]
Article 226(10) the VAT amount payable – EN 16931 has BT-112 (Invoice total VAT amount) and BT-115 (the sum of VAT amounts per rate), plus BT-109 (Invoice total with VAT). Factur‑X will have a total VAT figure in XML (and obviously on the PDF invoice totals). [eur-lex.europa.eu]
Article 226(10a) if the customer issues the invoice (self-billing), the mention “Self-billing” must be present. While this is a textual requirement, EN 16931 anticipates it: it has BT-1 (invoice number) but doesn’t directly have a “self-billing flag” in the core; however it allows for a note or invoice type code. Typically self-billing is indicated by setting the Invoice Type Code to a value that implies self-billing, or by including the literal text “Self-billing” as a note. Factur‑X can accommodate that: either through an element (like <TypeCode> set to a code for self-billing) or through the <ExchangedDocument/Name> or a <Note> field where the phrase can be put. The French/German spec itself doesn’t automatically add the text on PDF, so the supplier (or self-biller) must include it in the PDF content and ideally in the XML note. Nonetheless, the key is Factur‑X doesn’t remove this possibility; it supports it (the mention would simply appear in both representations). We see in Article 226 listing (10a) that “Self-billing” must appear where applicable, and Factur‑X implementers ensure that happens (likely through process or customizing the template). [vatupdate.com]
Article 226(11) if exemption, need a reference to law or statement it’s exempt. EN 16931 includes BT-120 (VAT exemption reason text) and BT-121 (VAT exemption reason code). Factur‑X’s XML has fields for these, allowing the invoice to explicitly state e.g. “VAT exempt under Art. X of Directive/Local law”. On the PDF, that text would be printed near the tax or line details. Thus Factur‑X supports showing the reason for 0% VAT, satisfying Article 226(11). [eur-lex.europa.eu]
Article 226(11a) if the VAT is reverse-charged to the customer, the invoice must say “Reverse charge”. Similarly, EN 16931 provides a way: typically a special VAT category code (like “AE” for reverse charge) and again possibly a note. The directive expects the phrase explicitly, so usually implementers include a note “Reverse charge”. Factur‑X can carry that in a <Note> field in XML (there is BT-17 “Invoice note” for such texts) and obviously present it on the PDF. [vatupdate.com] [eur-lex.europa.eu]
Article 226(12)-(14) cover special schemes: new means of transport details, margin schemes for travel agents, goods, art, etc. These are rather niche. EN 16931 doesn’t define detailed fields for new means of transport (as those invoices usually occur in cross-border car sales, and the law requires listing e.g. odometer reading, engine capacity etc.; that might be outside EN 16931’s standard data groups). If needed, such info could still be included either as line description or an additional supporting document. For margin schemes, EN 16931 doesn’t have a fixed field to say “Margin scheme – second-hand goods”, but if applicable, the invoice must contain that text. So again the way is via a Note or via specifying a special code on each line’s tax category (some localized implementations do that). Factur‑X doesn’t inherently list those phrases, but one can include them (for instance, adding a note on the invoice “Margin scheme – …” in the PDF and duplicating it in the XML’s notes). The key is that Factur‑X does not impede including any legally required notes – all such text can be placed in either <IncludedNote> elements or appropriate description fields in the data and will appear on the PDF. Article 226(13)-(15) essentially demand these specific mentions for special cases. While EN 16931’s core might not enumerate all those, it provides the needed placeholders (notes, reference fields). The European standard insisted that “any other references indicating an exemption” etc. should be consistent – meaning an e-invoice should carry them in a designated way. Factur‑X is flexible enough to include them either as structured data (if a code list covers them) or as textual notes. [ec.europa.eu]

Therefore, for every item in Article 226, there is a mapping into the EN 16931 data model, and Factur‑X, by following EN 16931, inherently supports each of those items. When a Factur‑X invoice is generated in practice, software often explicitly maps the required VAT Directive fields to the EN 16931 fields. For example, one French government guide or the CEN workshop might publish a mapping table: (Article 226 (5) “Name and address” -> EN 16931 BT-27, BT-28 etc.). Factur‑X would then include BT-27,28 in XML and show name/address on PDF.

In summary, all legal elements mandated by Article 226 appear in a properly populated Factur‑X invoice. The design principle of EN 16931 was to ensure that, as Recital 23 says, the presence of those elements is indispensable and the standard is consistent with them. Factur‑X carries that forward. For instance, a fully compliant Factur‑X (EN 16931 profile) invoice will include: Issue date, Invoice number, Seller and Buyer VAT numbers, Seller and Buyer names and addresses, each line’s description and quantity, line or invoice level supply date if needed, net amounts per VAT rate, each VAT rate and amount, total VAT, total gross, and any mandated notes (“Reverse charge”, etc.). Thus the mapping is exhaustive and one-to-one: there is nothing in Article 226 that cannot be represented in Factur‑X. [ec.europa.eu] [eur-lex.europa.eu], [eur-lex.europa.eu]

5.2 Where Factur‑X goes beyond VAT law: VAT law (Article 226) specifies the minimum content required for VAT invoices, but does not cover every piece of information that businesses might need on invoices for commercial or compliance reasons. Factur‑X (through EN 16931) includes data elements that go beyond the strict list of Article 226. For example, EN 16931 provides fields for bank account details of the payee (IBAN, BIC), even though VAT law doesn’t require an IBAN on an invoice. It also includes payment terms and payment due date, again not mandated by VAT directive but very useful for business. Factur‑X’s model (EN 16931) has a place for purchase order references or contract references (BT-13 Buyer reference, etc.), which facilitate procurement automation but are not in Article 226. Another area: allowances and charges – EN 16931 explicitly represents line-level or document-level discounts/surcharges (with reasons), whereas VAT law only implicitly expects that if a discount affects the taxable amount, the invoice should reflect it (Article 226(8) says show discounts if not included in unit price). Factur‑X’s structured data explicitly captures them, which is more detailed than just writing them on paper. Also, EN 16931 includes support for multiple VAT rates and categories in one invoice, with clear per-category breakdown, whereas VAT law simply demands that if multiple rates apply, each be detailed. Factur‑X standardizes how to do that across invoices. In general, Factur‑X/EN 16931 covers a semantic richness that tax law doesn’t specify but business needs often demand. Examples: the standard can carry ship-to and bill-to addresses separately, tax representative information (in some cases beyond just the VAT number), methods of payment, remittance information, and so on. [eur-lex.europa.eu]

Moreover, EN 16931 being a core model means it tried to capture the common denominator for European business invoices – which includes things not in Article 226 but found on typical invoices or required by certain procurement processes. For instance, a Buyer’s reference (like a person or department or code) is often required in B2G invoices so the invoice can be routed internally; VAT law doesn’t mention that, but EN 16931 includes BT-10 “Buyer reference”. Factur‑X can carry that. Another example is line item identifiers and classifications (like item commodity codes, GTINs, etc.) – not needed by tax law, but useful in supply chain automation; EN 16931 (and thus Factur‑X) allows item classification IDs to appear. Similarly, information like project references or delivery notes can be embedded.

By providing these extra data fields, Factur‑X goes beyond what VAT law explicitly asks for, aiming to cover business and interoperability needs. This doesn’t conflict with VAT law; it’s additional. However, from a compliance perspective, including these doesn’t make the invoice any less legally valid – they are just extra information. Actually, some national laws or business contexts might effectively require some of these (e.g., Italian law requires an IBAN on invoices for certain public sector payments – not EU VAT law, but local rule; Factur‑X can include IBAN under PaymentMeans).

So Factur‑X’s semantic scope is broader than the VAT Directive’s checklist. It captures commercial elements (like payment instructions, order numbers) and ensures computational clarity (like unit price vs line total vs totals, which VAT law doesn’t detail but the standard does in structured form). Another area beyond VAT law: Article 226 doesn’t talk about currency explicitly (it’s implied values are in some currency, but not mandated to show currency code if it’s obvious). EN 16931 requires currency codes for all monetary amounts for clarity. Factur‑X thus includes currency metadata, which is beyond a naive interpretation of the Directive but important for cross-border use.

In summary, Factur‑X “goes beyond VAT law” by including all the business and technical information defined in EN 16931 that is not strictly in Article 226. These additions improve invoice processing, automation, and cross-border understanding. They reflect the fact that an invoice is not only a tax document but also a commercial document used between trading partners. Factur‑X, by carrying EN 16931, ensures it can serve both purposes simultaneously.

5.3 Where VAT law goes beyond Factur‑X: VAT law can sometimes impose obligations that are not purely about the fields printed on the invoice. For example, Article 226 is about content, and we’ve mapped those. But there are other aspects in the VAT Directive’s invoicing section (Chapter 3 of Title XI) that aren’t directly represented as invoice data fields in Factur‑X. For instance, Article 219a and 232 regulate which country’s rules to follow for invoicing and needing acceptance of electronic invoices (pre-ViDA) – that’s procedural, not on the invoice face, so Factur‑X doesn’t cover that (that’s about obtaining buyer agreement for e-invoicing, etc.). Article 226b covers simplified invoices (fewer contents allowed for small amounts) – Factur‑X can handle a simplified invoice scenario by using a lower profile, but the decision when you can issue simplified invoice is legal.

Focusing on content: one could argue that VAT law might require some contextual info that is not explicitly a field. For example, one requirement of the VAT Directive (Article 219) is that invoices must be issued in a sequence (unique number) – Factur‑X provides a field for the number, but ensuring uniqueness is up to the issuer’s processes, not the file itself. So the numbering obligation and timely issuance obligations (e.g., Article 222, invoice by 15th next month for intra-EU; Article 226b on simplified invoice conditions) are legal obligations beyond what any format (including Factur‑X) can ensure. Factur‑X can hold a number and date, but it cannot by itself enforce that it was within 15 days of month’s end. That’s on the issuer.

Another area: Integrity and authenticity of the invoice (Article 233 of the Directive) – it requires that the business ensure the invoice’s content isn’t altered and origin is certain (e.g., via business controls or signatures). Factur‑X as a format doesn’t automatically guarantee that (although being PDF, one could electronically sign the PDF to help meet that requirement, which is something outside the core spec but possible). If someone simply exchanges a Factur‑X over email without signature or controlled system, they still need to ensure authenticity/integrity by other means (which could be like an audit trail or agreement). That’s a legal requirement not resolved by the format alone.

In terms of content going beyond Factur‑X: Another scenario could be national additional requirements. While Article 226 is harmonized, some Member States optionally require extra info on invoices under their local legislation (as long as they don’t conflict with EU law). For instance, Italy required an annotation of the protocol number for registered invoices in some contexts (though that’s after issuance), or some countries require the Fiscal Code (tax code) of individuals in addition to VAT number for certain domestic invoices. If those are not part of EN 16931, Factur‑X might not have a dedicated field. Italy’s FatturaPA (not EN 16931 based originally) had fields for things like stamp duty, etc., which Factur‑X/EN 16931 didn’t foresee. Such national requirements are being converged via CIUS, but if any remain outside the core, VAT law in a given country could “go beyond” Factur‑X’s default field set. However, often these can be accommodated in Extended profile or coded in existing fields (like using an AdditionalLegalInfo note).

One concrete example: New Means of Transport sales (Article 226(12) references Article 2(2)(b) with details like odometer reading for vehicles). EN 16931 did not specifically include fields for “odometer reading” or “engine capacity”. So if an invoice is for a new car sold cross-border (which has VAT exempt under certain conditions but requires these details on the invoice), the Factur‑X standardized structure doesn’t explicitly have “Odometer” field. The supplier would have to include that in the item description or an attachment on the invoice. It’s still possible to include, but there’s no dedicated structured field labeled “odometer”. So here, the VAT law’s requirement is beyond what the standard specifically caters to. The invoice is still legally compliant if it shows it (even unstructured), but as far as Factur‑X semantics, it’s not clearly separated (just part of description text). Another example: margin scheme notes – Factur‑X doesn’t have a yes/no field for “Margin scheme applied”; the issuer must put the required phrase as a free text note on the invoice. So legally, the invoice meets Article 226 when that text is present, but Factur‑X doesn’t verify it as a discrete data element. That’s up to the issuer’s diligence.

Thus, while Factur‑X covers the general VAT content, there are edges where VAT law requires a presentation or process that isn’t fully encapsulated in Factur‑X’s structured data. However, these are relatively limited. Another point is archival obligations: VAT law (Article 247-249) says you must keep invoices for X years and ensure data is legible, etc. Choosing Factur‑X (especially PDF/A-3) helps in legibility and durability (PDF/A is good for archiving) and the XML ensures data is preserved. But Factur‑X doesn’t itself ensure you store it for the requisite period – that’s procedural. But if one uses PDF/A, it’s easier to argue you meet “readability over time”.

In summary, VAT law “beyond Factur‑X” mainly refers to procedural or contextual requirements (timeliness, numbering uniqueness, authenticity, buyer’s consent to e-invoice, retention), and a few special content cases not explicitly structured in the standard (like detailing new means of transport specs). Factur‑X doesn’t cover those out-of-band requirements – they must be handled by processes or by inserting needed info in generic fields. The design assumption was that EN 16931 covers all common content needed for general VAT invoices, which it largely does, and anything truly not covered would be rare or handled via extension/notes. [ec.europa.eu]

5.4 Legal primacy of VAT law over standards and formats: No matter how good a format or standard is, it is ultimately subordinate to the law. The VAT Directive and national VAT laws have primacy – meaning if there’s any conflict between what the law requires and what a standard might suggest, the law wins. However, as we’ve seen, EN 16931 was crafted to align with law, not contradict it. But consider a hypothetical: if a country’s law said “invoices must be in language X” or must contain a specific disclaimer, and the standard didn’t explicitly mention that, compliance with the standard alone wouldn’t protect you legally – you’d need to meet that law as well. In practice, the EU VAT Directive is harmonized, so the standard is safe on content. But legal primacy also means aspects like audit requirements or acceptance criteria are governed by law, not by what the format can do. For example, even if Factur‑X can host all needed info, a Member State could by law require an e-invoice to be transmitted through a state portal (like Italy does) – using Factur‑X doesn’t exempt you from that, because that’s a legal mandate about method. Or a tax administration might require you to produce a readable invoice on request; if you stored only XML, you’d legally have to produce a human-readable version – Factur‑X conveniently has one embedded, so that’s good, but the impetus is the law requiring human readability to auditors, not the standard by itself. [ec.europa.eu]

Another angle: If someone implemented Factur‑X incorrectly (say they left out a legally required element by mistake), claiming “but the Factur‑X spec allowed me to omit it in this profile” is not a defense – the law’s requirement still must be met. This is why it’s crucial to pick the right profile for compliance. For instance, issuing a VAT invoice under EU law with the Factur‑X Minimum profile might omit a required detail – then legally that invoice is incomplete, and the company could face issues (like denial of customer’s VAT deduction until corrected). The law would override the fact that the format technically permitted a minimalist invoice. So businesses must use the standard in a way that fulfills the law, not blindly follow the lower spec if it conflicts with law.

The EU Commission in establishing EN 16931 explicitly required the standard to comply with the VAT Directive. If any discrepancy were found, the law would need to be followed and the standard likely updated. Up to now, none fundamental have been observed – the main mismatch was possibly the “new means of transport” details, which the standard doesn’t explicitly have fields for, but those can be handled in free text and thus not considered a conflict but just an omission of structured support. [ec.europa.eu]

To put it succinctly: formats and standards are tools to implement legal requirements, but they do not replace those requirements. A Factur‑X invoice is only legally valid if it meets the criteria of VAT law (complete content, timely issue, authenticity, etc.) – the format itself has no legal force; the law does. This is why, for example, a paper invoice with all Article 226 details is legally valid even if it’s not EN 16931, because law recognizes it. Conversely, an EN 16931/Factur‑X invoice missing a required VAT detail is not legally valid, standard or not.

One concrete demonstration of legal primacy: Many Member States require certain language on invoices for special schemes (as we mentioned). If one omitted those in an EN 16931 invoice because maybe they thought not needed, the tax authority can say the invoice doesn’t meet legal requirements. Another is that legally the buyer must ensure the invoice is correct to deduct VAT – even if it’s a Factur‑X file, if it’s missing something like VAT number of supplier, the tax authority can deny deduction until it’s corrected. The format being standard doesn’t override that necessity. [vatupdate.com]

Therefore, businesses should treat Factur‑X as a means of complying with law, not an independent rule set. In any case of doubt, they must supplement or adjust usage of Factur‑X to fulfill legal obligations. Usually, there’s no conflict because Factur‑X was made to comply, but as we elaborated, certain things like including mandated phrases, etc., must be done by the user.

In conclusion, the VAT Directive (and national VAT acts) holds ultimate authority. Factur‑X and EN 16931 were made to implement it, not supersede it. Whenever using Factur‑X, one must ensure that all Article 226 elements, and any other applicable local invoice requirements, are indeed present in the invoice (the appropriate profile helps with that). If there is any divergence, the law’s requirements must be met even if that means using an extension or in worst case going outside the standard’s comfort zone (though that’s rare). [ec.europa.eu]

To frame it another way: Being “Factur‑X compliant” is not a legal status – being “VAT-compliant” is the necessary status, and Factur‑X can help achieve it, but it’s the law that defines it. This ties into the next section (5A) where we differentiate those terms explicitly.

5A. Reconciling VAT law, EN 16931, and Factur‑X: roles and perspectives

The concepts of legal compliance (VAT law), semantic compliance (EN 16931), format compliance (Factur‑X), and operational interoperability (exchange/controls) are related but distinct. It’s helpful to look at an invoice from four different perspectives:

5A.1 Legal perspective (VAT Directive): Under the legal lens, what matters is whether an invoice fulfills the requirements of VAT legislation. The VAT Directive (2006/112/EC) and national laws based on it dictate what info must be on an invoice and certain conditions for its issuance and acceptance. From this perspective, an invoice is “VAT‑compliant” if it contains all the details listed in Article 226 (or Article 226b for simplified invoices when allowed) and if it respects other invoicing rules (like timely issue, sequential numbering, authenticity & integrity). The law doesn’t specify the format – an invoice can be on paper or in any electronic format as long as those conditions are met. For instance, a simple PDF or Word document can be VAT-compliant if it has all required fields and authenticity measures, even if it’s not structured. Conversely, if a fancy e-invoice in XML misses, say, the customer’s VAT ID when it was required, it’s not legally compliant, regardless of technical format. The legal perspective is concerned with the content and the trustworthiness of the invoice, not how software-friendly it is. It also covers concepts like self-billing agreements, invoice storage and audit, and the right for tax authorities to obtain the data (which increasingly includes e-reporting). Essentially, the VAT Directive is the ultimate checklist – everything on that list must be satisfied by the invoice and the process around it. Terms like “VAT-compliant invoice” mean the invoice meets these legal requirements (which is necessary for things like the customer’s right to deduct input VAT). This perspective is typically the domain of tax managers and legal auditors – they ask: does this invoice pass tax inspection? If not, it could be rejected for VAT purposes. Whether it’s Factur‑X or a napkin, if it has the info, legally it’s an invoice (although a napkin’s authenticity might be questionable!). So the law is both more flexible about format and more demanding about content: flexible because it doesn’t require an XML or specific standard (until ViDA’s future amendment potentially), demanding because missing any detail can jeopardize compliance. [vatupdate.com], [vatupdate.com] [vatupdate.com]

5A.2 Semantic perspective (EN 16931): The semantic perspective is all about standardized meaning and data structure. EN 16931 is the European standard that defines a semantic data model for e-invoices – essentially a structured representation of an invoice that includes certain business terms (BTs) and business rules. Being “EN 16931 compliant” means that an invoice’s data conforms to that model: all required business terms are present, the content follows the allowed code lists, and the business rules (like arithmetic consistency) are respected. This perspective assumes one is using an electronic format that can capture those semantics (like UBL or CII). If an invoice instance adheres to EN 16931, it implies it likely has all legal info (since EN 16931 was made to include those, as discussed), but it also has them in a particular structured way. For example, rather than just a single text block listing “10 widgets at €5 each, VAT 20% included”, the EN 16931 model breaks this into fields: line quantity = 10, line unit price = 5, etc., with a VAT category code = “S” (standard 20% maybe). Semantic compliance cares about coherence (like sums), unambiguous interpretation (like explicit currency codes, unit of measure codes, country codes for addresses, etc.), and the relationships between pieces of data (like each tax subtotal must relate to a rate). It’s not directly about legality (though aligned), it’s about interoperability and clarity. If an invoice is EN 16931-compliant, any software following the standard can interpret it correctly – know who the seller is, what each amount means, how to calculate totals, etc., without human guesswork. Achieving EN 16931 compliance might require adding information that VAT law doesn’t force but which is necessary for clear electronic processing (e.g., indicating invoice currency “EUR” explicitly, or using standardized country codes). From the semantic perspective, if an invoice deviates from the standard model (missing a mandatory BT, using an unrecognized code), it’s considered not compliant, even if legally it might be fine to a human. For instance, if a supplier puts the VAT breakdown only in a PDF table that a human can read, but the XML doesn’t detail each tax category because they used a profile that lumps them, then semantically it fails EN 16931 (which expects each tax category itemized). This perspective is typically of interest to technology teams, e-invoicing interoperability experts, and public procurement systems – they want to know if a given e-invoice will pass the standard’s validation (the European standard came with validation artefacts precisely to test semantic compliance). When we say an invoice is “EN 16931-compliant”, it means if you run it through the official validator, it should pass all checks (like no missing mandatory fields like invoice date, buyer ID, etc., no forbidden elements, and abiding by syntax rules from one of the allowed syntaxes). This is a stricter concept in some ways than pure legal compliance: legal compliance doesn’t care if you label something “Street name” vs “Address line 1” vs “Line 2” as long as address is there; semantic compliance does because it has defined data elements for each part. However, semantic compliance is meaningless if not tied to format – so one usually speaks of EN 16931 compliance in context of one of its syntaxes (like a UBL file can be validated). A paper invoice cannot be “EN 16931-compliant” because that concept applies to a structured data file. [docs.peppol.eu] [eur-lex.europa.eu], [eur-lex.europa.eu]

5A.3 File/document perspective (Factur‑X): This perspective is about the physical or digital format of the invoice file – the container and its format rules. Factur‑X compliance means that a file meets the Factur‑X specification: it is a PDF/A-3 with a correctly embedded XML invoice (in the UN/CEFACT CII format) and proper metadata. From the format perspective, we check things like: Does the PDF contain the XML as an embedded file? Is the XML one of the five profile schemas defined? Is the PDF itself PDF/A-3b or A-3u compliant (all fonts embedded, etc.)? Is the XMP metadata block present linking the XML? These are technical criteria for the file integrity and conformance to the Factur‑X standard. Being “Factur‑X compliant” doesn’t inherently assess the content semantics (though indirectly if the XML must validate against a schema, it ensures some semantic correctness too). It’s possible to have a Factur‑X file that is perfectly structurally correct (PDF with XML) yet the content might be semantically non-compliant or missing a legal element if the wrong profile was used or data omitted. For example, you could (theoretically) have a Factur‑X Minimum profile file that has no customer VAT ID. The file could still be Factur‑X format compliant (proper PDF structure) but it might be missing something needed legally (customer VAT ID is required if it’s reverse charge scenario) and it’s definitely not EN 16931 compliant because Minimum isn’t that. The file perspective is narrower: it deals with file-level interoperability. Can software open this as a valid PDF? Can it extract the XML easily? Does the XML pass the XSD check for that profile? If yes, the file is a valid Factur‑X file. This is important for tooling: PDF readers, archivers, etc. Factur‑X compliance ensures that, for instance, a receiving system knows how to find the XML inside the PDF and that it will parse according to one of the known schemas (Minimum, BasicWL, etc.). It ensures that, if you attach a Factur‑X invoice to an email, the recipient can use software to detect “This is Factur‑X” and handle it properly. It also implies the PDF is not just any PDF, but PDF/A-3 (which is an ISO archival format) – subtle but relevant for compliance with archival rules and also for consistent extraction. So file compliance is about meeting the technical spec given by FNFE/FeRD for Factur‑X. It’s a different checklist than the legal one. A file could be Factur‑X compliant and not legally complete, or vice versa (you could have a legally complete invoice as PDF that’s not Factur‑X because no XML inside). Obviously, the ideal is to achieve all: produce a Factur‑X file (format OK) that contains an EN 16931-compliant XML (semantics OK) carrying all Article 226 info (legal OK). But these are layers. The person looking at file compliance is maybe a interop specialist or software vendor ensuring that “yes, our system outputs the correct Factur‑X structure” or a platform that needs to verify incoming files are indeed Factur‑X and not some random PDF.

5A.4 Operational perspective (exchange, archiving, controls): This perspective is about how invoices flow and are used in practice – beyond just the content or the file format. It covers things like: Through what channel is the invoice exchanged (email, EDI network, PEPPOL, government portal)? How is it processed on receiving (automated import vs manual entry)? How is it stored and retrieved for audits? How do controls (either internal or by authorities) get applied? It’s about interoperability in the real world – ensuring the invoice can be delivered, accepted by systems, and remain accessible over time.

From an operational standpoint, Factur‑X has advantages such as being PDF-based (easy for humans and existing email processes) and having XML (for automation). But certain operational frameworks might insist on pure XML. For instance, some large companies or government agencies might have EDI hubs that expect an XML file upload or a PEPPOL BIS message. In those cases, sending a Factur‑X PDF might not fit their pipeline – even though semantically it’s fine, the channel doesn’t accept PDF. The operational compatibility could require extraction of the XML and re-wrapping it in expected envelope, or conversion to a different syntax. Another operational aspect: archiving and audit. Many companies keep PDFs of invoices for readability; if they had only XML, an auditor might demand a human-readable version. Factur‑X helps here by having the PDF locked in with the XML, so you don’t risk them diverging. Also, any digital signature could be applied to the PDF to ensure the integrity of both representations, which is operationally useful for compliance with authenticity rules. But not all systems are geared to verify or maintain an embedded XML. Some archiving systems might, for example, inadvertently strip attachments or not index the XML content – that’s an operational risk if using Factur‑X in an environment not expecting it.

When thinking of controls: if a tax authority runs data analytics on invoices, it’s easier done on structured data. If you only have images, they might require you to supply additional data. Factur‑X’s structure would facilitate such controls if the data is extracted. But operationally, many tax authorities currently still receive PDFs or papers and then have to trust business records or perform audits. With more digital reporting (like upcoming ViDA requiring transaction data reporting), the operational perspective is shifting toward requiring structured data flows. Factur‑X could be part of that: e.g., a company could still send a PDF invoice to a customer but separately submit the XML to the tax authority’s system. The viability of that depends on the integration of processes. If the company only uses Factur‑X internally or with trading partners and doesn’t do reporting, they’ll have to adapt to new obligations.

Another dimension is international interoperability: Factur‑X is primarily European; if a company deals outside the EU, will Factur‑X be accepted or understood? Possibly not – e.g., in the US or Asia, no one uses Factur‑X. They might require either paper or their own format (like some Latin American countries require XML with their schema and clearance). Operationally, one format doesn’t fit all jurisdictions. So from an operational perspective, a company might need to support multiple e-invoice formats of which Factur‑X is one (for EU trading, especially FR/DE or whenever partner agrees to PDF+XML).

Archiving: Many countries require storing invoices in the original format they were sent/received. If you send a Factur‑X, you have to store that PDF+XML file. Over say 10 years, PDF and XML are standard enough that it should still be readable – PDF/A is an archival standard. That’s a plus (operationally more future-proof). If you only had XML in a custom schema, maybe readability suffers in the long term without special viewer, but PDF covers that. So operationally Factur‑X is strong in archiving because it ensures human readability in the far future (paper equivalent) while still preserving data.

Controls include not just tax but also internal controls, e.g., matching invoice to PO and delivery. Factur‑X’s data part helps automate 3-way match (by pulling PO references, item details). But the PDF also allows a human to look if something fails. Some companies who tried pure EDI ended up also exchanging PDFs as a backup for when data mismatched or integrators needed manual review. Factur‑X bundles these, making it operationally smoother – one file contains what the AP clerk and the AP system both need. That’s why it’s popular with SMEs (lack of advanced IT – they want to at least see the invoice easily). [fnfe-mpe.org], [fnfe-mpe.org]

In summary, the operational perspective deals with how invoices are transmitted, processed, and stored in real workflows and systems. It emphasizes that even if something is legally and semantically correct, it must fit into business processes and technical ecosystems. Factur‑X was an attempt to offer a format that eases integration into both manual and automated processes, but it still has limitations in certain networks (like the PEPPOL case we’ll discuss in Section 6). [sfti.se]

5A.5 Why “Factur‑X compliant”, “EN 16931 compliant”, and “VAT‑compliant” are not interchangeable: From the above perspectives, it’s clear these terms target different criteria:

A “Factur‑X compliant” invoice means the file is in the proper hybrid format (PDF/A-3 + XML) with one of the defined profiles. It says nothing explicitly about whether all VAT law content is there or whether the data follows the standard rules (though by definition if it’s a Factur‑X file, it at least uses a subset of the standard’s schema). For instance, an invoice could be Factur‑X Basic profile – so we’d call the file Factur‑X compliant – but Basic profile doesn’t include all the EN 16931 fields, so it’s not fully EN 16931 compliant. If that Basic profile invoice left out, say, line item details because Basic WL or Basic has some omissions, then it’s also possibly failing legal compliance if those omitted fields were legally required. Another scenario: if someone created a file that has the embedded XML but the data in it breaks an EN 16931 business rule (like the totals don’t add up), it might still be technically Factur‑X format compliant (structure fine) but not semantically compliant. Or, imagine a Factur‑X that uses the Extended profile and includes some country-specific fields – it’s Factur‑X format compliant and covers EN core, but that extended data might make it not strictly EN 16931 compliant (though arguably still extended from it). Thus, Factur‑X compliance is a narrower technical measure and cannot guarantee that the full semantic content or legal content is correct. [fnfe-mpe.org]
An “EN 16931 compliant” invoice (i.e., conformant to the European standard) guarantees a rich set of structured data including all the core fields, but it doesn’t specify the format beyond the approved syntaxes. So an EN 16931 compliant invoice could be a UBL XML file sent via PEPPOL – which is not a Factur‑X PDF, it’s just an XML document. So it would be incorrect to call that Factur‑X (there’s no PDF) but correct to call it EN 16931 compliant. Conversely, a Factur‑X invoice in EN 16931 profile should be EN 16931 compliant if filled out properly – there the terms align. But as noted, a Factur‑X invoice in a lower profile is not EN 16931 compliant. So one cannot equate “We use Factur‑X” with “We comply with the European standard”, unless always using the full profile. A marketing claim like “Our invoices are Factur‑X – fully compliant with EU standard and VAT law!” could be misleading if they only use Basic profile. Only the specific combination of correct profile and correct data yields compliance.
A “VAT-compliant” invoice means it meets legal requirements. One can have a totally VAT-compliant invoice that is not EN 16931 or Factur‑X at all (e.g., a paper invoice with all needed details, or a PDF without XML). It’s not semantically standardized, but legally it’s fine. Conversely, you might have an EN 16931 compliant invoice that inadvertently misses a special local requirement (though unlikely, since 226 is covered, but supposing they forgot the “Reverse charge” phrase in the data or put it in XML but a human inspector doesn’t see it clearly – weird scenario, but anyway). More straightforward: a company might generate an EN 16931 compliant XML but fail to ensure authenticity (maybe they didn’t have controls or signature as required by law) – then from a legal standpoint, that invoice might be challenged even though data-wise it’s perfect. “VAT-compliant” involves aspects of process and form beyond just data fields: e.g., if law said “invoices must be in the local language”, a fully EN 16931 invoice in English might not be accepted in a certain country (rare in EU since any language generally accepted if parties agree, but you get the logic). So you can’t assume an EN 16931 invoice is automatically accepted in all jurisdictions for all purposes – one must check legal compliance. Another angle: Simplified invoices under 100 EUR may lawfully omit some fields (like buyer’s address maybe), but an EN 16931 validator might flag that as missing BT-45. So legally it’s fine (if member state allowed simplified invoice), but standard-wise it’s “non-compliant”. Here, “VAT-compliant” diverges from “EN 16931 compliant” because the standard doesn’t have a concept of simplified invoice except via some CIUS possibly. Indeed, Article 226b allows fewer fields for small invoices, whereas EN 16931 doesn’t define a separate smaller set – it defines a full set, expecting full invoices. Some countries might implement a CIUS for simplified invoices with less mandatory info, but baseline EN 16931 doesn’t incorporate that. Therefore an invoice under €100 could be VAT-compliant with just a date, seller identity, goods, tax amount, etc., but an EN 16931 validator might reject it for missing buyer name or such. So “VAT compliance” and “EN compliance” are not 100% identical set.

Thus, the three labels are about different aspects of compliance:

Factur‑X: format-level compliance,
EN 16931: data model compliance,
VAT: legal content/process compliance.

They overlap heavily – ideally one strives for all three – but each can exist without the others.

5A.6 Risks of false or partial compliance assumptions: If a business or vendor conflates these terms, it can lead to compliance gaps and nasty surprises. For example, a company might implement a software that outputs Factur‑X Basic profile invoices and then advertise “We comply with the European standard and VAT law!”. If they or their clients rely on that assumption, they might find later that some invoices are rejected by a public contracting authority or a tax auditor because they missed some required element (e.g., Basic profile doesn’t include line item detail but maybe a particular B2G scenario required it, or an auditor complains that the invoice doesn’t show a breakdown of VAT per item). Another risk is over-reliance on format: Just because you’re using a fancy format like Factur‑X, you can’t ignore the need for proper business controls for authenticity or archiving. Some might think “We use Factur‑X, so we’re automatically compliant with everything.” But if they, say, email Factur‑X invoices to customers without any security and don’t have a reliable audit trail, they might fail the requirement to ensure authenticity of origin (VAT law requires that the invoice not be forged or altered unnoticed) – a PDF can be edited unless signed, for instance. Or if they don’t have a good archiving policy (“we have the XML, we can regenerate PDF anytime” might not suffice if legally they needed to store the exact original sent including the PDF part).

Another scenario: a vendor might claim their solution is “EN 16931 compliant” because it emits all required fields, but if it doesn’t use one of the standard syntaxes or doesn’t adhere to format (maybe it produces a custom JSON or something), then receiving systems might not accept it. The customer might assume compliance means interoperability, then find out they have to map it manually – undermining the trust in “compliance” claims.

Also on the flip side, a company might do the bare minimum for legal compliance (making sure required fields are somewhere on the PDF) and assume that’s enough for e-invoicing standard – but if they need to integrate with automated systems, they’ll fall short. A partial compliance scenario is if someone uses Factur‑X but in Minimum profile. It meets maybe 60-70% of EN model and perhaps all VAT law fields, but it’s not full structured detail. If they then try to send this to a government e-invoicing platform expecting full EN 16931, it could be rejected or at least not automatically processed (imagine sending a Minimum profile Factur‑X to a buyer expecting line-level detail for matching – they can’t automate because no lines in the XML). That’s an operational risk due to partial compliance.

False compliance assumption examples:

“We use PDF invoices with all info, so we are compliant with e-invoicing.” Legally yes, but if “e-invoicing compliant” was meant as EN 16931, then no – those PDFs aren’t machine-readable. So if that company tries to bid in a public tender where they must send EN 16931 e-invoices, they’ll have a rude awakening.
“We have structured invoices according to the standard, so we don’t need to include that weird margin scheme note.” Mistake: the law specifically demands that phrase on margin scheme invoices. The standard may not have called it out, but legal compliance requires you still include it (probably in a <Note> in the XML and on PDF). If they omit it thinking “not in schema, not needed”, the invoice might be considered not properly annotated by tax authorities – risk in audit. [vatupdate.com]
“Our invoice data are EN 16931 compliant, so tax audit will be fine.” Not if they didn’t ensure integrity. An XML can be altered. The law cares that the invoice that was sent is the same one in archive, etc. If they didn’t address that (digital signatures or reliable systems), the data compliance won’t save them from potential issues of trust.
“We send Factur‑X via email to our French customers, that covers the upcoming mandate.” Actually, under upcoming French mandate, you may need to send through a platform, not email. Even though Factur‑X is an accepted format in France, how you send it will matter. So mis-reading “accepted format” as equivalent to fulfilling mandate could cause non-compliance (they might fail to report to tax portal).

These examples show that each “compliance” angle addresses only part of the picture. Companies should ensure full compliance by checking all angles: does the invoice meet legal requirements, is it in a structured standard form expected by partners/authorities, and is the file format correct for those channels, and did we operate it correctly (transmission, storage)? Not doing so leads to “false sense of security.”

A regulator or business partner might reject or flag an invoice for any gap: an auditor for a missing legal mention (even if format was fine), or an e-procurement system for an unexpected format or missing data field (even if legally it was okay in free text). [sfti.se]

The bottom line: “Compliance” must be viewed multi-dimensionally. One must not assume that because one dimension is covered, the others automatically are. Each label (Factur‑X, EN 16931, VAT) addresses a different compliance checklist, and all are needed for truly correct e-invoicing.

In practical advice: Businesses should ensure their invoices are VAT-compliant (the foundational legal need) and if they engage in electronic exchange, adhere to EN 16931 in content and produce/send them in a format acceptable to their partners or mandated systems (which may be Factur‑X or others). Overlooking any one of these can result in invoice rejection, payment delays, or compliance penalties.

Relationship with PEPPOL

6.1 Whether and how Factur‑X relates to PEPPOL: PEPPOL (Pan-European Public Procurement Online) is an interoperability network and set of specifications enabling electronic document exchange (notably e-invoices) across borders. It defines the PEPPOL BIS Billing 3.0 format – which is a CIUS of EN 16931 implemented in UBL XML syntax. The question is how Factur‑X (a PDF+XML format) fits into the PEPPOL context. In practice, PEPPOL’s transport infrastructure (the eDelivery network of Access Points) expects payloads in specific XML formats (like UBL invoices conforming to BIS 3). Factur‑X is not one of the official PEPPOL BIS formats, so a Factur‑X file cannot be directly sent as the primary invoice document through the PEPPOL network. PEPPOL’s protocols are built around sending an XML message (for example, a UBL Invoice XML) with certain header metadata (SBDH) specifying the document type. There’s no standard PEPPOL document type for “PDF with embedded XML”. They standardized on UBL mainly, with optional use of the UN/CEFACT CII XML as an alternative syntax (some PEPPOL access points support it since CII is in the EN 16931 syntaxes list, but usage of CII in PEPPOL is very rare; UBL is dominant). Factur‑X’s XML is essentially a variant of the CII syntax – so the XML part alone could theoretically be sent via PEPPOL if one wraps it as a CII invoice. But the PDF part wouldn’t be transmitted that way (at least not as the main payload). [docs.peppol.eu] [eur-lex.europa.eu]

However, PEPPOL does allow attachments to invoices (like supporting documents). In theory, one might attempt to send a UBL invoice via PEPPOL with an attached PDF that happens to contain the same invoice data (like a Factur‑X PDF as an attachment). But the PEPPOL BIS documentation explicitly advises against attaching a duplicate PDF invoice image to a structured invoice. It calls out that including the supplier’s visual invoice copy (PDF) can cause confusion and is not recommended. The rationale is that if both a structured invoice and a PDF copy are delivered, it puts burden on the receiver to ensure they match and figure out which one to rely on. In PEPPOL’s interoperable philosophy, they want to avoid such duality – the structured data is meant to be the one source of truth. Therefore, they discourage sending the PDF rendering through the network to avoid inconsistent or redundant representations. Instead, the receiving system can generate a human-readable rendering if needed from the XML (some AP software does that, or a simple style sheet can be applied to UBL). [sfti.se]

So, how does Factur‑X relate to PEPPOL? – Largely, it doesn’t directly. They are parallel solutions for e-invoicing:

Factur‑X is a bilateral format suited for email or portal exchange, focusing on human/machine combined.
PEPPOL is a multilateral network focusing on machine-to-machine exchange (with standardized semantics only).

If a company is using PEPPOL, they normally would send UBL invoices. If they have Factur‑X internally, they might have to extract the XML from the Factur‑X and convert it to UBL to send via PEPPOL. The core data (EN 16931 semantics) is preserved through conversion, but the PDF part is left behind. Some specialized integration solutions might allow, e.g., sending the Factur‑X XML as a CII invoice on PEPPOL (because CII is technically allowed as an alternate syntax by the standard). There is mention of at least one implementation (perhaps an extension or planning on how to send a Factur‑X file through an AS4 access point by embedding the PDF in a binary container with correct doc type – the GitHub link [10] in search results suggests a technical discussion on sending Factur‑X through a PEPPOL AS4 with attachments). However, that’s not a mainstream use and not an official BIS specification. It would require the receiver’s access point and software to support it too, which is not guaranteed.

In summary, PEPPOL primarily handles pure structured invoices (like UBL), and Factur‑X is not an official format in that network. So for companies engaged in PEPPOL e-invoicing (such as many B2G contexts in Europe), Factur‑X would not be used as-is; they would adopt the UBL route. That said, Factur‑X and PEPPOL share the same underlying semantic model (EN 16931). So data-wise, a Factur‑X invoice and a PEPPOL BIS invoice convey the same info. This means a company could generate a Factur‑X for itself/its customer, and also generate the corresponding UBL to send via PEPPOL. But the duplication might be unnecessary if the customer is connected to PEPPOL – they likely don’t want the PDF at all, just the data.

6.2 Why PEPPOL primarily operates with pure XML syntaxes: The design of PEPPOL was to maximize automation and interoperability. As Recital 7 of Directive 2014/55/EU noted, only machine-readable invoices that can be processed automatically should count as e-invoices under that law. A PDF, even if structured inside, is heavier and more complex to handle automatically because it requires an extra step to extract the XML, and typically network infrastructure might treat it as binary. The choice to use pure XML syntaxes (like UBL, UN/CEFACT) in PEPPOL means that the data can be directly parsed by any access point and routing metadata can even be derived from it. A PDF container would complicate that and add overhead (size – PDFs are larger due to fonts/graphics, complexity – an AP might need a PDF processor embedded to get to the XML). Also, PEPPOL was initially built from efforts like CEN BII and country pilots focusing on XML. At that time (around 2010-2016), hybrid PDF wasn’t standard; ZUGFeRD 1.0 existed by 2014 but was not widely known in EU projects. When EN 16931 came out (2017), the two approved syntaxes were indeed UBL and CII XML. The PDF embedding concept is not considered a separate syntax but a usage of CII. However, openPEPPOL did not incorporate that concept because: [ec.europa.eu] [eur-lex.europa.eu]

It complicates interoperability (everyone in network would need to support that feature),
It doesn’t add value in a closed automated network (the humans usually see the invoice via their local system’s UI, not via the file, and if they need a PDF they can render it from XML).

Another reason is network efficiency: transmitting PDFs (with logos, etc.) is more data heavy. If you’re sending millions of invoices, sending just the structured data (which might be 10-30 KB for an invoice in XML) is far more efficient than sending a PDF (which could easily be 100 KB or more). Over thousands of transactions, that adds bandwidth and storage overhead with no benefit for those doing straight-through processing.

Additionally, from a governance perspective, PEPPOL wanted one single source of truth (the XML). If they allowed PDF+XML, there’s risk that some suppliers might accidentally have mismatches; whose responsibility then to catch it? Might the receiving AP validate that XML and PDF data are consistent? That’s outside their scope – they’d prefer not to run such checks. Better to disallow it and avoid potential disputes (“The PDF said €100, the XML said €90 – which do we pay? If PDF was included, buyer might see PDF showing 100 and pay that, while automation used 90 from XML. That’s a serious error potential.) Eliminating the PDF eliminates that risk on the network level. [sfti.se]

6.3 Interoperability considerations: As alluded, interoperability is easier with a homogeneous approach. PEPPOL network had to get many countries and software to agree – focusing on one syntax (UBL) was a pragmatic choice. They did define a CIUS (Core Invoice Usage Specification) for the invoice (PEPPOL BIS 3) which restricts how EN 16931 is used in UBL to ensure consistency across countries. The presence of Factur‑X doesn’t directly disrupt this because Factur‑X is typically used in bilateral exchange (like email, or local upload). However, if a supplier using Factur‑X wants to connect to a PEPPOL-accessible buyer, they must consider interoperability: either change format or find a conversion path. Many e-invoicing providers support multiple formats and can do conversion behind the scenes (so a supplier can upload Factur‑X to their provider’s portal, and the provider converts it to UBL and sends via PEPPOL – that’s feasible since the data models align). But that conversion needs careful handling of differences (there are small semantic differences between CII and UBL implementations). [docs.peppol.eu]

One interoperability risk: lack of support for hybrid – if one tries to send Factur‑X outside of contexts that expect it, it may be rejected or just not utilized. For cross-country, cross-platform flows, keeping it purely structured avoids any proprietary concept or PDF reliance.

Another aspect is addressing and routing: In PEPPOL, endpoints are identified by IDs (like VAT or GLN numbers) in a registry, and messages are addressed by standard document type IDs (like “invoice:billing:PEPPOL:ver3”). Factur‑X usage typically is via email or portal where addressing is just an email or an upload selection. If one wanted to route Factur‑X through a network like PEPPOL, one would have to fudge a document type ID. Possibly one could send Factur‑X’s XML and ignore the PDF portion (which defeats including PDF anyway). Or treat the PDF as just an attached supporting doc – but as per SFTI guideline, that’s not recommended. [sfti.se]

6.4 Legal vs transport roles: Factur‑X’s role is essentially format/standard (embedding semantics into a user-friendly file). PEPPOL’s role is transport/infrastructure (ensuring the invoice can go from system A to B reliably). They operate at different layers. Legally, the EU mandated that public bodies must accept EN 16931 invoices (Directive 2014/55/EU), but did not force them to accept PDF or Factur‑X specifically. Many public bodies complied by standing up PEPPOL access points or portals that accept UBL files. Some (like France and Germany) also accept Factur‑X PDFs on their national portals. But that’s a local decision. So from a legal compliance perspective, if you send a Factur‑X to, say, a Belgian government entity via email, that might not fulfill the directive because Belgium might insist you submit through their e-invoice portal which expects a PEPPOL UBL. The law (Dir 2014/55) doesn’t name PEPPOL specifically, but in practice, countries implemented via specific channels. So legally, one might not be free to choose Factur‑X if the recipient requires another channel.

Hence, Factur‑X is great for B2B where channels are flexible (if buyer agrees, email is fine), whereas PEPPOL is often mandated for B2G. So we see, legally for B2G, Factur‑X is secondary (except in France, Germany where they explicitly allow it on their portals – but even there, one might convert behind scenes to core data).

Transport-wise, as said, Factur‑X is not a transport mechanism; it’s just a file. To “transport” it, you rely on email, upload, etc. That relies on bilateral arrangements. PEPPOL defines a multi-lateral transport methodology: if you know the buyer’s ID, you can send through the network without needing email. So if one invests in connecting to PEPPOL, using Factur‑X externally becomes redundant; you’d use the network’s format. Conversely, if one’s environment is email-centric, Factur‑X is helpful because email is dumb transport (just sending files), so combining human+data in the file is valuable. On PEPPOL, they handle having data and humans can get a PDF later, so no need to send PDF.

6.5 Limitations of Factur‑X in PEPPOL environments: If a supplier exclusively issues Factur‑X invoices and then deals with a customer that says “please send via PEPPOL”, the supplier might face some friction:

They might need a converter or new software to send UBL.
If they try to send the Factur‑X PDF itself via PEPPOL (perhaps as attachment or something creative), the buyer’s AP or software might ignore or drop the PDF. Indeed, SFTI’s note says a buyer in Swedish public sector who receives both forms should treat them as one public document and not ignore one, but that’s a headache; hence they say “should never be included”. [sfti.se]

Additionally, many AP solutions probably would either drop attachments or not handle them well. One Swedish guide implies an AP might pass attachments but the receiving system might not store them or connect them to the invoice data properly. If a PDF was attached contrary to guidelines, a public entity’s archive might treat the PDF and the XML as separate records, causing confusion. [sfti.se], [sfti.se]

Another limitation is future mandates: with ViDA (see Section 8), if cross-border B2B e-invoicing becomes mandatory in structured form (and perhaps through certain channels), Factur‑X itself might not be accepted by tax authorities for reporting. They might want only the raw data (like a specific format via API). Factur‑X’s advantage of being a hybrid might be moot then – companies might just send pure data to tax and optionally give a PDF to the customer. But the hybrid might not be used in that pipeline.

So summarizing:

Factur‑X cannot currently be used directly as a PEPPOL BIS invoice. There’s no official support for it as a primary payload, making it effectively incompatible unless you strip the PDF and just use the XML portion under CII (which few do).
Businesses using Factur‑X still need an alternative solution for customers requiring PEPPOL. This could be considered a limitation in adoption – you can’t just have Factur‑X cover all cases.
Also, any improvement that PEPPOL brings (like immediate delivery, guaranteed routing) wouldn’t apply if you stick to email Factur‑X. So if a buyer says “I prefer you to send via network so I can automatically get and ack it”, the Factur‑X user would have to adapt.

In many ways, Factur‑X is more suited to decentralized exchanges (email, direct send) and SME usage where a service provider might not be in the loop, whereas PEPPOL is a centralized network approach often used by larger entities and mandated flows. They have different ecosystems with minimal overlap.

The essence: PEPPOL and Factur‑X are two parallel approaches to e-invoicing which historically haven’t merged. Factur‑X’s strength (combined PDF+XML) is somewhat redundant in PEPPOL’s structured network, and even a potential nuisance as pointed out by guidelines. That’s why Factur‑X is typically not used in PEPPOL context. Companies must plan accordingly: supporting Factur‑X for some partners and PEPPOL UBL for others if needed. [sfti.se]

Impact on EU e‑Invoicing mandates

7.1 Use of Factur‑X in B2G and B2B contexts: In the public procurement domain (B2G), all EU countries have been required since April 2019 to accept invoices conforming to EN 16931 under Directive 2014/55/EU. This means any supplier can send a structured e-invoice meeting the European Standard and the government must process it. Factur‑X, when used at its full EN 16931 profile, fulfills this criterion. In practice, some Member States explicitly allow Factur‑X (or its twin “ZUGFeRD”) as one of the accepted formats for B2G e-invoicing. For example, France’s Chorus Pro portal accepts Factur‑X alongside pure UBL and pure CII XML invoices. Similarly, Germany’s public sector can receive invoices in the ZUGFeRD 2.1 format (identical to Factur‑X) as an alternative to the official XRechnung XML. In those cases, a supplier can submit a PDF with embedded XML to authorities, and it counts as a proper e-invoice. However, not every country’s system supports PDF hybrids – many have opted for pure XML via networks like PEPPOL (see Section 6). Thus, Factur‑X’s uptake in B2G is uneven across the EU: it is embraced in jurisdictions that promote PDF+XML for ease of use (notably France and Germany), but elsewhere the mandate is satisfied with pure EN 16931 XML files, and a Factur‑X file might need conversion by an intermediary. On the whole, as long as the XML inside Factur‑X is EN 16931-compliant, it meets the letter of the law for B2G e-invoicing, but the medium of a PDF container is a local preference rather than an EU-wide standard. [ec.europa.eu], [ec.europa.eu] [ec.europa.eu] [ec.europa.eu], [ec.europa.eu]

In the business-to-business (B2B) context, e-invoicing mandates are emerging but not fully harmonized yet. Historically, the EU VAT Directive allowed electronic invoices but did not require them, so B2B adoption was voluntary or encouraged by business benefits. Italy broke ground by mandating structured e-invoices for all domestic B2B transactions from 2019 (under a special derogation), using a national XML format through a clearance system. Other Member States are now setting timelines for B2B mandates (especially after a 2022 law change allowed it without derogations), often as part of the broader VAT digitalization efforts. France will require all companies to be able to receive e-invoices by 2026 and to issue them in phased deadlines through 2027, under its “Pourquoi Pas Fabricant” reform, accepting Factur‑X as one of the official formats. Germany has enacted a B2B e-invoicing mandate starting in 2025 for reception and 2027–2028 for issuance, and explicitly cites the use of EN 16931 formats (XRechnung or ZUGFeRD/Factur‑X) to comply. In these forthcoming B2B mandates, Factur‑X is generally recognized as a compliant format (when using the full EN profile) because it carries the standard data; for instance, France’s regulation lists Factur‑X alongside UBL and CII XML as acceptable for domestic invoices. However, some countries that mandate B2B e-invoicing might not incorporate Factur‑X in practice if their systems only ingest raw data. For cross-border B2B within the EU, there is not yet an EU-wide mandate (ViDA will introduce one – see Section 8), but many companies voluntarily exchange EN 16931 invoices. In those exchanges, Factur‑X can be used bilaterally if both parties agree, providing a human-readable copy for convenience. In summary, Factur‑X is making inroads in domestic B2B mandates where authorities allow hybrid files, but it is not universally imposed. Businesses in countries with upcoming mandates should check the officially permitted formats: Factur‑X is often permitted in France and Germany, whereas in clearance-centric systems (like Italy’s SdI) a pure XML is required and a Factur‑X would have to be converted. The trend at the EU level is toward ensuring all B2B e-invoices comply with EN 16931, with format choices (PDF hybrid or not) left to practical considerations by each country. [ec.europa.eu], [ec.europa.eu] [ec.europa.eu], [ec.europa.eu]

7.2 Relationship with clearance and reporting systems: A “clearance” or real-time reporting regime is one where invoice data is transmitted to or through tax authorities for approval or recording before (or as) the invoice is delivered to the customer. Examples include Italy’s Sistema di Interscambio and upcoming mandates in France, among others. Factur‑X as a format is not itself a transmission system – it’s a file. In clearance models, typically the requirement is to submit invoice data in a specific structured form to the tax portal; PDF components are generally not accepted in such transmissions. For instance, Italy mandates that invoices be sent as an XML message in the government-specified FatturaPA format, with no PDF attached; a purely human-readable PDF would be rejected as not an “e-invoice” for legal purposes. In such environments, using Factur‑X would add no benefit – the tax authority only cares about the XML content, and the PDF part would be ignored. Indeed, many clearance systems supply their own human-readable rendering after processing, so they do not want an external PDF. As a result, Factur‑X is usually not the primary vehicle in clearance models. Instead, businesses might internally use Factur‑X to generate the invoice, then have software extract the XML and transmit just the XML to the authority, discarding the PDF or using it only for the buyer’s copy. This was anticipated in France’s upcoming system: large companies with existing EDI (e.g. EDIFACT) or Factur‑X processes can continue them internally, but their chosen “platform de dématérialisation” will convert the invoice into the mandated format for submission to the tax portal. In other words, Factur‑X can feed a clearance system with data, but it is not itself a clearance solution. Another aspect is latency: clearance often demands near-real-time data exchange (e.g., an invoice must be reported within a day of issuance). A bulky PDF container is unnecessary overhead; direct XML or API transmissions are more efficient. Thus, clearance regimes “exist beyond” Factur‑X – they operate at the data pipeline level. Companies in such jurisdictions need to ensure their invoice data (perhaps originating from Factur‑X files or any source) is mapped to the required schema for reporting. If they simply send Factur‑X files to customers via email, that does not fulfill a clearance obligation: the data still must be uploaded to the authority’s system in the prescribed way. In summary, Factur‑X on its own does not meet the requirements of clearance/reporting mandates, which revolve around timely submission of structured data to tax authorities. It can be used in parallel to satisfy business needs (providing the customer with a nice PDF), but from the government’s perspective, only the structured content and its transmission matter. Many Member States with such systems explicitly state that a PDF (even with XML inside) will not count as an electronic invoice for mandate purposes. As we move into an era of digital VAT reporting, Factur‑X’s role is likely supportive (helping businesses produce the needed data) rather than central to the compliance transaction.

7.3 When Factur‑X is accepted vs. when structured XML is required: The general rule is that Factur‑X is accepted in scenarios that prioritize interoperability and business convenience, whereas a raw structured XML is required in scenarios that prioritize automation efficiency or centralized processing. Factur‑X tends to be accepted (and even encouraged) in decentralized exchanges – for example, in B2B networks or B2G portals where the goal is to accommodate all suppliers including SMEs. In France’s B2G portal, a supplier may upload a Factur‑X PDF or a pure XML; both will be processed. Germany’s federal platform similarly allowed email submission of a ZUGFeRD PDF in some cases. Here, the authorities balanced strict data needs with user-friendliness. On the contrary, in centralized or high-volume systems, especially clearance, only the structured XML is typically allowed. Italy’s system, as noted, requires FatturaPA XML; Poland’s upcoming KSeF will require invoices in a specific XML format; these systems do not accept PDF at intake. Even in France’s 2026 B2B model, while Factur‑X (PDF+XML) will be accepted by platforms from suppliers, the transmission between platforms and the tax authority will likely strip away the PDF portion, transmitting just standardized data. In short, Factur‑X is suitable as an exchange format between two parties if they wish, but whenever an invoice must go through a data hub or authority system, the structured XML alone is king. Another angle is business preference vs. mandate: If two companies voluntarily trade e-invoices, they might use Factur‑X because it’s convenient (no separate PDF needed). But if a law or customer requires a specific format (say, UBL XML via PEPPOL), then that requirement overrides – you then must provide the syntax and method they ask, and a Factur‑X file would not meet the channel requirements. The “acceptance” of Factur‑X is thus context-dependent. As a rule of thumb: Factur‑X is accepted where e-invoicing policy is flexible on format as long as EN 16931 data is present, and not accepted where policy mandates a particular transmission syntax or platform. Businesses need to identify for each trading relationship whether a hybrid PDF is allowed. For example, a French company invoicing another in France after 2026 can send Factur‑X through an accredited platform (it’s on the list of allowed formats). But if a French company is invoicing an Italian buyer, and the transaction falls under Italy’s clearance (for domestic Italian suppliers it would, but not for a French supplier – still, hypothetically if it did), that French company couldn’t send Factur‑X into Italy’s SdI – they would have to stick to Italy’s format. Similarly, a supplier to a Swedish government agency would typically send a PEPPOL BIS (UBL XML) invoice; sending only a Factur‑X PDF by email wouldn’t fulfill the official procedure, even though Sweden adheres to EN 16931 (via UBL). In the coming years, with the EU’s ViDA reforms (see Section 8), it’s expected that structured core data will be compulsory in more situations, tilting the balance further toward pure data exchange. Factur‑X will be accepted only insofar as its data content and syntax align with the mandated ones. [ec.europa.eu] [ec.europa.eu] [ec.europa.eu], [ec.europa.eu]

7.4 High‑level EU context (avoiding country-specific deep dives): At the European level, we see a clear direction: electronic invoicing is becoming the norm for both public and private sector trade, and it must be semantic-standard compliant. Directive 2014/55/EU jump-started this by forcing B2G e-invoicing acceptance via EN 16931. The forthcoming ViDA legislation (expected to amend the VAT Directive) will make structured e-invoicing the default for B2B across the single market by 2028. These policies do not prescribe a single syntax for businesses to use in every case, but they do insist on the common semantic model. That means national deviations (like proprietary formats) are being phased out or made interoperable with EN 16931. The high-level vision is an integrated EU e-invoicing landscape: each invoice should carry the core information in a recognizable way (facilitating cross-border trade and tax reporting), even if the packaging can differ. As of mid-2020s, the landscape is a patchwork – some countries have full mandates (Italy, and soon France, Poland, Spain, etc.), others rely on voluntary adoption or only B2G mandates. Factur‑X, being a Franco-German creation, naturally saw most traction in those countries, but its concept has influenced broader thinking on making e-invoicing accessible. The EU’s approach remains format-neutral at the legislative level (the law doesn’t say “you must use UBL” or “you must embed in PDF”), but it does say e-invoices must be machine-readable and follow the standard. This encourages various compliant implementations to flourish. In this big picture, Factur‑X is one implementation of the standard, primarily important in parts of Europe that emphasize incremental adoption. Elsewhere, businesses might achieve the same compliance via pure XML or networks. A key point is that, as mandates spread, the difference between “pure XML” and “hybrid PDF” is a matter of technique, not substance – the substance is having the data in the right form. So, while Factur‑X offered a clever bridge in the absence of mandates, the drive toward 100% e-invoicing (with or without clearance) means that all compliant invoices will share the same data DNA. The likely long-term convergence is that everyone will produce EN 16931 data, delivered through interoperable channels (e.g. PEPPOL or national hubs). Factur‑X may continue as a user-friendly vehicle in many scenarios (especially for SMEs and for providing readable archives), but the high-level EU strategy doesn’t single it out – it treats it as one tool in the toolbox. In sum, EU policy is making e-invoicing ubiquitous and standardized; Factur‑X’s fate will hinge on whether stakeholders still need a PDF layer on top of that standardized data as this transformation matures.

Impact of ViDA (VAT in the Digital Age)

8.1 Why EN 16931 – not Factur‑X – is central to ViDA: The European Commission’s VAT in the Digital Age (ViDA) initiative is a legislative package to modernize VAT reporting and fight fraud, adopted in 2025. A core component is the introduction of mandatory e-invoicing for (initially) cross-border B2B transactions and digital reporting of the invoice data to tax authorities in real-time. In the ViDA proposals and the political agreement around them, the emphasis is squarely on the European e-invoicing standard (EN 16931) and its compliant syntaxes, rather than any specific file format like Factur‑X. The reasoning is straightforward: ViDA aims to ensure that all businesses issue invoices that can be automatically processed and reported, which requires structured, standardized data. EN 16931 provides the definition of that data. Factur‑X, on the other hand, is just one method of packaging that data and is not a standard in itself for content. The ViDA legislative texts (amendments to the VAT Directive) make this clear. For instance, the new Article 218 as approved states that invoices must be issued in a structured electronic format and that Member States must allow invoices which comply with the European standard on electronic invoicing and its list of syntaxes. This essentially enshrines EN 16931 as the benchmark for what counts as an e-invoice after 2027. There is no mention of PDF or hybrid formats in the law, because those are considered technical choices beneath the level of legislation. The law cares that an invoice’s data is structured and standard-compliant; whether a PDF copy travels along is irrelevant to the legal requirement. In fact, ViDA removes the need for buyer consent to e-invoicing and defines “electronic invoice” in a way that excludes unstructured documents. It implies that a PDF invoice (without machine-readable data) will no longer be regarded as an invoice for VAT purposes once the ViDA rules kick in. From that perspective, Factur‑X does meet the structured criteria (by virtue of its XML), but the PDF part is extraneous to compliance: it’s “allowed” but not necessary under the new regime. What ViDA is really driving home is semantic and syntactic interoperability. It is pushing the EU toward convergence on formats like UBL and CII XML (the syntaxes listed under EN 16931) for all B2B invoices. So, the focus is on ensuring everyone’s systems speak the same data language, not on whether the invoice comes in a PDF wrapper. The upshot is that EN 16931 sits at the heart of ViDA’s e-invoicing vision, while Factur‑X is tangential. Policymakers view Factur‑X as one of many implementations of EN 16931. They neither mandate nor prohibit it. But by mandating the standard itself, they effectively say: “use whatever format you want, as long as it’s EN 16931-compliant.” And if a format is not, it cannot be used as an invoice anymore. This indirectly places Factur‑X in a compliant position (since it uses an accepted syntax) but does not elevate it above others. In summary, ViDA’s concern is that every invoice contains the required structured data (the ‘what’), not how it is presented (the ‘how’). The legislation cements EN 16931 as the normative reference for content. Factur‑X, being an implementation of EN 16931 using the UN/CEFACT syntax, automatically aligns with this – but so do pure UBL or pure CII files. Therefore, ViDA will accelerate e-invoicing adoption on a standard basis, but it doesn’t particularly promote hybrid PDFs; it assumes a fully digital (machine-to-machine) environment as the end goal.

8.2 Role of Factur‑X in transition scenarios: During the transition to the ViDA regime (between now and the 2028 deadline, and even beyond as systems adjust), Factur‑X can play a useful transitional role for businesses. Many companies, especially SMEs or those in countries that haven’t yet mandated e-invoicing, still rely on PDF invoicing and manual processes. Requiring them to jump straight to pure XML might be challenging. Factur‑X offers a gentle onboarding: a company can start issuing invoices in Factur‑X format, thereby internally generating EN 16931-compliant XML, while still having a familiar PDF for their records and for customers who prefer a visually verifiable document. This helps them achieve compliance with upcoming requirements (since the data portion is standard) without completely overhauling their invoicing templates and customer communication overnight. In a scenario where ViDA’s cross-border e-invoicing rule comes into effect (likely by 2028), a company could choose to send Factur‑X invoices to its EU customers – the structured XML ensures they meet the new legal definition of an invoice, and the PDF can serve as a courtesy copy. The customer’s systems could ignore the PDF and just read the XML. Meanwhile, for the reporting to tax authorities, the company would extract the same XML data and submit it as required. Thus, Factur‑X can act as a bridge between old and new practices: it encapsulates the new compliance (XML data) within the old familiar form (PDF). The European Commission explicitly acknowledged that taxable persons will be allowed to issue invoices according to the European standard (EN 16931) even before it becomes mandatory. Factur‑X is one way to do exactly that voluntarily. Another transitional aspect is cross-border handling. Until ViDA, if a business in Country A sends an e-invoice to Country B, they face different format expectations; some might send UBL via PEPPOL, others email a PDF. Factur‑X could be used as a common denominator between willing trading partners in this interim period. It’s not widespread cross-border yet, but nothing precludes two parties from agreeing to exchange Factur‑X – they benefit from structured data without complex onboarding (if one side doesn’t parse the XML, they can still read the PDF). Once ViDA is fully implemented, all cross-border invoices will need to be structured, so in a sense every invoice will resemble what Factur‑X carries internally. At that point the “transition” is over and the question becomes whether the PDF sidecar is still needed. But certainly in the next few years, as companies ramp up their capabilities, Factur‑X can smooth the transition by letting them practice generating EN-compliant invoices early. It can also serve in pilot programs or phased rollouts – e.g., a company might first switch its domestic invoicing to Factur‑X as a preparation step, then later adapt to send just XML when connecting to networks. Additionally, for companies that might not have immediate access to PEPPOL or other e-invoicing networks, emailing a Factur‑X ensures their invoice is future-proof to an extent (the data can be later fed into reporting systems). In summary, Factur‑X’s role in the transition to fully digital VAT is as a facilitator and educational tool – it helps businesses generate compliant data while preserving continuity. It is likely to be promoted by some industry groups or solution providers as a stepping stone in markets where PDF invoicing is still prevalent. However, it remains a temporary hybrid solution. The true target state under ViDA is end-to-end structured data exchange; Factur‑X just happens to deliver structured data in a backward-compatible wrapper, which is very handy during the years of migration.

8.3 Limitations for near real‑time digital reporting: When tax authorities require continuous or near real-time reporting of invoice data (a key element of ViDA’s Digital Reporting Requirements), certain limitations of the Factur‑X approach become evident. First, consider timeliness: digital reporting means as soon as an invoice is issued (or within a short window, e.g., 2 days), the data must reach the tax authority’s system. If a company were to rely solely on exchanging Factur‑X PDFs via email with its customer, that doesn’t automatically fulfill the reporting duty – the company would need to take the extra step of extracting the XML and sending it through an API or portal to the authority. This is an additional step where things can go wrong (e.g. forgetting to report, or mismatches between what was sent to the customer and what was reported). By contrast, if a company uses a dedicated e-invoicing system that directly transmits the invoice data, reporting can be more seamless. Thus a hybrid approach might introduce complexity in meeting tight reporting deadlines unless it’s well-integrated. Second, technical overhead: Factur‑X files are heavier (because of the PDF) and slightly more complex to handle than pure XML. In a scenario of real-time clearance with potentially millions of invoices daily nationwide, having each invoice include an embedded PDF could impose unnecessary load on network and storage systems. The authorities don’t need the PDF for any analytics or cross-checks – they only need the data. Indeed, as noted, France’s real-time reporting system (to start in 2026–27) will accept Factur‑X invoices from companies but will likely strip or ignore the PDF portion, using just the data. Similarly, if the EU were one day to create a union-wide reporting pipeline, it would almost certainly be pipeline of data, not of PDF binaries. So the limitation is that Factur‑X is not optimized for machine-to-machine pipelines – it’s a compromise format that carries some baggage. Third, lack of clearance features: a real-time reporting system often returns statuses, errors, or a unique ID back to the supplier (for example, Italy’s SdI issues an acceptance or rejection and a protocol number). Factur‑X as a static file can’t on its own accommodate that interactive loop. One could imagine stamping the PDF or appending metadata after clearance (some have suggested using the PDF’s capability to add a visible or embedded clearance ID upon confirmation), but that requires additional processes outside the initial invoice issuance. In pure clearance systems, the final “approved” invoice might be a modified version of what was submitted (with an added barcode or document ID). For a company using Factur‑X, implementing such modifications to the PDF post-clearance is possible but not standard behavior. It introduces another layer of processing (either the issuer has to regenerate a PDF with the clearance code, or attach a receipt). In summary, Factur‑X is somewhat out of place in a strict real-time reporting environment, which is all about immediate data exchange. It works, but you end up treating it essentially as an XML with an attached PDF that no one uses in the reporting chain. As ViDA pushes more countries to adopt such systems, the practical approach will be: use Factur‑X if you want for your customer-facing invoice, but ensure your internal systems take the XML and report it through the right channels. The PDF will be increasingly irrelevant to the compliance workflow. Companies that fail to realize this might erroneously think emailing a Factur‑X to their buyer is enough, when in fact they also needed to send the data to the tax authority. Therefore the limitation is not that Factur‑X can’t be reported (it can, via its XML), but that its PDF component does nothing to help and could even hinder efficiency in a regime that values instantaneous, automated data flows. As tax administrations converge on wanting just standard data in near real-time, the value proposition of embedding that data in a PDF diminishes for those stakeholders. [ec.europa.eu]

8.4 Expected future relevance under ViDA: Once the ViDA measures are fully in force (by 2028–2030, depending on phase-ins), the landscape of e-invoicing will likely be much more homogeneous. Every business invoice in the EU will need to be electronic and standard-compliant. In that scenario, is there still a place for Factur‑X? The answer is nuanced. On one hand, if all invoices are going through structured channels (like PEPPOL or national platforms), the recipients won’t require a PDF for processing – they’ll process the data. And tax authorities certainly won’t require or want PDFs. We may see a world where the majority of invoices are exchanged as pure data messages. In such a world, Factur‑X could seem like an unnecessary relic, since any receiving software can generate a human-readable display from the XML if needed. The overhead of shuttling the PDF back and forth may deter its use. On the other hand, we can expect that businesses will still have a need for human-readable invoice copies for internal use, customer service, dispute resolution, etc. Archive laws often require that invoices be stored in a form that is legible to humans (unless one assumes universally available viewers). Factur‑X conveniently packages a human-readable original with the machine data, which could be attractive for archiving. Even under ViDA, when a company must archive its invoices (typically for 7-10 years), having them as PDF/A-3 with embedded XML ensures long-term readability – auditors can open the PDF and see the invoice exactly as issued, while also extracting data if needed. This is a strong point in favor of Factur‑X’s continued relevance for record-keeping and presentation purposes. Moreover, consider smaller businesses or certain sectors slow to adapt – they might rely on intermediary service providers or even continue to send invoices by email (which after ViDA would have to be structured). For them, sending a Factur‑X instead of just an XML might feel more natural (“it looks like an invoice”) and gives their trading partner something that can be opened and printed without specialized software. As long as the data is there for compliance, the PDF is an added convenience. Thus, Factur‑X may survive as the user-friendly face of e-invoicing in a fully digital era. It should be seen as complementary to the ViDA framework: ViDA mandates the data; Factur‑X can wrap that data in a user-oriented format. We might compare it to how some secure email systems send you an HTML file that you click to see the message – not strictly necessary, but helpful for user experience. Another aspect of ViDA is cross-border interoperability: since all Member States must allow EN 16931 invoices, a business in one country can send an invoice in the standard format to a customer in another and know it’s acceptable. If that invoice is Factur‑X, the customer in the other country can extract the XML and handle it in their local system (perhaps converting to their preferred syntax if needed). This could encourage more cross-country use of Factur‑X, especially between, say, France/Germany and other countries that haven’t developed their own flavors. However, it’s more likely that companies will default to pure XML via networks for cross-border transactions (due to scale and the push for automation). Ultimately, as a “hybrid solution, not an end state,” Factur‑X’s role will probably recede in importance as full automation spreads, but it will not disappear entirely. It will remain a valuable tool in specific scenarios: SMEs who want simplicity, businesses who value a self-contained invoice file, and cases where a visual format is needed alongside data. It may also continue to be the standard in industries where invoices are sent directly to consumers (B2C billing isn’t mandated by ViDA, but if companies adopt e-invoices for B2C, a PDF is practically needed for the consumer to read it). In conclusion, under ViDA’s fully digital VAT regime, the foundation is EN 16931 data compliance — that is non-negotiable — and Factur‑X acts as an optional layer on top. Companies will focus on ensuring their systems output the required data; once that’s achieved, using Factur‑X is just one way to package it for delivery or archiving. It’s a means to an end, not the end itself. The strategic consensus is likely that Factur‑X served as a bridge and will remain in niche use, but the future points toward streamlined data exchange where the “document” is mostly for human reference rather than the primary vehicle of business transactions.

EDI and legacy formats

9.1 Relationship between Factur‑X and traditional EDI: Long before modern XML e-invoicing standards, many companies (especially large multinationals and those in automotive, retail, and manufacturing supply chains) have used EDI (Electronic Data Interchange) systems to exchange invoices and other documents. Traditional EDI typically relies on formats like UN/EDIFACT messages (for example, the EDIFACT “INVOIC” message) or other industry-specific structured formats. These invoices are purely machine-readable and are transmitted via VANs or direct connections – essentially, they are the old-school equivalent of an e-invoice. Factur‑X, by contrast, was designed in the late 2010s to help companies not using EDI to start structuring their invoices. Thus, Factur‑X and classic EDI inhabit parallel worlds with the same goal (automating invoice processing), but they arose to serve different communities. Factur‑X did not replace EDI, nor was it intended to. Companies that already had fully functional EDI solutions (which output, say, EDIFACT files or XML according to proprietary standards) have generally continued to use those; they might not see a need to generate PDF hybrids. Indeed, early adopters of ZUGFeRD/Factur‑X were often mid-size companies or those in B2B environments without a common EDI platform. The semantic data model of EN 16931 was influenced in part by what was common in existing invoice practices, including EDI content requirements, but it’s a new model. There isn’t a one-to-one correspondence between EDIFACT segments and EN 16931 business terms in all cases. For example, EDIFACT messages can be very detailed and allow custom segments; EN 16931 focuses on core elements. As a result, an EDIFACT invoice may include things that don’t directly map to EN 16931 or vice versa. EN 16931 did not adopt EDIFACT as an official syntax – the approved syntaxes under the EU standard are the UN/CEFACT XML and the UBL XML. Traditional EDIFACT syntax was deliberately left out to push modernization (EDIFACT is a text-based format from the 80s and 90s, less self-descriptive than XML). Therefore, Factur‑X (which uses one of the approved XML syntaxes) is a step beyond classic EDI in terms of standardized approach. In practice, many large companies maintain their EDI for high-volume partners and might use Factur‑X or UBL for other connections. The coexistence looks like this: EDI is often point-to-point or via closed networks, with agreements in place between trading partners on format and content; Factur‑X is used more in open ecosystems or to comply with government standards when EDI isn’t mandated. Factur‑X could be seen as a more accessible form of EDI for the masses – it creates a structured invoice without needing a custom EDI infrastructure, just by using PDF files and email. [eur-lex.europa.eu]

9.2 Possibility and limits of semantic alignment: There is a drive to align legacy EDI formats with the modern standard. In theory, one can map an EDIFACT INVOIC message to the EN 16931 model – indeed many of the data points are similar (both will have seller and buyer info, line items, tax amounts, etc.). It is possible to create conversion mappings so that an invoice sent in EDIFACT can be converted to an EN 16931-compliant XML and vice versa. Some industries have created crosswalks or are updating their guidelines to ensure that if you follow their EDI conventions, you satisfy EN 16931 requirements. However, there are limits. EDIFACT messages often allow more variability and optional segments that aren’t in EN 16931’s core. Conversely, EN 16931 has strict rules and some data elements that a given EDI implementation might not use. For example, EN 16931 expects an explicit code for each VAT category on an invoice line (standard rate, zero rate, etc.), whereas an older EDI implementation might have simply implied that from the tax percentage or didn’t transmit an explanatory code. Aligning them means curtailing some of EDI’s flexibility and enriching some parts of the EDI message. Another example: EN 16931 requires a “Buyer Reference” (BT-10) for public sector invoices (often a purchase order or contract reference) – some EDI invoices might not always include an equivalent field if it wasn’t required by the partner. To align, businesses must ensure that those references are captured in EDI when needed. As the European standard becomes the baseline for even private exchanges, we’re seeing EDI guidelines incorporate those requirements (e.g., making certain data mandatory that previously was optional). But full semantic alignment means that an invoice sent in any format carries the same meaning. The EU’s goal is to minimize divergent interpretations. EDIFACT, being by nature a structured format, can be made almost semantically equivalent to an EN 16931 invoice if a proper subset is used (in fact, UN/CEFACT, the body behind EDIFACT, evolved a “Cross Industry Invoice” which is conceptually an updated model aligning with EN 16931 – but delivered as XML rather than old EDIFACT syntax). The limit is that legacy systems may not easily adapt to new rules: an ERP that has been spitting out EDIFACT D96A format for 20 years might not have fields for some of the new requirements, or might populate certain fields in non-standard ways. Upgrading those mappings costs time and money. Therefore, while alignment is technically feasible and happening, it’s not instantaneous or universal.

9.3 Practical constraints in legacy environments: Many large organizations have invested heavily in EDI and are understandably reluctant to change those processes unless necessary. For such organizations, Factur‑X might be seen as redundant. Their suppliers or customers either use the existing EDI pipeline or get a PDF separately; introducing Factur‑X would add a third format to manage. They likely prefer to keep using their tried-and-true EDIFACT or XML EDI and focus on converting it to meet any new government submission requirements (e.g., an EDI provider might convert a firm’s EDIFACT into a compliant UBL for sending to a government portal). Indeed, in France’s upcoming mandate, companies can continue using EDIFACT for B2B as long as their chosen platform can convert it to an accepted EN 16931 format before sending to the tax authority. This underscores that legacy formats will persist behind the scenes, with conversion at the edge. A practical constraint here is potential information loss or misinterpretation during conversion. If an EDIFACT message contains something that doesn’t cleanly map to EN 16931, it might end up in a generic field (like an additional note). Conversely, if EN 16931 has a concept that the legacy format lacks, that data might be absent. For instance, EDIFACT can carry multiple tax totals for different tax types, as can EN 16931; but if a company’s legacy system always assumed one VAT rate per invoice, they might ignore others. Aligning requires updating business processes, not just formats. Another constraint is supplier/buyer readiness: smaller suppliers might not be on EDI, which is exactly why hybrid formats like Factur‑X were introduced – to allow them a path into structured invoicing without full EDI. But from the perspective of a large buyer with an EDI portal, it might be easier to just on-board those SMEs via a web portal or a lightweight XML upload rather than dealing with emailed PDFs. So the push from big players might actually be toward portal entry or direct data entry (or simple XML) rather than email-based PDF solutions. Additionally, some legacy formats are so entrenched in certain industries (e.g., the PEPPOL BIS itself will be considered “legacy” if one day a new version appears) that moving everyone to a new hybrid might be impractical. Instead, the trend could be to incorporate visual elements into those processes differently – for example, an EDI portal might auto-generate a PDF for human readability, rather than expecting the supplier to send one. Indeed, many modern EDI tools and e-invoicing platforms allow a user to upload a PDF which is then OCR’d or mapped to data; or conversely, allow a user to view an XML in a pretty PDF format on screen. These are alternative solutions to the same problem Factur‑X addresses (the human/machine divide), implemented at the platform level rather than in the file. So, while Factur‑X offers an elegant solution on the file level, a lot of legacy systems solve the problem elsewhere (in the application layer). That approach will likely continue: if a company has a portal for invoices, it might give the user a PDF preview and also ingest the data, without requiring a hybrid file. In conclusion, legacy EDI and other formats will continue to exist, and they can be bridged to the new standard but not without effort. Factur‑X does not directly integrate with older EDI systems – it’s more of a parallel track. Companies will either continue using their legacy formats internally and convert at boundaries to standard formats for interoperability, or gradually retire them in favor of standard ones. Factur‑X, as a standard format itself, is part of the ecosystem that might replace or wrap legacy formats for those who choose it. But entrenched EDI hubs may see it as just another format to map to. The real crux is that all roads must lead to EN 16931 in the end, whether via direct usage of Factur‑X or via conversion from EDIFACT or other legacy schemas. The multiplicity of formats was historically a barrier to e-invoicing adoption, and the European Standard aims to reduce that fragmentation. Thus, over time, one can expect legacy formats to either evolve to mimic EN 16931 or gradually sunset as companies move to truly standard solutions. Factur‑X might help some companies retire older EDI by offering a simpler solution. But for those that stick with legacy EDI, the strategy will be to adapt and convert, rather than adopting Factur‑X as an intermediary, unless there’s a clear benefit in doing so for specific partner communications. [einvoice.belgium.be], [einvoice.belgium.be]

Commercial invoicing models

10.1 Neutrality of Factur‑X toward business models: One of the strengths of Factur‑X (and the EN 16931 standard it implements) is that it is agnostic to the commercial process or business model behind the invoice. It only concerns the outcome – the invoice document – and not how that invoice came to be. Whether an invoice is generated by a supplier, by a customer (self-billing), or by an electronic platform, Factur‑X can accommodate it. The format doesn’t embed information about who created the invoice; it just contains the roles of seller and buyer and the details of the transaction. This means Factur‑X can be used in traditional billing (supplier issues an invoice to customer in the normal way) as well as in less common models like self-billing or automated billing triggers. The legal requirements for invoice content (Article 226 of the VAT Directive) apply equally, and Factur‑X’s data model can represent those required elements regardless of who is the issuer. For example, in a traditional sale, the supplier’s software might produce the Factur‑X file; in a self-billing scenario, the customer’s software would produce the Factur‑X file on the supplier’s behalf – but in both cases, the XML portion will populate the fields for “Seller” and “Buyer” in the same manner, and it will include all the required particulars of the supply. Nothing in the format ties it to a specific workflow. This neutrality is by design: standards bodies intended EN 16931 to be applicable to all types of invoices (B2B, B2G, B2C, self-billed, etc.), and Factur‑X inherits that generality. By focusing on the data (amounts, parties, tax details, etc.), it doesn’t matter if the invoice was created manually, by an automated system, or even retroactively – as long as the data is correct. In contrast, some proprietary invoicing systems or platform-specific formats might impose certain process assumptions, but Factur‑X steers clear of that: it’s meant as a universal container for invoice information. From a business perspective, this means adopting Factur‑X won’t force you to change how you conduct business or how you agree on invoicing with your trading partners – it simply changes how the finalized invoice is represented.

10.2 Applicability to self‑billing, triggered invoices, and platform‑generated invoices: The Factur‑X format can be used in all common invoicing models, including cases where invoices are issued by parties other than the supplier or through automated processes. For instance, self‑billing (where the customer issues the invoice in the supplier’s name) is fully supported by Factur‑X, as the format can include all legally required elements such as the compulsory mention “Self-billing” on the invoice. The structured XML in Factur‑X has fields for the seller and buyer details, allowing the customer (as the issuer) to correctly identify the supply’s parties and include the required self-billing indication. Similarly, Factur‑X can accommodate invoices triggered automatically by events (e.g. periodic billing or consumption-based billing) because the format imposes no constraints on who or what generates the invoice, only on the data content. Whether an invoice is prepared by a human, an ERP scheduler, or a third-party platform, the Factur‑X requirements remain focused on having the necessary data fields (dates, amounts, tax details, etc.) present in the XML. Platform-generated invoices (such as those created by e-commerce marketplaces or government portals on behalf of a supplier) can also be rendered in Factur‑X format. What matters is that the platform populates the invoice’s XML with the correct information. In all these scenarios, Factur‑X acts as a neutral container for the outcome (the invoice document) and does not dictate the workflow that led to its creation. The legal responsibilities (for example, obtaining prior agreement for self-billing or ensuring the invoice is issued timely) remain with the transacting parties under VAT law, not with the format. Factur‑X simply ensures that, once the invoice is created, it can express all legally required and relevant data in a structured way, no matter who issued it or how it was generated. [datenbank.nwb.de]

10.3 Emphasis on invoice content rather than process: Factur‑X, like EN 16931 itself, is concerned with the content of the invoice, not the business process behind it. This means the format standardizes what information is on the invoice (and how it is represented in data terms), but is agnostic to how the invoice is transmitted or approved. As Recital 8 of Directive 2014/55/EU notes, semantic interoperability (agreement on content) is distinct from and independent of the transmission method or platform. Factur‑X ensures that the content of an invoice (parties, amounts, tax details, etc.) is unambiguous and standardized; it deliberately does not prescribe the workflow for issuing or delivering the invoice. For example, Factur‑X does not include fields that would track an invoice’s approval steps or whether it was cleared by a tax authority – those are operational or procedural aspects handled outside the invoice file. The idea is that any process – whether a simple email exchange, a complex EDI integration, or a clearance through a government portal – can carry a Factur‑X invoice as the payload, and the data within will be consistent. Similarly, Factur‑X does not itself ensure compliance with obligations like obtaining customer’s agreement to receive e-invoices or ensuring authenticity of origin; those are process and control matters governed by VAT law (e.g. Articles 232 and 233 of the VAT Directive) and must be met through organizational or technical measures (such as business controls or digital signatures) beyond the format. In summary, Factur‑X cleanly separates information content from process: it standardizes invoice data so it can be understood across systems, while leaving parties free to choose how to exchange or process the invoice. This clarity of roles helps companies adopt Factur‑X without overhauling their entire invoicing process – they can keep their existing process (self-billing, email, portal, etc.) and simply output the invoice in a compliant hybrid format. The invoice’s legal and operational validity still depends on following the correct procedures (timely issuance, acceptance by the recipient, etc.), which are not dictated by Factur‑X. Factur‑X’s job is to ensure that, once an invoice is issued, its content can meet legal requirements and be interoperable, regardless of the surrounding process. [ec.europa.eu]

Other hybrid formats and alignment

11.1 Relationship with ZUGFeRD: ZUGFeRD (“Zentraler User Guide des Forums elektronische Rechnung Deutschland”) is simply the German name for the same hybrid invoice standard that France calls Factur‑X. In practice, “Factur‑X” and “ZUGFeRD” refer to the identical data format. When the Franco-German working group released the first version of the hybrid invoice specification in 2017, it was branded as “Factur‑X 1.0” in France and “ZUGFeRD 2.0” in Germany, but the technical content was the same down to every field. Subsequent updates have been issued jointly (e.g. the current 2025 release is published as Factur‑X 1.0.8 – ZUGFeRD 2.4). The documentation explicitly states that the German term ZUGFeRD and the French term Factur‑X “are now to be used synonymously; they describe the identical data structure”. In practice, organizations in Germany often use ZUGFeRD to refer to the format and those in France say Factur‑X, but there is no technical difference. Both communities coordinate through a joint committee, ensuring that enhancements or new profiles are adopted uniformly. One minor historical distinction is that ZUGFeRD 1.0 (2014) was an earlier German-only hybrid format that predated EN 16931 and had different data specs; but with ZUGFeRD 2.0/Factur‑X 1.0, France and Germany converged on a single standard aligned to EN 16931. So, anyone using ZUGFeRD 2.x today is effectively using Factur‑X under a different name. For global interoperability, the Factur‑X name is gaining favor (being language-neutral and explicitly tied to the “invoice” concept), but documentation and software often mention both. The bottom line: there is no need to convert or worry about compatibility between Factur‑X and ZUGFeRD – an invoice in one is by definition an invoice in the other. Businesses dealing with German partners might still label files or options as ZUGFeRD, but they can exchange those seamlessly with French partners who call it Factur‑X. [0_FACTUR-X…5_12_04_EN | PDF]

11.2 Differences between national implementations: While the semantic standard EN 16931 is Europe-wide, its implementation can vary by country (via allowed CIUS customizations or local regulations), and not all countries chose the hybrid PDF approach. Factur‑X is officially recognized mainly in France and Germany, and each has tailored it slightly to local needs within the standard’s framework. For example, the Factur‑X specification defines a “Reference Profile XRECHNUNG” to embed Germany’s standard CIUS (XRechnung) inside a Factur‑X file. In practice, this means a German supplier to the federal administration could send a ZUGFeRD/Factur‑X file where the XML part is flagged as XRechnung-compliant (satisfying all German public-sector rules) – the PDF container is extra. Conversely, France has defined an extended profile (EXTENDED-CTC-FR) within Factur‑X to cover additional data needed for its upcoming continuous transaction controls (like France’s 2026+ B2B e-invoicing mandate). Despite these extensions, the core of Factur‑X remains the same across borders. Differences lie in which profile is used and what extra data might be included. Outside of FR and DE, other Member States have taken different routes: some mandated pure XML invoice formats rather than hybrids. For instance, Italy requires invoices in a proprietary XML (FatturaPA) transmitted via a government system – PDF hybrids are not used in that model. Spain uses its own Facturae XML for certain exchanges, and many countries rely on PEPPOL UBL or local CIUS as the structured format for B2G e-invoicing. These variations mean that a Factur‑X file, while semantically standard, may not be accepted everywhere unless it is converted to the locally mandated format or profile. However, because all these formats (Factur‑X, UBL, national CIUS) share the EN 16931 semantics at heart, conversion or interoperability is usually feasible. The interoperability challenge arises if national implementations introduce extra requirements: for example, a country might require an invoice to carry a specific code or information not in the base standard. Factur‑X’s Extended profile mechanism is intended to accommodate such additions in a controlled way so that one country’s specifics do not break another’s system. Still, businesses must be aware of national e-invoicing “dialects”: an invoice structured for France (even if Factur‑X) might need slight adjustments to meet, say, Dutch or Spanish public-sector rules (e.g., different code lists or references). In summary, EN 16931 ensures a large degree of commonality, but implementation differences persist at national level – some countries fully embrace the hybrid PDF (FR/DE), others insist on pure XML through their networks. The trend, especially under EU initiatives, is toward convergence, but companies operating cross-border should remain attentive to the format and transmission requirements of each target country. [0_FACTUR-X…5_12_04_EN | PDF], [0_FACTUR-X…5_12_04_EN | PDF]

11.3 Interoperability risks: The existence of multiple e-invoice formats and profiles in Europe carries interoperability risks if not properly managed. One raison d’être of EN 16931 was to combat the “excessive complexity and additional costs” caused by a multiplicity of non-interoperable national invoice standards. Factur‑X itself was born as a solution to align the French and German approaches, precisely to avoid fragmentation between those two large economies. However, across the EU, divergence remains: while Factur‑X provides one interoperable format for those who adopt it, others use UBL, EDIFACT-based formats, or proprietary XML schemas. If each Member State (or industry) were to promote its own hybrid or variant without alignment, businesses trading internationally would face the same old problem – needing different invoice formats for different partners or countries. Interoperability issues can manifest in various ways. For example, a company using Factur‑X to invoice a German public authority would be interoperable (since Germany accepts ZUGFeRD invoices that conform to EN 16931’s CIUS XRechnung). But if that company sent a Factur‑X invoice (perhaps with a French profile) to a country that only supports, say, PEPPOL BIS UBL, the structured data might not be usable there until converted. Differences in profiles or extensions also pose a risk: if a sender includes custom extension data (even within Factur‑X’s Extended profile) that the receiver’s system doesn’t recognize, it might be ignored or cause processing errors. Moreover, over-reliance on the PDF aspect of hybrid invoices in some circles, and pure XML in others, could hinder straight-through processing between those circles – for instance, an AP system expecting a UBL file might not readily ingest an embedded XML from a PDF. These are precisely the scenarios that EU standardization seeks to eliminate. The mitigation of these risks is ongoing: bodies like CEN and forums like the European Multi-Stakeholder Forum on e-Invoicing encourage use of the common semantic model and publish syntax mappings to ease conversions. Nonetheless, businesses should be alert to “false interoperability” – assuming that because an invoice is EN 16931-based, it will be plug-and-play everywhere. Misalignment in format or profile can still require conversion or manual intervention. A concrete example: an invoice in Factur‑X Basic profile (lacking line-item detail) sent to a buyer whose system expects full EN 16931 detail might be rejected or require follow-up, even though both sender and receiver are “using the standard.” Thus, the risk is not with the core standard but with partial compliance or format mismatches. To safeguard interoperability, companies and solution providers are moving towards supporting multiple syntaxes and doing format conversions behind the scenes. The long-term regulatory push (ViDA) also aims to reduce these inconsistencies by making structured e-invoicing ubiquitous and narrowing the acceptable formats. But until convergence is fully achieved, careful attention must be paid to format compatibility in cross-platform or cross-border invoicing. [ec.europa.eu] [e-rechnung-bund.de]

11.4 Long‑term convergence expectations: European e-invoicing is on a path towards greater convergence and simplification. The ultimate vision, reinforced by the VAT in the Digital Age reforms, is that all businesses will use a common semantic standard (EN 16931) and a limited set of syntaxes for electronic invoices, reducing today’s fragmentation. In fact, Directive 2014/55/EU itself suggested that one long-term objective should be to “limit the number of syntaxes used”, focusing on the most commonly used ones. We are already seeing this play out: essentially UBL and UN/CEFACT XML (CII) have emerged as the two dominant syntaxes under EN 16931 (with Factur‑X using the latter). It is conceivable that, in the future, further consolidation could occur – for example, if one syntax becomes universally preferred, translations between formats might become unnecessary. More concretely, the ViDA proposals agreed in March 2025 (Council Directive (EU) 2025/516) will make structured e-invoices the default across the EU in B2B, phasing out unstructured invoices. As all Member States implement this, the diversity of formats should diminish. We expect a convergence on interoperability frameworks like PEPPOL as well, which already normalizes format (by promoting UBL) and transport protocols across borders. There is also a push to align any remaining hybrid models with broader networks – for instance, the Factur‑X consortium has introduced ways to incorporate national CIUS requirements (like XRechnung) into the PDF hybrid so that it doesn’t stand outside the mainstream e-invoicing infrastructure. In the long term, as companies large and small become capable of handling pure structured data, the added value of the PDF layer may recede – e-invoices might be exchanged as data only, with visualizations generated on the fly if needed. That would truly fulfill the vision of fully automated invoicing. However, given the installed base of SMEs and the ongoing need for human-readable records, a format like Factur‑X could persist as a user-friendly option well into the future, ensuring no business is left behind during the convergence. We may also see hybrid approaches converge: for example, PEPPOL might one day officially support PDF+XML as a modality if there is demand, or Factur‑X might evolve to be transport-neutral (just as a way to package data with visuals, whether sent by email or uploaded to a platform). In summary, the trajectory is toward universal semantic compliance (everyone using EN 16931 core) and streamlined syntactic choices, which will greatly simplify cross-border invoicing. Factur‑X has positioned itself within that trajectory by adhering to the standard from the start. Over time, it will either seamlessly integrate into the converged framework (as one of the last-mile formats for human readability) or gradually become less necessary as stakeholders opt for pure data exchange. Either way, the convergence of law, standards, and technology – with EN 16931 as the fulcrum – is expected to eliminate the major discrepancies currently experienced, fulfilling the once-ambitious goal of truly interoperable e-invoicing across Europe. [ec.europa.eu] [e-rechnung-bund.de] [0_FACTUR-X…5_12_04_EN | PDF], [0_FACTUR-X…5_12_04_EN | PDF]

Key limitations and common misunderstandings

12.1 Factur‑X is not a VAT compliance guarantee: Using the Factur‑X format does not automatically guarantee that an invoice complies with all VAT legal requirements. Factur‑X is a tool that can carry all required information, but it’s still up to the user to ensure that the information is correct, complete, and meets the law. The EU VAT Directive’s Article 226 lists elements “indispensable” for an invoice’s validity – these must appear on the invoice, whether you use Factur‑X or not. If a company were to omit a legally required detail (for example, the supplier’s VAT ID, or the phrase “Reverse charge” where applicable) or include incorrect data, the invoice would be legally non-compliant even if the file is in Factur‑X format. In practice, Factur‑X (especially at EN 16931 profile) makes it easier to comply because it has designated fields for each Article 226 item. But it is not foolproof: one can still populate those fields erroneously or not update their system to include new legal mandates. Moreover, compliance involves more than just the invoice’s fields. For example, ensuring the invoice’s authenticity and integrity (a requirement under VAT law for electronic invoices) is not achieved by the format alone – Factur‑X doesn’t automatically sign the invoice or validate the sender. Businesses must implement appropriate controls (like digital signatures, EDI agreements, or reliable audit trails as per Directive 2006/112/EC Article 233). If they fail to do so, an invoice might be challenged by tax authorities despite being in Factur‑X. Another scenario: timely issuance and storage obligations (Articles 222 and 247) – a Factur‑X invoice issued late or not stored properly is still a compliance breach. In short, Factur‑X can facilitate VAT compliance by providing a structured template that covers the bases, but it is not a substitute for robust compliance processes. One should think of it as analogous to a well-designed tax form – using the right form helps, but you must still fill it out correctly and follow the rules. Tax authorities will judge an invoice’s validity by substantive content and legal criteria, not just by its format. Thus, companies must remain vigilant: continue to consult VAT requirements (including any local specifics) and use Factur‑X in a way that all those requirements are met. An error or omission (say a missing “Self-billing” mention on a self-billed invoice, or a tax point date in a continuous supply) is not forgiven just because the invoice was a structured PDF. Indeed, an incorrect Factur‑X invoice could be just as non-compliant as a wrong paper invoice – and would need correction or could jeopardize VAT deductions. The format is only as compliant as the data entered into it and the processes surrounding it. [ec.europa.eu]

12.2 Factur‑X ≠ EN 16931 compliant by default: A common misconception is that every Factur‑X invoice automatically conforms to the European e-invoicing standard EN 16931. In reality, only certain profiles of Factur‑X achieve full EN 16931 semantic compliance. As discussed, Factur‑X defines profiles like Minimum, Basic WL, Basic, EN 16931 (Comfort), and Extended, which contain increasing levels of detail. The lower-tier profiles are explicitly subsets of the EN 16931 core model. For example, a “Basic WL (Without Lines)” invoice might include only summary amounts and tax totals, omitting line-item details – such an invoice does not meet the full EN 16931 requirements, since EN 16931 expects line-level data for each item or service. Similarly, the Basic profile with lines may still exclude some information considered mandatory or critical under the standard (such as certain reference numbers or bank details). Therefore, a Factur‑X file in those profiles is not an “EN 16931-compliant invoice” in the formal sense. Only the “EN 16931” profile (also called Comfort) and properly configured Extended profiles cover the complete semantic data set of the European Standard. Using a lower profile may be perfectly acceptable between trading partners by agreement, and it may contain all legally required data for VAT, but if a scenario specifically demands an EN 16931 compliant invoice – for instance, a public procurement platform that has implemented the standard – sending a Basic profile Factur‑X would fall short. The recipient might reject the invoice or flag it as invalid for not containing all required fields or for failing standard validation rules. In one real-world example, the French government’s Chorus Pro portal initially permitted a “Minimum” profile for very simple B2G invoices, but for full compliance with the EU standard, it moved towards requiring the EN 16931/Comfort profile. The key point is that the mere use of the Factur‑X format doesn’t tell you the compliance level – the profile choice does. Factur‑X files carry an indicator of the profile in the XML and PDF metadata. Software and recipients will check that. If an organization mistakenly assumes “we’re using Factur‑X, so we’re good with the European standard,” but they are actually using Basic or Minimum profile, they could be in for a surprise. Their invoices might not be accepted by, say, a contracting authority that expects an EN 16931 invoice (which corresponds to Factur‑X’s Comfort profile) or by a customer’s AP system configured to ingest full-detail data. In summary, Factur‑X can produce EN 16931-compliant invoices, but not every Factur‑X file is one. Achieving compliance requires selecting the correct profile and populating it correctly. This is why implementers should treat Factur‑X profiles as stepping stones – if you require EN 16931 compliance (for regulatory or interoperability reasons), you must use the full profile and validate against the standard’s rules. A lower profile should be chosen only when both parties agree to a lighter content and when not constrained by an EN 16931 mandate. Confusing “Factur‑X” generally with “EN 16931 compliance” is dangerous: one is a container format, the other is a content standard. The container can hold both compliant and non-compliant datasets. Thus, always align your use of Factur‑X with the needed compliance level, and monitor the profile indicated in the files you send or receive. [0_FACTUR-X…5_12_04_EN | PDF]

12.3 Factur‑X is not a clearance or reporting mechanism: Some may mistakenly equate using the Factur‑X format with fulfilling obligations for real-time tax reporting or clearance systems, but these are entirely different matters. Clearance refers to a regime where invoices (or their data) must be submitted to a tax authority’s system for approval or logging, typically before or as they are issued to the customer. E-reporting refers to sending structured transaction data to tax authorities, either in real-time or periodically. While Factur‑X can carry the necessary data for such systems, it does not by itself transmit any data to the tax authorities – that requires a separate process or platform. For example, France’s upcoming central e-invoicing and e-reporting mandate will allow businesses to use Factur‑X as the format of invoices exchanged with trading partners, but those businesses (or their service providers) still must send the invoice data to the tax authority’s portal (PPF) in a mandated way. In Italy’s clearance system (SdI), using Factur‑X is not an option at all; invoices must be sent in the FatturaPA XML format through the SdI network. Even in jurisdictions where Factur‑X is accepted for sending to partners or to public bodies, the tax authority typically wants the raw structured data, not a PDF file. This means that if you adopt Factur‑X, you may benefit from easier data extraction: you or your service provider can pull the XML out of the PDF and forward it to the authority’s systems. But that is an additional step; simply emailing a Factur‑X PDF to your customer does not fulfill a live reporting requirement. A real-world illustration comes from France’s guidance on the 2024–2026 mandate: during a transitional period, they may allow PDF invoices with Factur‑X for certain small businesses, but those will carry only basic “header” data, and the platforms will have to flag such invoices since they lack full line-item detail. Ultimately, as of 2026, all invoice data (including line items) must be transmitted – meaning the Factur‑X file must be converted to pure data if the PDF was initially used. The bottom line is that Factur‑X is a format for exchanging invoices between supplier and buyer – it doesn’t communicate with the tax authority on its own. Companies should not assume that using Factur‑X relieves them from additional compliance steps required by clearance regimes. They must still ensure that the invoice’s XML is delivered to the tax portal or reporting system in the prescribed manner (directly or via an intermediary). In a clearance model, the “cleared” status or official validation often needs to be reflected on the invoice (for example, with a unique code or number). Factur‑X has no built-in concept of clearance status; it would be up to the implementer to add any such reference (perhaps as an additional note or reference field in the XML or on the PDF after clearance). In summary, Factur‑X addresses the format of the invoice, not the flow of approval/reporting. If you operate in a country with invoicing clearance or rapid reporting, treat Factur‑X as a complementary tool – a way to structure and exchange data with your trading partners – but make sure you also comply with the transmission of that data to the authorities via the mandated channels. [e-rechnung-bund.de] [External s…glish v2.1 | PDF]

12.4 PDF readability ≠ legal or semantic compliance: The fact that a Factur‑X invoice is human-readable as a PDF can lead to a false sense of confidence. It is essential to understand that just because the invoice looks correct to the eye, this does not guarantee that it meets all legal and semantic requirements. Under the EU rules, what defines an “electronic invoice” is the presence of structured data, not the visual representation. In everyday business, people might refer to emailed PDFs as “e-invoices,” but strictly speaking a PDF that isn’t accompanied by compliant structured data is not an electronic invoice under Directive 2014/55/EU. Factur‑X, of course, does have structured data – that’s what makes it a true e-invoice. However, if one were to focus only on the PDF portion (the human-readable part), one could miss compliance issues hidden in the data layer. For example, suppose there is a discrepancy between the PDF and the XML (perhaps a discount was shown on the PDF but not reflected in the XML totals). A human might not notice the XML error by just looking at the PDF, but an automated system or an auditor examining the data will catch the issue. Additionally, a visually “fine” PDF might be semantically incomplete – e.g. it might show all amounts, but the XML could be missing a required field like a tax point date or an identifier needed for EN 16931 validation. The invoice might pass a casual visual check (and even a basic accountant’s review), but fail a business rule check or a government portal’s validation because of the data issue. Also, consider that PDF rendering doesn’t enforce business rules – nothing stops a PDF from showing things out of alignment (like an untotaled tax category) that a human might overlook. In contrast, the Schematron in the XML would flag it. Therefore, visual readability is no substitute for compliance. One must validate the structured content to ensure both semantic accuracy (all required data present, all calculations correct) and legal correctness. Another aspect: a company might think keeping PDFs ensures they meet archiving rules, since an auditor can read the invoice. But if the jurisdiction (under new e-invoicing definitions) requires that the original invoice be stored with its structured data, then just storing printed or imaged PDFs wouldn’t meet the requirement. To reiterate, the PDF is a convenience layer; the authoritative information for compliance is the data. This is why many large e-invoicing frameworks discourage relying on a PDF copy alongside the XML, to avoid confusion about which is the “true” invoice. With a hybrid like Factur‑X, the two are bound together, but the principle remains: in any dispute or validation, the structured data carries more weight. Companies should train their staff and configure their systems to always consider the XML content as the source of truth. If the PDF and XML differ, the XML needs correction – and until corrected, the invoice may not be considered compliant. Lastly, it’s worth noting that for an invoice to be legally valid, it must be both legible and complete. The PDF ensures legibility to a human, but completeness is judged by the data. Regulatory auditors increasingly use automated tools to analyze e-invoices; a pretty PDF won’t prevent non-compliance notices if the underlying data is flawed or missing required elements. In summary, never assume that “it looks right” means “it is right” – always verify that the structured content of a Factur‑X (or any e-invoice) is correct and compliant. [e-rechnung-bund.de], [e-rechnung-bund.de]

12.5 Risks of incorrect compliance claims: Given the nuances above, it’s clear that phrases like “Factur‑X compliant” or “EN 16931 compliant” can be misapplied, leading to dangerous misconceptions. Businesses should be wary of overconfident claims by software providers or internal teams that may mask partial compliance. For example, a company might implement an e-invoicing solution and advertise that it is “EN 16931-compliant”, when in fact it produces only the Basic profile of Factur‑X or violates some business rules. If the company doesn’t test thoroughly, it might start issuing those invoices and later find that certain customers or government portals reject them. This could result in payment delays, strained customer relationships, or even penalties. Similarly, a supplier might believe that sending a PDF invoice with an embedded XML ensures their customers and the tax administration have everything needed. But if that XML is incomplete (missing data like the buyer’s VAT ID or using a non-compliant country extension), the invoice may not be accepted. German public entities, for instance, require invoices to meet the XRechnung CIUS; they do accept ZUGFeRD/Factur‑X only if it uses the XRechnung-compliant profile and meets the federal ordinance’s terms of use. An incorrectly configured “Factur‑X” that doesn’t meet those specifics would be rejected. Another risk is internal: a business might treat the PDF part of Factur‑X as the official record and ignore the XML, failing to notice that their system didn’t populate some fields – they may only discover the error when an audit or a customer flags it. Furthermore, presuming that Factur‑X alone satisfies a digital reporting obligation can leave a company non-compliant if they fail to actually transmit the data (as noted, the format doesn’t do that for you). To avoid these pitfalls, organizations should approach e-invoicing with a holistic compliance mindset: format, content, and process all need to align. Testing against validators (for EN 16931 rules) and against trading partner requirements is essential. It’s wise to obtain formal certifications or confirmations for your e-invoice outputs when possible (for instance, the French FNFE offers a conformity assessment for Factur‑X files, and many tax authorities provide validation portals). Also, companies should pay attention to ongoing changes – compliance today doesn’t guarantee compliance tomorrow if standards or laws change. The EU environment is evolving (code lists update every six months, and new mandates like ViDA will update requirements), so static claims of compliance can become outdated quickly. In summary, false confidence in e-invoicing compliance can be costly. The remedy is to ensure precise use of terms (know exactly which profile or standard is meant by “compliant”), continuous testing/validation, and staying informed on legal and technical updates. The reward for doing so is significant – smooth operations and avoidance of penalties – but the risks of getting it wrong include rejected invoices, delayed payments, VAT credit denials, and potential fines. It’s better to be meticulously correct than complacently wrong. [e-rechnung-bund.de] [0_FACTUR-X…5_12_04_EN | PDF], [0_FACTUR-X…5_12_04_EN | PDF]

Strategic takeaways for businesses

13.1 When Factur‑X makes strategic sense: Adopting Factur‑X can be a strategic win for businesses under several circumstances. First, it is particularly valuable for companies that deal with a mix of trading partners varying in technological maturity. If some customers or suppliers are not ready to consume pure XML invoices, Factur‑X offers a “best of both worlds” solution by providing a human-readable PDF and a machine-readable XML together. This makes it an excellent transitional tool for small and medium-sized enterprises (SMEs) or any organization in the process of upgrading its systems to full electronic data interchange. Rather than leaping directly to XML and risking leaving some partners behind, a company can implement Factur‑X and immediately automate what is possible while still giving less-digitized partners a familiar PDF they can open and process manually if needed. Second, Factur‑X makes sense when a business wants to future-proof its invoices without alienating current processes. By embedding standard data in your invoices now, you are effectively preparing for upcoming mandates (like ViDA) that will require structured data, all while continuing to use PDFs which are the current norm. This readiness can be a competitive advantage: you can respond faster to customers who request e-invoices and integrate more easily with their AP automation systems. Third, Factur‑X is strategically useful for archiving and audit: many companies and tax authorities still value or require invoices to be stored in a human-readable format (for example, PDF/A for long-term archiving). Factur‑X inherently satisfies that by using PDF/A-3, which is an accepted archival format, while preserving the data for any future needs. From a governance perspective, implementing Factur‑X can reduce errors and processing time (leading to faster payments and fewer disputes) by enabling automated validation of invoices. Companies with high invoice volumes, in particular, can benefit from this hybrid automation. Additionally, in B2G contexts where e-invoicing is mandatory, using Factur‑X (at the appropriate profile) can ensure compliance while minimizing overhead – you produce one invoice that meets the government’s data requirements and simultaneously provides a nice-looking PDF for your own filing or for internal use. Finally, Factur‑X can be a unifying format for cross-border invoices within certain regions. For instance, a business operating in France, Germany, and neighboring countries might standardize on Factur‑X for all invoices, since it will be understood by French and German partners and is convertible to other formats when needed. In summary, Factur‑X makes strategic sense as a transition mechanism towards full e-invoicing: it allows you to start reaping the benefits of digital invoices (automation, fewer errors, faster processing) immediately, even if your ecosystem isn’t 100% ready for pure XML. It helps insulate you from changing requirements, because the underlying data model is the European standard, meaning any further regulatory changes are likely to be extensions of what you’re already capturing. However, it is not the only strategy – some companies may jump straight to XML or use service providers – but for many, especially those with diverse counterparts, Factur‑X offers a practical, low-friction path forward. [0_FACTUR-X…5_12_04_EN | PDF]

13.2 Benefits and limits for tax control and audit: Factur‑X can strengthen tax control and auditability of invoices by combining clear human presentation with rich, structured data. On the benefit side, the presence of an EN 16931-compliant XML within the invoice means that tax authorities (and internal auditors) can leverage software to automatically analyze the contents of invoices, rather than relying on manual interpretation. This can facilitate easier compliance checks – for example, validating that VAT amounts and rates match taxable amounts, or that required fields are present – which can be done by automated tools using the structured data. It also allows for cross-referencing of invoice data against VAT returns or customer listings more readily. For businesses, having structured data in invoices means they can run internal controls (like verifying that the VAT on invoices matches their own calculations, or that the invoice references a valid purchase order) without human error. Additionally, because the PDF portion is visually identical to a traditional invoice, auditors (internal or external) can review invoices in a familiar format. If an auditor queries a particular transaction, the company can provide the Factur‑X PDF, which the auditor can read as usual, but also supply the XML to allow detailed analysis or cross-checking (for instance, import into audit software). The PDF/A-3 format ensures that the visual invoice will remain legible for years (a boon for meeting record-keeping requirements), and the embedded XML ensures that even if company systems change, the raw data can be extracted later in a standard form. However, there are also limits to these benefits. The mere presence of structured data doesn’t automatically mean tax authorities will accept or use it unless their systems are set up for it. In countries without advanced e-audit systems, the fact that you have Factur‑X may not yield immediate audit advantages – you might still be asked for summary listings or to manually justify figures. Nonetheless, the trend is toward tax authorities utilizing digital data more (e.g., SAF-T filings, real-time reporting), so having invoices in this format is future-looking. Another limitation is that garbage in, garbage out: if the data in the XML is wrong (even if the PDF looks fine), automated checks will raise issues. So companies must ensure strong data governance around invoice creation. Factur‑X’s built-in validation rules (if used) can act as a first line of defense by catching errors before invoices go out, but they are not a substitute for understanding tax rules. Also, while Factur‑X holds the data, companies need the right tools to leverage it: e.g., an AP department needs software capable of reading Factur‑X XML to actually get value from it; otherwise, they might end up treating it like a regular PDF, squandering its potential. From a tax control perspective, Factur‑X provides an opportunity for better compliance (because errors can be caught and corrected earlier), and easier provision of data to tax inspectors. In an audit, you could quickly provide a tax authority with the XML from a range of invoices, allowing them to verify, say, the VAT declarations efficiently. Compare this to an audit of paper/PDF invoices where they might sample documents and manually inspect them – digital data allows more comprehensive checks in less time. In summary, Factur‑X bolsters the audit trail by ensuring that every invoice has a consistent set of data points that can be systematically verified. It reduces the risk of overlooked details and makes proving compliance (or identifying non-compliance) more straightforward. The limitations lie in the need for proper implementation and the external environment’s readiness – but those are evolving. Companies that adopt Factur‑X early position themselves to deal smoothly with tax controls as they become more digitized.

13.3 Implications for ERP systems, archiving, and controls: Implementing Factur‑X (or any structured e-invoicing) often requires upgrades or adjustments to ERP and accounting systems. Traditional ERP invoice modules that were designed to produce print/PDF output must be configured to output the relevant data into the XML. This means companies need to ensure their master data and transaction data are complete – for example, capturing things like unit of measure codes, tax category codes, or payment bank details as discrete fields, whereas previously such information might have been just free-text on an invoice. Many modern ERPs have modules or add-ons for e-invoicing that support standards like EN 16931, but it’s important to map all necessary fields (including optional ones that could become mandatory in certain scenarios) from the ERP database to the invoice output. Data governance becomes crucial: inconsistencies or gaps in the ERP (like missing address fields, outdated tax codes, etc.) will directly lead to validation errors in Factur‑X output. On the plus side, once the ERP is configured for EN 16931, it can often produce not just Factur‑X but also other formats (since the core data is the same).

From an archiving perspective, Factur‑X simplifies compliance with storage requirements. Many countries require electronic invoices to be stored in their original format and to remain readable for years. Storing a PDF/A-3 with embedded XML addresses both the readability (human-readable PDF and a self-contained format that is likely to be accessible far into the future) and the completeness (all data is there) aspects. Organizations should update their archiving policies to ensure they preserve the Factur‑X files exactly as sent or received (without alteration) and maintain the ability to retrieve the XML from them if needed. It may be prudent to store backups of just the XML data as well, or index the XML content in an archive for searchability. Importantly, if a company uses digital signature services to sign PDFs (for authenticity/integrity), they should integrate that into their Factur‑X generation process – a signed Factur‑X PDF carries its signature over both the PDF content and the embedded XML, thereby sealing the entire invoice for audit purposes. Archival systems might need an update to handle the extraction of attachments from PDF/A-3 (to facilitate search or data analysis).

Regarding internal controls, Factur‑X can enhance them but also demands new ones. Companies should update their invoice verification routines to take advantage of the XML. For instance, an incoming Factur‑X from a vendor can be automatically checked against purchase orders in the ERP for mismatches (price, quantity, VAT) before payment, flagging discrepancies for review. Outgoing invoices can be put through a validation step (using EN 16931 Schematron rules) to catch errors that would cause customer rejections. These automated controls reduce the risk of human oversight and improve data quality. At the same time, staff may need training to understand the new process: e.g., what it means if an invoice fails validation, how to interpret validation error messages, or how to properly input data into the ERP so that all required fields are filled. Businesses might also implement new monitoring: for example, tracking how many invoices fail partner or portal validations, and addressing root causes (like missing customer IDs or incorrect tax codes in the system) promptly.

Finally, IT departments should plan for the maintenance of e-invoicing components. As standards evolve (with new code lists, etc.), ERP mappings and validation rules might need periodic updates. If using an external solution or middleware for Factur‑X conversion, ensure it’s kept up to date with the latest specifications (such as those semi-annual updates to align with EN 16931 validation artefacts). In summary, adopting Factur‑X touches multiple aspects of the back-office: ERP data quality, IT integration, document management, and control workflows. When managed well, these adjustments pay off in efficiency and accuracy. But companies should approach it as a cross-functional project – involving IT, accounting, tax compliance, and records management – to ensure a smooth transition. Those who do will find that their invoicing process becomes more robust and easier to audit, with much of the grunt work automated and fewer nasty surprises (like lost invoices or manual data entry errors). [0_FACTUR-X…5_12_04_EN | PDF]

13.4 Why EN 16931 readiness remains foundational: Amid all the focus on formats and platforms, businesses should not lose sight of the core: the ability to produce and handle EN 16931-compliant invoice data is the foundational requirement for the new era of e-invoicing. The European Norm is essentially the “common language” of invoices, and upcoming regulations (like the ViDA reforms) are cementing it as the baseline. For example, the recent Council adoption of ViDA measures in 2025 defines electronic invoices in terms of the EN 16931 semantic model and requires a structured XML format for B2B invoices. In practical terms, this means that whether you use Factur‑X, pure UBL, or another syntax, your systems must be capable of providing all the information that EN 16931 demands, in the correct form. If not, switching formats won’t help – you’d be pushing incomplete data around. Being “EN 16931 ready” involves ensuring that your customer and supplier master data, your product/service data, and your transaction processing capture the necessary elements. Can your system record multiple VAT rates on a single invoice and produce a correct breakdown? Can it output invoice line identifiers and link them to orders or deliveries? Do you have fields for things like the buyer’s reference or payment terms in a structured way? Many companies have discovered, during e-invoice onboarding, that they had to add fields or modules to capture data that was previously just typed into description fields. This kind of readiness is fundamental because it is format-agnostic: once you have the data structured internally, you can output it to Factur‑X, UBL, or any future format with relative ease. Conversely, if you attempt to implement an e-invoicing format without solidifying your data, you’ll run into repeated issues. Consider also that Member States often define CIUS (Core Invoice User Specifications), i.e. slight restrictions or extensions to EN 16931 for national use. If your data practices are robust, adapting to a CIUS (like adding a mandatory “Contract number” field for public sector invoices in one country) is manageable. If not, it could require painful manual workarounds. As a concrete example, Germany’s incoming B2B e-invoicing mandate (2025–2028) will require that invoices be EN 16931-compliant in either XRechnung or ZUGFeRD format. By that point, any company still issuing PDF invoices lacking structured data will simply not get paid by German customers – a compelling reason to get EN-ready. Similarly, France’s 2024–2026 mandate enumerates UBL, CII (for Factur‑X), and a national XML as accepted syntaxes, but all of them map to the same core data set. In sum, EN 16931 is the non-negotiable foundation: it is the reference for regulators, the expectation of large buyers and governments, and the key to interoperability. Businesses should invest in aligning their invoicing workflows with this standard – audit your invoices against EN 16931’s business terms, fill the gaps, and train staff on them. Formats will come and go, networks may vary, but a company that “speaks EN 16931” fluently will be equipped to handle whatever the future state of e-invoicing is, including real-time reporting to tax authorities. Factur‑X is one means to express EN 16931 data; what matters first is having that data and understanding it. In other words, data readiness trumps format: get your invoice content in order according to the standard, and you will find complying with any format or mandate (Factur‑X, PEPPOL, national platform, etc.) vastly easier. [e-rechnung-bund.de]

13.5 Factur‑X as a transition and hybrid solution, not an end state: It’s important for businesses to view Factur‑X in the correct strategic light – it is a means to an end, not the ultimate destination of e-invoicing evolution. Factur‑X was devised as a transitional “bridge” format to help parties move from unstructured to structured invoicing with minimal disruption. In the long run, the goal in Europe is to achieve fully digitized invoice flows and automated compliance, where the exchange of data is seamless. In that envisioned end state, the reliance on human-readable documents will diminish: invoices might be transmitted directly from system to system (or via government hubs) with visualization only when needed. Does this mean Factur‑X will become obsolete? Not necessarily – but its role may change. As discussed, Factur‑X is extremely useful now because it mitigates the gap between different maturity levels and provides a comfort blanket (the PDF) in the shift to digital. In the future, when all businesses, including SMEs, are accustomed to true e-invoices, the need to package a PDF with the XML may decrease. A small vendor who today might insist on sending a PDF could in a few years be using a government-provided portal or free tool that generates fully structured invoices without any PDF. At that point, the hybrid model might be used mostly for specific use cases, such as B2C invoices (where consumers expect a PDF/image but the company still wants an embedded XML for internal automation), or as an archival format. In fact, the latest Factur‑X specifications already anticipate that future: they introduce support for more elaborate data (like sub-line items for complex billing) to cover scenarios beyond the original EN 16931 so that the format can still be used as compliance demands get more granular. But there is a recognition that real-time reporting regimes (like those in ViDA) work best with direct data, not documents – for near-instant exchange with tax authorities, extracting an XML from a PDF is an extra step. Thus, in a fully mature continuous transaction control environment, companies might exchange purely the XML (or even just send data via API) with one another and to authorities, using a standardized syntax. The PDF could then be generated on-the-fly for human viewing when needed (much as many web-based invoice portals allow a PDF download of an XML invoice). [0_FACTUR-X…5_12_04_EN | PDF], [0_FACTUR-X…5_12_04_EN | PDF]

In that sense, Factur‑X’s PDF side can be seen as a training wheel for the e-invoicing journey – extremely helpful for balance and safety while the ecosystem stabilizes, but less relied upon once everyone is confidently riding on structured data. Nonetheless, we are not there yet. The transition will span several years, and during this period, hybrid solutions remain critical. Businesses should leverage Factur‑X now to position themselves for the end state, while planning for a future where processes may bypass PDFs. One practical approach is to implement Factur‑X as part of a solution that can easily be configured to send or receive “naked” XML when required, so that toggling off the PDF is an option when it no longer adds value. Another consideration is that even in a post-2028 world (when cross-border e-invoicing is mandated), differences in IT capabilities will likely persist globally – if you deal with partners outside the EU, a hybrid invoice might still be useful for them if they lack a compatible system. Also, remember that the concept of a hybrid invoice could be repurposed: just as Factur‑X started with invoices, similar approaches can handle orders (Order-X) or other documents, easing transitions in those areas. So Factur‑X is not a dead-end technology; it’s a flexible one. But businesses should keep their eyes on the prize: the end state is an environment of fully integrated, automated data exchange and compliance. Factur‑X is a powerful interim solution on the road to that destination, enabling benefits now and smoothing the journey. Just as importantly, it helps ensure that no company is left unable to participate in the digital economy due to lack of capability – it brings everyone along. By adopting it, companies invest in both present efficiency and future readiness. However, they should also continue strengthening their core data capabilities and integrations, so that when the day comes to let go of the PDF wheel, they can do so gracefully and fully embrace the streamlined, real-time world of digital VAT. In conclusion, Factur‑X should be seen as part of a broader strategy, not the final objective: the objective is end-to-end digital invoicing compliance, and Factur‑X is one clever strategy to achieve it in a gradual, inclusive way.