Factur-X

Factur-X is a hybrid electronic invoice format that embeds a structured XML data file inside a standard, human-readable PDF/A-3. It was developed jointly by France and Germany (where the equivalent standard is called ZUGFeRD) to let businesses exchange invoices that machines can parse automatically while humans can still open and read them normally. It is the leading format for France's mandatory e-invoicing rollout.

How it works

A Factur-X file is, at heart, an ordinary PDF. Open it in any PDF reader and you see a normal invoice layout: line items, totals, tax breakdown, supplier details. What makes it different sits underneath: an XML attachment, structured according to the EN 16931 European semantic data model, carrying every invoice field in machine-readable form. Because the PDF is packaged as PDF/A-3, it can legally contain this embedded file without breaking archival compliance.

The XML follows one of several "profiles" (MINIMUM, BASIC, EN 16931, EXTENDED), which determine how much detail is included, from just enough for tax purposes up to full line-item granularity needed for automated data extraction and matching. A receiving system doesn't need OCR or layout analysis to read a Factur-X invoice: it just pulls the XML and gets clean, structured fields directly, with no guesswork about where a number sits on the page.

This dual structure solves a real coordination problem. Suppliers who aren't ready to send pure XML (via a network like Peppol) can still issue something compliant and machine-readable. Buyers get structured data without asking humans to key it in. Software that only understands PDFs still works, and software built for structured invoicing gets what it needs from the same file.

Why it matters for document processing

Factur-X removes the guessing that plagues normal invoice OCR: no misread totals, no ambiguous table columns, no need for fragile key-value extraction heuristics. When the XML is present and well-formed, extraction accuracy approaches 100% for the fields the profile covers, and processing can move toward true straight-through processing rather than review-heavy exception handling.

The catch: not every invoice arriving in your pipeline will have valid, complete XML. Some will have mismatches between the PDF and embedded XML, missing profiles, or malformed attachments. A production pipeline still needs a parsing layer that checks for embedded XML first, falls back to visual extraction when it's absent or broken, and validates the two representations against each other. Document AI systems built for France's e-invoicing mandate need to handle this hybrid reality, not just the ideal case.

Related terms

• https://sygnet.ai/solutions/e-invoicing-france
• https://sygnet.ai/glossary/data-extraction
• https://sygnet.ai/glossary/validation-rules
• https://sygnet.ai/glossary/cross-document-validation
• https://sygnet.ai/blog/pdf-invoices-after-sept-2026-validity-dual-flow-management

FAQ

Is Factur-X the same as ZUGFeRD?

They're closely related. Factur-X is the French name for the joint France-Germany hybrid invoice standard; ZUGFeRD is the German name for essentially the same specification, kept aligned in newer versions. Small differences existed in early releases, but current versions (ZUGFeRD 2.x and Factur-X) are functionally interoperable and share the same underlying XML schema.

Do I still need OCR if invoices are Factur-X?

Not for the XML data itself, but you still need a robust pipeline. Some incoming files will lack valid XML, have corrupted attachments, or come from partners not yet compliant. A resilient system checks for embedded XML first and falls back to OCR or VLM-based extraction when it's missing, rather than assuming every file is fully structured.