Inspect a PDF invoice
Drop a PDF in. The inspector looks for embedded invoice XML in both places producers put it
(the /EmbeddedFiles catalog and page-level file-attachment annotations), reports the declared
Factur-X/ZUGFeRD profile and the PDF/A-3 AFRelationship, and — where the profile is a full
EN 16931 invoice — runs the official validation ruleset over the XML. Nothing is stored: your file is
processed in memory and discarded.
What the profiles mean
A Factur-X (France) / ZUGFeRD (Germany) invoice is one PDF/A-3 file carrying both the human-readable page and a machine-readable XML invoice. The declared profile decides how much the XML contains — and whether it can be judged against EN 16931 at all.
| Profile | What it is | EN 16931 validation |
|---|---|---|
| MINIMUM | Document-level data only — seller, totals, VAT amount. No invoice lines. A bookkeeping aid; not accepted as an e-invoice under German law since 2025. | Not applicable — by design, not a full EN 16931 invoice. Running the ruleset would report expected failures. |
| BASIC WL | “Without lines” — document-level data, no line items. Same legal caveat in Germany as MINIMUM. | Not applicable, same reason. |
| BASIC | A proper EN 16931 invoice restricted to simple cases (lines included). | Yes — validated here. |
| EN 16931 (COMFORT) | The full EN 16931 semantic model. | Yes — validated here. |
| EXTENDED | A conformant extension — fields beyond EN 16931 for complex invoicing. | Validated, with a caveat: findings on extension fields can be expected; core BR-* failures still matter. |
| XRECHNUNG | XRechnung carried in a ZUGFeRD/Factur-X container. | Yes — EN 16931 plus the German BR-DE layer. |
| ZUGFeRD 1.0 | Legacy format predating EN 16931 (different XML root and namespaces). | Not applicable — the ruleset does not exist for it. Re-issue as ZUGFeRD 2.x / Factur-X. |
What “AFRelationship” tells you
PDF/A-3 requires each embedded file to declare how it relates to the page content.
Factur-X uses Alternative for full-invoice profiles (the XML is an equivalent rendering of the
invoice) and Data or Source for MINIMUM/BASIC WL (the XML merely supports the PDF).
A missing or wrong value is a spec violation some receiving platforms reject on.
No XML inside your PDF?
Then it is an ordinary PDF, and no inspector can conjure the data out of it. The CSV converter builds a valid XRechnung, Peppol or UBL e-invoice from a spreadsheet export instead — and validates every one before you download it. Already have standalone XML? Validate it free.