Standards 10 min read 22 October 2026

Validating ZUGFeRD and Factur-X e-Invoices in PDF: Tools and Common Errors

ZUGFeRD and Factur-X embed structured XML inside a PDF/A-3 file to create a hybrid e-invoice readable by humans and parseable by machines. This guide covers the EN 16931 validation rules, the Mustang Project validator, common errors in the XML payload, and how to fix them before submission.

ZUGFeRD and Factur-X are hybrid e-invoice formats: a human-readable PDF/A-3 combined with a machine-readable XML payload embedded as an attached file. The PDF is compliant with ISO 19005-3 (PDF/A-3); the XML follows the EN 16931 European e-invoicing standard and is attached via the /AF (associated files) mechanism introduced in PDF 2.0 and backported to PDF/A-3. The combination means accounts payable software can extract and process the XML automatically, while the PDF is readable by any human recipient. But this dual-format design also means there are two ways for the invoice to be wrong: PDF/A-3 conformance failures, and EN 16931 XML schema/semantic validation failures. This guide covers both validation dimensions, the tools available, and the most common errors encountered in practice.

ZUGFeRD, Factur-X, and XRechnung: the standards landscape

ZUGFeRD — Developed by the Forum Elektronische Rechnung Deutschland (FeRD), ZUGFeRD is the German implementation of hybrid e-invoicing. Version 2.0 and later align with the European standard EN 16931. ZUGFeRD supports multiple profiles with increasing data completeness: MINIMUM (only legally required fields), BASIC WL (without line items), BASIC, EN 16931 (the core standard profile), EXTENDED (additional fields for complex commercial use cases), and XRECHNUNG. Factur-X — The French equivalent, jointly developed by FNFE-MPE and FeRD. Factur-X 1.0 and ZUGFeRD 2.1 are fully aligned: the XML format is identical; only the embedded file name differs (ZUGFeRD uses zugferd-invoice.xml; Factur-X uses factur-x.xml). Most validators treat them equivalently. XRechnung — The German government's mandatory B2G (business-to-government) e-invoice format for invoices to federal public authorities. XRechnung can be delivered as a standalone XML file (UBL or UN/CEFACT CII), not necessarily in a PDF. When delivered embedded in a PDF, it follows the ZUGFeRD/Factur-X PDF/A-3 structure but uses the XRECHNUNG profile. EU ViDA mandate — The VAT in the Digital Age (ViDA) initiative will mandate structured e-invoicing for intra-EU B2B transactions from 2028, using EN 16931 as the core standard. This deadline drives adoption of ZUGFeRD/Factur-X across EU member states. See PDF Invoicing and the E-Invoice Mandate for the broader e-invoicing context.

PDF/A-3 conformance validation

The PDF side of a hybrid invoice must conform to PDF/A-3b as a minimum (PDF/A-3a or 3u are also acceptable). PDF/A-3b requires: - All fonts fully embedded - No JavaScript - No encryption - Colour spaces with ICC profiles for any ICC-based colour - XMP metadata present and consistent with the Info dictionary - /AF associated files correctly structured (the XML payload must be an /EmbeddedFile stream with /AFRelationship set to /Data or /Alternative) veraPDF — The reference tool for PDF/A-3 validation. Run verapdf --flavour 3b invoice.pdf to check PDF/A-3b conformance. veraPDF reports failures with rule IDs mapped to the PDF/A specification. Common failures in invoices generated by accounting software: - Missing ToUnicode CMaps — Accounting software may use system fonts without generating ToUnicode mappings. PDF/A-3a and 3u require ToUnicode for all fonts; PDF/A-3b does not. For PDF/A-3b, this is not a blocking error, but it is best practice. - Non-embedded fonts — Particularly common with fonts pulled from system resources at PDF export time. - Incorrect /AFRelationship — The /AFRelationship key in the associated file's file specification dictionary must be a PDF name from the allowed set. - Missing /MarkInfo — For PDF/A-3a, the document must be tagged and /MarkInfo /Marked set to true.

EN 16931 XML validation with Mustang and other tools

The XML payload embedded in the PDF must conform to the Cross Industry Invoice (CII) UN/CEFACT schema at the selected ZUGFeRD/Factur-X profile level. Two validation layers apply: Schema validation — The XML must be valid against the CII XSD schema. Schema errors prevent processing. Business rule validation (Schematron) — EN 16931 defines over 200 business rules in Schematron that go beyond schema validity. Examples: a tax amount must equal base amount × tax rate (within rounding tolerance); a payment due date must be after the invoice date; a seller's country code must be a valid ISO 3166-1 alpha-2 code. These rules are implemented in Schematron XSLT stylesheets published by the OpenPEPPOL and CEN maintenance committees. Mustang Project — Mustang is the primary open-source Java library for ZUGFeRD/Factur-X creation and validation. The Mustang-CLI can validate both the PDF/A-3 conformance (using veraPDF internally) and the EN 16931 XML rules: java -jar Mustang-CLI.jar --action validate --source invoice.pdf FNFE Validation Portal — validation.factur-x.eu provides an online validation portal for Factur-X/ZUGFeRD invoices. Upload the PDF and receive a validation report for both PDF/A-3 and EN 16931 conformance. Common XML errors: - Missing mandatory elements (seller VAT ID, buyer reference) - Wrong date format (must be CCYYMMDD, not YYYY-MM-DD) - Tax category code not from the allowed code list - Line item total does not sum to document total - Currency code not matching for amounts

Frequently asked questions

What is the minimum ZUGFeRD profile required for compliance?

For invoices subject to the German e-invoice law (effective January 2025 for B2B invoices with German-registered parties), the minimum is ZUGFeRD 2.3 profile EN 16931 or XRECHNUNG. The MINIMUM and BASIC WL profiles do not include all fields required by the EN 16931 standard and should not be used for compliance invoices. For B2G invoices to German federal authorities, XRechnung is mandatory. The FeRD profiles are documented at ferd-net.de. For EU cross-border invoices under ViDA (from 2028), EN 16931 profile or EXTENDED is required.

Can I validate a ZUGFeRD invoice without Java?

Yes. Options not requiring Java: (1) The online validation portal at validation.factur-x.eu handles both PDF and XML validation in a browser. (2) Python's factur-x library supports ZUGFeRD 2.x and Factur-X validation with Python-only dependencies. (3) The FeRD online checker at ferd-net.de provides a portal. For production pipelines in non-Java environments, the Python factur-x library is the most convenient option and supports both creation and validation of hybrid invoices.

My accounting software exports ZUGFeRD PDFs — do I need to validate them?

Yes, for any invoices subject to legal e-invoice requirements. Accounting software updates, edge cases in customer data, and version upgrades can introduce regressions in the generated XML. The most common failures in software-generated ZUGFeRD invoices: incorrect handling of credit notes (negative amounts), missing buyer reference for B2G invoices, rounding errors in tax calculations, and profile downgrade (the software generates BASIC when the recipient requires EN 16931). Running invoices through a validator (Mustang CLI or validation.factur-x.eu) on a sample basis catches these issues before recipients reject invoices. Implementing validation in your invoice generation pipeline is the robust long-term solution.

Try it yourself

Everything in this article can be done directly in the free PDFTheGuide editor — no account required.

Edit PDF Protect PDF Open editor