e-Invoicing in Germany: XRechnung explained

What the invoice contains

An e-invoice must be structured and follow the European standard EN 16931. The accepted formats are XRechnung (XML, based on UBL or UN/CEFACT CII) and ZUGFeRD 2.x hybrid invoices (PDF with embedded XML). The profiles MINIMUM and BASIC-WL do not qualify. In a hybrid invoice the XML is the legal invoice and a different PDF image can put input VAT at risk. A PDF sent by email is now an 'other invoice' and no longer an e-invoice. All required details under sections 14 and 14a UStG must be in the structured data, not in a link or attachment. For B2G the federal government uses XRechnung with the Leitweg-ID in the buyer reference field BT-10.

What your ERP has to deliver

Systems must create and receive EN 16931 XML in XRechnung or ZUGFeRD form and read the XML as the leading data. They need a way to receive e-invoices by a channel that can be reached (the BMF has said one email address is enough), validate incoming files, and archive the structured file unchanged and readable under tax retention and GoBD rules. Credit notes and corrections must also be issued as e-invoices, and ERP workflows must separate e-invoices from other invoices, because only e-invoices guarantee a clean input VAT claim.

Practical insights

• Germany has no clearance platform. The tax authority does not see the invoice when it is sent, and compliance is checked later in audits, so company-side validation is the main control.
• The XML is the invoice. If a ZUGFeRD file shows a PDF that differs from its XML, the XML wins, and a mismatch can put the recipient's input VAT deduction at risk.
• The EUR 800,000 test uses the prior year's turnover. A company just above or below the line should check its own figures each year to know whether the 2027 or the 2028 date applies.
• A single email address can meet the receiving duty, but a shared inbox for all invoices may need rules to separate e-invoices from other documents before booking.

Common pitfalls

• Sending a plain PDF by email after the transition and treating it as an e-invoice. It is an 'other invoice' and the recipient may be unable to claim input VAT until a correct e-invoice arrives.
• Using the ZUGFeRD MINIMUM or BASIC-WL profile, which do not contain enough data to count as an e-invoice.
• Archiving only a PDF image and not the original structured XML, which breaks the retention rule.
• Forgetting that credit notes issued as invoices, and recurring-service invoices that change, also need the e-invoice format.