Which E-Invoice Format? A Practical Guide to Choosing
The technical question during a changeover is rarely “e-invoicing yes or no” but which format? Three names always come up — XRechnung, ZUGFeRD and Peppol. They are not alternatives in an either/or sense; they solve different problems.
Keeping the three terms apart
The most common misconception is to treat all three as the same kind of thing. In fact they describe different layers:
- XRechnung is a data format: a pure XML file, the German standard for invoices to public-sector bodies.
- ZUGFeRD is a hybrid data format: a PDF with the same structured data embedded as XML. Technically identical to Factur-X in France.
- Peppol is not a format but a transmission network — the route by which the invoice reaches the recipient. The format carried on it is Peppol BIS Billing, also based on EN 16931.
XRechnung vs. ZUGFeRD compares the technical structure in detail. This guide is about the decision.
Choosing by situation
| Your situation | Recommended format | Why |
|---|---|---|
| Invoices to authorities and municipal bodies | XRechnung | Mandatory in B2G, including the Leitweg-ID |
| Mid-sized customers who also look at the invoice | ZUGFeRD | One document for humans and machines, nothing to explain to the recipient |
| Customers with fully automated processing (ERP) | XRechnung (UBL or CII) | No PDF ballast, directly importable |
| Recipients elsewhere in the EU | Peppol BIS over the Peppol network | One route without bilateral arrangements — see Peppol ID |
| Mixed customer base, low volume | ZUGFeRD as the default | Accepted by every recipient — including those who have not switched yet |
By industry and size
Trades and small service businesses have the smoothest ride with ZUGFeRD: the customer still receives a PDF they can open and file, and the structured data travels along invisibly. The sector-specific questions are covered in E-invoicing in the trades.
Construction and public contracts cannot avoid XRechnung. Here the Leitweg-ID is the real bottleneck — it is assigned per contracting authority and must be maintained in master data. See E-invoicing for public authorities.
Retail and industry with high volumes should go with pure XML and not drag PDF generation along at all. Where EDI procedures already run, the extended transition period applies — the switch can be planned rather than forced.
Freelancers and small businesses need no outgoing format at all for now: until 2028 only the receiving obligation applies to them. See E-invoicing for small businesses.
On the receiving side there is no choice
Important for planning: the format decision only concerns sending. When receiving you must be able to accept any standard-compliant format — you cannot instruct a supplier to send ZUGFeRD instead of XRechnung. Your intake must therefore read both: pure XML in UBL and CII, plus ZUGFeRD PDFs from which the embedded XML is extracted.
Checklist: is my software e-invoicing-ready?
Test your current program against these seven points. Every “no” is a concrete item for your vendor:
- Outgoing: Does it produce XRechnung or ZUGFeRD in a version compliant with EN 16931 — and does it state the version?
- Incoming: Does it read incoming XML files and ZUGFeRD PDFs, or only what it produced itself?
- Validation: Does it validate against the Schematron rules before sending, or do you find out when the customer rejects the invoice?
- Leitweg-ID: Is there a dedicated field, or do you have to type it into a notes box?
- Archiving: Does it store the structured original — or only a PDF printout? See Archiving e-invoices.
- Master data: Can VAT ID, bank details and payment terms be maintained cleanly per customer?
- Corrections: Can it produce credit notes and corrections with a proper reference to the original invoice?
Whether a switch is worth it at all or a free tool suffices is weighed up in E-invoicing software.
Test the format before you commit
The format question resolves fastest against a real file. In the browser tool, produce the same invoice once as XRechnung and once as ZUGFeRD, send both to a test customer, and see what arrives in their system. Both variants are validated against EN 16931 and the German business rules — locally in the browser, with no upload.
Frequently asked questions
Which e-invoice format should I choose?
XRechnung for public-sector customers, ZUGFeRD for customers who also want to read the invoice, Peppol BIS for cross-border delivery over a network. All three comply with EN 16931.
Do I have to commit to one format?
For sending, yes — one format per customer group keeps processes simple. For receiving, no: you must be able to accept any standard-compliant format.
What is the difference between UBL and CII?
Both are XML syntaxes of XRechnung. UBL comes from the OASIS world, CII from UN/CEFACT. They are equivalent in content; ZUGFeRD uses CII internally.
How do I tell whether my software is e-invoicing-ready?
It must produce a standard-compliant outgoing format, read incoming XML and ZUGFeRD files, archive the structured original, and carry the Leitweg-ID as a proper field.