E-invoicing in Germany: what finance teams must do by 2027 and 2028

E-invoicing in Germany is now law for business-to-business sales. Since 1 January 2025, every business established in Germany must be able to receive an e-invoice: a structured file that follows the European standard EN 16931, such as XRechnung or ZUGFeRD. Issuing follows in two steps. From 1 January 2027 it is mandatory for businesses whose total turnover in the previous year exceeded €800,000, and from 1 January 2028 for everyone else. Until then, paper and PDF invoices remain allowed under transition rules. Invoices up to €250, tickets, Kleinunternehmer and sales to consumers are carved out.

The rules come from the Wachstumschancengesetz of 27 March 2024, which rewrote § 14 UStG for supplies after 31 December 2024 and set the transition periods in § 27(38) UStG. The tax authorities' reading is in two BMF letters, of 15 October 2024 and 15 October 2025; the second added rules on format errors, corrections and archiving. Below is what they mean for finance teams as of October 2026.

#Who must receive e-invoices since 1 January 2025

Every business established in Germany: companies, partnerships, freelancers, landlords, doctors, associations acting as businesses and Kleinunternehmer. There is no transition period and no exception for receiving. Established means a registered office, place of management or a fixed establishment involved in the supply in Germany.

The bar is low: the BMF says an ordinary e-mail inbox is enough. Peppol is not required: the law prescribes no channel, so e-mail, an API, a supplier portal download or a shared group server all work. What you cannot do is refuse. A business that cannot accept an e-invoice has no right to demand a paper or PDF version, and the supplier has met its duty if it can show it tried to deliver, for example with a send log.

Receiving a file is not the same as being able to read it. An XRechnung is pure XML with no PDF inside, so approvers need a viewer. The free one at e-rechnung.elster.de suits the odd invoice, not a purchase ledger.

#When you must issue e-invoices: 2025, 2027 and 2028

Issuing is phased by § 27(38) UStG. The test is the issuing business's total turnover (Gesamtumsatz) in the previous calendar year, and each relief covers supplies made in a given year and invoices issued by the end of that year.

A hypothetical example: a wholesaler with €3.2 million turnover in 2026 must issue e-invoices for every domestic B2B supply made from 1 January 2027. A design studio with €640,000 in 2026 may keep sending paper, or PDFs where the customer agrees, until 31 December 2027, although large customers may ask it to switch earlier for commercial reasons. Both have had to be able to receive e-invoices since January 2025.

None of these dates has moved since 2024: the BMF's FAQ, last revised in March 2026, confirms them. Further ahead, Council Directive (EU) 2025/516 (ViDA) brings digital reporting for intra-EU B2B supplies from 1 July 2030. The BMF says a German reporting system will follow, but no bill has been published.

#What counts as an e-invoice: EN 16931, XRechnung, ZUGFeRD and PDF

The law now knows only two kinds of invoice. An e-invoice is issued, transmitted and received in a structured format that allows electronic processing. Everything else is a “sonstige Rechnung”:

An e-invoice must follow EN 16931, the European standard for the data model of an invoice, or an EDI format agreed between the parties that allows correct and complete extraction of all VAT data. EN 16931 can be expressed in two XML syntaxes, UBL and UN/CEFACT CII. In practice German finance teams meet four kinds of document:

Two BMF rules matter more than the format debate. First, in a hybrid invoice the XML is leading. Before 2025 the picture prevailed; now, if the PDF and the XML differ, the structured data counts, and input VAT can only be deducted from the structured part. Approving an invoice by looking at the PDF while posting from the XML is no longer a safe process.

Second, all mandatory VAT details must be in the structured part. A reference to an attachment does not count, and a link to an external file is never enough. Supplementary detail, such as a timesheet breakdown, may travel as an attachment inside the e-invoice. For construction invoices the BMF currently accepts the trades with their totals in the XML and the detailed bill of quantities in an attached document, provided the XML clearly refers to it.

#Exceptions: small amounts, tickets, Kleinunternehmer and more

The mandate only applies where VAT law requires an invoice between two businesses established in Germany. Even then, a sonstige Rechnung remains permanently allowed for:

• Small-amount invoices with a gross total of up to €250 (§ 33 UStDV). The test is the invoice total, not individual lines.
• Tickets for passenger transport that count as invoices (§ 34 UStDV).
• Invoices from Kleinunternehmer under § 19 UStG (§ 34a UStDV). A Kleinunternehmer who moves to standard VAT must issue e-invoices from that date, and every Kleinunternehmer must still be able to receive them.
• Supplies to non-business legal persons, such as many associations and public bodies acting in a sovereign capacity, and to private consumers.
• Most tax-exempt supplies under § 4 Nr. 8 to 29 UStG, such as financial services and residential lettings, where no invoice is required in the first place. If one invoice mixes exempt and taxable items, the e-invoice rules apply to the whole document.
• Cross-border supplies, where the supplier or the customer is not established in Germany. A foreign company registered for German VAT without a fixed establishment here does not have to issue e-invoices.

