German e-invoicing: from mandatory format to a dependable data pipeline

What has applied since 1 January 2025

The Federal Ministry of Finance defines the term narrowly: since 1 January 2025 an e-invoice exists only where the invoice is issued, transmitted, and received in a structured electronic format that permits electronic processing. An ordinary PDF has since then been an "other invoice".

The duty to receive already applies, and the ministry is clear that very little is needed to satisfy it: an email inbox is sufficient. It adds that the recipient is not obliged to carry out any electronic processing beyond what the retention rules already require.

That sets the most important distinction in this topic. The statutory minimum is an inbox and proper retention. Validation, ERP posting, and approval workflow are operational benefit, not legal obligation.

Evidence for this section1

Who has to issue, and from when

On the issuing side the transitional periods expire in stages. Until 31 December 2026 any issuer may still use other invoice types, although an electronic PDF requires the recipient to agree.

From 1 January 2027 the general exemption ends. One relief remains: where the issuer had prior-year turnover of up to 800,000 euro, the period runs to the end of 2027. Above that threshold, structured issuing is required from 2027.

From 1 January 2028 the duty applies in principle to all covered transactions. EDI procedures that are not already conformant may continue on a transitional basis until the end of 2027.

Evidence for this section12

The exemptions are substantial

The common claim that from 2028 every company must issue every invoice electronically is false. The scope carries statutory exemptions that matter a great deal in day-to-day operations.

• supplies to private consumers
• many exempt supplies under section 4 numbers 8 to 29 of the German VAT Act
• small-value invoices up to 250 euro gross
• travel tickets
• supplies by small businesses under the Kleinunternehmer rule

Evidence for this section1

Formats, and what they mean for the architecture

The ministry names the common formats explicitly: XRechnung and ZUGFeRD from version 2.0.1, excluding the MINIMUM and BASIC-WL profiles, meet the VAT requirements for an e-invoice.

One architectural principle follows. The structured part is the authoritative record, not the human-readable rendering shipped alongside it. Archiving the picture and discarding the data satisfies the duty on paper and throws the benefit away.

The ministry regards technical validation as sensible but not a direct precondition for input VAT deduction. It still belongs in any serious pipeline, because it exposes errors where they are still cheap to fix.

Evidence for this section1

An intake channel that does not swallow errors

The most common design fault is an inbox with no error path. An invoice that cannot be parsed must not disappear quietly. It belongs in a visible queue with a named owner.

Then come the requirements that turn up quickly in operation: malware scanning, duplicate detection, quarantine for unclear cases, and a traceable match to supplier and purchase order.

Evidence for this section13

Measure the effect before automating

Without baseline figures there is no way to show later whether the pipeline improved anything. Useful measures are cycle time from receipt to approval, the share of manual interventions, the error rate in matching, and discounts lost to late payment.

Published experience reports and vendor studies can serve as orientation, but they are not a forecast for your own organisation. Datenschaftler does not transfer such figures onto a client project and does not present them as its own results.

Evidence for this section3