The e-invoicing glossary

Every term with a definition that stands on its own — and where it helps, the real field from the API and a tool you can use without leaving the page.

68 entries · As JSON

Start here

Six terms that almost every e-invoicing question begins with.

EN 16931
EN 16931 is the European standard that defines which data an electronic invoice must carry and what each item means — it describes a semantic data model rather than a file format, and XRechnung, ZUGFeRD, Factur-X and Peppol BIS all implement it.
XRechnung
XRechnung is the German standard for electronic invoices to public authorities: a CIUS of EN 16931, maintained by KoSIT, technically pure XML in either the UBL or the CII syntax — with no PDF part.
ZUGFeRD
ZUGFeRD is a hybrid format: a PDF/A-3 file that a person can read and that simultaneously carries a complete XML invoice in CII syntax embedded inside it — one file readable by both humans and machines.
Validation
Validation is the machine check of an e-invoice against the rules of its format, in three stages: syntax (is the XML well-formed?), schema (are the fields correctly typed?) and business rules (does the content make sense?).
Leitweg-ID (routing ID)
The Leitweg-ID is the electronic delivery address of a German public authority: it routes an XRechnung to the right place inside the government network and travels in field BT-10 (buyer reference).
E-invoicing obligation
The e-invoicing obligation requires businesses to issue and receive invoices in a structured electronic format rather than on paper or as a plain PDF — in Germany it applies to B2B in stages, beginning with the obligation to receive.

By topic

Every entry by subject area — the order you need while the vocabulary is still new.

Standards5 entries

Formats & syntax18 entries

Validation & rules8 entries

Infrastructure12 entries

Fields & identifiers11 entries

Law & compliance14 entries

All terms, A to Z

The full index with definitions. For when you already know the term.

A

Access Point: An access point is a certified provider through which a company participates in Peppol — it accepts documents, hands them to the counterpart's access point, and is the only way to take part in the framework.
Audit-proof storage: Audit-proof storage means an archived document cannot be altered afterwards without detection and that every change remains traceable — the technical implementation is free, the proof is not.

B

B2B: B2B (business-to-business) covers invoices between companies — this is the actual subject of the German e-invoicing reform, because it involves far more documents than dealings with public authorities.
B2G: B2G (business-to-government) covers invoices to public authorities — in Germany e-invoicing has applied here considerably longer than between businesses, and the Leitweg-ID is mandatory.
BG number (business group): A BG number identifies a group of related fields in EN 16931 — BG-4 is the seller, BG-16 the payment instructions. Rules frequently require a whole group rather than a single field.
BR-DE rules: BR-DE rules are the additional German business rules of XRechnung that go beyond EN 16931 — among other things they require a seller contact and payment details, and they are the most common reason an invoice is rejected.
BT number (business term): A BT number identifies a single data field in EN 16931 — BT-1 is the invoice number, BT-10 the buyer reference. Validator error messages almost always cite the BT number rather than the field name used in your own system.
Business rule: A business rule checks a factual statement about the invoice rather than its technical shape — for instance that the sum of the line items equals the net amount. In EN 16931 these rules carry identifiers such as BR-11 or BR-CO-10.
Buyer reference (BT-10): The buyer reference (BT-10) is the field in which the recipient expects its own routing identifier — in Germany it carries the Leitweg-ID, in other countries an order number or cost centre.

C

CEN: CEN (the European Committee for Standardization) is the body that develops and maintains EN 16931 — its technical working groups decide which fields count Europe-wide as the core of an invoice.
Chorus Pro: Chorus Pro is the French platform for invoices to public authorities — every invoice to a French public body goes through it, and it is the forerunner of the broader French reform.
CII (Cross Industry Invoice): CII (Cross Industry Invoice) is the invoice XML syntax developed by UN/CEFACT and one of the two syntaxes permitted by EN 16931 — ZUGFeRD and Factur-X embed CII inside the PDF file.
CII or UBL?Guide: CII and UBL are two XML syntaxes for the same business content: both implement EN 16931 and both are equally valid — which one you need is decided by the recipient, not by the standard.
CIUS: A CIUS (Core Invoice Usage Specification) is a national or sector-specific tightening of EN 16931: it may make fields mandatory or narrow value ranges, but never add new ones — XRechnung is the German CIUS.
Clearance model: In the clearance model an invoice must pass the tax administration before reaching the recipient — the state inspects and acknowledges each document individually. Italy works this way, Germany does not.

D

Digital signature: A digital signature cryptographically proves who issued a document and that it has not been altered since — Germany does not require one for e-invoices, several other countries do.

E

