# ZUGFeRD validators: what to test before you send a hybrid invoice

- Date: 2026-04-20
- Modified: 2026-10-04
- Reviewed: August 15, 2026
- Reading time: 3 min read

A practical 2026 guide to validating ZUGFeRD and Factur-X invoices: XML rules, PDF/A-3 checks, profile fit, common failures, and which validator types to

> Reviewed against FNFE-MPE Factur-X resources, UN/CEFACT XML schemas.

This guide is for teams generating ZUGFeRD or Factur-X and wondering whether “the PDF opens” means the invoice is ready to send.

It does not. A usable hybrid invoice needs more than a readable PDF: the embedded XML must match the intended profile, mandatory data must be present, totals must reconcile, and the PDF container itself should meet the archival expectations of the format.

## What a validator should actually check

- The embedded XML is present and can be read correctly from the PDF container.
- The invoice data complies with EN 16931 and the selected ZUGFeRD or Factur-X profile.
- Monetary totals, VAT breakdowns, units, and dates are internally consistent.
- The PDF file itself meets the expected PDF/A-3 constraints for a hybrid invoice workflow.
## Use more than one kind of validation

A strong workflow usually combines at least two layers. First, validate the business content and XML rules. Second, check the PDF/A-3 container and embedded-file packaging. If a recipient channel applies its own checks, treat that as a third gate rather than your only test.

A practical combination is a ZUGFeRD-aware invoice validator for the XML and business rules, plus a PDF/A validator such as [veraPDF](https://verapdf.org/) for the document container.

## Recommended validation workflow

- Generate the ZUGFeRD or Factur-X invoice from source data you have already reviewed.
- Run a rule-based invoice validation against the target profile and EN 16931 expectations.
- Run a PDF/A-3 check on the final document, not on a draft PDF without embedded XML.
- Extract or inspect the embedded XML and compare key fields with the reviewed source invoice.
- Only then send the document through email, portal, or Peppol depending on the recipient process.
## Common failures and what they usually mean

- The PDF opens normally, but the XML is missing, malformed, or not attached as expected.
- The XML is valid enough to parse, but required business fields or profile identifiers are wrong.
- Line totals, taxable bases, and VAT amounts do not reconcile after extraction or mapping.
- The document looks right to a human reviewer but fails PDF/A-3 checks because the hybrid container is incomplete or non-compliant.
## Official and primary references

- [FeRD package page for ZUGFeRD 2.5.2 / Factur-X 1.09.2](https://www.ferd-net.de/publikationen-produkte/publikationen/detailseite/zugferd-252-english).
- [KoSIT validator configuration for EN 16931 and XRechnung rules](https://github.com/itplr-kosit/validator-configuration-xrechnung).
- [KoSIT XRechnung FAQ for validation context](https://xeinkauf.de/xrechnung/faq/).
- [veraPDF PDF/A validation project](https://verapdf.org/).

> **How a hybrid invoice is validated**
>
> A ZUGFeRD or Factur-X invoice has one more stage: first the PDF/A-3 container and the embedded XML are checked, for example with veraPDF. The embedded XML then passes the CII schema, the EN 16931 business rules and the profile rules such as BR-FX, plus the BR-DE rules with the XRECHNUNG profile. The report lists every failed rule: one error means reject, warnings alone still mean accept.

## FAQ

### Is opening the PDF enough to prove ZUGFeRD compliance?

No. A readable PDF only proves that the visual layer can be rendered. It does not prove that embedded XML is present, valid, or aligned with the intended profile.

### Why use both an invoice validator and a PDF/A validator?

They test different layers. One focuses on invoice semantics and rules, while the other checks PDF/A conformance and the document container.

### Can validation remove the need for human review?

No. Validation is essential, but teams still need human review for source-quality issues, profile selection mistakes, and business-context errors that automated checks may not fully interpret.

## Official references

- [FNFE-MPE Factur-X resources](https://fnfe-mpe.org/factur-x/)
- [UN/CEFACT XML schemas](https://unece.org/trade/uncefact/xml-schemas)