XRechnung vs ZUGFeRD: Which Format You Need When

XRechnung vs ZUGFeRD: the difference

The difference between XRechnung and ZUGFeRD is not in the content. Both formats describe the same invoice data under the same standard. Invoice number, service period, tax rate and bank details sit there as clearly named data fields, not as running text on a page. Software on the receiving end reads them out and posts them without anyone retyping amounts.

The difference starts where the invoice reaches a human being. An XRechnung carries no layout. There is no typeface, no logo and no page design, and anyone who double-clicks the file sees lines of data. It only becomes readable through a program that renders it for display. ZUGFeRD goes the other way and puts exactly the same data inside an ordinary PDF that looks like any other invoice. The human opens the PDF, the software grabs the data set inside. That design is called a hybrid format: one file, two ways of reading it.

Two rows of this table are skipped in most comparisons and turn out to be the expensive ones in practice: the permitted syntax and the row on what counts as an e-invoice. Both come up further down.

An example: the same invoice as XRechnung and as ZUGFeRD

The quickest way to see the difference is with an example: a single invoice, once as an XRechnung and once as a ZUGFeRD file, placed side by side. The invoice data is identical: same number, same three line items, same tax rate, same total.

As an XRechnung the result is a file of a few kilobytes. Every field sits there under its own name, the invoice number as one element and the net amount as another, with the currency alongside. A human opening it sees angle brackets. Accounting software opening it reads every field straight out of it. A complete file with all its mandatory entries is shown by the example on the page about the XRechnung.

As a ZUGFeRD file the result is a PDF with a letterhead, a table and a totals block, which is exactly the document your customers have been receiving for years. The difference is in the attachment: the PDF is a PDF/A-3, and that variant is allowed to carry arbitrary files along. The same XML as above sits in there, invisible but delivered. How PDF and XML come together technically, and which of the five profiles actually count, is explained on the page about the ZUGFeRD format.

From this follows a rule that often gets it wrong: with ZUGFeRD the data set wins over the visible page. Where PDF and XML differ, the XML is authoritative. Anyone posting such an invoice by hand while looking at the printout may well post a different figure than the one they pay.

Not every ZUGFeRD file is an e-invoice

This is the mistake almost every comparison table makes. They treat ZUGFeRD and e-invoice as the same thing and leave readers believing that any file carrying the name meets the requirement. It does not.

ZUGFeRD knows five profiles, five levels of the same format. MINIMUM carries only a minimal set for posting, BASIC WL leaves out the invoice line items. Neither counts as a complete invoice in Germany, and neither meets the requirements of the standard. BASIC, EN 16931 and EXTENDED do, with EN 16931, formerly called COMFORT, being the level for everyday business. On top of that comes the version: ZUGFeRD is valid from 2.0.1 up, older releases are out.

In practice that means: when you switch, do not ask your software whether it can do ZUGFeRD, ask which version and which profile it writes. A program that dutifully delivers MINIMUM produces no e-invoice in the formal sense, even though the package says ZUGFeRD. With XRechnung the question does not arise, because any file that survives the validation rules is a complete invoice.

The second row nobody explains is the syntax. EN 16931 can be expressed in two technical notations, UBL and UN/CEFACT CII. XRechnung allows both, ZUGFeRD only CII. If your house already produces UBL, for dispatch over Peppol for instance, that data set cannot simply be dropped into a PDF. It has to be translated first, and that is a step people happily overlook when planning.

XRechnung vs ZUGFeRD: which is better?

Asking which is better leads nowhere, because both formats meet the same standard. Price is no help either: both standards are freely available and cost nothing, you only pay for the software that writes them. Whether ZUGFeRD or XRechnung is the right call is settled somewhere else entirely: who receives the invoice, and what can they do with it? Four cases cover nearly everything.

Invoices to public bodies: almost always XRechnung

Here the answer is unambiguous: XRechnung. Public sector buyers name the required format and the Leitweg-ID in their tender documents, and without that number the invoice is rejected even when everything else is correct. ZUGFeRD is accepted only to a limited extent in the public sector. Anyone invoicing public bodies regularly needs XRechnung, and not as a fallback but as the standard route.

Invoices to companies: ZUGFeRD is more convenient

