ZUGFeRD vs XRechnung: which e-invoice format a German company needs

ZUGFeRD and XRechnung are the two e-invoice formats German companies use, and both follow the European standard EN 16931. XRechnung is a pure XML file, required by federal public authorities. ZUGFeRD is a PDF with an embedded XML file, readable by people and systems alike. For B2B invoices, both qualify as e-invoices, as long as a ZUGFeRD file uses a sufficient profile.

The debate about which format is better is mostly a distraction. The two carry largely the same data, and most companies will receive both. What matters is whether the data inside the file is complete and correct, and whether the receiving side can process it without anyone reading XML.

---

What is the difference between ZUGFeRD and XRechnung?

XRechnung is the German specification of EN 16931, developed for the public sector and maintained by the coordination office for IT standards (KoSIT). An XRechnung is a structured XML file and nothing else. There is no visual invoice inside it. Opened without a viewer, it is a long list of tags and values. It can be written in two technical syntaxes, UBL and CII, and both are valid.

ZUGFeRD was developed by the Forum elektronische Rechnung Deutschland (FeRD), an industry initiative. A ZUGFeRD invoice is a PDF/A-3 document with an XML file embedded in it. A person opens the PDF and sees a normal invoice. A system reads the XML. Its French counterpart, Factur-X, is technically the same format, which makes ZUGFeRD useful for companies with customers in both countries.

So the practical difference is the human-readable layer. With XRechnung, the recipient needs software to display the invoice. With ZUGFeRD, anyone can read it, and software can still process it.

One rule applies to the hybrid: if the PDF and the XML disagree, the XML counts. The Federal Ministry of Finance (BMF) is clear that the machine-readable part is decisive for tax purposes. A ZUGFeRD invoice whose PDF shows one amount and whose XML shows another is a problem, not a convenience.

Which ZUGFeRD profiles count as an e-invoice?

ZUGFeRD comes in profiles that define how much data the XML part contains. According to the BMF letters on e-invoicing, ZUGFeRD qualifies from version 2.0.1, with two exceptions:

• MINIMUM and BASIC WL do not qualify. They contain only header data, not all invoice details that German VAT law requires, so they are not e-invoices for the mandate.
• BASIC, EN 16931 (formerly COMFORT), EXTENDED and XRECHNUNG qualify.

The XRECHNUNG profile is worth knowing about: it produces a ZUGFeRD file whose XML meets the XRechnung rules. That lets a company send one hybrid format that public and private customers can both use, provided the public recipient accepts the hybrid.

Some invoicing tools create MINIMUM or BASIC WL files, because these profiles were designed for simpler purposes such as pre-filling data. If your current tool says "ZUGFeRD", check the profile before assuming it covers the mandate. The dates and thresholds of that mandate are explained in our guide to e-invoicing in Germany.

When do you need XRechnung specifically?

The clearest case is the public sector. Under the federal e-invoicing regulation (E-Rechnungsverordnung), invoices to federal authorities must in principle use XRechnung. Other standards are allowed only if they meet EN 16931. The regulation also requires a few extra details, most importantly the Leitweg-ID, a routing number the authority gives you with the order, plus bank details, payment terms and your email address. Without the Leitweg-ID, the authority cannot route the invoice to the right office.

The federal states and municipalities have their own rules and portals. If you invoice public customers outside the federal level, ask each one which formats and which transmission routes it accepts.

In B2B, some larger companies also ask for XRechnung, often because their incoming invoice process is built on pure XML. That is a matter of agreement between the parties, not a legal requirement. German VAT law treats a qualifying ZUGFeRD invoice and an XRechnung the same way.

Which format should a German B2B company send?

For most private-sector customers, a ZUGFeRD invoice in the EN 16931 profile is the practical default. It meets the legal requirements, a recipient without e-invoicing software can still read the PDF, and a recipient with software can process the XML. During the transition until the end of 2027, many smaller customers still fall into the first group.

XRechnung makes sense as a second option: for public customers, and for business customers who ask for it. Many invoicing tools that produce one format can also produce the other.

There is a third route that larger customers sometimes bring up: EDI. Companies that already exchange invoices through EDI connections, for example in retail or automotive supply chains, can keep them, as long as the data can be converted into a format that meets EN 16931 without losing information. The BMF also names Factur-X and Peppol BIS Billing as examples of formats that can work. For a company starting from PDF invoices, none of this changes the default. It only means that a customer who asks for something other than ZUGFeRD or XRechnung is not necessarily asking for something unlawful.

A simple rule for the customer master data helps: record the format each customer wants, and for public customers the Leitweg-ID, once, on the customer record. Invoicing then follows the record instead of someone's memory.

The choice of format is the easy part. The harder part is the data. An e-invoice that passes the format check can still be missing details that § 14 of the German VAT Act (UStG) requires, such as the correct VAT ID, the delivery date or a separate amount for each VAT rate. The full list is in our article on invoice requirements in Germany.

What does the receiving side have to handle?

Receiving is where the format question turns practical, because a company cannot choose what its suppliers send. From January 2025, every business must be able to receive e-invoices, so finance teams will see XRechnung, ZUGFeRD in several profiles, and plain PDFs side by side for some time.

The BMF letter of 15 October 2025 distinguishes three kinds of errors, and each one has a different consequence:

• Format errors: the file is not technically valid, or the mandatory fields cannot be extracted. It is then not an e-invoice, only an "other invoice".
• Business rule errors: the file is an e-invoice, but it breaks a rule of the format, for example a missing mandatory field. It should be corrected.
• Content errors: the data is technically fine, but a tax detail is wrong, such as the VAT rate or the service date. These can put the input VAT deduction at risk.

The first two are found by a validator. The third needs someone, or something, that knows the order, the supplier and the booking history. Whatever arrives, the XML is the original for the GoBD (German digital bookkeeping rules) and must be stored unchanged, as explained in archiving invoices under GoBD.

How does Agent F handle both formats?

Agent F sends and receives XRechnung and ZUGFeRD. Outgoing invoices are created from the order and the customer record, in the format the customer needs. Incoming files are read directly, checked against the format rules and the § 14 UStG details, and errors are explained in plain language rather than as validator codes, so the person handling the invoice knows what to ask the supplier for. The invoice then continues into the approval and booking flow described in accounts payable automation, with suggestions that a person approves.

For any company, a short check is useful now: find out which profile your invoicing tool produces, ask your public customers for their Leitweg-IDs and preferred formats, and run a few incoming e-invoices through your process to see who ends up reading the XML.

Learn how Agent F works, or see it on your own invoices at agent-f.ai/demo.