E-invoice: An e-invoice is an invoice in a structured, machine-processable format — a scanned sheet of paper or an ordinary PDF explicitly is not one, because its data cannot be read out without interpretation.
E-invoicing obligation: The e-invoicing obligation requires businesses to issue and receive invoices in a structured electronic format rather than on paper or as a plain PDF — in Germany it applies to B2B in stages, beginning with the obligation to receive.
E-reporting: E-reporting is the obligation to report invoice data to the tax administration, independently of how the invoice reaches the recipient. It is the second half of many national reforms alongside e-invoicing itself.
Early payment discount: An early payment discount rewards fast payment — in XRechnung it is not free text but encoded in a prescribed string inside the payment terms field, which is a frequent source of errors.
ebInterface: ebInterface is the Austrian XML invoice standard maintained by the economic chamber and Austrian Standards, and required for invoices to the federal government via the business service portal.
EDI: EDI (electronic data interchange) is the structured exchange of data between companies without manual steps in between — e-invoicing is the EDI use case that legislators have now made mandatory.
EDIFACT: EDIFACT is the older, non-XML UN messaging standard for electronic data interchange, established in retail and industry for decades — its INVOIC message is the counterpart to an invoice.
Electronic address (BT-34 / BT-49): The electronic address states under which identifier the seller (BT-34) and buyer (BT-49) can be reached electronically — in a Peppol context it is the participant ID, without which a delivery cannot be addressed.
EN 16931: EN 16931 is the European standard that defines which data an electronic invoice must carry and what each item means — it describes a semantic data model rather than a file format, and XRechnung, ZUGFeRD, Factur-X and Peppol BIS all implement it.
Extension: An extension adds fields that the EN 16931 core does not know, in contrast to a CIUS, which may only restrict. Using one leaves the zone of guaranteed European interoperability and requires an agreement with the recipient.

F

Factur-X: Factur-X is the French name for the same hybrid format that Germany calls ZUGFeRD — developed jointly by both countries and technically identical, so one file is valid in either.
Facturae: Facturae is the Spanish XML invoice format with its own syntax and a mandatory electronic signature — it predates EN 16931 and is therefore not simply another CIUS.
FatturaPA: FatturaPA is the Italian invoice format routed through the state-run SDI system — unlike Germany, a public authority inspects and forwards every single invoice before it reaches the recipient.
FeRD: FeRD (Forum elektronische Rechnung Deutschland) is the body that develops and maintains ZUGFeRD — hosted at the German Federal Ministry for Economic Affairs, it works with its French counterpart on Factur-X.
Five-corner model: The five-corner model adds the tax administration as a fifth corner to the four-corner model: providers additionally report invoice data to the state — France built its reporting system this way.
Four-corner model: In the four-corner model the sender hands the document to its own provider, that provider passes it to the recipient's provider, which delivers it — four parties, and neither company needs to know the other's technical setup.

G

GoBD: The GoBD are the German tax administration's rules on how tax-relevant data must be kept, stored and made available during an audit — they determine how an e-invoice has to be archived.

H

Hybrid format: A hybrid format combines the human-readable and the machine-readable invoice in a single file — visibly a PDF, technically also an embedded XML document. ZUGFeRD and Factur-X are the common examples.

I

Invoice number (BT-1): The invoice number is the unique, sequentially assigned identifier of a document — it is required for VAT purposes, must never repeat, and is field BT-1 in EN 16931.
ISDOC: ISDOC is the Czech XML invoice standard, created before EN 16931 and still widely used there — anyone invoicing into the Czech Republic will meet it alongside the European formats.

K

KoSIT: KoSIT (Koordinierungsstelle für IT-Standards) is the German body that maintains the XRechnung standard and publishes the official validator and its Schematron rule set — its rules decide whether an XRechnung counts as conformant.
KSeF: KSeF (Krajowy System e-Faktur) is the Polish state platform for electronic invoices operating on the clearance principle — every invoice is registered there and receives an identifier.

L

Leitweg-ID (routing ID): The Leitweg-ID is the electronic delivery address of a German public authority: it routes an XRechnung to the right place inside the government network and travels in field BT-10 (buyer reference).

N

NLCIUS: NLCIUS is the Dutch CIUS of EN 16931 in UBL syntax — closely related to Peppol BIS and required for invoices to Dutch public authorities.

O

OZG-RE: OZG-RE is one of the two German federal intake platforms for electronic invoices — it receives XRechnung documents for connected authorities and checks them before forwarding.

P

PDF/A-3: PDF/A-3 is the archival flavour of PDF and the only one that permits embedding arbitrary files — precisely the property that makes it the carrier of the XML invoice in ZUGFeRD and Factur-X.
Peppol: Peppol is a Europe-wide framework for exchanging procurement documents: participants connect through a certified provider, and delivery between those providers follows uniform rules — the four-corner model.
Peppol BIS Billing 3.0: Peppol BIS Billing 3.0 is the invoice specification of the Peppol community: a CIUS of EN 16931 in UBL syntax that prescribes how a document must look so any participant can process it.
Peppol participant ID: The Peppol participant ID uniquely identifies a recipient within the framework and consists of a scheme prefix plus a value — such as a VAT identification number or a national register number.

