XRechnung, ZUGFeRD and Peppol: German e-invoice formats compared

What makes an invoice an e-invoice?

Since 1 January 2025, § 14 UStG distinguishes between the e-invoice (E-Rechnung) and the “other invoice” (sonstige Rechnung). An e-invoice is an invoice that is issued, transmitted and received in a structured electronic format and enables electronic processing. The format must comply with the European standard EN 16931 – or another format agreed between issuer and recipient, provided it delivers the data just as correctly and completely.

What counts is the data record, not the appearance. A PDF, a scan or a photo is an “other invoice”, even if it arrives by email. When you must receive and send e-invoices is covered in the guide on the e-invoicing obligation 2025 to 2028; this guide is about the formats themselves.

EN 16931 defines a semantic data model with business terms numbered “BT” (Business Term) and “BG” (Business Group), for example BT-1 invoice number, BT-2 invoice date or BT-10 buyer reference. For this model the standard allows two technical notations (syntaxes): UBL 2.1 and UN/CEFACT CII. All formats common in Germany build on this.

XRechnung: the German standard (UBL or CII)

XRechnung is the German specification (CIUS) of EN 16931, maintained by the Coordination Office for IT Standards (KoSIT). It is a pure XML file without a visual representation: to read it you need a program or a viewer. In terms of content it is stricter than the standard. Additional German business rules (BR-DE) require, among other things, the buyer reference (BT-10), a seller contact with name, phone and email (BG-6) and payment details.

An XRechnung can be written in UBL or in CII – both are equivalent and the recipient must be able to process both. The current version is 3.0.x; with XRechnung 4.0 the KoSIT is preparing a version based on the revised EN 16931. You should no longer use older versions below 3.0.

For whom? XRechnung is mandatory for invoices to federal authorities and to most state and municipal authorities. Large companies increasingly require it too, because it can be imported directly into their accounting system.

ZUGFeRD and Factur-X: PDF and XML in one file

ZUGFeRD is a hybrid format of the Forum elektronische Rechnung Deutschland (FeRD): a PDF/A-3 with the invoice data embedded as CII XML. People read the PDF, programs read the XML data. Factur-X is the technically identical French name – a ZUGFeRD file from version 2.1 is also Factur-X.

For tax purposes, the XML file is always decisive with ZUGFeRD. If the PDF and XML differ, the structured part applies. So make sure your program generates both from the same data and that the PDF is never edited afterwards on its own.

ZUGFeRD has several profiles with different numbers of data fields. Not every profile meets the requirements of an e-invoice:

XRechnung or ZUGFeRD – which format for whom?

From 2027/2028 both formats fulfil the obligation to send e-invoices between businesses. The choice depends mainly on the recipient. As a simple rule of thumb: authority → XRechnung; company with its own e-invoice processing → the format it requires; small business without special software → ZUGFeRD in the EN 16931 profile, because it is also a normal PDF.

Invoices to public authorities: Leitweg-ID and portals

Since 27 November 2020 all suppliers to the federal government must submit their invoices as e-invoices (E-Rechnungsverordnung des Bundes); only direct orders up to €1,000 net are exempt. The federal states have their own regulations, some with different thresholds and deadlines – if in doubt, ask the contracting authority.

Every public body has a Leitweg-ID. It controls which authority the invoice reaches and is structured as follows: coarse address (e.g. 991 for the federal government), fine address and a two-digit check digit, such as “991-12345-67”. You enter the Leitweg-ID in the buyer reference field (BT-10). If it is missing or wrong, the invoice is usually rejected automatically and is deemed not received – the payment period then does not start.

Transmission takes place via the administration’s invoice receipt platforms: at federal level the ZRE and OZG-RE platforms, in the states their own portals. There you can upload a finished XRechnung, send it to the platform by email, send it via Peppol or, on some portals, enter an invoice directly in the web form. For upload and web form you need a user account on the platform.

Peppol: a network, not a format

Peppol (Pan-European Public Procurement Online) is a network for the secure exchange of business documents. Sender and recipient are not connected directly but via certified access points of their service providers – similar to the telephone network. Every participant has a Peppol ID; for German authorities this is usually the Leitweg-ID with the prefix 0204.

Peppol transports invoices in the Peppol BIS Billing 3.0 (UBL) format or as XRechnung. For you as a self-employed person: Peppol is not mandatory in Germany. You only need it if a client expressly requires it or if you send a very large number of invoices automatically. In other EU countries, such as Belgium, Peppol is already the standard transmission network for B2B invoices.

Transmission channels compared

The German VAT Act (Umsatzsteuergesetz) does not prescribe a specific transmission channel. What matters is that the structured file reaches the recipient unchanged. In practice, the recipient decides whether a channel is “good”:

Validating e-invoices

An e-invoice can be formally faulty even though it looks fine. Validation takes place in two stages: first against the XML schema (is the file technically structured correctly?), second against the business rules (Schematron) of EN 16931 and, where applicable, XRechnung (are totals, tax rates and mandatory fields correct?). The KoSIT provides a freely available validator for this, which most programs also use.

Common errors and their causes:

• BR-DE-15: buyer reference (BT-10) missing – for authorities the Leitweg-ID, for companies an order or customer number if necessary.
• BR-DE-2: seller contact (BG-6) with name, phone and email missing.
• BR-CO-15: invoice total does not match net amount plus tax – often due to rounding per line instead of per tax rate.
• Wrong tax category code: for reverse charge the file needs “AE”, for tax-exempt intra-Community supplies “K”, for small businesses (Kleinunternehmer) “E” with an exemption reason. More in the guide on the reverse charge procedure.
• Wrong invoice type code (BT-3): 380 for an invoice, 381 for an invoice correction (credit note), 384 for a corrected invoice, 326 for a partial invoice.

Received e-invoices: reading and archiving

Since 2025 you must be able to receive e-invoices – also as a small business (Kleinunternehmer). An email inbox is enough, but you need a program that displays the XML in readable form. For the input VAT deduction the invoice must contain all mandatory details; the XML part is decisive, not an accompanying PDF.

You must keep the e-invoice in its original format, i.e. the XML file or the ZUGFeRD PDF with embedded XML, unalterable and machine-readable. A printout is not enough. The guide on GoBD-compliant archiving explains the periods and rules.

E-invoice formats with KontoVexa

KontoVexa issues your sales invoices as ZUGFeRD in the EN 16931 profile, as XRechnung in CII or in UBL – you set the default format once and can change it per customer and per invoice. You enter the Leitweg-ID on the customer or in the invoice as the buyer reference, and the seller contact (BG-6) in the settings. Before issuing, KontoVexa validates the file with “Check E-Rechnung” against the official rules. Sending is by email; KontoVexa does not currently offer sending via Peppol.

You send incoming XRechnung and ZUGFeRD invoices to your personal inbox address or upload them. KontoVexa displays them in readable form, transfers the amounts into your bookkeeping and archives the original unalterably for ten years. More on the page e-invoicing with KontoVexa; everything on mandatory details is in the guide writing invoices.

Frequently asked questions