Skip to content
eDocument Tools

Factur-X — the hybrid PDF invoice

What a Factur-X file actually contains, how the CII XML is attached to the PDF, what the profiles mean, and why 'XML found' and 'PDF/A-3 valid' are two different statements.

One file, two audiences

Factur-X is a hybrid invoice: a PDF a person can read, with a structured UN/CEFACT CII invoice embedded inside it as a file attachment. Open it in any PDF reader and you see an invoice page; open it in accounting software and it can read the XML directly, with no OCR and no manual entry.

That is the whole design idea. Structured invoicing normally forces a choice between a document people can read and data machines can process. Factur-X refuses the choice by shipping both in one file, which is why it was the pragmatic route into e-invoicing for small suppliers who still email PDFs.

In Germany the same specification is published as ZUGFeRD. Since Factur-X 1.0 / ZUGFeRD 2.1 the two are technically aligned — the same file works in both countries.

How the XML is attached

The container is PDF/A-3, the archival PDF profile that permits arbitrary embedded files. The invoice XML is attached with a defined filename — factur-x.xml for current versions, historically ZUGFeRD-invoice.xml — and an AFRelationship of Alternative, which declares that the attachment is an alternative representation of the page content rather than a supplementary document.

The PDF's XMP metadata additionally carries a Factur-X description block naming the document type, the version and the conformance level. So a complete reader has three places to look: the attachment itself, the attachment relationship, and the XMP metadata.

Profiles

Factur-X defines conformance levels, and they differ in how much of the invoice is present in the XML:

  • MINIMUM — little more than the seller, buyer, totals and a document reference. Intended for expense-report style capture. Not an EN 16931 compliant invoice on its own.
  • BASIC WL — "without lines". Header, parties, VAT breakdown and totals, but no invoice lines. Also not EN 16931 compliant.
  • BASIC — adds invoice lines. The first level that is a complete structured invoice and EN 16931 compliant.
  • EN 16931 (historically COMFORT) — the full EN 16931 core model.
  • EXTENDED — goes beyond the core model, for cases the European standard does not cover.

The profile is declared inside the XML, in ram:GuidelineSpecifiedDocumentContextParameter/ram:ID, as a URN such as urn:factur-x.eu:1p0:basic. The CII viewer reads and labels that identifier when you open extracted Factur-X XML.

Two consequences worth planning for: a MINIMUM or BASIC WL file is a valid Factur-X file that is not a complete structured invoice, so a receiving system must handle the absence of lines rather than treating it as an error; and the declared profile is a claim, so a document can name EN 16931 and still fail its rules.

"XML detected" is not "PDF/A-3 valid"

These are two separate questions, and conflating them is the most common overstatement in Factur-X tooling.

  • Factur-X XML detected means: this file is a PDF, it has an embedded file that looks like a Factur-X attachment, and that attachment parses as a Cross Industry Invoice. This is what a browser-based tool can honestly determine.
  • PDF/A-3 conformance validated means: the whole PDF satisfies ISO 19005-3 — embedded colour profiles, embedded fonts, XMP metadata conformance, the attachment relationship, transparency restrictions and the rest. Establishing this requires a conformant PDF/A validator such as veraPDF. It is a substantial piece of software and it is not something to approximate.

The Factur-X viewer reports the first and says plainly that it has not checked the second. The Factur-X validator goes further and runs the invoice rules, and it makes the same distinction on every result.

Reading a Factur-X file yourself

A PDF attachment is stored as an embedded file stream, usually deflate-compressed, referenced from the document catalogue's /Names /EmbeddedFiles tree and from the page's /AF array. Extract that stream, decompress it, and you have the CII XML — which you can then open in the CII viewer as an ordinary document.

Related reading

For the syntax inside the attachment see UN/CEFACT Cross Industry Invoice; for the semantic model it implements see EN 16931; for the regulatory context see French e-invoicing.

Frequently asked questions

Is Factur-X the same as ZUGFeRD?

They are the same specification published under two names: Factur-X in France by FNFE-MPE and ZUGFeRD in Germany by FeRD. From version 2.1 / 1.0 onwards the two are technically aligned, which is why a single file works in both countries.

What are the Factur-X profiles?

They are conformance levels, from least to most complete: MINIMUM, BASIC WL (without lines), BASIC, EN 16931 (also called COMFORT) and EXTENDED. MINIMUM and BASIC WL carry too little to be a complete structured invoice on their own and are not EN 16931 compliant; BASIC and above are. The profile is declared in the guideline identifier inside the XML.

Can I check PDF/A-3 conformance here?

No, and it is important not to confuse the two questions. Finding and reading the embedded XML tells you the invoice data is there. Confirming that the file is a valid PDF/A-3 document — colour spaces, fonts, XMP metadata, the attachment relationship — is a separate check requiring a conformant PDF/A validator such as veraPDF. Any tool claiming both from one pass is overstating what it did.

Which comes first if the PDF and the XML disagree?

The XML is the invoice for processing purposes; the PDF is the human-readable rendering. A file whose two halves disagree is defective, which is one of the practical reasons to extract and inspect the XML rather than trusting the page.

Related