Some things people expect to be exempt are not. Cash purchases have no special rule: a business lunch or a builders' merchant receipt above €250 needs an e-invoice once the transition ends, and the BMF suggests issuing a receipt on the spot and correcting it later with an e-invoice sent by e-mail. Self-billing (Gutschriften) and reverse-charge supplies under § 13b UStG are covered too. Invoices to public authorities follow a separate regime, the E-Rechnungsverordnung, with its own threshold (€1,000 at federal level).

#Errors, input VAT and archiving

The October 2025 BMF letter introduced distinctions that belong in every approval workflow:

• Format errors: the file breaks the syntax, or an agreed EDI format does not allow complete extraction. The document is then not an e-invoice at all but a sonstige Rechnung, which only works while a transition rule or an exception applies.
• Business rule errors: the XML is valid but fails the format's logic checks, for example a missing mandatory field or a VAT amount that does not match the rate. If a mandatory VAT detail under §§ 14 and 14a UStG is affected, the invoice is not proper. Errors in other fields, such as a missing BT-10, are irrelevant for VAT.
• Content errors without a validation error, such as the wrong VAT rate, still make the invoice improper. Validation supports your duty to check an invoice; it does not replace it.

The consequence becomes sharp once the transitions end. Where an e-invoice is mandatory, a PDF or paper invoice is not a proper invoice and, in principle, does not entitle you to deduct input VAT (section 15.2a(1) UStAE as amended). The recipient can repair this with a corrected e-invoice that refers specifically to the original, and the UStAE allows the conditions for deduction to be proven by other means.

You may rely on the result of a suitable validation tool for format and business rules if you act with ordinary commercial care, and the BMF recommends keeping the validation report. For archiving, § 14b UStG requires you to keep every incoming and outgoing invoice for eight years, and for an e-invoice at least the structured part must be stored unaltered in its original form. A printout is not enough. The GoBD, the BMF's bookkeeping principles last amended on 14 July 2025, apply on top.

#What it means for DATEV and SAP users

DATEV. Most German SMEs and their tax advisers work with DATEV. Its E-Rechnungsplattform provides an e-invoice inbox that receives via the TRAFFIQX network and Peppol, displays XRechnung and ZUGFeRD data, and archives invoices in Belege online (DATEV Unternehmen online). The harder question is usually who does what: agree whether invoices are validated and coded in-house or by the tax adviser, who checks the XML against the order, and which system holds the archive copy.

SAP. In SAP S/4HANA and SAP ERP, the German mandate is handled through SAP Document and Reporting Compliance (DRC), which creates outbound e-invoices from billing documents and sends them by e-mail or Peppol. Inbound, SAP documents a process for e-invoices received by e-mail: they are validated in the eDocument Cockpit and handed to an incoming automation solution; reception via Peppol is also possible. Availability depends on edition, release and SAP Notes, so confirm it with your SAP team.

Whatever the system, the usual failure points are master data rather than software: missing VAT IDs, no agreed address for invoice receipt, order references that suppliers cannot fill in, and customers who expect a specific BT-10 value.

#Turning the mandate into an automation project

The mandate's real value sits on the receiving side. Every e-invoice arrives as machine-readable data: supplier, VAT ID, line items, order reference, amounts and bank details, with no OCR guesswork. The BMF names exactly this as the purpose of the reform: invoice data no longer has to be keyed in again. A sound pipeline has six stages:

1. Intake. One address or access point for all supplier invoices. Separate e-invoices, PDFs and paper from day one, because they follow different legal and processing paths until 2028.
2. Validation. Run every file through an EN 16931 validator (KoSIT publishes an open-source one) and store the report. Send format errors back to the supplier automatically with a clear reason.
3. Rendering from the XML. Show approvers a view generated from the structured data, never the embedded PDF, because the XML is what counts.
4. Matching. Match header and lines against purchase orders and goods receipts, or against contracts and recurring patterns for spend without an order. Structured line data makes tolerances and partial deliveries manageable.
5. Coding and posting. Derive the general ledger account, cost centre and tax code from supplier, order and history, and post to DATEV or SAP through their interfaces. Exceptions go to a person; everything else flows through.
6. Archive and audit trail. Store the original XML, the validation report and the approval log together for eight years.

A hypothetical example shows the scale. A company receiving 800 supplier invoices a month that spends, say, six minutes on keying, checking and coding each one spends 80 hours a month on data entry. If most arrive as e-invoices by 2028 and two thirds post without manual touch, the effort shrinks to genuine exceptions. Your numbers will differ, so measure your current minutes per invoice before you set a target.

AI has a narrower place than vendors suggest. Structured data removes the need to read invoices; language models help with the long tail, such as coding invoices without an order from free-text descriptions and handling the PDFs that stay legal until 2028. Keep VAT-relevant decisions rule-based and auditable.

#E-invoicing readiness checklist

#How we can help

Bespoke IT builds invoice intake, validation and matching pipelines that sit on top of DATEV and SAP rather than replacing them, so structured e-invoices are checked, matched and posted while people handle the exceptions. If you want to map your current process and see what can be automated before January 2027, start with our process automation page. For the tax side, involve your tax adviser: this article explains the rules but cannot assess your specific case.