FAQ: Frequently Asked Questions about E-Invoicing

Answers on mandates, formats, Austria and technical use – based exclusively on publicly available sources.

General understanding

What is an e-invoice – and what is it not?
An e-invoice in the EU sense is an invoice issued, transmitted and received in a structured electronic format that enables automatic electronic processing (Directive 2014/55/EU). The decisive factor is machine-readability – not electronic transmission. A PDF sent by email is therefore not an e-invoice. In Germany, the Growth Opportunities Act (§14 UStG) stipulates: an invoice is only an e-invoice if it is structured and EN-16931-compliant. Everything else is called a "sonstige Rechnung" (other invoice).
Why is a PDF not an e-invoice?
A PDF sent by email is not a structured document in the EU sense: the invoice data exists as a visual layout rather than in defined machine-readable fields. OCR can only reconstruct data heuristically and with errors. An e-invoice is an XML document in which every data point is assigned to a defined Business Term (BT-*). Hybrid formats such as ZUGFeRD and Factur-X are valid e-invoices because the embedded XML is the legally authoritative document – not the visible PDF.
What is EN 16931?
EN 16931 is the European standard for the core data model of an electronic invoice (CEN/TC 434). EN 16931-1 defines the syntax-neutral semantic data model with Business Terms (BT-*) and Business Groups (BG-*). Syntax bindings (CEN/TS 16931-3-x) specify the implementation in UBL 2.1 (Peppol syntax) and UN/CEFACT CII (ZUGFeRD/Factur-X syntax). National specifications such as XRechnung and Peppol BIS Billing 3.0 are CIUS restrictions on EN 16931.
What is the difference between CIUS and Extension?
A CIUS (Core Invoice Usage Specification) only restricts EN 16931: optional fields become mandatory, code lists are narrowed, additional Schematron rules are added. A CIUS-compliant invoice is always also EN-16931-compliant – any receiver that can handle the Core can handle any CIUS. An Extension expands the model with fields not present in the Core; an Extension invoice is therefore not necessarily compatible with pure EN-16931 receivers. Examples of CIUS: XRechnung, Peppol BIS 3.0. Example of Extension: ZUGFeRD EXTENDED.
What is ViDA?
ViDA (VAT in the Digital Age) is an EU legislative package – comprising Directive (EU) 2025/516, Regulation (EU) 2025/517 and Implementing Regulation (EU) 2025/518 – in force since 14 April 2025. It requires member states to introduce structured e-invoices and near-real-time reporting (Digital Reporting Requirements, DRR) for intra-EU B2B transactions – mandatory from 1 July 2030. Since April 2025, member states may also introduce national B2B mandates without a separate EU authorisation.
What is the difference between e-invoicing, e-reporting and e-archiving?
E-invoicing covers the creation, transmission and receipt of structured e-invoices between trading partners. E-reporting covers the transmission of transaction or VAT data to the tax authority, not to the trading partner (e.g. France for B2C and cross-border B2B, Spain SII). E-archiving covers tamper-proof long-term retention with requirements for immutability, legibility and integrity. These three obligations are legally separate and may apply independently.

Germany's e-invoicing mandate

