E-Invoicing in Germany 2026: XRechnung, ZUGFeRD and the Deadlines to 2028

Since 1 January 2025, every company in Germany must be able to receive B2B e-invoices – with no transition period at all. For sending them, staggered deadlines run through to 2028. Yet one misconception persists: a PDF sent by email is not an e-invoice. This article explains, without hype, what makes a real e-invoice, how XRechnung and ZUGFeRD differ, who has to send when, and how to read, validate and archive the XML files in a compliant way.

What has applied since 2025 and what many miss

On 1 January 2025 the e-invoice became mandatory for domestic B2B business in Germany – but at first only on the receiving side. Every company that supplies or buys services from other businesses must since then be able to accept and process structured e-invoices. There was no grace period for this. In practice a mailbox that accepts the file is the minimum; you also need to be able to read and process it.

The second part of the obligation – sending – is staggered and runs through transition periods until the end of 2027. This split causes most of the confusion: even a business allowed to keep sending paper or PDF for years still has to accept incoming e-invoices today. Ignore that, and you risk your input VAT deduction if a supplier correctly issues an e-invoice that then gets lost in your inbox.

What an e-invoice really is

An e-invoice in the legal sense is an invoice issued, transmitted and received in a structured electronic format that allows automatic processing. The reference is the European norm EN 16931. It defines which data fields an invoice must contain and in what structure – from invoice number and delivery date through tax rates to bank details.

The reverse conclusion is what matters: a plain PDF, scanned paper or a photo of the invoice is not an e-invoice, no matter how tidy it looks. In legal terms such documents are called "other invoices." The reason is technical: a PDF is human-readable, but software cannot reliably read out amounts and line items from it without errors. Only the machine-readable XML structure turns an invoice into an e-invoice.

XRechnung and ZUGFeRD compared

Two formats have become established in Germany, both of which meet EN 16931. XRechnung is a pure XML file with no visual layer. It is the binding standard for invoices to public authorities (B2G) and is maintained by the Coordination Office for IT Standards (KoSIT). Open an XRechnung in an editor and you see only code – you need a visualization to look at it.

ZUGFeRD takes a more pragmatic route: it is a hybrid format. On the outside it is a PDF/A-3 that any person can read normally; embedded inside that PDF is an XML file with the structured data. A recipient can therefore either view the invoice as usual or process it automatically. For day-to-day B2B, ZUGFeRD is often the more convenient choice. Important: with ZUGFeRD the embedded XML part always counts legally, not the visible PDF.

Technically both formats use the same data basis. XRechnung comes in the UBL and UN/CEFACT CII syntaxes, ZUGFeRD relies on CII. As of July 2026 the current ZUGFeRD version is 2.4 (in force since 15 January 2026), and XRechnung 4.0 is announced for the second half of 2026, implementing the revised norm EN 16931-1:2026 – the first major overhaul of the data model since 2017.

The transition periods to 2028

Sending follows a phased plan. Until 31 December 2026 you may still send paper invoices for domestic B2B sales; a PDF or another non-conforming format is only allowed with the recipient's consent. This deadline applies to all businesses regardless of turnover.

Until 31 December 2027 this relief is extended for invoice issuers whose prior-year turnover (that is, 2026) does not exceed 800,000 euros. Smaller businesses get an extra year of breathing room. Anyone with more than 800,000 euros of turnover in 2026, by contrast, must actively send e-invoices from 1 January 2027.

From 1 January 2028 all transition rules end: every domestic B2B invoice must be issued as a structured e-invoice under EN 16931. If you have no solution by then, treat 2026 as a preparation year – not as a deadline to push to the last minute.

Who is exempt from the obligation

There are permanent exemptions from the obligation to issue. These include small-value invoices up to 250 euros gross, travel tickets, and invoices to end consumers (B2C) – so the private tradesman's bill to a homeowner stays free-form. Certain tax-exempt sales under section 4 of the German VAT Act (UStG) also fall outside the obligation.

