How to Validate a ZUGFeRD PDF: PDF/A-3, XML and Profile Checks

To validate a ZUGFeRD PDF you check two things: the PDF must conform to PDF/A-3, and the embedded XML must match the CII schema and the business rules of its profile. veraPDF handles the PDF/A check, and the Mustang validator covers both parts in one run. For the XRECHNUNG profile, the KoSIT rules apply as well.

Last reviewed: September 2026. This article is general information, not tax advice.

Why isn't looking at the PDF enough?

According to the German Finance Ministry (BMF) letter of 15 October 2025 (opens in a new tab), the structured part of a hybrid invoice is the leading part. If PDF and XML differ, the XML prevails, and input VAT can only be deducted on the basis of the XML. A PDF can look perfect while the XML is missing, declares the wrong profile or contains calculation errors. Under paragraph 6a of the letter, a file with format errors is not an e-invoice but an "other invoice" (sonstige Rechnung).

That is why validation works through the file layer by layer. For background on the format and its profiles, see What is ZUGFeRD?.

What are the layers of a ZUGFeRD check?

Layers 1 to 4 can be automated. Layers 5 and 6 need a human eye, at least on a sample basis.

Step 1: Check PDF/A-3 conformance with veraPDF

veraPDF (opens in a new tab) is an open-source validator covering all PDF/A parts and conformance levels. It is available as a desktop application and for the command line:

verapdf --flavour 3b invoice.pdf

--flavour 3b sets the check to PDF/A-3b. Level b is sufficient for ZUGFeRD; files in PDF/A-3a or PDF/A-3u are also PDF/A-3.

Typical findings and their causes:

• Font not embedded: the invoicing software uses standard fonts without including them in the file.
• OutputIntent missing: there is no ICC colour profile, which PDF/A requires.
• Wrong PDF/A identification: the XMP metadata lacks pdfaid:part with the value 3.
• Embedded file without MIME type or AFRelationship: PDF/A-3 requires both for every embedded file.

veraPDF says nothing about the invoice data. A PDF can be fully PDF/A-3 conformant and still contain no XML at all.

Step 2: Check the embedded XML, AFRelationship and XMP

First, the right file has to be inside the PDF. Its name depends on version and profile:

• factur-x.xml: ZUGFeRD 2.1 and later, profiles MINIMUM to EXTENDED
• xrechnung.xml: XRECHNUNG profile
• zugferd-invoice.xml: ZUGFeRD 2.0

Our tool to extract XML from PDF invoices shows at a glance which attachments the PDF contains and what the invoice XML is called. The file is processed in your browser only.

The XML must also be linked in the /AF array of the PDF catalogue with an AFRelationship value, usually Alternative. Without that link the XML is just an arbitrary attachment, and many programs ignore it.

In the XMP metadata, the file declares its profile and the XML file name. This is the block for the EN 16931 profile:

<rdf:Description rdf:about=""
    xmlns:fx="urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#">
  <fx:DocumentType>INVOICE</fx:DocumentType>
  <fx:DocumentFileName>factur-x.xml</fx:DocumentFileName>
  <fx:Version>1.0</fx:Version>
  <fx:ConformanceLevel>EN 16931</fx:ConformanceLevel>
</rdf:Description>

Because fx is not a predefined namespace, the PDF must also contain a PDF/A extension schema describing these properties. If it is missing, veraPDF already reports an error.

The declared profile must match the profile stated in the XML, in BT-24 at rsm:ExchangedDocumentContext/ram:GuidelineSpecifiedDocumentContextParameter/ram:ID:

If BT-24 says MINIMUM or BASIC WL, the file is not an e-invoice for German VAT purposes, even if every technical check passes.

Step 3: Validate the XML against the CII schema

The embedded XML uses the UN/CEFACT CII syntax with the root element rsm:CrossIndustryInvoice and the namespace urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100. Each profile has its own XSD schema. Common schema errors:

