What Is an E-Invoice? Definition, Formats and the German Rules

An e-invoice in Germany is an invoice issued, transmitted and received in a structured electronic format that allows electronic processing, as defined in Section 14 of the German VAT Act (§ 14 UStG). The format must follow the European standard EN 16931, such as XRechnung or ZUGFeRD, or be agreed between the parties. A PDF alone is not an e-invoice.

This matters to anyone who invoices German businesses, including foreign suppliers and English-speaking founders. The definition has applied since 1 January 2025. Below you will find a classification table for common invoice files, a field-level example, and a five-question test you can apply to any file in your inbox.

The definition in one sentence

German law uses the term "electronic invoice" (elektronische Rechnung). The core sentence in § 14(1) UStG (opens in a new tab) reads, in translation:

An electronic invoice is an invoice that is issued, transmitted and received in a structured electronic format and allows electronic processing.

A short version you can quote: an e-invoice is a machine-readable invoice data set whose format complies with EN 16931 or has been agreed between supplier and customer.

Everything else is an "other invoice" (sonstige Rechnung) under § 14(1) sentence 4 UStG: paper, or any other electronic format. This is a change of meaning. Until the end of 2024, any invoice sent electronically, including a PDF by email, counted as an electronic invoice in Germany. Since 2025, the PDF is an other invoice.

What are the four elements of the definition?

All four must be present. If one is missing, the file is not an e-invoice.

The Federal Ministry of Finance (Bundesministerium der Finanzen, BMF) interpreted these elements in its letter of 15 October 2025, which amends section 14.1(2) of the VAT Application Decree (Umsatzsteuer-Anwendungserlass, UStAE). Two points from it are practical:

• "PDF files without integrated data sets, image files or details in emails" are explicitly other invoices.
• An XML file with format errors is not an e-invoice. It counts as an other invoice in another electronic format.

Section 14.5(1) UStAE adds that all mandatory VAT details under §§ 14 and 14a UStG must be in the structured part. A reference to an attached PDF that contains them is not enough.

Which e-invoice formats does Germany accept?

The law does not prescribe one format. EN 16931 defines a semantic data model and two permitted syntaxes, UBL and UN/CEFACT CII. The formats used in Germany build on it:

• XRechnung: a pure XML format that the Coordination Office for IT Standards (KoSIT) specifies for Germany on the basis of EN 16931. The current version is 3.0.2; according to xeinkauf.de, XRechnung 3.0 stays in force until at least 31 July 2027. See what is XRechnung for the structure.
• ZUGFeRD: a hybrid format that embeds a CII XML file in a PDF/A-3. Accepted from version 2.0.1, except the MINIMUM and BASIC WL profiles. The current version is ZUGFeRD 2.5.2, technically identical to Factur-X 1.09.2. Details are in what is ZUGFeRD.
• Other EN 16931 formats: section 14.1(12) UStAE allows further European formats as long as they comply with the standard.
• EDI and other agreed formats: allowed if the VAT details can be extracted correctly and completely into an EN 16931 compliant or interoperable format (section 14.1(15) UStAE).

Which accepted format two companies use is a matter of civil law between them, according to section 14.1(12) UStAE.

Hybrid files: which part counts?

A hybrid format combines a structured part (XML) and a visual part (PDF) in one file. Under section 14.4(3) UStAE, the structured data is the leading part. If PDF and XML differ, the XML prevails, and input VAT deduction (Vorsteuerabzug) is possible only from the structured part (section 14.4(4a) UStAE). Accounts payable teams should therefore look at the XML content, not only at the PDF page.

Example: one supply, six invoice files

Muster GmbH bills Beispiel AG for consulting in October 2026: EUR 4,000 net plus 19 % VAT, EUR 4,760 gross, invoice number RE-2026-0042. Both companies are established in Germany. This is how German VAT law classifies each possible file:

For a supply in 2028, only the e-invoice rows would remain. The Germany e-invoicing 2027 guide explains when the transition ends for your company, including the EUR 800,000 turnover threshold.

If Muster GmbH were a UK company billing Beispiel AG, the German obligation would not apply, because both parties must be established in Germany (section 14.1(6) UStAE). The classification would stay the same, though: the XRechnung would still be an e-invoice, and the PDF an other invoice that needs consent.

