Factur-X Format Explained: Technical Guide for the French E-Invoicing Mandate
What is Factur-X? How does it work, what profiles exist, and how does it relate to ZUGFeRD? A clear technical guide for French businesses preparing for the September 2026 mandate.
Factur-X Format Explained: Technical Guide for the French E-Invoicing Mandate
Factur-X is France's national electronic invoice format, and from September 2026, it will be mandatory for B2B transactions for large French businesses — with the mandate extending to all VAT-registered businesses by 2028.
But what exactly is Factur-X? How does it differ from a PDF? What are the profiles? And how does it relate to ZUGFeRD, the German format?
This guide answers all of these questions clearly.
What Is Factur-X?
Factur-X is a hybrid invoice format — a PDF/A-3 file with a structured XML document embedded inside it.
This means:
- Your customer sees a normal, printable PDF invoice — no change from what they're used to
- Their accounting software reads the embedded XML to import invoice data automatically
- The tax authority (DGFiP) can process the structured data for reporting via your PDP
The embedded XML follows the EN 16931 European e-invoice semantic data model — the same standard used by Germany's XRechnung and ZUGFeRD.
Factur-X and ZUGFeRD: Are They the Same?
Yes — technically, Factur-X is identical to ZUGFeRD 2.x.
Both formats are implementations of the EN 16931 standard wrapped in the same PDF/A-3 container. The PDF/A-3 file structure, the XML schema, and the profiles are all the same. The only difference is the name:
| Country | Format name | Technical spec |
|---|---|---|
| France | Factur-X | EN 16931 / PDF-A3 |
| Germany | ZUGFeRD | EN 16931 / PDF-A3 |
| International | Factur-X (ISO 19005-3) | Same spec |
If your accounting software generates ZUGFeRD 2.x EN 16931 profile, it can almost certainly generate Factur-X as well — the configuration difference is minimal (typically just changing the embedded XML filename and namespace parameter).
Factur-X Profiles
Factur-X has six profiles (levels of data completeness). For the French mandate, only the higher profiles qualify:
| Profile | EN name | French name | Mandate compliant? | Use case |
|---|---|---|---|---|
| Minimum | MINIMUM | Minimum | ❌ No | Very basic — missing mandatory fields |
| Basic WL | BASIC WL | Basique WL | ❌ No | Insufficient for mandate |
| Basic | BASIC | Basique | ❌ No | Still insufficient |
| EN 16931 | EN 16931 | Confort | ✅ Yes | Standard B2B invoicing — most common |
| Extended | EXTENDED | Étendu | ✅ Yes | Additional French/EU fields |
| XRechnung | XRECHNUNG | (not used in FR) | ✅ Yes | German-specific, not typical in France |
For the French mandate: always use the EN 16931 (Confort) profile or higher.
The Minimum and Basic profiles are technically valid Factur-X but do not contain all the fields required by the EN 16931 standard — and therefore do not satisfy the French mandate.
The PDF/A-3 Container: How It Works
A standard PDF cannot reliably contain embedded files in a way that accounting software can extract. Factur-X uses PDF/A-3 — the archival version of PDF with embedded file attachment support.
Inside the PDF/A-3 file, there are two elements:
- The visual layer — the human-readable invoice layout (what you see when you open it)
- The embedded XML file — always named
factur-x.xmlfor the EN 16931+ profiles
The XML file is attached using the PDF/A-3 "associated file" mechanism, which means software tools can reliably extract it without having to parse the PDF layout.
What the XML looks like (simplified)
<?xml version="1.0" encoding="UTF-8"?>
<rsm:CrossIndustryInvoice
xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">
<rsm:ExchangedDocumentContext>
<ram:GuidelineSpecifiedDocumentContextParameter>
<ram:ID>urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:en16931</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>
<rsm:ExchangedDocument>
<ram:ID>FA-2026-00042</ram:ID> <!-- Invoice number -->
<ram:TypeCode>380</ram:TypeCode> <!-- 380 = commercial invoice -->
<ram:IssueDateTime>
<udt:DateTimeString format="102">20260415</udt:DateTimeString>
</ram:IssueDateTime>
</rsm:ExchangedDocument>
<!-- Seller, buyer, line items, taxes, payment terms... -->
</rsm:CrossIndustryInvoice>
The profile is identified by the <ram:ID> element — note urn:factur-x.eu:1p0:en16931 for the EN 16931 profile.
Mandatory Fields for Factur-X EN 16931
The EN 16931 profile requires these core fields (a subset of the full standard):
| BT number | Field | Mandatory? |
|---|---|---|
| BT-1 | Invoice number | ✅ |
| BT-2 | Invoice issue date | ✅ |
| BT-9 | Payment due date | ✅ |
| BT-10 | Buyer reference | ✅ (for certain contexts) |
| BT-29 | Seller tax identification (SIRET or TVA intracommunautaire) | ✅ |
| BT-31 | Seller VAT identifier | ✅ |
| BT-48 | Buyer VAT identifier | ✅ (if VAT-registered buyer) |
| BT-81 | Payment means type code | ✅ |
| BT-84 | Payment account IBAN | ✅ (if payment by transfer) |
| BT-112 | Invoice total | ✅ |
| BT-115 | Amount due for payment | ✅ |
Missing any of these will cause validation failure.
Validation: How to Check Your Factur-X
Before going live, validate your Factur-X invoices:
Option 1: Ecosio Validator (free) ecosio.com/en/peppol-and-xml-document-validator/
- Upload your Factur-X PDF
- Select "Factur-X" or "ZUGFeRD" as document type
- Review errors and warnings
Option 2: VeraPDF (open source) For technical users who want to verify the PDF/A-3 container itself (independent of the XML content):
verapdf --flavour 3b facture_test.pdf
Option 3: Your PDP's validation service Once you've signed a PDP contract, most PDPs provide a pre-production validation environment where you can test Factur-X invoices against the DGFiP requirements before going live.
How Factur-X Travels to the Recipient
Under France's September 2026 mandate, Factur-X invoices do not simply get emailed as PDF attachments. They must travel through a certified routing infrastructure:
- Your accounting software generates the Factur-X PDF
- Your PDP (Partenaire de Dématérialisation Privé) receives the file, validates it, and routes it
- The PDP routes the invoice to your customer's PDP
- Your customer's PDP delivers it to their accounting software
- Both PDPs report transaction metadata to DGFiP in real time
If you don't use a certified PDP, you can use the government's free PPF (Portail Public de Facturation) as a fallback — but it does not offer API integration or ERP connectivity.
Factur-X vs. UBL: Which to Use for France?
France's mandate accepts both Factur-X and UBL 2.1 (Universal Business Language). Certified PDPs can handle both.
In practice:
- Factur-X is the dominant format for French domestic B2B (it's the national standard)
- UBL 2.1 is used for Peppol-based cross-border invoicing (e.g., invoicing a Belgian or German Peppol recipient)
Your PDP should be able to receive whichever format your software generates and convert as needed for routing.
Conclusion
Factur-X is a practical, well-designed format that balances human readability with machine processability. If you're a French business preparing for the September 2026 mandate:
- Check that your software generates Factur-X in the EN 16931 (Confort) profile or higher
- Validate your output before the mandate goes live — don't assume your software is correct without testing
- Sign a contract with a certified PDP to handle routing — the format alone is not enough, you also need the routing infrastructure
- If you already use ZUGFeRD (from German business), the technical adaptation to Factur-X is minimal