Validate a ZUGFeRD or Factur-X PDF and fix the usual errors
A hybrid invoice can fail in the PDF, in the metadata that ties the PDF to the XML, or in the XML itself. The free validator checks all of it in one go and shows which layer failed. Here is what each layer checks and how to fix what goes wrong.
Updated 19 October 2026
The four layers
| Layer | Checks | Engine |
|---|---|---|
| 1. PDF/A-3 | The PDF conforms to ISO 19005-3 | veraPDF |
| 2. Hybrid metadata | XMP declares the Factur-X/ZUGFeRD data; the attachment is there with the right name and relationship | Mustang |
| 3. XML schema | The XML matches the XSD of its profile | Mustang |
| 4. Business rules | Schematron of the profile, including the EN 16931 rules | Mustang |
curl https://validate.invoir.dev/api/v1/validate \
-H "Authorization: Bearer inv_YOUR_KEY" \
-F [email protected]The JSON report has one entry per layer, in that order, each with its findings (API docs). Files are processed in memory and never stored.
PDF/A-3 errors
- The file is not PDF/A-3 at all
- A normal PDF, or PDF/A-1 or PDF/A-2 (which don't allow arbitrary embedded files). The XMP must declare
pdfaid:part3, and the file must actually conform. Most PDF libraries need an explicit PDF/A-3 mode. - Fonts not embedded
- The most frequent PDF/A error. Every font, including Helvetica or Arial used by default, must be embedded. Use an embedded TrueType/OpenType font in your template.
- No output intent
- PDF/A needs an output intent with an ICC colour profile (usually sRGB) whenever device colours are used.
- Forbidden features
- Encryption, JavaScript, external content references and some transparency settings are not allowed in PDF/A.
Metadata and attachment errors
- No Factur-X extension schema in the XMP
- PDF/A requires custom XMP properties to be described. The Factur-X properties (document type
INVOICE, file name, version, conformance level) need their extension schema block in the metadata. - Conformance level doesn't match the XML
- The XMP says
EN 16931but the XML's guideline ID says BASIC, or the other way round. Write both from the same setting. - Wrong attachment name
- Current versions expect
factur-x.xml(andxrechnung.xmlfor the ZUGFeRD XRECHNUNG profile); ZUGFeRD 2.0 usedzugferd-invoice.xml. The name in the XMP must match the attachment. - Attachment not associated
- PDF/A-3 wants the embedded XML listed as an associated file of the document, with an
AFRelationshipand a MIME type (text/xml).
XML errors
- Schema errors for the profile
- Each profile has its own XSD. An element that is fine in EN 16931 can be forbidden in BASIC or BASIC WL. Declare the profile that matches the data you write.
- CII details
- Dates as
<udt:DateTimeString format="102">20261019</udt:DateTimeString>; elements in the schema's order; thersm,ram,udtandqdtnamespaces of the current CII version. - EN 16931 business rules
- Mostly totals and VAT:
BR-CO-15,BR-CO-13,BR-CO-17,BR-S-08; and identification:BR-S-02(seller VAT ID),BR-CO-26. Fixes are on the EN 16931 page.
What no validator checks
- Whether the PDF and the XML say the same thing. Render both from the same data. In Germany the XML prevails when they differ (BMF FAQ, question 12a).
- Whether the profile is enough. A MINIMUM or BASIC WL file can be perfectly valid and still not count as an e-invoice in Germany (question 7). Use EN 16931.
To look at the XML inside a PDF, use the embedded XML viewer or POST /api/v1/extract. Background on the formats: ZUGFeRD, Factur-X.
Check a file in your browser, or over the API. The free validator runs the official rules (KoSIT, CEN and Peppol Schematron, Mustang, veraPDF) and lists every error with its rule ID. Nothing is stored. The same check is one HTTP call with a free API key: 25 documents a month, no credit card.
Sources
- FeRD: ZUGFeRD 2.5.2; FNFE-MPE: Factur-X.
- veraPDF, the open PDF/A validator; Mustang.
- Bundesministerium der Finanzen: FAQ E-Rechnung, questions 7 and 12a.