Inside the XRechnung, each detail has its own field. An abridged excerpt from the UBL header of the example invoice:

<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID>
<cbc:ID>RE-2026-0042</cbc:ID>
<cbc:IssueDate>2026-10-15</cbc:IssueDate>
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>

CustomizationID (BT-24) tells the receiving system which specification the file follows. cbc:ID is the invoice number (BT-1) and cbc:IssueDate the invoice date (BT-2). This field mapping is what "electronic processing" means in practice: the accounting system reads values from known fields instead of guessing them with text recognition.

Five-question test: is this file an e-invoice?

Answer the questions in order. A "no" ends the test.

1. Is there a structured data set? You need an XML file or an EDI message. For a PDF, check whether an XML file is embedded. If not, it is an other invoice.
2. Does the format follow EN 16931, or was it agreed? XRechnung and ZUGFeRD 2.0.1 or later (except MINIMUM and BASIC WL) comply. An EDI format needs an agreement and must allow complete extraction of the VAT details.
3. Is the file free of format errors? Does it match the schema of its syntax? A format error makes it an other invoice under section 14.1(2) UStAE.
4. Are all mandatory VAT details in the structured part? Tax number or VAT ID, supply date or period, VAT rate and VAT amount must sit in data fields, not only in an attached PDF.
5. Did the data arrive in structured form? Was the invoice transmitted and received electronically? A printout that someone scans and forwards is not an e-invoice for the recipient.

Five times "yes" means you have an e-invoice. Whether it is also correct in content, with the right amounts, rates and details, is a separate question. Section 14.5(1) UStAE notes that a wrong VAT rate can exist even when validation reports no error.

How does an e-invoice differ from related terms?

The full timeline for other invoices and EDI is in the overview of the Germany e-invoicing mandate. For further articles, see the e-invoicing mandate guides.

Does a person need to be able to read an e-invoice?

Not directly. Section 14.4(3) UStAE states that machine readability is enough for an e-invoice. An additional PDF is not required, because a visualisation application can display the data set for humans. For archiving, the structured part must be kept in its original format; see e-invoice archiving in Germany.

How to check an invoice file with docutools.pro

Questions 1 to 3 of the test can be answered with our tools.

1. For a ZUGFeRD PDF, open the PDF XML extractor and click "Choose PDF". If the tool finds embedded XML, you see the "Invoice summary" and the "XML source" tab. If it finds none, a notice appears: the file is an ordinary PDF without structured invoice data. The extractor runs in your browser, so the file does not leave your computer. It does not check the profile or PDF/A.
2. Click "Download XML" to save the structured part as a separate file.
3. Upload that file in the XRechnung validator. The file is sent to our server for the check. The "KoSIT validation" checks the way the KoSIT validator does (configuration 2026-08-31): first the XML schema, then the business rules. The result reads "KoSIT-conformant / Valid XRechnung" or "Not KoSIT-conformant", followed by the rules that fired.
4. Read the result. A schema error points to a format error, which means an other invoice. A business-rule error does not automatically mean the file is not an e-invoice. The guide to the KoSIT validator explains what each stage checks.
5. If your invoicing software cannot export e-invoices, use our ZUGFeRD invoice generator to create "XRechnung XML", "ZUGFeRD XML" or "ZUGFeRD PDF" files.

The free viewer allows 2 uploads per day of up to 500 KB each. More uploads and larger files are part of the Pro plan. The viewer reads XML only, not PDF files, so extract the XML from a ZUGFeRD PDF first.

A passed check shows that format and business rules are correct. No software can confirm for you that the VAT rate and the description of the supply are factually right.

Sources

• § 14 UStG, issuing invoices (gesetze-im-internet.de, German) (opens in a new tab)
• BMF letter of 15 October 2025 on mandatory e-invoicing (German) (opens in a new tab), sections 14.1, 14.4 and 14.5 UStAE
• Directive 2014/55/EU on electronic invoicing in public procurement (EUR-Lex) (opens in a new tab)
• XRechnung at XStandards Einkauf (xeinkauf.de) (opens in a new tab)

Last reviewed: October 2026

This article is general information, not tax or legal advice.