E-Invoice Glossary

Key terms for electronic invoicing, EN 16931, formats and mandates – briefly explained.

B

BAO §132 (Austria)
The Austrian Federal Tax Code (Bundesabgabenordnung) §132 sets a retention obligation of generally 7 years from the end of the calendar year of the last entry. Storage on data media is permissible provided that complete, orderly, and faithful reproduction is guaranteed at all times. German GoBD does not apply in Austria.
Source ↗
BG (Business Group)
A group of related Business Terms in the EN 16931 data model, e.g. BG-4 Seller, BG-7 Buyer, BG-23 VAT breakdown, BG-25 Invoice line. The model defines mandatory, conditional and optional elements with defined cardinalities.
BR rule / Schematron
EN 16931 is validated by Schematron business rules. BR-* rules check structure and mandatory fields; BR-CO-* rules check calculations and consistency (e.g. BR-CO-13: net total = sum of line amounts minus allowances plus charges); BR-CL-* rules check code lists (currency, country, unit of measure). National CIUS add their own rules, e.g. BR-DE-* for XRechnung.
BT (Business Term)
An individual data element in the EN 16931 data model, e.g. BT-1 Invoice number, BT-2 Invoice date, BT-5 Invoice currency, BT-31 Seller VAT identifier, BT-106 Sum of invoice line net amounts. Business Terms are grouped into Business Groups (BG-*) and serialised as unique fields in UBL or CII XML.

C

CIUS (Core Invoice Usage Specification)
A CIUS restricts EN 16931 without extending the model: optional fields become mandatory, code lists are restricted, additional business rules (BR-*) are added. A CIUS-compliant invoice is always also EN-16931-compliant. Examples: XRechnung (Germany), Peppol BIS Billing 3.0, ebInterface.
Clearance
A CTC model in which an invoice must be validated, registered and approved by a government platform before delivery to the buyer – only then is it legally valid. Examples: Italy (SDI), Poland (KSeF). Germany and Austria do not currently use a clearance model.
CTC (Continuous Transaction Controls)
Models in which the tax authority receives transaction data in near real-time rather than retrospectively. Four basic types: Clearance (prior approval), Near-Real-Time Reporting (parallel notification), Post-Audit (retrospective audit) and DCTCE (decentralised, Peppol-based). The EU ViDA architecture uses the DCTCE model.

D

DCTCE (Decentralised CTC and Exchange)
A decentralised CTC model in which the normal four-corner delivery is preserved and a reporting copy is sent in parallel to the tax authority ("fifth corner"). No central mandatory clearing. This model forms the basis of the EU ViDA architecture (DRR from 2030), the French Y-model (PA/PPF) and Belgium's e-reporting plan (from 2028).

E

E-Reporting
Transmission of transaction or VAT data to the tax authority – not to the trading partner. Can be near real-time. Important: even a business that owes no e-invoice may owe e-reporting (e.g. France for B2C and cross-border B2B). E-reporting is a legally separate obligation from e-invoicing.
ebInterface
Austrian XML format for e-invoices, developed and maintained by AUSTRIAPRO (subsidiary of WKÖ, ebinterface.at). Versions supported by the Austrian federal administration: 4.3, 5.0, 6.0, 6.1. From version 5.0 onwards, convertible to EN 16931. Together with Peppol BIS, the only accepted standard for the Austrian federal administration.
Source ↗
EN 16931
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 and UN/CEFACT CII. The updated version EN 16931-1:2026 extends the model for B2B and DRR requirements.
Source ↗
Extension (EN 16931)
An Extension expands the EN 16931 model with additional fields or code lists – as opposed to a CIUS, which only restricts. An Extension-compliant invoice is not necessarily compatible with pure EN-16931 receivers; the receiver must explicitly support the Extension. Example: ZUGFeRD profile EXTENDED.

F

Factur-X
Hybrid format (PDF/A-3 with embedded UN/CEFACT CII XML), technically identical to ZUGFeRD. Factur-X is maintained by FNFE-MPE (France), ZUGFeRD by FeRD (Germany). Both formats are fully interoperable and share the same profiles (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED). At least the BASIC profile is required for a valid invoice.
Source ↗
Four-corner model (Peppol)
The transmission model in the Peppol network: sender (C1) sends to sender Access Point (C2), which transmits via AS4 to receiver Access Point (C3), which delivers to receiver (C4). All Access Points are certified by OpenPeppol. Discovery of the correct receiver Access Point uses SML (Service Metadata Locator) and SMP (Service Metadata Publisher).

G

