Factur-X is a Franco-German e-invoice standard that combines a human-readable PDF with a machine-readable XML attachment in a single PDF/A-3 file. It's the French adaptation of Germany's ZUGFeRD standard — technically identical in structure, aligned at version 1.0 (Factur-X/ZUGFeRD 2.0+).
For France's 2026–2027 mandate, Factur-X is one of three accepted formats (alongside UBL 2.1 and CII). It's particularly popular with French businesses because it maintains a visual PDF that humans can open and read, while embedding the structured data that platforms (PPF/PDP) need for automated processing.
PDF/A-3
Container format
CII
XML standard (UN/CEFACT)
6 Profiles
Minimum to Extended
= ZUGFeRD
Same spec, French branding
What Is Factur-X?
Factur-X is a hybrid invoice format that solves the fundamental tension in e-invoicing: humans need readable documents; machines need structured data. Instead of choosing one or the other, Factur-X embeds both in a single file:
PDF Visual Layer
A standard PDF/A-3 document that looks exactly like a traditional invoice. Your customer can open it in any PDF reader and see the familiar invoice layout with seller/buyer details, line items, totals, and payment information. The PDF/A-3 standard ensures long-term archivability (no external font dependencies, embedded colour profiles, etc.).
XML Data Layer
An embedded XML file (factur-x.xml) conforming to the UN/CEFACT Cross-Industry Invoice (CII) standard. This XML contains all the structured invoice data that platforms, ERPs, and tax authorities need for automated processing. The XML is attached to the PDF as an embedded file stream — invisible to human readers but machine-extractable.
PDF/A-3 Container
PDF/A-3 (ISO 19005-3) is the archival PDF standard that allows file attachments — this is what makes the hybrid possible. Older PDF standards (PDF/A-1, PDF/A-2) don't support embedded files. Your PDF generation library must support PDF/A-3 specifically. Libraries: iText (Java/.NET), PyPDF/reportlab (Python), PDFLib, Apache PDFBox.
Franco-German Standard
Factur-X was jointly developed by the French FNFE-MPE and German FeRD. It's technically identical to ZUGFeRD 2.x — the same CII XML schema, same profiles, same PDF/A-3 container. The only difference is branding. If your system generates ZUGFeRD 2.x invoices, they ARE Factur-X invoices (and vice versa).
Profiles Explained
Factur-X defines 6 profiles with increasing levels of XML data richness. The profile determines which fields are included in the embedded XML:
Factur-X Profile Hierarchy
Invoice number, date, seller/buyer names, total amount, currency. Just enough to identify the invoice. NOT sufficient for France's mandate — use for simple archival scenarios only.
Adds tax breakdown, payment details, and seller/buyer tax IDs (SIRET/TVA). Still no line-item detail. May be accepted by some PDPs but not ideal.
Adds line-item detail: product descriptions, quantities, unit prices. The minimum level recommended for France's mandate.
Full compliance with the European e-invoicing standard EN 16931. This is the recommended profile for France — it matches the PPF's expected data model and supports all mandatory French fields.
Everything in EN 16931 plus additional fields for complex scenarios: delivery details, contract references, advance payments, allowances/charges at document and line level.
German-specific extension for public sector. Not relevant for France but included in the spec for cross-border compatibility.
Recommendation: EN 16931 Profile
For France's mandate, use the EN 16931 (Comfort) profile. It provides full European standard compliance, includes all fields the PPF and PDPs expect, and works seamlessly for cross-border invoicing with other EU countries that accept EN 16931.
Technical Implementation
Generating a Factur-X invoice involves 4 steps:
Generate CII XML
Create the factur-x.xml file conforming to the chosen profile's schema. The XML uses UN/CEFACT CII namespaces (rsm:CrossIndustryInvoice, ram: for data elements). Critical French fields: seller/buyer SIRET (Système d'Identification du Répertoire des Établissements), TVA intracommunautaire (French VAT ID, format FR + 2 check digits + 9-digit SIREN), and the Factur-X profile declaration in the XML header.
Generate PDF Visual
Create the PDF representation of the invoice using your existing PDF generation pipeline. The visual layout is entirely your choice — there are no mandatory visual requirements for Factur-X. However, the PDF must conform to PDF/A-3 (ISO 19005-3). Key PDF/A-3 requirements: all fonts must be embedded, no transparency in older PDF operators, ICC colour profile included, and XMP metadata declaring PDF/A-3 conformance.
Embed XML in PDF/A-3
Attach the factur-x.xml as an embedded file stream to the PDF/A-3 document. The attachment must be declared in the PDF's document catalog with specific relationship type 'Data' and MIME type 'text/xml'. The XMP metadata must include a Factur-X extension schema declaring the conformance level (profile) and version. This is where most implementations fail — incorrect XMP metadata or wrong relationship type causes validation errors.
Validate & Submit
Validate the generated Factur-X file before submission to your PDP or the PPF. Validation checks: PDF/A-3 conformance (use veraPDF — the reference PDF/A validator), CII XML schema validation (XSD), Schematron business rule validation (EN 16931 rules), and Factur-X-specific metadata validation. Only after passing all checks should you submit to the platform.
Validation & Testing
Factur-X validation has multiple layers — all must pass:
PDF/A-3 Conformance (veraPDF)
Use the open-source veraPDF validator to check PDF/A-3 compliance. Common failures: non-embedded fonts (especially when using CJK characters), transparency operators in the visual layer, missing ICC colour profile, and incorrect XMP metadata structures. Run veraPDF on every generated invoice during development.
CII XML Schema Validation (XSD)
Validate factur-x.xml against the official CII XSD schemas published by FNFE-MPE. The schemas are profile-specific — use the EN 16931 schema for the Comfort profile. Schema validation catches structural errors: missing mandatory elements, wrong data types, incorrect namespace prefixes.
EN 16931 Business Rules (Schematron)
Beyond schema conformance, EN 16931 defines ~160 business rules enforced via Schematron. Examples: BR-01 (invoice must have an invoice number), BR-CO-10 (sum of line amounts must equal invoice total), BR-S-08 (standard VAT rate must have a non-zero percent). The official Schematron files are published by CEN TC 434.
Factur-X Metadata Validation
Verify that the PDF's XMP metadata correctly declares the Factur-X conformance level. The XMP must contain: fx:ConformanceLevel (e.g., 'EN 16931'), fx:DocumentType ('INVOICE' or 'CREDITNOTE'), and fx:Version (e.g., '1.0'). Incorrect metadata causes PDP/PPF rejection even if the XML and PDF are individually correct.
ERP Integration
Most businesses won't build Factur-X generation from scratch. Here are the practical ERP integration paths:
ERP-Native Factur-X
Some ERPs have built-in Factur-X/ZUGFeRD generation. SAP S/4HANA (via Document Compliance), Sage (French editions), and Cegid have native support. If your ERP generates Factur-X natively, your primary task is configuring the French-specific fields (SIRET, TVA, etc.) and connecting to your PDP's API for submission.
Middleware Approach (Recommended)
For ERPs without native Factur-X support — or when you need multi-country capability — use middleware like InvoStaq. Your ERP exports invoice data in its native format (IDOC, CSV, API). The middleware handles: CII XML generation at the correct profile, PDF/A-3 creation and embedding, validation, and submission to your PDP/PPF.
Inbound Factur-X Processing
When you receive Factur-X invoices from suppliers, your system must: extract the embedded XML from the PDF/A-3, parse the CII structure, map fields to your ERP's AP format, validate, and post. The PDF visual is useful for human review; the XML drives automated processing. Your middleware or PDP handles extraction.
Dual-Format Strategy
Some businesses issue Factur-X for French trading partners and UBL 2.1 for Belgian/international Peppol partners. A middleware platform can generate both formats from a single ERP data export — eliminating the need to maintain separate generation pipelines for different countries.
Skip the Factur-X Complexity
InvoStaq generates validated Factur-X (EN 16931) from your ERP data automatically — CII XML, PDF/A-3 embedding, Schematron validation, and PDP submission included.