• The XML is not well-formed, for example because an element is not closed (SCHEMA-001).
• The namespace or root element is wrong (SCHEMA-002).
• Elements appear in the wrong order. CII enforces a strict sequence.
• Dates use the wrong format: udt:DateTimeString with format="102" expects YYYYMMDD, for example 20260928.
• The file contains elements the declared profile does not allow, such as EXTENDED fields in an EN 16931 file.

These are format errors in the sense of the BMF letter, and the file then does not count as an e-invoice.

Step 4: Check the business rules with Schematron

Schematron rules check the logic of the invoice: mandatory fields, calculations, VAT categories and codes. ZUGFeRD must pass the EN 16931 rules, for example BR-CO-10 for the sum of line net amounts (BT-106) or BR-CO-15 for the total including VAT (BT-112 = BT-109 + BT-110). The XRECHNUNG profile adds the German KoSIT rules, such as BR-DE-15: the buyer reference BT-10 must be provided.

For this step you can use our e-invoice validator. Upload the extracted XML; the viewer checks it against the official EN 16931 and XRechnung rules from KoSIT and explains each message. Our reference of xrechnung validation errors lists every code. One point matters when reading the results: messages prefixed BR-DE apply to XRechnung only. If you are checking an EN 16931 profile file for a business customer, those messages are not decisive. The EN 16931 rules always apply.

The most frequent rule violations and how to fix them are covered in our guide to fix XRechnung validation errors.

Step 5: Compare the PDF with the XML

Automated validators generally do not compare the invoice image with the XML, so this comparison is up to you. The summary in the ZUGFeRD extractor shows the key XML values, which you can place next to the PDF:

• BT-1 invoice number and BT-2 invoice date
• BT-31 seller VAT identifier
• BT-109 net total, BT-110 VAT total and BT-112 gross total
• BT-9 due date and BT-84 payment account (IBAN)

Under section 14c.1 (4a) of the German VAT Application Decree (UStAE), an image part with different invoice details, such as a different VAT amount, may count as a second invoice, with a risk of owing that VAT under § 14c UStG. Rounding differences and descriptions shortened for layout reasons are not challenged.

Step 6: Check the mandatory details and content

Passing validation does not prove the invoice is correct. The BMF gives the example of a wrong VAT rate: if the amounts are arithmetically consistent with it, no validator reports an error. So check the details required by § 14 (4) UStG, such as the date of supply, quantity and type of goods or services, the net amount per VAT rate and, for exempt or reverse-charge supplies, the required note. Our German invoice requirements checker walks you through these points. According to the BMF, validation expressly does not replace the recipient's duty to check an invoice for completeness and accuracy; it supports it.

Which tool checks what?

The Mustang project (opens in a new tab) is licensed under Apache 2.0 and checks a ZUGFeRD PDF in one call:

java -Xmx1G -Dfile.encoding=UTF-8 -jar Mustang-CLI-2.26.0.jar --no-notices --action validate --source invoice.pdf

Use the KoSIT validator for the XRECHNUNG profile, and run it on the extracted xrechnung.xml, not on the PDF.

Common errors and how to fix them

What do validation errors mean for VAT?

The BMF letter of 15 October 2025 distinguishes three types of error:

The letter does not say explicitly whether a pure PDF/A defect with a correct XML harms the invoice for VAT purposes. What counts for the e-invoice is the structured part. Fix PDF/A errors anyway, because receiving systems may reject such files.

Keep the validation report

According to the BMF, a business exercising the care of a prudent merchant may rely on the technical result of a suitable validation tool as far as format and business rules are concerned. As evidence, the BMF recommends keeping the validation report. Store it with the invoice for the same eight-year period. How to file e-invoices and supporting records properly is explained in our guide to e-invoice archiving in Germany.

Validate outgoing invoices before sending and incoming invoices on receipt. After each update of your invoicing software, run a test invoice, because output format and code lists can change. More guides on checks and error messages are collected in the validation and errors category.