XRechnung vs ZUGFeRD: which German e-invoice format?

Open an XRechnung file for the first time and you will not see a letterhead or a table. You see hundreds of lines of angle brackets. Open a ZUGFeRD file and it looks like any other PDF. Both are e-invoices under German VAT law, which surprises many people. The difference is not legal. It is practical: who needs to read the file, and with what?

If you have worked in France, ZUGFeRD will feel familiar, because it is technically identical to Factur-X. If you have used Peppol in the Netherlands or Scandinavia, XRechnung’s UBL variant will look familiar too.

What XRechnung is

XRechnung is Germany’s standard for structured invoice data, maintained by the Coordination Office for IT Standards (KoSIT). Technically it is a national specification of the European standard EN 16931, with extra German business rules. The file is pure XML, in either the UBL or the UN/CEFACT CII syntax. There is no human-readable layer. Reading it takes software. Machines love it. People less so.

According to KoSIT’s version overview, XRechnung 3.0 has applied since 1 February 2024. The current technical bundle is 3.0.2, most recently with a bug-fix release of 31 August 2026. In September 2026, KoSIT published a preliminary version of XRechnung 4.0 based on the revised EN 16931. The final release is expected in spring 2027, and version 3.0 stays in force until at least 31 July 2027.

One quirk catches many people when their first file bounces: XRechnung always requires a buyer reference in field BT-10. For public authorities, that is their routing ID (Leitweg-ID). For business clients, most suppliers enter the purchase order number. Leave it empty and validation fails. Every time.

What ZUGFeRD is

ZUGFeRD is a hybrid format from the Forum for Electronic Invoicing Germany (FeRD). The file is a PDF/A-3 with an XML in CII syntax embedded inside. People open the PDF, software reads the XML. Version 2.4 has applied since 15 January 2026 and added sub-lines for bundles and kits. ZUGFeRD 2.5 (Factur-X 1.09) followed in June 2026 with new EXTENDED fields, and the corrigendum 2.5.2 in August. For an ordinary invoice in the EN 16931 profile, little changes.

ZUGFeRD comes in profiles that carry different amounts of data. That matters. Only some profiles meet the German mandate.

For invoices to German business clients, EN 16931 is the profile that will not get you into trouble. BASIC is allowed but does not cover every case. Few small businesses need EXTENDED, which exists mainly for industrial supply chains where invoices carry delivery references, batch numbers and other logistics data that a normal service invoice never contains.

Side by side

The fields that matter

EN 16931 gives every data field an identifier starting with BT, for business term. Validator error messages refer to these numbers constantly. The ones you will meet most:

The table also shows why a validator is not enough. It checks that BT-31 is filled and correctly formatted. Whether it holds your VAT ID or, by mistake, your client’s, it cannot tell. The mandatory content is the same as on paper, as listed in German invoice requirements.

Which format for which client?

Public authorities set the format, and that is almost always XRechnung. Suppliers to federal bodies have known this since 2020.

With businesses, it depends on the recipient. Large companies with automated accounts payable take both. Small trades businesses that still check invoices on screen are happier with ZUGFeRD, because the PDF opens without any extra tool. To them, a PDF with XML and a PDF without look the same, but their bookkeeping software sees the difference.

The pragmatic approach: if you want to maintain one format, use ZUGFeRD in the EN 16931 profile and switch to XRechnung for authorities when needed. Most invoicing tools generate both from the same data.

Recipients should apply the same principle in reverse. If you receive ZUGFeRD invoices, do not just look at the PDF. Let your software import or display the XML. Most bookkeeping tools show on import whether an embedded XML was found and which profile it uses. If there is none, the file is not an e-invoice at all, just an ordinary PDF.

The hybrid trap

ZUGFeRD stores the same information twice, once as a picture and once as data. The tax authorities consider the XML decisive. If the PDF shows a discount the XML does not know about, the XML wins. That happens when someone edits the PDF after creating it, or when software builds the two parts from different sources. Never touch a ZUGFeRD file after generating it, not even to add a stamp or signature.

For checks, KoSIT’s open-source validator is what many tools use internally. It tests the XML against the standard and the business rules. Content errors such as a wrong VAT rate remain your job.

And other formats?

German law also allows other structured formats if both parties agree and the data can be converted into EN 16931 without loss. That mainly concerns EDI connections between large retailers and their suppliers. Small businesses can ignore it. Non-compliant EDI is only allowed until the end of 2027. After that, EDI messages must carry the data in a form that meets the standard, or the parties switch to XRechnung or ZUGFeRD.

The mandate timeline is in the article on e-invoicing in Germany. If you need XML export built into your own platform, plan for both formats from the start. OnlineBuilders supports projects of that kind.

Receiving both formats yourself? Continue with receive e-invoices in Germany, which shows how to make an XRechnung readable without special software.

Check an invoice for mandatory details: Tick what your invoice contains.