Small businesses under section 19 UStG have been exempt since 2025 from having to issue e-invoices themselves. The important catch: the receiving obligation still applies. Even someone who never has to write an e-invoice must ensure that incoming e-invoices are accepted and retained. An exemption on issuing is not an exemption on receiving.

Creating e-invoices and handling payment

Creating them does not require expensive specialist software. Many accounting and invoicing programs generate XRechnung or ZUGFeRD at the click of a button; for occasional invoices there are free online generators and the official KoSIT-related tools. If you already use a point-of-sale or inventory system, first check whether an e-invoice export is already built in – that is the case more often than people think.

Just as important as the invoice itself is getting paid. Small businesses in particular benefit when customers can pay straight from the invoice instead of triggering bank transfers by hand. A payment provider like PayPal (Ad) can be tied to an invoice via a payment link or QR code, which noticeably shortens both the checkout and the later matching of incoming money – reducing open items and the effort spent on reminders. The structured e-invoice and the payment channel are two separate things, but in daily practice they interlock.

Reading and checking e-invoices

Because an e-invoice is at its core an XML file, you sometimes want to open it directly – for instance, in a dispute, to see which line items and tax rates are actually stored. In an XML editor you see the structure with its nested elements and can search specifically for fields such as the invoice total or the VAT identification number. For a ZUGFeRD file you first extract the embedded XML from the PDF.

Before sending, you should validate every e-invoice you generate yourself. KoSIT provides an official validator that checks whether all mandatory fields are present and the file conforms to EN 16931 and the XRechnung standard. There are also several free online checkers that verify XRechnung (UBL and CII) and all ZUGFeRD profiles in the browser. A formally faulty e-invoice can be rejected by the recipient and, in the worst case, endanger the input VAT deduction – so validation is not a luxury.

Archiving: what the GoBD require

E-invoices are subject to Germany's principles for proper bookkeeping (GoBD). In a letter dated 14 July 2025, the Federal Ministry of Finance clarified that the structured part – that is, the XML file – must be retained in its original format. It is precisely this XML part that is decisive for the input VAT deduction. A mere printout or screenshot is not enough: the file must remain unalterable, complete and machine-readable throughout the entire retention period.

With hybrid formats like ZUGFeRD, the embedded XML must not be lost. You only have to archive the human-readable PDF part in addition if it contains tax-relevant extra information not held in the XML – for example, differing details or posting notes. Simply tagging a file in a folder is not sufficient; what is required is audit-proof, unalterable storage.

On the retention period there is a relief many are not yet aware of: the Fourth Bureaucracy Relief Act shortened the retention period for accounting vouchers – which include invoices – from ten to eight years. This applies to all documents whose ten-year period had not yet expired on 1 January 2025. For other records such as annual financial statements, ten years still apply. When in doubt, and during ongoing audits, check the specific rule rather than deleting across the board.

Common mistakes in practice

The classic one is mixing up PDF and e-invoice: a nicely designed PDF will not meet the obligation from 2027 or 2028. Equally common is underestimating the receiving obligation – it has applied without exception since 2025, including for small businesses. A third mistake: saving only the PDF of a ZUGFeRD file and losing the embedded XML. That renders the invoice worthless for archiving purposes.

Further pitfalls are outdated format versions – since 2025 only the EN 16931 (Comfort) and Extended profiles are permitted for ZUGFeRD, older minimal profiles no longer – and missing validation before sending. Keep these points in view and use 2026 as a test phase, and you can approach the remaining deadlines calmly instead of having to switch at the last moment.

How tools on CalcSI help

When you want to open an e-invoice and understand its structure, the XML editor helps: with it you can see the nested fields of an XRechnung or of the XML extracted from ZUGFeRD, and find amounts, tax rates and identifiers directly. With the VAT calculator you quickly check whether net, tax and gross add up cleanly in a line item. If you export invoice data from another system, use CSV to JSON to turn it into a structured format for further processing. And for a payment link or transfer reference on the invoice, the QR code generator produces a scannable code in seconds. That way you get the technical side of e-invoicing under control without having to buy a whole software suite.