"We Already Send Invoices as PDF, So We're Fine"
This is the most expensive sentence in e-invoicing right now, and I've heard it four times this month.
A PDF of an invoice is a picture of an invoice. It has text positioned at coordinates on a page. Nothing in the file says which of those pieces of text is the buyer's VAT number, which is the due date and which is the total including VAT. A human infers all of that from layout and habit.
An electronic invoice, in the sense the mandates mean, is structured data. Under the European standard EN 16931 every field has a defined name and place. The buyer's VAT identifier isn't "somewhere near the top right", it's BT-48. The invoice total with VAT is BT-112. Software reads it without guessing, and without OCR.
Those are different things, and only one of them satisfies the mandate.
Factur-X Is the Compromise, and It's a Good One
The obvious way to build electronic invoicing is to drop PDFs entirely and send pure XML. That's what XRechnung does in Germany, and it's clean for the machines. It's also unreadable for the accounts payable clerk who has to look at it, and it throws away thirty years of everyone knowing what an invoice looks like.
Factur-X takes the other route: keep the PDF, and put the structured data inside the file.
The result is one document with two audiences. Your customer's finance team opens it and sees the invoice they expect. Their accounting software opens the same file, finds the embedded XML and reads the fields directly. No OCR, no template matching, no fragile parsing of a layout that changes when you redesign your letterhead.
ZUGFeRD is the same thing under a German name. Since version 2.1 the specifications are aligned, so a Factur-X file and a ZUGFeRD file are the same artefact. If a supplier says they send ZUGFeRD and your system expects Factur-X, you are already compatible.
What a Factur-X File Is Made Of
Three things have to be true at once. Most files that fail are failing exactly one of them.
1. The container is PDF/A-3. Not any PDF. PDF/A-3 is an ISO archival format whose distinguishing feature is that it permits arbitrary embedded files, which is the hook Factur-X hangs the XML on. Exporting a normal PDF from your usual design tool does not produce one, and the difference is invisible to the eye.
A detail worth knowing because people get told otherwise: PDF/A-3a, 3b and 3u are all conformant Factur-X. 3a adds tagging for accessibility, 3u guarantees Unicode mapping for text extraction, 3b is the baseline. If a vendor tells you that you specifically need 3u, ask why.
2. The embedded XML validates against EN 16931. The standard publishes its rules as Schematron, which is machine readable, so this is a definite question with a definite answer. "There is XML in the file" is not the same claim.
The XML itself comes in two syntaxes. Factur-X uses CII (Cross Industry Invoice, a UN/CEFACT format). PEPPOL and a lot of public sector invoicing use UBL. Both express EN 16931, and both are legitimate.
3. The attachment is declared correctly. The embedded file needs the right filename, the right MIME type, and an /AFRelationship value describing how it relates to the document. That value is profile conditional: Data for the two smallest profiles, Alternative for the richer ones. France and Germany have historically read this differently, so a mismatch here is worth a warning rather than a rejection.
Profiles: How Much Detail the XML Carries
Factur-X defines several profiles, and they differ by how much of the invoice makes it into the structured data.
- MINIMUM carries almost nothing: the parties, the totals. Not enough to be a legal invoice on its own in most cases.
- BASIC WL adds document level detail but still no line items.
- BASIC adds line items.
- EN 16931 is the full European standard, and the one the mandates are written around.
- EXTENDED adds more again, for cases the standard doesn't cover.
The profile is declared inside the XML at BT-24, and it should agree with the metadata stamped on the PDF. It's entirely possible to build a file whose XML is full EN 16931 while its PDF metadata claims MINIMUM. The file opens, and it disagrees with itself.
That's not hypothetical, and it's why our own generator reads the profile back off BT-24 after building the XML rather than trusting what the request asked for. A caller can choose what to target. Nobody, including us, gets to declare what the result is.
The Half No Validator Checks
Everything above is checkable by software. This last requirement is not, and it's the one that gets companies in trouble.
The page has to show what the XML says. Factur-X requires the human readable presentation to reflect the structured data. Same totals, same dates, same parties, same currency.
A file where the PDF says one total and the XML says another will pass every validator you point at it. Each half is internally valid. It is also, in an audit, an invoice that says two different things.
This is easy to produce by accident: generate the XML from your accounting system, generate the PDF from your design tool, and let them drift apart by one change to a discount rule. It's why our invoice templates lock the blocks that carry the invoice data, and why the generator refuses to render a template that doesn't declare a placeholder for each required business term. The layout can be yours. The numbers on it have to come from the same place the XML does.
How to Tell Which of the Three You're Failing
If your software vendor has told you you're compliant, that claim is checkable in about thirty seconds.
Our free Factur-X validator runs the EN 16931 rules in your browser, using the official CEN Schematron. Your invoice is not uploaded, which matters more than it sounds: an invoice carries your customer list, your pricing and your payment terms, and every other validator I could find wants you to post that to their server.
It'll tell you the profile the file declares, whether the embedded XML validates, and how the attachment is put together. The ISO PDF/A-3 conformance check and the XRechnung and PEPPOL rule sets genuinely need a server, so those are a separate opt in that says so.
Findings come with plain language fixes rather than rule identifiers, for all 223 rules rather than the popular ones.
And if you need to produce these rather than check them, generating a compliant Factur-X invoice is one API call on the Business plan, with the XML validated against the same Schematron before the PDF is assembled.