From when does the e-invoicing mandate apply in Germany?
The Growth Opportunities Act (published 27 March 2024, BGBl. I 2024 Nr. 108) amended §14 UStG and introduced a phased B2B mandate. From 1 Jan 2025: receiving obligation for all domestic companies. From 1 Jan 2027: issuing obligation for companies with prior-year turnover above €800,000. From 1 Jan 2028: issuing obligation for all domestic B2B transactions (§27 para. 38 UStG).
What does the receiving obligation from 1 Jan 2025 mean?
Since 1 Jan 2025, all domestic companies must be able to receive EN-16931-compliant e-invoices without requiring recipient consent. There is no obligation to issue e-invoices at this stage; the obligation concerns receipt only. Accepted formats include XRechnung, ZUGFeRD (from COMFORT profile), Factur-X and Peppol BIS 3.0.
From when do I have to issue e-invoices?
Companies with prior-year turnover above €800,000 must issue e-invoices for domestic B2B transactions from 1 Jan 2027. For all other companies, the issuing obligation applies from 1 Jan 2028. Until end of 2026, paper and PDF invoices ("sonstige Rechnungen") remain permissible with the recipient's consent (§27 para. 38 UStG).
Does the e-invoicing mandate also apply to small businesses (§19 UStG)?
Small businesses (Kleinunternehmer) are exempt from the issuing obligation but must be able to receive e-invoices since 1 Jan 2025. Supplies by or to small businesses are also exempt from the issuing obligation (§19 UStG). The receiving obligation applies regardless of turnover.
What applies to low-value invoices under €250?
Low-value invoices up to €250 gross (§33 UStDV) and transport tickets (§34 UStDV) are exempt from the e-invoicing mandate. For these invoices, issuing as a sonstige Rechnung (paper, PDF) remains permissible.
Which formats are valid e-invoices in Germany?
All EN-16931-compliant formats are valid: XRechnung (UBL 2.1 or CII), ZUGFeRD from version 2.0.1 with at least BASIC profile (EN 16931/COMFORT recommended), Factur-X (technically identical to ZUGFeRD) and Peppol BIS Billing 3.0. ZUGFeRD 1.0 is not EN-16931-compliant and therefore not valid. The MINIMUM and BASIC WL profiles do not meet the requirements for a complete invoice under the UStG.
What applies to EDI users after 2028?
EDI remains permissible after 2028 provided that a legally compliant reporting data record can be extracted from the EDI invoice. The EDI format itself does not need to conform directly to EN 16931, as long as the substantive EN 16931 requirements are met.

Austria

Is there a B2B e-invoicing mandate in Austria?
No. As of May 2026, Austria has no national B2B mandate for e-invoices. PDF and paper remain permissible in B2B. A B2B obligation for intra-EU transactions is expected via ViDA (from 1 July 2030). No standalone national Austrian B2B mandate has been enacted.
Which formats does the Austrian federal administration accept?
The Austrian federal administration accepts exclusively ebInterface (versions 4.3, 5.0, 6.0, 6.1) and Peppol BIS 3.0. XRechnung and ZUGFeRD are not accepted by Austrian federal agencies. Legal basis: IKT-Konsolidierungsgesetz §5 and BVergG 2018 §368.
How do I submit an e-invoice to Austrian authorities?
E-invoices to the Austrian federal administration can be submitted via three channels: the Unternehmensserviceportal USP (usp.gv.at) using the "E-Rechnung an den Bund" application, via e-Rechnung.gv.at, or through a Peppol Access Point (AS4 transport, Peppol BIS 3.0). The B2G obligation has applied since 1 Jan 2014 (federal level) and since 18 April 2020 also to foreign suppliers.
How long must e-invoices be retained in Austria?
In Austria, BAO §132 requires retention of generally 7 years from the end of the calendar year of the last entry. Storage on data media is permissible provided that complete, faithful reproduction is guaranteed at all times. German GoBD does not apply in Austria.

Formats in detail

