How to Create a ZUGFeRD or XRechnung Invoice
Since the E-Rechnungspflicht took effect, a PDF alone no longer counts as a proper invoice between German businesses: the law expects structured data conforming to EN 16931. The generator above produces exactly that. Fill in the form once and take away a ZUGFeRD PDF/A-3b or a standalone XRechnung XML, checked before it leaves the page.
ZUGFeRD or XRechnung: which format should you create?
The two German e-invoice formats serve different recipients:
- ZUGFeRD is for B2B invoices between companies. The file is a PDF with embedded XML, so your customer sees a normal-looking invoice while their accounting system reads the data automatically. Choose it for private-sector customers.
- XRechnung is for B2G invoices to public authorities (federal, state, and municipal). It is pure XML with no PDF layer and requires a Leitweg-ID from the recipient. Choose it when you invoice the public sector.
This page creates ZUGFeRD. Invoices to public authorities have their own tool:
Which details must a German e-invoice contain?
German tax law and EN 16931 together fix a minimum data set. The form checks every entry as you type; having these details to hand speeds things up:
- Seller name, address, and a tax identifier (USt-IdNr. or Steuernummer)
- The customer's name and complete postal address
- An invoice number used only once, plus the invoice date
- One or more line items, each with quantity, net unit price, and VAT rate
- A VAT summary broken down per tax category and rate
- How the invoice is to be paid, including the IBAN
For invoices to public authorities, the Leitweg-ID (buyer reference, BT-10) is mandatory and must be obtained from the authority before you issue the invoice.
Which ZUGFeRD profile should you choose?
A profile determines how much detail the XML layer carries. German B2B practice almost always calls for EN 16931 (Comfort): full line-item detail, accepted everywhere from DATEV to SAP. Profiles below it, such as MINIMUM, drop the line items and only suit automated accounts-payable workflows matched against purchase orders.
Compatible with DATEV, SAP, and Lexware
The generator names the embedded XML attachment exactly as German accounting packages expect, so DATEV, SAP, Lexware, sevDesk, and Lexoffice read the data without manual entry. The payload follows the Cross Industry Invoice (CII) syntax these systems parse natively.
Your invoices already exist in another format?
PDF, DOCX, or XLSX invoices from your current workflow never need retyping. Two neighbouring tools take over:
Validation is built into the download
A generated file and a valid file are two different things. Each invoice from this page runs through the official EN 16931 Schematron first, so the download is ready to send the moment you have it.
Deadlines, thresholds, and who exactly is affected: our guide covers the details:
Creating invoices from your own software instead of a form? The ZUGFeRD API page shows the calls, with curl and C# samples.
Related reading
- ZUGFeRD invoices in English: what German law allows and what your client's accountant actually needs
- Your German customer wants an e-invoice. Do you actually have to send one?
- E-invoicing in Germany: what English-speaking businesses actually have to do
- Validate ZUGFeRD output from your own code: the four rule layers and the bugs that pass three of them
- Embedding CII XML into PDF/A-3: file name, AFRelationship, XMP metadata and the mistakes validators actually flag