XRechnung, ZUGFeRD and choosing a format
Germany has two mainstream formats and they are not interchangeable in the eyes of your recipient. This page is about choosing between them and about the profile trap inside ZUGFeRD.
The two families
XRechnung is pure XML: the German CIUS of the European norm EN 16931. There is nothing human-readable in the file. It exists in two syntaxes, UBL and CII, and both are valid XRechnung — a recipient may require one of them specifically.
ZUGFeRD is hybrid: a PDF that carries the XML inside it. A person opening the file sees an invoice; a machine reading it finds the structured data. ZUGFeRD and the French Factur-X are the same technical family.
The platform emits XRechnung at version 3.0, which has been in force since 1 February 2024.
| You are invoicing | Send |
|---|---|
| A federal public authority | XRechnung — the E-Rechnungsverordnung requires it |
| A Land or municipal authority | Ask the buyer; most accept XRechnung, their rules are their own |
| A German business that asked for XRechnung | XRechnung, in the syntax they named |
| A German business with no preference | ZUGFeRD — they get a readable document and the data in one file |
| A business outside Germany | Peppol BIS |
The ZUGFeRD profile trap
ZUGFeRD comes in profiles, and two of them do not produce a compliant German e-invoice: MINIMUM and BASIC-WL. The BMF circular excludes both explicitly, because neither carries enough structured data to satisfy EN 16931.
This is the single most expensive mistake available in German e-invoicing, because the file looks right. It opens as a normal PDF invoice, it contains XML, and it will be delivered without complaint — and it still is not an e-invoice for the purposes of § 14 UStG.
When you create an invoice on the platform without naming a profile, the document is generated with the EN 16931 profile, which is compliant. The risk arises when a profile is chosen deliberately, or when you upload a file produced elsewhere: check which profile your own accounting software writes before you rely on it.
BASIC-WL deserves one extra warning: it carries no invoice lines at all, only document totals. If you meet it, you will have to enter the totals and the VAT breakdown per rate by hand.
What the platform checks
An XRechnung is validated against the German business rules published by KoSIT before it is accepted. A ZUGFeRD file is validated as a ZUGFeRD document. Either way a rejection tells you which rule failed, and the rule text is in German because the rule set is German.
Two things are worth knowing about that:
Validation is not a review. A document can pass every rule and still be wrong for your customer — the wrong reference, the wrong cost centre, the wrong contact. Rules check form, not intent.
Your local validator may disagree slightly. KoSIT publishes patch releases within version 3.0 on its own schedule. If a document passes on your side and fails here, or the reverse, send both the file and the finding to support rather than assuming one side is broken.
The field that stops most first attempts
An XRechnung must carry a buyer reference or a purchase order reference. If neither is present, the document is refused before it is transmitted, with this message:
A buyer reference or purchase order reference MUST be provided.
For a public buyer that reference is the Leitweg-ID, and it is mandatory — see Leitweg-ID and public buyers. For a business customer, put their own order or contract reference there; it is what their accounts-payable system matches on.
Plain PDF
You can still send a PDF, and the platform will deliver it. Understand what you are doing: it is a sonstige Rechnung, allowed during the transitional period only with your customer's consent, and not at all once your issuing duty starts. See German e-invoicing compliance for the dates that apply to you.