What is an E-Rechnung? The definition that changed in 2025

Since the Wachstumschancengesetz took effect, § 14 Abs. 1 UStG defines an elektronische Rechnung as an invoice that is issued, transmitted, and received in a structured electronic format and that enables electronic processing. The format must either conform to the European norm EN 16931 or be agreed between the parties and allow correct and complete extraction of the required data into a format interoperable with that norm.

Everything that does not meet this bar is a sonstige Rechnung: paper invoices, and also every electronic invoice in a non-qualifying format. The law deliberately puts an emailed PDF in the same legal category as paper. A PDF is digital, but it is a picture of an invoice, not a data record; software cannot reliably book it without a human or an extraction layer reading it first.

EN 16931 is the European norm behind all qualifying formats. It defines the semantic data model of an invoice: a catalogue of named fields called Business Terms (BT), from BT-1, the invoice number, through seller and buyer identification, line items, VAT breakdown, and payment terms, together with the business rules that connect them, for example that totals must add up. Syntaxes like UBL and UN/CEFACT CII carry this model as XML.

This is why "which format?" matters less than it first appears: XRechnung, qualifying ZUGFeRD profiles, and Peppol BIS Billing all express the same EN 16931 semantics. A system that understands the Business Terms once can process all of them. Our Peppol e-invoice extraction guide walks through the field model in detail.

Hybrid formats like ZUGFeRD contain two representations of the same invoice: a human-readable PDF layer and an embedded XML data record. Before the reform, German practice treated the visible PDF as authoritative. That has flipped: per the BMF letter of October 15, 2025, the structured XML part is now the legally decisive representation, and the visible layer is subordinate. If the two ever disagree, the data record wins, which is one more reason your process must actually read the XML rather than filing the pretty PDF.

The same BMF letter sorts invoice errors into three classes: Formatfehler (the file violates EN 16931 syntax, so it is not an e-invoice at all), Geschäftsregelfehler (the file violates the norm’s business rules, for example inconsistent totals), and Inhaltsfehler (formally valid but wrong content, such as an incorrect VAT rate). The classes have different consequences, and validation software checks the first two automatically.

Since January 1, 2025 every domestic business must be able to receive e-invoices for domestic B2B transactions; the supplier no longer needs your consent to send one. The BMF keeps the entry bar low, an email inbox suffices, but receiving is the easy half. The invoice then has to be read, validated, matched, booked, and archived for eight years with its structured part unaltered.

Realistically, accounts payable will handle a mixed inflow for years: structured e-invoices from large partners, PDFs and paper from the long tail during the transition. Processing both classes into the same validated output schema, rather than running two parallel processes, is the pragmatic goal. That is exactly the job of schema-validated invoice parsing: XRechnung XML, ZUGFeRD hybrids, Peppol invoices, and scans all resolve into one set of typed fields with confidence scores and provenance.

Reading about formats is one thing; an accounts-payable inbox full of them is another. Two free resources and one production path:

• Peppol e-Invoice Extractor: pull the seller, buyer, line items, VAT breakdown, and totals out of an e-invoice, free in the browser
• Peppol e-invoice extraction guide: the EN 16931 field model (Business Terms) explained field by field
• Invoice parsing with schema validation: process XRechnung, ZUGFeRD, Peppol invoices, PDFs, and paper scans into one validated output schema, with confidence and provenance on every value