ZUGFeRD validator — check PDF & XML e-invoices free

Most common errors

BH-PDF-01 The PDF contains no embedded invoice XML — a plain PDF is not an e-invoice under the mandates, even if it looks like an invoice.

BH-ZF1-01 ZUGFeRD 1.0 detected: the legacy format is not EN 16931 conformant and does not fulfil the e-invoicing mandate — migrate to ZUGFeRD 2.x.

BH-PROFILE-01 Profile MINIMUM or BASIC WL: a booking aid only, not a full e-invoice. The mandate requires at least the EN 16931 (COMFORT) profile.

BR-CO-16 The amount due doesn't match the totals arithmetic — with ZUGFeRD often because the PDF visual and the XML are generated separately and drift apart.

BR-02 Invoice number missing in the XML — it may be printed in the PDF, but receiving systems only read the embedded XML.

What is ZUGFeRD?

ZUGFeRD is Germany’s hybrid e-invoice format: a PDF/A-3 that reads like a normal invoice for humans while carrying machine-readable XML (UN/CEFACT CII) inside. Since version 2.0, ZUGFeRD is technically identical to the French Factur-X — one invoice, two markets. Legally, only the XML part counts: if the visual and the XML disagree, the XML wins.

Profiles: from MINIMUM to XRECHNUNG

ZUGFeRD tiers its data scope into profiles: MINIMUM and BASIC WL (booking aids, not full e-invoices), BASIC, EN 16931/COMFORT (the standard for the mandate), EXTENDED (more fields, but the recipient must support it) and XRECHNUNG (additionally satisfies the German BR-DE rules). The validator reads the profile identifier and applies exactly the rules that profile demands — a MINIMUM file is not wrongly measured against EN 16931 mandatory fields.

The most common finding: not an e-invoice at all

In practice the most frequent result is not a rule violation inside the XML but a PDF without embedded XML — produced by tools that confuse “PDF invoice” with “e-invoice”. Since the 2025 receiving mandate this surfaces quickly: receiving systems only read the XML. Second most frequent: ZUGFeRD 1.0 from legacy systems, which does not fulfil the mandate.

For software makers

The validator answers “is this file okay?” — the developer API answers it inside your product: validate ZUGFeRD PDFs and parse them into normalized JSON, same engine, messages in three languages, self-hosted if you need it.

Frequently asked questions

What's the difference between ZUGFeRD and Factur-X?

Technically none: ZUGFeRD 2.x (Germany, FeRD) and Factur-X (France, FNFE-MPE) are the same standard — a PDF/A-3 with embedded CII XML. The embedded file is usually called factur-x.xml in both.

Which ZUGFeRD profile satisfies the German e-invoicing mandate?

At least the EN 16931 (formerly COMFORT) profile. MINIMUM and BASIC WL count as booking aids only; EXTENDED is conformant but must be supported by the recipient. The validator detects the profile automatically and applies exactly the rules that profile requires.

My PDF looks like an invoice — why is it rejected?

What counts is the embedded XML, not the visual. A scanned or conventionally generated PDF without an XML attachment is not an e-invoice. The validator reports this as BH-PDF-01.

Is my file uploaded?

No — even the PDF analysis (extracting the XML from the PDF/A-3 container) runs entirely in your browser via WebAssembly.

Validate ZUGFeRD — drop the PDF, see the result