XRechnung and ZUGFeRD: what the data set holds, how to read it

XRechnung is a pure XML file. ZUGFeRD is a PDF file with the same kind of XML embedded in it. In both cases the data set counts: if the PDF image and the XML differ, the structured data take precedence (BMF letter of 15 October 2024, a circular of the Federal Ministry of Finance, cited below as BMF 2024, para. 31; “para.” stands for the numbered paragraphs, Randnummern). People cannot readily read the data set, so you need a programme that displays it.

Two formats on one standard

Both formats implement the European standard EN 16931. The BMF names XRechnung and ZUGFeRD as examples of permitted formats (paras 25, 29 and 30). When the obligation begins for your business is described in the article E-invoice deadlines in construction: which date applies to you. This article is about the files themselves.

KoSIT is the coordination office for IT standards in public administration (Koordinierungsstelle für IT-Standards), and FeRD is the German e-invoicing forum (Forum elektronische Rechnung Deutschland).

According to KoSIT, XRechnung is at version 3.0, which has applied since 1 February 2024 and remains in force until at least 31 July 2027. A preliminary version of XRechnung 4.0 appeared in September 2026, and KoSIT expects the final version in spring 2027. Since 2.0.1, ZUGFeRD has carried EN 16931 within it, except for the profiles MINIMUM and BASIC-WL (BMF 2024, para. 30). FeRD gives 2.5.2 of 4 August 2026 as the current version.

When image and XML do not match

Anyone who receives ZUGFeRD has two views of the same invoice. The BMF rules as follows: if the image contains no details that differ from the XML, it is a duplicate copy with identical content. If it shows something else, for example a different service description or a different tax amount, it may amount to a further invoice, for which section 14c of the German VAT Act (Umsatzsteuergesetz, UStG) has to be checked. Minor technical deviations, such as a shortened service description or rounding differences, are not objected to (BMF 2024, para. 32). An additional human-readable document is not required for an XRechnung but can optionally be sent along (para. 6).

Which permitted format and which transmission route you use is settled under civil law with your contract partner, for example sending by email, an interface or a download via a portal (para. 36). You can also agree an extension that lets you add sector-specific details (para. 38).

Profiles in ZUGFeRD

ZUGFeRD has the profiles MINIMUM, BASIC WL, BASIC, EN 16931 and EXTENDED, plus a reference profile XRECHNUNG. According to the FeRD FAQ, BASIC WL has no invoice lines and therefore cannot represent an invoice under the VAT Act. MINIMUM, like BASIC WL, is an aid for bookkeeping. That fits the exception in the BMF letter (paras 25 and 30). BASIC, EN 16931, EXTENDED and the XRECHNUNG profile do count as a complete invoice.

You must agree the EXTENDED profile with your contract partner in advance. FeRD also points out that if you check a ZUGFeRD file in the EN 16931 profile only against the XRechnung rules, error messages can appear even though the invoice is fine as ZUGFeRD.

What is in the data set

The mandatory details come from sections 14 and 14a UStG. Which detail belongs in which field of EN 16931 has been compiled by KoSIT and FeRD in a mapping table that the tax authorities recommend (BMF letter of 15 October 2026, cited as BMF 2026, paras 8 and 9). The fields carry codes such as BT-10 (buyer reference) or BT-22 (free text).

The service description in the structured part must be clear enough for the tax rate, the type of service and the place of supply to be checked from it. Further details, such as a breakdown of timesheets, may follow in an embedded attachment (BMF 2026, paras 10 to 12).

An attachment therefore belongs in the file. A link to an external target does not meet the requirements, nor does a mere reference to an annex containing mandatory details (BMF 2024 as amended on 15 October 2025, para. 35). The BMF currently makes one exception for the bill of quantities in construction work: an embedded annex may hold the breakdown, and the data set refers to it (BMF 2026, para. 14). In ZUGFeRD, accompanying documents are embedded in the XML Base64-encoded, which according to FeRD is possible only in the EN 16931 and EXTENDED profiles.

What validation checks

Since its letter of 15 October 2025 the BMF has distinguished three kinds of error (paras 6a, 6b and 35a):

• Format errors: the file does not meet the technical requirements of the syntax. It is then only an “other invoice” (sonstige Rechnung).
• Business rule errors: the file breaks validation rules, for example because a mandatory field such as BT-10 is missing or a tax amount does not arithmetically match the tax rate. For VAT purposes this counts only if a mandatory VAT detail is affected. A missing BT-10 is irrelevant for VAT; in B2B dealings, according to the BMF questions and answers, a placeholder such as “-” is enough there.
• Content errors: the file is technically fine but wrong, for example with a wrong tax rate or an inadequate service description.

Technically, a file with a business rule error no longer counts as conforming to the standard. For VAT purposes it remains in principle an e-invoice if it contains the mandatory details correctly and completely (BMF 2026, paras 22 and 23).

A suitable validation application uncovers format errors and business rule errors. According to the Federal Chamber of Tax Advisers, it does not find content errors in most cases. It therefore does not replace the recipient’s duty to check the invoice for completeness and correctness, but supports it. A business may rely on the technical result of a suitable validation if it exercises the care of a prudent businessperson. You keep the validation report as proof (BMF 2025, para. 35a). The BMF does not recommend a particular validation application. What follows from all this for your input VAT deduction is for your tax adviser to clarify.

Viewing for free

For a visual check you need two things: a validator and a visualisation. KoSIT provides both. Its checking tool validates XRechnungen against the configuration, and its visualisation component turns the XML into a readable display. The tax authorities also offer an e-invoice viewer through ELSTER that displays XRechnung and ZUGFeRD (BMF questions and answers, question 12a). The BMF states that an XML file is not suitable for checking by eye and only a visualisation application makes it readable (BMF 2024, para. 28).

For ZUGFeRD the embedded XML is regarded as leading in Germany. FeRD treats technical errors in the PDF/A part as warnings, but the recipient can demand a corrected PDF. The KoSIT page says that rule changes can temporarily lead to error messages, so the result may lag behind the current state.

Invoices contain names, addresses and bank details. A programme that runs locally on your computer saves you the question of where the file goes during checking. For a web service, clarify that beforehand with your data protection officer; invented sample files are enough for trying it out. Whether a free solution is enough for your firm depends on how many invoices arrive and who checks them.

What you can do now

1. Ask a supplier for a test invoice as XRechnung or ZUGFeRD and open it with a visualisation programme.
2. In the display, find the service description and check whether an attachment is embedded.
3. Ask the maker of your construction software which format and which profile it issues.
4. Settle with your tax adviser who validates technically and who checks the content.

General information, not legal or tax advice. Your tax adviser clarifies the individual case. As of 13 November 2026.