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

- Date: 2026-04-20
- Reading time: 7 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 combine.

## Article overview

        This article explains ZUGFeRD validators: what to test before you send a hybrid invoice as a practical reference for European e-invoicing. It defines the topic in plain language, places it in the compliance context, and connects the explanation to invoice formats such as XRechnung, ZUGFeRD/Factur-X, UBL, and CII.

Use the article as a starting point before changing a finance or ERP workflow: identify the applicable country rule or standard, decide which structured format is expected, validate the generated XML, and keep a documented exception process for invoices that require manual review.

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.

        ## How to use this guide

        Use the article as a starting point before changing a finance or ERP workflow: identify the applicable country rule or standard, decide which structured format is expected, validate the generated XML, and keep a documented exception process for invoices that require manual review.

## 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.

This is why teams often combine a ZUGFeRD-aware invoice validator with 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.
- Open the document in a viewer that can display the structured invoice content and compare key fields with the 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 overview of ZUGFeRD / Factur-X](https://www.ferd-net.de/en/standards/zugferd/factur-x).
- [FeRD download page for the current ZUGFeRD package](https://www.ferd-net.de/en/download-zugferd).
- [KoSIT support guidance for XRechnung-related validation context](https://xeinkauf.de/xrechnung/supporthinweise/).
- [veraPDF PDF/A validation project](https://verapdf.org/).
## Validate the hybrid invoice before you trust the PDF view

Invoice-Converter.com helps teams generate ZUGFeRD from current invoices, inspect extracted data, and validate the result before delivery. That reduces rejection risk without pretending validation is optional.

[Open the ZUGFeRD validator](/en/zugferd-validator)