Two formats, one standard, and about thirty German rules underneath
XRechnung and ZUGFeRD both carry the same European standard, so neither is more legal than the other. What separates them is what the file physically is, and what Germany adds on top. This guide covers both, and names the rules that actually get invoices rejected.
The usual place to start with XRechnung and ZUGFeRD is “one is XML, one is a PDF”. That is true, and it is not the part that costs you money. What costs you money is the set of German business rules, numbered BR-DE-1 upwards, that an XRechnung must satisfy before a recipient’s system will take it. They are published, they are machine-readable, and almost nothing in English explains them. That is most of what this guide is.
The short version
Both formats implement EN 16931, the European semantic standard for an invoice. Both satisfy the German business-to-business mandate. The decision is practical, not legal.
| If the recipient is | Send | Because |
|---|---|---|
| A German public authority | XRechnung | It is what the federal e-invoicing regulation asks for, and they will give you a Leitweg-ID to put in it |
| An ordinary business | ZUGFeRD, BASIC or higher | The file is also a readable PDF, so a client with no e-invoicing software can still open it |
| A business that asked for XML | XRechnung | Their system wants data, not a document |
| Outside Germany | Whatever they specify | The German mandate does not reach them, and their own country’s rules do |
| A private consumer | A PDF is fine | Consumers are outside the mandate; an e-invoice needs their consent |
What each file actually is
The difference is physical, and it decides who can read your invoice without new software.
An XRechnung is an XML file. It carries the invoice as data and nothing else. Open it in a text editor and you get tags. A person needs a viewer to read it as an invoice, which is a real cost to impose on a small client.
A ZUGFeRD file is a PDF with the same data embedded inside it. It is built on PDF/A-3, the archival PDF format that permits file attachments, and the attachment is the invoice in XML. Your client double-clicks it and sees an invoice. Their accounting software, if it has any, reads the XML and skips the picture. The same file serves both.
ZUGFeRD is developed jointly with a French counterpart and the identical specification ships under two names. ZUGFeRD 2.5.2, published on 4 August 2026, is Factur-X 1.09.2. If a French client asks for Factur-X, you already know how to make one.
XRechnung is two standards, not one
This trips up more people than it should, including us. XRechnung is usually described as a CIUS, a Core Invoice Usage Specification, which is the European standard’s own word for a national narrowing of itself. A CIUS may make an optional field compulsory. It may not invent new ones.
That description is half the story. KoSIT, which maintains the standard, states plainly that the XRechnung standard consists of the CIUS XRechnung and the Extension XRechnung. The Extension does add fields the European standard does not have, among them sub invoice lines and third-party payments.
The two are told apart by the specification identifier written into the file. The CIUS uses a marker meaning compliant; the Extension uses one meaning conformant. You will almost certainly send the CIUS. The Extension exists for invoices with structures ordinary trade does not need, and a receiver who expects the CIUS may not accept it.
The German rules that actually reject your invoice
EN 16931 has its own business rules. Germany layers more on top, coded BR-DE-…, and
these are the ones a small business trips over, because they demand things a normal invoice
template leaves out.
They are published as machine-readable files, so this is not interpretation. The current release carries 53 German rules for the UBL syntax and 46 for CII. The core rules are identical in both; only the extension rules differ.
The seller contact rules, which cause most rejections
This is the single most common failure, and the reason is that they are separate rules rather than alternatives. An XRechnung needs a seller contact group, and inside it:
- BR-DE-5 a contact name
- BR-DE-6 a contact telephone number
- BR-DE-7 a contact email address
All three are fatal, and all three are required at once. An email address alone does not satisfy
the telephone rule. If you have never put a phone number on your invoices, your first XRechnung
will be rejected for that and the message you get back will say BR-DE-6.
Addresses, for both parties
The European standard is content with a country. Germany is not. BR-DE-3 and BR-DE-4 require your own town and post code, and BR-DE-8 and BR-DE-9 require your client’s. All four are fatal. A client record with a name and a country will not do.
The buyer reference
BR-DE-15 makes the buyer reference field compulsory in every XRechnung. For a public authority that is the Leitweg-ID they issued you. For a business it is whatever reference they gave you, a purchase order number for instance. What it may not be is empty.
Payment instructions
BR-DE-1 requires the invoice to carry payment instructions. In practice that means the file must say how you expect to be paid, and BR-DE-23 to BR-DE-25 then insist the details match the method: a transfer needs credit-transfer details and must not carry card or direct-debit ones, and so on for each. A file that says “transfer” and then supplies card details is refused for inconsistency.
The rule nobody expects: early-payment discounts
BR-DE-18 governs how a Skonto, an early-payment discount, is written into the payment terms field, and it is unusually strict. The text has to follow a fixed pattern of segments separated by hash marks, naming the days and the percentage, in capital letters, with two decimal places and no extra whitespace. Free prose describing your discount will fail.
#,
then SKONTO, then TAGE= and the number of days, then
PROZENT= and the percentage, each segment separated by # and the line
closed with one. If the discount applies to part of the invoice rather than the whole, a fourth
segment gives the base amount.| Rule | What it demands | Severity |
|---|---|---|
BR-DE-1 | Payment instructions must be present | Fatal |
BR-DE-2 | A seller contact group must be present | Fatal |
BR-DE-3 / BR-DE-4 | Seller town, seller post code | Fatal |
BR-DE-5 / BR-DE-6 / BR-DE-7 | Contact name, telephone, email | Fatal |
BR-DE-8 / BR-DE-9 | Buyer town, buyer post code | Fatal |
BR-DE-10 / BR-DE-11 | Delivery town and post code, when a delivery address is given | Fatal |
BR-DE-14 | The VAT category rate | Fatal |
BR-DE-15 | The buyer reference | Fatal |
BR-DE-16 | With most tax categories, a seller VAT identifier, tax registration or tax representative | Fatal |
BR-DE-18 | The early-payment discount pattern | Fatal |
BR-DE-22 | Every attachment filename must be unique | Fatal |
BR-DE-23 to BR-DE-25 | Payment details must match the payment method | Fatal |
BR-DE-30 / BR-DE-31 | Direct debit needs a creditor identifier and the debited account | Fatal |
BR-DE-17 | Invoice type code from a short permitted list | Warning |
BR-DE-19 / BR-DE-20 | The account should be a valid IBAN for SEPA payments | Warning |
BR-DE-26 | A corrected invoice should name the invoice it corrects | Warning |
BR-DE-27 / BR-DE-28 | Telephone should have at least three digits; email exactly one @ | Warning |
Fatal means the file is refused. A warning means it goes through and somebody may ask a question. The list above is the German layer only, and your invoice must satisfy the European standard’s own rules underneath it as well.
What XRechnung does not require
Two things are widely believed to be compulsory and are not. Both are worth knowing because software sometimes enforces them anyway.
An electronic address, probably. Here is exactly what we checked and what we did not, because the distinction matters. We read the published validation rules: no Schematron rule in EN 16931 or in XRechnung tests that the seller or buyer electronic address is present, and the one German rule that touches it only constrains the scheme code when an address is there. So a file without one passes those checks. What we could not verify is the specification document itself, which sets cardinalities the rule files do not encode. Absence of a validation rule is not proof that a field is optional, and we are not going to pretend otherwise. Peppol requires one outright, because it needs the address to route the file. The practical advice: put your email in, it costs nothing, and treat a tool that insists on it as cautious rather than wrong.
A Leitweg-ID, as such. What is compulsory is a buyer reference. When your customer is a public authority, that reference is the Leitweg-ID. When it is a business, it is their own reference. The field is required; the Leitweg-ID specifically is not.
The ZUGFeRD profile ladder
ZUGFeRD is not one thing. It ships as a ladder of profiles carrying progressively more data, and the bottom two rungs are not invoices.
| Profile | What it carries | A full invoice in Germany? |
|---|---|---|
| MINIMUM | Totals only, as a booking aid. No line items | No |
| BASIC WL | More header data, still no line items | No |
| BASIC | Line items, and a restricted field set | Yes |
| EN 16931 (COMFORT) | The full European standard | Yes |
| EXTENDED | The standard plus additional fields | Yes |
| XRECHNUNG | The XRechnung rules, inside a ZUGFeRD container | Yes |
The “no” on the first two is not our opinion. The maintainers publish it against each profile, and the reason is structural: an invoice without line items cannot show what was supplied, which German VAT law requires. Both profiles exist to help a bookkeeping system post a payment, not to be the invoice.
UBL or CII: does the choice matter?
EN 16931 permits two XML syntaxes, and XRechnung requires support for both: UBL 2.1 and UN/CEFACT CII. They express the same invoice in different tag vocabularies.
For a sender the honest answer is that it rarely matters. The German rules are the same in both, as the published rule files show, so an invoice that satisfies the rules in one satisfies them in the other. Two practical notes. ZUGFeRD’s embedded XML is CII, so if you send ZUGFeRD the choice is made for you. And where a recipient states a preference, follow it, because their software may only have been tested against one.
Getting it there: email or Peppol
German law prescribes no delivery channel. That is worth repeating because it is the single cheapest thing to know: email with the file attached is a legal way to send an e-invoice between businesses. A download portal, a shared folder or EDI are equally acceptable, and the parties agree the route between themselves.
Peppol is a transport network rather than a format. Participants have addresses, messages travel between certified access points, and both sides need to be reachable on the network. Peppol BIS Billing 3.0, the invoice specification used on it, is itself a restriction of EN 16931, which is why a Peppol invoice looks so much like an XRechnung.
For a one-person business, Peppol is usually something you join through a provider rather than operate. It becomes worth it when a customer requires it, and not much before. Germany does not require it for business-to-business invoicing at all.
Reading an e-invoice somebody sends you
You have had to be able to receive an e-invoice since January 2025, which raises a practical question the rules do not answer: how do you actually read one?
A ZUGFeRD file is easy, because it is a PDF. Open it as usual.
An XRechnung is XML and needs a viewer. Quba is a free, open-source one published under the ZUGFeRD project, licensed Apache 2.0, and it runs on Windows, macOS and Linux without an internet connection. Drag the file on and it renders as an invoice. The federal tax portal also offers a viewer for looking at an e-invoice, and it is worth being precise about what that is: a viewer displays, it does not validate. Several guides describe it as a check on validity. It is not one.
Checking before you send
Every rule in this guide can be tested before the file leaves your machine, and testing takes seconds against the days a rejection costs.
- In a browser, free, no registration: the European Commission’s online EN 16931 validator takes the file and lists the rules it broke.
- On your own machine: the KoSIT validator is the reference implementation for XRechnung, and Mustangproject checks ZUGFeRD files including the PDF container.
Keep the validation report. German tax guidance distinguishes a format error from a business-rule error and accepts that a business exercising ordinary commercial care may rely on the technical result of a validation. The report is how you show you did.
Or let the tool do it
The free ANUPRESS invoice generator builds XRechnung, Factur-X, UBL and CII in your browser, with no account and nothing sent to a server. You choose the rulebook and it checks the document against it before building the file, so a missing buyer reference stops you at the form rather than at the recipient. It is free, unlimited and unwatermarked.
Open the free invoice generator
So which do you send?
- Is the customer a German public authority? Send XRechnung, and ask them for the Leitweg-ID before you raise the invoice rather than after.
- Did the customer specify a format? Send that. A specified format beats every other consideration here, because their system is what has to accept it.
- Is the customer a business with no e-invoicing software? Send ZUGFeRD in BASIC or EN 16931. They see a PDF, and the structured data is there when they need it.
- Anything else? ZUGFeRD at EN 16931 is the sane default: a full invoice, a readable document, and the same file works for a French client as Factur-X.
Where this guide stops
Naming the limits is more useful than pretending there are none.
This is not tax advice, and it is not a substitute for the specifications. It is a reading of published rule files, and where a rule matters to you the published text is the authority.
Rule texts are summarised, not quoted. The German rules are published in German. The descriptions here are our translations of what each rule demands, made for a reader deciding what to put on an invoice. For an implementation, read the rule files.
Some things are deliberately absent. We have not quoted profile identifier strings, because a reader does not type them and we did not verify them. We give no price for a Peppol access point, because that is commercial and varies. And we give no in-force date for ZUGFeRD 2.5.2, because the maintainers publish a publication date and not a validity date, and inventing the difference would be guessing.
The public-sector picture is federal only. Each German state runs its own portal and its own deadlines. If you invoice a state authority or a municipality, check theirs.
XRechnung and ZUGFeRD FAQ
Is XRechnung or ZUGFeRD better for a small business?
For business customers, ZUGFeRD in the BASIC profile or higher, because the file is also a readable PDF and your client can open it without any special software. For a public authority, XRechnung, because that is what the federal e-invoicing regulation asks for. Both satisfy the German business-to-business mandate, so the choice is about what the recipient can handle rather than about legality.
Which ZUGFeRD profile should I use?
BASIC or higher. The format’s own maintainers mark BASIC, EN 16931 and EXTENDED as recognised in Germany as a complete invoice under VAT law, and mark MINIMUM and BASIC WL as not recognised. Those two lower profiles carry no invoice line items and exist as a booking aid, so a file in either of them is not a full invoice however valid the XML is.
Is XRechnung a CIUS or an extension of EN 16931?
Both. KoSIT states that the XRechnung standard consists of the CIUS XRechnung and the Extension XRechnung. The CIUS restricts the European standard by making optional fields compulsory. The Extension adds fields the European standard does not have at all, including sub invoice lines and third-party payments. The two are told apart by the specification identifier the file carries.
Does an XRechnung need a Leitweg-ID?
It needs a buyer reference, which is not quite the same thing. Rule BR-DE-15 makes the buyer reference field compulsory in every XRechnung. When you invoice a German public body that reference is the Leitweg-ID it issued you. When you invoice an ordinary business it is whatever reference they gave you, such as a purchase order number. The field must not be empty either way.
Why do XRechnung invoices get rejected?
Usually because of the German rules layered on top of the European standard rather than the standard itself. The most common are the seller contact rules: an XRechnung needs a contact name, a telephone number and an email address, and those are three separate compulsory rules rather than alternatives. Missing town or post code for either party, and an empty buyer reference, account for most of the rest.
Does my invoice need an electronic address to be a valid XRechnung?
Supply one. We checked the published validation rules, and no Schematron rule in EN 16931 or XRechnung tests for its presence, so a file without one passes those particular checks. That is not the same as the field being optional: the XRechnung specification sets cardinalities that the rule files do not encode, and we could not verify that document directly. Peppol requires an electronic address outright, because it needs one to route the file. Treat a tool that insists on it as cautious rather than wrong.
Do I have to use Peppol to send an e-invoice in Germany?
No. German law prescribes no delivery channel at all, so email with the file attached is a legal way to send an e-invoice between businesses. Peppol is a transport network with its own addressing and certified access points, and it is one option among several rather than a requirement.
How do I open an XRechnung file I have been sent?
An XRechnung is XML, so it opens in any text editor but reads like a data file. To see it as an invoice, use a viewer. Quba is a free open-source one published under the ZUGFeRD project on GitHub, it runs on Windows, macOS and Linux, and it needs no internet connection. The federal tax portal also offers a viewer, which displays an e-invoice but does not validate it.
Bottom line
Neither format is more legal than the other, so stop choosing on that basis. Send ZUGFeRD to businesses, because it is a PDF as well as data and it costs your client nothing to open. Send XRechnung to public authorities, because that is what they ask for. Keep the profile at BASIC or above and the two bottom rungs of the ladder can never catch you.
Then spend your attention where the rejections actually come from. Put a telephone number and an email address on your invoices, not one or the other. Carry a town and a post code for yourself and for your client. Never leave the buyer reference empty. Those four habits clear most of the German rules before you have thought about XML at all.
If you would rather not think about it, the free invoice generator builds both formats in your browser and checks the document against the rulebook first. And if you are still working out the underlying obligation, the guide to invoicing in Germany covers who has to send an e-invoice, and by when.
Written by the ANUPRESS team. The rule codes in this guide were read from KoSIT’s published rule files on 10 September 2026, and the profile table from the format maintainers’ own documentation. Rules change, and this guide is information rather than tax advice. Found something out of date? Tell us and we will check it.
