Factur-X Explained: The Hybrid Standard for FR-DE E-Invoicing

Think of Factur-X as a bilingual document, one that speaks fluent "human" on one side and fluent "machine" on the other. A French accountant opens it and sees a perfectly formatted invoice. A German ERP system reads the same file and extracts structured data automatically. An EU tax authority validates it against a common European standard. Nobody has to translate anything, and nothing gets lost on the way.

That is exactly what Factur-X delivers. Built on a decade of Franco-German regulatory cooperation, it is not just another file format. It is the technical answer to one of the most stubborn problems in cross-border B2B trade: how do you create an invoice that humans can read and machines can process, without forcing companies to choose between the two?

This article breaks down how the hybrid format actually works under the hood, why it carries the dual Factur-X / ZUGFeRD identity, and the concrete format details software vendors need before the mandate deadlines arrive.

Factur-X is a hybrid e-invoice standard that embeds structured, machine-readable XML data directly inside a human-readable PDF/A-3 file. The result is a single document that satisfies two needs at once: a finance team opens it and reads it like a normal invoice, while an ERP system or tax platform extracts and processes the XML automatically, with no manual re-entry.

If you have ever watched an accounts payable team re-key invoice data from a PDF into their ERP, you already understand why this matters. The hybrid format eliminates that step. The machine-readable layer is already there, embedded and waiting.

The standard emerged from a formal collaboration between FNFE-MCE (Forum National de la Facture Électronique et des Marchés Publics Électroniques) in France and FeRD (Forum elektronische Rechnung Deutschland) in Germany. Both bodies recognized that their respective national formats were solving the same problem and converging on the same technical architecture. Rather than maintain two parallel standards, they aligned them. The result: Factur-X and ZUGFeRD 2.x are technically identical, sharing the same XML schema, the same PDF/A-3 container, and the same profiles. The difference is naming and national context.

This is worth pausing on, because it has real consequences for vendors building cross-border invoicing workflows. A file generated as ZUGFeRD 2.x in Hamburg is a valid Factur-X file in Lyon. You do not need two systems, two pipelines, or two compliance reviews. The same bilingual document speaks both dialects natively.

Both names conform to the EN 16931 European e-invoicing standard, the semantic data model mandated by CEN, which is what guarantees a file written in Lyon is read correctly by a system in Hamburg or Brussels. What EN 16931 actually defines, its business terms and conformance rules, is covered in detail in that dedicated article; here it is enough to know the hybrid format is built to match it.

The bilingual document holds up well when you look under the hood. There are two distinct layers, one for humans and one for machines, and each has a specific technical job.

The human-readable layer: PDF/A-3

PDF/A-3 is an ISO-standardized archival format designed for long-term preservation. Unlike a regular PDF, PDF/A-3 forbids external dependencies: no live hyperlinks, no dynamic content, no fonts that might vanish in ten years. It is self-contained by design. The critical feature is its support for embedded file attachments, which is precisely what the standard exploits. The XML invoice is not bolted on loosely. It lives inside the PDF as a named attachment, referenced through the document's /AF (Associated Files) relationship, and the spec fixes the filename so any conformant reader knows exactly where to find it. That makes the two components inseparable and legally co-dependent.

The machine-readable layer: CII XML

The XML follows the Cross-Industry Invoice (CII) schema developed by UN/CEFACT, a United Nations body for international trade-facilitation standards. EN 16931 permits two syntaxes for the same semantic data: CII and UBL. Factur-X uses CII only, never UBL, a detail that trips up teams who assume any EN 16931 XML will slot in. Choosing CII gives the data layer a globally recognized structure, not merely a European one.

A second rule is easy to miss and expensive to get wrong: the visual PDF is the legally faithful representation of the invoice and must agree with the XML term for term. The picture a human reads and the data a machine parses cannot disagree. If the displayed total and the XML total diverge, the file is non-compliant, full stop.

Together these layers form the bilingual document. Remove either one and you are left with a plain PDF (human-readable, machine-opaque) or a raw XML file (machine-readable, human-unfriendly). The standard keeps both, inseparably bound inside one file.

The five compliance profiles

Factur-X defines five profiles, each a different level of data completeness, like editions of the same document ranging from a pocket phrasebook to a full legal dictionary:

For most businesses, EN 16931 (Comfort) is the right pick. It carries complete invoice data, full cross-border interoperability, and direct compliance with national mandates, without the overhead of Extended.

For SMEs that lack EDI infrastructure, the hybrid format is especially valuable. A company with no EDI capability can generate a Factur-X PDF that its customer's ERP processes automatically, without the sender ever standing up an EDI pipeline. The format effectively closes the EDI gap for the long tail of the B2B market.

For software vendors embedding compliant invoice archiving into their ERP platforms, understanding these profiles is not optional. They determine which fields must be stored, validated, and retained for audit.

Most companies get this wrong. The relationship between the two names confuses a lot of people, so let me be blunt: they are the same standard. Not "compatible." Identical.

When FNFE-MCE and FeRD aligned their formats in 2019, they did not merely agree on interoperability guidelines. They synchronized the underlying technical specification, so a Factur-X EN 16931 (Comfort) file and a ZUGFeRD 2.x EN 16931 (Comfort) file come from the same schema, pass the same validation rules, and run through the same tools. The label on the tin is the only difference.

That matters enormously for cross-border workflows. You do not need separate generation engines, separate validation pipelines, or separate compliance reviews for the French and German markets. One implementation covers both, in Berlin and in Paris alike. If you are still weighing the hybrid container against a pure-XML alternative, the trade-offs are laid out in XRechnung vs ZUGFeRD: choosing your e-invoice format.

