A hybrid invoice can fail in the PDF part, in the XML part, or in the link between them: the XML is attached the wrong way, the metadata announces another profile than the XML contains, a total does not add up. This tool looks at all three and tells you which one is the problem.
It reports a technical validation result from a documented subset of checks, listed below. It does not say that an invoice is legally compliant or certified, and it is not the official FeRD / FNFE-MPE validation (XSD and Schematron), which is why it is called technical checks.
Loading the tool…
Overview
About Factur-X / ZUGFeRD Validator (Technical Checks)
What is checked. Three layers. First the PDF: does the XMP metadata declare PDF/A and is it part 3, the part that allows attachments; are there common structural problems such as fonts that are not embedded. Second the attachment and metadata: is there an embedded XML with a relationship (AFRelationship), a MIME type of text/xml, an entry in the associated-files list, a file name of factur-x.xml (or xrechnung.xml), and does the Factur-X block in the XMP metadata name the same profile and file as the XML does. Third the invoice itself, from the Cross Industry Invoice XML: these EN 16931 business rules are implemented: BR-02 to BR-09 and BR-11 (mandatory fields such as number, date, type code, currency, seller, buyer and countries), BR-13 to BR-16 (document totals present, at least one line where the profile requires it), BR-CO-10, BR-CO-13, BR-CO-14, BR-CO-15 and BR-CO-16 (the arithmetic between line sums, VAT breakdown, totals, prepaid amount and amount due), and for the XRechnung profile BR-DE-1, BR-DE-2 and BR-DE-15.
What "profile" does here. The five profiles carry different amounts of data. MINIMUM and BASIC WL have no invoice lines, so the tool does not ask for any; BASIC, EN 16931 and EXTENDED must have lines. The profile is read from the guideline identifier inside the XML and compared with the one in the PDF metadata.
What is not checked. The official validation artefacts for ZUGFeRD / Factur-X (XSD schemas and Schematron rules per profile, the latter delivered as XSLT) are published by FeRD and FNFE-MPE, and the Schematron rules need an XSLT processor that browsers do not provide natively. This site does not run them, so you do not get the official result here. Also not checked: the remaining EN 16931 business rules (for example VAT category and exemption consistency, code-list values, date and identifier formats beyond presence), country-specific rules, a full ISO 19005 PDF/A validation, and tax correctness. For a conclusive technical validation, run the official FeRD / FNFE-MPE artefacts or a validator that includes them, and ask the recipient or platform which checks they apply. Treat this tool as a fast first look that catches common faults.
Wording on purpose. The tool never says "valid" or "compliant". The headline is always "technical validation result", with the number of errors and warnings, and each item shows the rule or check behind it. Passing these checks does not make an invoice legally compliant, and it is no certification.
Compatibility
Supported Formats
PDF files up to 50 MB containing Cross Industry Invoice XML (Factur-X / ZUGFeRD profiles MINIMUM, BASIC WL, BASIC, EN 16931 and EXTENDED, or XRechnung CII); the checks are not tied to one ZUGFeRD or Factur-X release number. A stand-alone XML file is not checked here; use the XRechnung Viewer for that.
Guide
How to Use Factur-X / ZUGFeRD Validator (Technical Checks)
- Drag in the hybrid invoice PDF. It is read in your browser.
- Read the headline result, then each group: PDF/A and file structure, attachment and metadata, invoice content.
- Fix errors in the system that produced the invoice (the PDF generator or the e-invoicing component), then check again.
- For a conclusive result, run the official FeRD or FNFE-MPE validation as well.
Highlights
Features
- Checks the link, not just the parts Compares the attachment, the PDF metadata and the XML profile with each other.
- Rule identifiers shown Each finding names the check or EN 16931 rule behind it, so you can look it up.
- Profile-aware Does not demand invoice lines from MINIMUM and BASIC WL, and does demand them from the richer profiles.
- Clear about its limits States what was and was not checked, and never claims legal compliance.
Applications
Use Cases
- Checking an invoice before you send it to a customer who validates strictly
- Finding out why a received invoice was rejected by an import or an e-invoicing platform
- Testing the output of a new invoicing template or library
- Confirming that the XMP profile and the XML profile agree after a conversion
- Catching a total that does not add up before it reaches the ledger
Good to Know
Limitations
The checks are a documented subset: container checks, required fields, and amount arithmetic. They are not the official XSD and Schematron validation. They do not cover every PDF/A rule, every EN 16931 business rule, VAT category consistency, code-list values, or national rules. Further validation with the official FeRD / FNFE-MPE artefacts may be required by your recipient or platform.
A clean result is not a statement that the invoice is legally compliant or will be accepted by a recipient, a platform or a tax authority. An error is not proof that an official validator would reject the file, though the listed rule is a good place to start looking.
This tool runs entirely in your browser — your file is never uploaded to our servers. See our Privacy Policy for full details.
Support
Frequently Asked Questions
Is this the official ZUGFeRD / Factur-X validation?
No. The official validation artefacts are published by FeRD and FNFE-MPE (XSD and Schematron per profile) and need an XSLT processor to run. This tool is not wired to them; it runs a documented subset of checks in the browser and says so in every result.
Why will it never tell me my invoice is "valid" or "compliant"?
Because a browser tool cannot know the legal context: which countries are involved, which rules apply, what the recipient accepts. It reports what it checked and what it found: a technical validation result.
What does "PDF/A-3 declared" mean?
The XMP metadata of the PDF contains a pdfaid entry with part 3. It is what the file claims about itself. Proving conformance needs a full PDF/A validator.
What are the BR-CO rules in the results?
Rule identifiers from EN 16931, the European standard behind these formats. For example BR-CO-15 says the total with VAT must equal the total without VAT plus the VAT total.
The XMP says one profile and the XML another. Which is right?
The XML is what software reads. A mismatch usually means the PDF was produced by one component and the XML replaced or generated by another. Make the metadata match the XML, or regenerate both from the same source.
Does the PDF leave my browser?
No. All checks run locally. The file is not uploaded and nothing from it is sent to analytics.
Keep Going
Related Tools
- ZUGFeRD / Factur-X XML Extractor Pull the invoice XML out of a ZUGFeRD or Factur-X PDF, see which profile it declares, and download it. The PDF is read in your browser.
- XRechnung Viewer Open an XRechnung (or ZUGFeRD / Factur-X) invoice and read it as a clear table of parties, lines, VAT, totals and payment data. Runs in your browser.
- E-Invoice Format Detector Find out what an XML or PDF e-invoice file is: ZUGFeRD, Factur-X, XRechnung, KSeF FA(3), Peppol BIS or plain UBL, from fixed signals you can see.
- PDF Attachments Extractor List every file embedded in a PDF, see what each one really is, and download one or all of them. The PDF stays in your browser.
- PDF/A Checker & Converter Check which PDF/A level a PDF declares and spot common problems in your browser. Convert to PDF/A-1b, -2b or -3b on the server if you need to.