Factur-X (called ZUGFeRD in Germany, the same Franco-German standard) solves an old dilemma: humans cannot read XML, and machines cannot reliably read PDFs. So it ships both in one file.
The container: PDF/A-3
The outer layer is a normal-looking PDF in the PDF/A-3 archival profile, which is the variant of PDF designed for long-term storage and, crucially, allowed to carry embedded file attachments. Your customer opens the invoice like any PDF; nothing looks unusual.
The payload: CII XML
Embedded inside the PDF is an XML file in the UN/CEFACT Cross Industry Invoice (CII) syntax. It carries the same invoice as structured data: seller and buyer identities, line items, tax rates and amounts, dates, payment terms and totals, each in a defined field. Accounting software and tax platforms read this layer directly, with no OCR and no manual re-entry.
The rulebook: EN 16931
The XML is not freeform. EN 16931 is the European norm that defines which fields an e-invoice must contain and how they relate: totals must reconcile, tax categories must be coded correctly, references must resolve. A Factur-X file that fails EN 16931 validation is not a compliant e-invoice, no matter how good the PDF looks. Serious systems validate every generated document against the norm before it leaves.
Why hybrids won the merchant market
Pure-XML formats like XRechnung are ideal for government portals and automated pipelines but unreadable for a customer. For commerce, the hybrid wins: one file that satisfies the customer, the accountant, and the tax administration simultaneously. That is why France and Germany standardized on it together, and why one correctly generated document works on both sides of the border.