The practical upshot: a German company invoicing a French customer, or the reverse, uses a single file that meets both national mandates at the same time. That is not a marketing claim. It is a direct consequence of the 2019 Franco-German alignment and the shared EN 16931 conformance underneath.

France and Germany are the two largest EU economies, and both have enacted e-invoicing mandates that name the hybrid format as a compliant choice. The mechanics differ, and each has its own dedicated guide.

In France, Factur-X is accepted through Chorus Pro for the public sector and, for the upcoming B2B mandate, transmitted via the Portail Public de Facturation (PPF) and the Partner Dematerialization Platform (PDP) model alongside UBL and CII. The rollout timeline, thresholds, and penalty structure are covered in E-Invoicing France 2026: Deadlines, Formats & Penalties.

In Germany, the Wachstumschancengesetz makes ZUGFeRD 2.x, which is Factur-X, an explicitly named compliant format. Businesses must already be able to receive structured e-invoices, and the obligation to issue them phases in by company size over the following years. The full German timeline, the XRechnung/ZUGFeRD choice, and the GoBD angle are laid out in E-Invoicing Germany 2027: XRechnung, ZUGFeRD & GoBD.

The shared signal in both countries is a move from "paper-equivalent" invoicing to data-driven tax reporting. A PDF that merely looks like an invoice is no longer enough. The XML embedded in the file is what tax systems actually consume and what auditors examine, which is exactly why archiving the file intact, both layers, for a decade or more becomes the real challenge.

Generating a valid file is step one. Keeping it legally intact for ten years is the harder problem, and it is mostly owned by other articles in this series.

In short: a Factur-X invoice must be archived as a single unmodified PDF-plus-XML unit, in its original form, for the full retention period. Plain cloud storage cannot prove that. A file in an S3 bucket or a SharePoint folder can be altered by anyone with the right permissions, often with no trace, which is the gap auditors care about. The fix is a tamper-evident seal at the point of archiving: a cryptographic hash of the file anchored to an immutable record makes any later change detectable.

The mechanics behind each of those points live in their own guides. The original-form rule and the rest of Germany's requirements are in GoBD-compliant e-invoice archiving. Why ordinary storage fails the integrity test, and what a cryptographic seal actually proves, is the subject of tamper-proof vs secure storage. The three pillars of a compliant archive, original format, integrity, and audit trail, are unpacked in e-invoice archiving requirements. Retention periods, which vary by jurisdiction, are mapped in E-Invoice Retention Periods by Country.

For ERP and SaaS vendors, the French and German mandates are not only a compliance event for end-customers. They are a product decision.

The short version: you can build a Factur-X generation and archiving layer in-house, or you can embed a purpose-built one via API and white-label it under your own brand. Building it means owning every schema update, profile change, and retention rule as the rules evolve. Embedding it shifts that maintenance, and much of the regulatory risk, to a specialist, while you keep the customer relationship and the revenue. The full economics, the in-house total cost of ownership, and a decision matrix are in Build vs Buy: compliant e-invoice archiving, and the branding, multi-tenancy, and liability mechanics of reselling it are in white-label e-invoice archiving for software vendors.

Adopting the hybrid format is not simply a matter of generating a new file type. It means validating data quality, picking the right profile, and securing the document lifecycle from creation to long-term retention. Here is a practical checklist.

1. Map ERP data to the CII XML schema

Every field in the EN 16931 semantic model must source from a specific data point in your ERP. Tax codes, payment terms, line-item descriptions, and buyer/seller identifiers all have defined positions in the CII schema. Gaps in your ERP data model produce invalid files, and invalid files mean non-compliant invoices.

2. Validate PDF and XML synchronization

The visual PDF and the embedded XML must carry identical data. A mismatch, even a rounding difference in a line-item total, makes the document non-compliant. Build automated validation into the generation pipeline rather than checking by hand after the fact.

3. Choose your profile deliberately

The EN 16931 (Comfort) profile covers the majority of B2B use cases and satisfies both French and German mandates. Move to Extended only if your industry has specific data needs that Comfort cannot meet. Picking the wrong profile is a common cause of downstream validation failures.

4. Decide whether to build or embed

A custom generation-and-archiving engine needs ongoing maintenance as the standards shift; embedding via API offloads that to a specialist. Work through the trade-off in Build vs Buy: compliant e-invoice archiving.

5. Plan for ViDA

Design for the transaction-level reporting that the EU's VAT in the Digital Age reform will introduce across member states, explained in What is ViDA?. The hybrid format's structured XML layer is well-positioned for it, provided your archiving infrastructure can surface that data on demand.

6. Secure the document lifecycle

Give every file a tamper-evident seal at the point of archiving. Immutable blockchain timestamps provide cryptographic proof of existence and integrity; the underlying mechanism is detailed in the tamper-proof guide linked above.

Vendors operating across several EU markets will also want to understand how the hybrid format moves over the Peppol network. See What Is Peppol? A Deep Dive into the Global E-Invoicing Network for how these standards interact.

Factur-X solves the generation problem elegantly: a single hybrid file, two readable layers, one European standard, valid in Paris and Berlin without modification. It is a well-designed answer to a genuinely complex interoperability challenge.

But the format is only the start of the compliance story. The harder work is what happens after the invoice is sent: how it is received, validated, stored, and proven unaltered a decade later when an auditor asks for it. That is where most implementations fall short, not because the technology is missing, but because archiving gets treated as an afterthought rather than a core requirement.

Vendors who get this right, who embed audit-grade archiving into their platforms before the deadlines force the issue, will be in a materially stronger position than those who retrofit it later.

If you are building or upgrading an invoice workflow for the French or German market, explore how OriginVault's white-label e-invoicing archiving layer gives your platform GoBD-compliant, blockchain-sealed document retention, under your brand, through a single API integration.