Between companies both formats are valid, and this is where ZUGFeRD plays its advantage. The recipient gets a file they can look at as usual, and their software still gets the data. Nobody has to explain why the invoice suddenly looks different. For customers who have not switched yet, that is the gentler route.

That leaves the question of whether a particular customer can read the data in at all. Answer it once rather than per invoice: ask your twenty most important customers and record the answer in the customer record, ideally where the payment terms sit too. That costs a morning and settles it for years. If you would rather skip that, send hybrid and leave the question open, because that is exactly what the design was invented for.

Invoices to private customers: no obligation at all

Here the question falls away. Invoices to private individuals are not covered by the German e-invoicing mandate, a readable PDF is enough. The same goes for small-value invoices up to 250 euros and for transport tickets. Sending an e-invoice anyway breaks nothing, but it is not required, and a private customer can do little with a bare XML file in any case.

Invoices abroad: settle it per country

Outside Germany hardly anyone knows XRechnung, it is a German flavor of the standard. ZUGFeRD at least made it across the border: in France the same standard is called Factur-X, and files are mutually readable. For the rest of Europe EN 16931 is the common ground, but dispatch often runs over Peppol and its own format. Anyone invoicing abroad regularly settles that per country, not in one sweep.

Converting ZUGFeRD into XRechnung: is that possible?

The question comes up often, and the honest answer is that one direction is easier than the other. The embedded XML can be pulled out of a ZUGFeRD file, which any PDF viewer manages through the attachment list. That XML is not automatically a valid XRechnung, though. XRechnung is a tightened flavor of the standard with validation rules of its own, and it asks for entries ZUGFeRD does not require, above all the buyer reference and, for public bodies, the Leitweg-ID. Without them the file fails validation even though the figures are correct.

The other way round is more work. Anyone wanting to convert an XRechnung into ZUGFeRD has to produce a PDF, translate the data into CII if it exists as UBL, and assemble both into a PDF/A-3. That is not a desk job, it is a job for software.

So the practical advice is: do not convert, issue it correctly. Running an invoice through a tool twice costs time and creates a source of error that was not there before. If your program can produce both formats, pick the right one while creating the invoice. If it can only do one, that is a reason to review the program, not the invoice.

What Unusual Suite sends

In short: an XRechnung packaged the way a ZUGFeRD file is. That sounds like a contradiction until you separate format from packaging.

The format is what the data set says, so XRechnung or ZUGFeRD. The packaging is whether that data set travels bare or sits inside a readable PDF. ZUGFeRD settles both at once, the format and the PDF wrapper are part of the standard. XRechnung settles only the format, and the file normally goes out bare.

Unusual Suite combines the two sides: the data set is an XRechnung, and it is embedded in a readable PDF and attached as a separate file as well. The recipient gets an entirely ordinary invoice to look at and the data to read in, just as with ZUGFeRD, except that what sits inside is an XRechnung. Towards public bodies that is exactly the required format, and between companies it is just as valid. The file does not carry the name ZUGFeRD, because for that the packaging would have to follow the ZUGFeRD standard too.

Invoices are built from data already recorded. Line items come from tracked hours including project, billing rule and period, while mandatory entries such as address, VAT ID and payment details are pulled from the company and customer records. It is made for service firms that bill by effort.

One limit belongs here. Incoming invoices are filed as documents and can be found through full-text search with text recognition, but their XML data is not read out. Anyone who mainly receives invoices and wants them posted automatically needs a different tool for that. When comparing programs it therefore pays to check issuing and receiving separately. Which criteria matter in that choice is covered by the overview of electronic invoicing software.

Conclusion: the recipient decides, not the format

XRechnung vs ZUGFeRD is not a matter of faith. Both meet the same standard, both are valid, and anyone issuing either one cleanly has met the requirement. What matters is who receives the invoice: for public bodies the route runs through XRechnung with its Leitweg-ID, while between companies the hybrid route is the easier one for as long as not everyone has switched.

More important than the choice is one question for your own software: which version and which profile does it write? A ZUGFeRD file in the MINIMUM profile is not an e-invoice, whatever the name promises. When you actually have to switch depends on the deadlines of the German e-invoicing mandate, and those run differently depending on turnover.