What is the difference between ZUGFeRD and XRechnung?
ZUGFeRD is a hybrid format: a PDF/A-3 file with embedded CII XML. The PDF is human-readable, the XML is the legally authoritative structured invoice. XRechnung is a pure XML format with no PDF layer, available in UBL 2.1 or CII. Both are CIUS specifications on EN 16931; XRechnung has additional German mandatory rules (BR-DE-*): mandatory IBAN for credit transfer, mandatory contact details, Leitweg-ID (BT-10) for B2G.
What is the difference between ZUGFeRD and Factur-X?
ZUGFeRD and Factur-X are technically identical: both use PDF/A-3 with embedded UN/CEFACT CII XML and share the same profiles and version levels. ZUGFeRD is maintained by FeRD (Forum elektronische Rechnung Deutschland), Factur-X by FNFE-MPE (France). Both are fully interoperable.
What ZUGFeRD profiles exist and which one do I need?
There are five core profiles in ascending scope: MINIMUM, BASIC WL (without lines), BASIC, EN 16931 (COMFORT) and EXTENDED, plus the reference profile XRECHNUNG. At least BASIC is required for a valid invoice under the UStG. For Germany's B2B mandate, EN 16931 (COMFORT) or higher is recommended. MINIMUM and BASIC WL are not complete invoices according to the BMF.
Why are MINIMUM and BASIC WL not valid e-invoices?
The MINIMUM profile contains only header and totals data; the BASIC WL profile contains no invoice lines. Both are, according to the German BMF, not complete VAT invoices and must not be used as statutory e-invoices in the B2B mandate context. They can serve as internal booking aids or workflow triggers but do not replace a complete invoice.
What is ZUGFeRD 1.0 and why is it no longer valid?
ZUGFeRD 1.0 (2014) and ZUGFeRD 2.x use completely different XML schemas with different namespaces and structures; the formats are not compatible. ZUGFeRD 1.0 is not EN-16931-compliant and therefore does not satisfy the requirements of Germany's B2B mandate. Only ZUGFeRD from version 2.0.1 onwards is valid.
What is the difference between XRechnung and Peppol BIS Billing 3.0?
Both are CIUS specifications on EN 16931. XRechnung (Germany) has stricter national rules (BR-DE-*): mandatory IBAN for credit transfer, mandatory contact details, Leitweg-ID (BT-10) for B2G invoices. Peppol BIS 3.0 is the international CIUS for the Peppol network with its own mandatory fields (e.g. Buyer Reference or Order Reference, Scheme Identifier of the electronic address). An XRechnung sent via Peppol must additionally satisfy Peppol rules; for German B2G validate against both rule sets.
What is Peppol?
Peppol (Pan-European Public Procurement OnLine) is an international network for standardised document exchange, operated by OpenPeppol AISBL. The four-corner model connects senders and receivers via certified Access Points (AS4 protocol); discovery uses SML/SMP. Peppol BIS Billing 3.0 is the most widely used e-invoice specification in the network. Austria and Belgium use Peppol BIS as their B2G standard.

Archiving and law

How long must e-invoices be retained in Germany?
The statutory retention period for invoices in Germany is 8 years (§14b UStG). It was reduced from 10 to 8 years by the Fourth Bureaucracy Relief Act (BEG IV, 23 October 2024) – applicable to invoices whose retention period had not yet expired on 31 December 2024. Other accounting records are subject to §147 AO, also now 8 years.
Must an e-invoice be electronically signed?
No. An electronic signature is not a mandatory requirement for e-invoices in the EU. Article 233 of Directive 2006/112/EC provides three equivalent methods for ensuring authenticity of origin and integrity of content: internal business controls with a reliable audit trail, qualified or advanced electronic signature (AdES/QES), and EDI. A signature is therefore an option, not a requirement.
What is GoBD?
GoBD are the principles for the proper management and storage of books, records and documents in electronic form (German Federal Ministry of Finance). They apply exclusively in Germany. Core requirements: immutability (subsequent changes must be traceable), traceability, completeness, machine-readability and tax authority data access. In Austria, BAO §132 and RKSV apply instead.
What does "retain in the original format" mean?
An e-invoice must be retained in its structured original format in a tamper-proof manner: XML, or PDF/A-3 with embedded XML. A printout or plain PDF is not sufficient – the machine-readable structure must remain integrity-preserved throughout the entire retention period. For ZUGFeRD/Factur-X, the embedded XML is the legally authoritative archive object, not the PDF.

Technical use

What is a Gutschrift in the e-invoice context?
The German word "Gutschrift" is ambiguous. In VAT law (self-billing) it denotes an invoice issued by the recipient on behalf of the supplier (document type 389). Commercially, "Gutschrift" usually means a correction or cancellation invoice (credit note, document type 381). Confusing the two leads to an incorrect InvoiceTypeCode (BT-3) in the e-invoice.
What is reverse charge in e-invoices?
Reverse charge means that the VAT liability shifts to the recipient of the supply. In the e-invoice: VAT category AE, tax rate 0, mandatory note "reverse charge" (BT-120), VAT identification numbers of both parties required. Validated by Schematron rules BR-AE-*.
What are the most common validation errors in e-invoices?
Common errors: rounding differences in the totals chain (BR-CO-13/14/15/17) when line amounts and totals are rounded differently; missing seller tax identification; missing tax exemption note for categories E, AE, K, G (BR-E-*, BR-AE-*); invalid code list values (e.g. non-standard units of measure); missing Buyer or Order Reference in Peppol; missing or incorrect Leitweg-ID for German B2G invoices.

This information is provided for general orientation and does not constitute legal or tax advice. Despite careful research and verification against official sources, no guarantee is given for completeness or accuracy. Last updated: May 2026.