R

Receiving e-invoicesGuide: The obligation to receive e-invoices is technically satisfied by an email inbox — the real work starts afterwards: reading out the structured original, checking it and retaining it in an audit-proof way.
Retention obligation: The retention obligation requires invoices to be kept legible and analysable for a statutory period — for an e-invoice it is the structured original that must be retained, not a printout derived from it.

S

Schematron: Schematron is an ISO-standardised rule language that uses XPath expressions to check whether the content of an XML document is factually correct — it is the stage at which business rules such as BR-DE-2 or BR-11 actually run.
SDI (Sistema di Interscambio): SDI (Sistema di Interscambio) is the Italian exchange platform every invoice passes through: it checks the document, acknowledges it and delivers it to the recipient — without SDI an invoice in Italy counts as not issued.
Section 14 UStG: Section 14 of the German VAT Act sets out which details an invoice must contain for the recipient to deduct input tax — if one is missing, that deduction is at risk regardless of the file format.
Service period: The service period states when the supply being invoiced was actually performed — it is mandatory for VAT purposes and must not be confused with the invoice date.
Severity (fatal / warning): Severity decides whether a rule violation rejects the invoice or merely notes it: rules flagged fatal cause rejection, those flagged warning do not. The same factual statement can carry different weight in different rule sets.
Small business scheme (§ 19 UStG): Businesses under the § 19 small business scheme do not show VAT — this does not exempt them from having to be able to receive e-invoices, and their invoices need a note referring to the scheme.
SML (Service Metadata Locator): The SML (service metadata locator) is Peppol's central directory that resolves via DNS which SMP is responsible for a given participant — it is the first stop of every delivery.
SMP (Service Metadata Publisher): An SMP (service metadata publisher) is the directory recording which document types a Peppol participant accepts and at which technical address — without that entry a participant cannot be reached.

T

Tax number: The tax number is issued by the tax office and identifies the taxpayer nationally — it is not the same as the VAT identification number, and an invoice needs at least one of the two.

U

UBL (Universal Business Language): UBL (Universal Business Language) is the OASIS-standardised XML syntax for business documents and the second syntax permitted by EN 16931 — Peppol BIS 3.0 and the UBL flavour of XRechnung build on it.

V

Validation: Validation is the machine check of an e-invoice against the rules of its format, in three stages: syntax (is the XML well-formed?), schema (are the fields correctly typed?) and business rules (does the content make sense?).
VAT identification number: The VAT identification number identifies a business in the European single market and is mandatory for cross-border supplies — in EN 16931 it sits with the seller as BT-31.
ViDA: ViDA (VAT in the Digital Age) is the EU reform package adapting value-added tax to digital processes — it makes structured invoices the European default and introduces a cross-border reporting obligation.

X

XRechnung: XRechnung is the German standard for electronic invoices to public authorities: a CIUS of EN 16931, maintained by KoSIT, technically pure XML in either the UBL or the CII syntax — with no PDF part.
XRechnung or ZUGFeRD?Guide: XRechnung and ZUGFeRD differ not in content but in packaging: XRechnung is pure XML for public authorities, ZUGFeRD a PDF with embedded XML for recipients who also want to look at the document.
XRechnung rejected — what now?Guide: The most common reasons an XRechnung is rejected are not XML errors but violated business rules: a missing seller contact, missing payment details, an incorrectly encoded discount, or totals that do not add up.
XSD (XML Schema): An XSD describes the permitted structure of an XML document — which elements may appear in which order, with which data type and how often. It checks the shape, not whether the content makes business sense.

Z

ZRE (central invoice intake platform): ZRE is the central invoice intake platform of the German direct federal administration — which of the two federal platforms applies is revealed by the recipient's Leitweg-ID.
ZUGFeRD: ZUGFeRD is a hybrid format: a PDF/A-3 file that a person can read and that simultaneously carries a complete XML invoice in CII syntax embedded inside it — one file readable by both humans and machines.
ZUGFeRD or Factur-X?Guide: ZUGFeRD and Factur-X are technically the same format under two national names — what matters in practice are the profiles and the national add-on rules, not the file itself.
ZUGFeRD profiles comparedGuide: The ZUGFeRD profiles grade how much structured information a file carries — from MINIMUM, which is only a booking aid, up to EXTENDED. Only from the EN 16931 profile onwards does a file count as a full e-invoice.