# 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 ## 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. 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 For What a validator should actually check, review these points before moving on. - 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 For Recommended validation workflow, this sequence gives the practical order of work. - 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 For Common failures and what they usually mean, review these points before moving on. - 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 For Official and primary references, review these points before moving on. - [FeRD package page for ZUGFeRD 2.5 / Factur-X 1.09](https://www.ferd-net.de/publikationen-produkte/publikationen/detailseite/zugferd-25-english). - [KoSIT validator configuration for EN 16931 and XRechnung rules](https://github.com/itplr-kosit/validator-configuration-xrechnung). - [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 existing invoices, inspect extracted data, and validate the result before delivery. That reduces rejection risk while keeping human review in the loop. [Open the ZUGFeRD validator](/en/zugferd-validator) ## 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)