GoBD (Germany)
Principles for the proper management and storage of books, records and documents in electronic form (German Federal Ministry of Finance). Core requirements: immutability, traceability, completeness, machine-readability, data access for the tax authority. E-invoices must be retained in the structured original format (XML) – a printout or plain PDF is not sufficient. GoBD applies exclusively in Germany.
Gutschrift (meaning distinction)
The German word "Gutschrift" is ambiguous: in VAT law it denotes an invoice issued by the recipient on behalf of the supplier (self-billing, 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.

H

Hybrid format
A hybrid format combines a human-readable PDF/A-3 (ISO 19005-3) with an embedded XML file containing the structured invoice data. Representatives: ZUGFeRD (Germany) and the technically identical Factur-X (France). The embedded XML is the legally authoritative document; where PDF and XML differ, the XML prevails.
Source ↗

K

KoSIT
Koordinierungsstelle für IT-Standards (Coordination Centre for IT Standards), operating on behalf of the IT Planning Council. KoSIT is the official publisher of the XRechnung specification and the KoSIT Validator for validating XRechnung files. Specifications and releases are available at xeinkauf.de.

L

Leitweg-ID
Buyer Reference (BT-10) for routing e-invoices to German public-sector recipients. Structure: coarse address (2-digit federal state code) – fine address – check digit. Mandatory only for B2G invoices in Germany. In the Peppol network, the Leitweg-ID is used as a Participant Identifier with the prefix 0204.
Source ↗

M

MINIMUM profile (ZUGFeRD)
The ZUGFeRD MINIMUM profile contains only header and totals data (for booking stamps/workflows); 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. At least the BASIC profile is required for a valid invoice.

O

OpenPeppol
Non-profit organisation (OpenPeppol AISBL) under Belgian law, headquartered in Brussels, operating the Peppol network and maintaining the specifications including Peppol BIS Billing 3.0. Currently 23 countries have their own Peppol Authorities; over 1.4 million network participants in more than 65 countries.

P

PDF/A-3
Archive format under ISO 19005-3 which, unlike earlier PDF/A variants, allows embedding arbitrary file attachments. It is the technical basis for ZUGFeRD and Factur-X: the embedded XML contains the structured invoice data, while the PDF/A-3 provides the human-readable view. For pure XML formats (XRechnung, UBL), the XML itself is the archive object.
Peppol BIS Billing 3.0
International e-invoice specification in the Peppol network: a CIUS of EN 16931 based on UBL 2.1, maintained by OpenPeppol. Transported via the four-corner model using the AS4 protocol. B2G standard in Austria, Belgium, Netherlands and other countries; also valid for German B2B e-invoices.

Q

QES (Qualified Electronic Signature)
Highest level of electronic signature under eIDAS Regulation (EU) 910/2014: based on a qualified certificate from a trust service provider, legally equivalent to a handwritten signature (Art. 25(2) eIDAS). Not mandatory for e-invoices in the EU – a signature is only one of three equivalent methods for ensuring authenticity and integrity (Art. 233 VAT Directive).

R

Receiving obligation / Issuing obligation
Terms from the German B2B mandate (§14 UStG): the receiving obligation (from 1 Jan 2025) requires all domestic companies to be able to receive EN-16931-compliant e-invoices without requiring recipient consent. The issuing obligation is phased: from 1 Jan 2027 for companies with prior-year turnover exceeding €800,000; from 1 Jan 2028 for all companies (§27 para. 38 UStG).
Source ↗
Retention period (Aufbewahrungsfrist)
The period for which invoices must be kept in a tamper-proof manner. In Germany: 8 years for invoices (§14b UStG; §147 AO applies in parallel to other accounting records), reduced from 10 years by the Fourth Bureaucracy Relief Act (BEG IV) – applicable to invoices whose retention period had not yet expired on 31 December 2024. In Austria, BAO §132 mandates generally 7 years from the end of the calendar year of the last entry.
Source ↗
Reverse charge
Under reverse charge, 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-*.

S

Sonstige Rechnung (other invoice)
Term from §14 UStG (since the Growth Opportunities Act 2024): any invoice that is not a structured, EN-16931-compliant e-invoice – i.e. paper, plain PDF, scanned invoice, JPG. A sonstige Rechnung does not meet the requirements of the German B2B mandate. Until end of 2026 it remains permissible with recipient consent.
Source ↗

V

VAT category codes (UNCL5305)
Code values for the VAT category in e-invoices (BT-151): S = standard rate, Z = zero rated, E = exempt, AE = reverse charge, K = intra-community supply, G = export (third country), O = outside scope. For categories E, AE, K, G and O, an exemption reason (BT-120 text or VATEX code BT-121) is mandatory.
ViDA (VAT in the Digital Age)
EU legislative package comprising Directive (EU) 2025/516, Regulation (EU) 2025/517 and Implementing Regulation (EU) 2025/518, in force since 14 April 2025. Three pillars: Digital Reporting Requirements (DRR) and e-invoicing for intra-EU B2B transactions (mandatory from 1 July 2030), platform economy (deemed supplier rules), Single VAT Registration (OSS expansion).
Source ↗

W

Wachstumschancengesetz (Growth Opportunities Act)
German law published on 27 March 2024 (BGBl. I 2024 Nr. 108) which amended §14 UStG. It defines the e-invoice as a structured, EN-16931-compliant document and introduces the phased B2B e-invoicing mandate: receiving obligation from 1 Jan 2025, issuing obligation from 1 Jan 2027 (turnover >€800,000) and from 1 Jan 2028 (all companies).
Source ↗

X

XRechnung
Germany's national CIUS on EN 16931, maintained by KoSIT (IT Standards Coordination Centre) on behalf of the IT Planning Council. Pure XML without a PDF layer; available in UBL 2.1 or UN/CEFACT CII. B2G standard for invoices to German federal authorities, mandatory since 27 Nov 2020. Current version: XRechnung 3.x. Austrian federal agencies do not accept XRechnung.
Source ↗
Sources & official references →

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.