What is the difference between XRechnung and ZUGFeRD?

XRechnung is pure XML — no human-readable form. Standard in the German B2G area (authorities), works for B2B too. ZUGFeRD from profile EN 16931 is a hybrid: PDF with embedded XML — humans see the PDF, software reads the XML. ZUGFeRD is more common in practice, both are legally equivalent.

Can I just have a PDF invoice 'converted' into an e-invoice?

Not reliably. PDF-to-XRechnung conversion would have to interpret text via OCR and heuristics — error-prone (VAT rates, order numbers, discount terms). Cleaner: generate the invoice structured from master data from the start, NOT backwards from the PDF. Legacy stock can be converted, but every result needs review.

Do I still need to keep incoming e-invoices as PDFs?

No — and it would be problematic. The original is the XML file. You must keep that GoBD-compliant for 8 years, unchanged (hash-locked). Generating a PDF preview is fine, but it's an attachment/preview, not the original. Anyone who throws away the XML and only keeps the PDF has lost the original.

Back to overview

05 · E-invoicing

E-invoicing: B2B mandatory since 01.01.2025

Germany's Wachstumschancengesetz made electronic invoicing mandatory in B2B. Receiving must be possible for everyone since 01.01.2025. Sending is staggered: from 01.01.2027 for everyone with turnover above EUR 800k, from 01.01.2028 for all B2B. PDF alone is not enough — structured XML is required.

What it's about

An 'e-invoice' under the law is an invoice in a structured electronic format that allows machine processing. PDF files are not e-invoices — even when sent electronically. Two formats apply in Germany: XRechnung (pure XML standard, mandatory in B2G) and ZUGFeRD from profile EN 16931 (PDF with embedded XML, more common in practice). Both must satisfy the EN 16931 mandatory fields and pass the KoSIT validator. Without a correct e-invoice, no input VAT deduction — that gets expensive.

What is mandatory

Receiving capability since 01.01.2025 (email inbox for XRechnung/ZUGFeRD)
Structured format per EN 16931 (XRechnung CIUS or ZUGFeRD profile EN 16931)
Validation against the KoSIT validator (Schematron check for XRechnung)
Mandatory fields: service/delivery date, VAT ID, order reference, bank details
Discount terms in structured fields, not free text
GoBD-compliant 8-year archive, immutable (hash-secured)
No format change on receipt: the original XML is the invoice
On errors: cancellation + new invoice, no after-the-fact editing

What I take care of

Implementation of an e-invoice generator (XRechnung 3.0.x or ZUGFeRD 2.3+)
Validation against the KoSIT validator before every send (no 'just ship it')
GoBD-compliant archive in Supabase Storage with hash lock and write protection
Receiving path: email inbox + parsing (extract XML, validate, import into accounting)
Integration with DATEV export or existing ERP (lexware, SAP, etc.)
Migration of legacy PDF invoices: assess which ones still need conversion
Status dashboard: received/sent/open/rejected invoices

Legal basis

German Wachstumschancengesetz (Art. 23) · § 14 UStG · GoBD (principles for proper computer-aided accounting) · EN 16931 · CIUS XRechnung

Frequently asked

What is the difference between XRechnung and ZUGFeRD?: XRechnung is pure XML — no human-readable form. Standard in the German B2G area (authorities), works for B2B too. ZUGFeRD from profile EN 16931 is a hybrid: PDF with embedded XML — humans see the PDF, software reads the XML. ZUGFeRD is more common in practice, both are legally equivalent.
Can I just have a PDF invoice 'converted' into an e-invoice?: Not reliably. PDF-to-XRechnung conversion would have to interpret text via OCR and heuristics — error-prone (VAT rates, order numbers, discount terms). Cleaner: generate the invoice structured from master data from the start, NOT backwards from the PDF. Legacy stock can be converted, but every result needs review.
Do I still need to keep incoming e-invoices as PDFs?: No — and it would be problematic. The original is the XML file. You must keep that GoBD-compliant for 8 years, unchanged (hash-locked). Generating a PDF preview is fine, but it's an attachment/preview, not the original. Anyone who throws away the XML and only keeps the PDF has lost the original.

Need support?

Let's talk for 30 minutes. I'll look at your situation and tell you what makes sense as a next step.

Book a slot