Glossary · Reviewed October 2026

The e-invoicing glossary, in plain language.

Sixteen terms that decide whether an invoice flow works or stalls: how Peppol moves a document, which format each country expects, and what the compliance models actually ask of your systems. Written for finance and IT teams who have to build this, not for the people who sell it.

Definitions are grouped by the layer they belong to: the network that carries the document, the format it is written in, and the rules that govern it. Every entry is short enough to quote, specific enough to act on.

01 · Network & identifiers

Peppol: A European framework of agreements for exchanging structured business documents between organisations. It defines how a company is identified on the network, how access points find each other, and what a valid invoice must contain. Peppol is not software — you connect to it through an access point.
Peppol access point: A service, run by a certified provider, that sends documents into the Peppol network and receives them. Your access point looks up your customer's access point in the Peppol directory, delivers the invoice as a structured message, and returns a delivery status you can store with the invoice.
Peppol identifier: The address a company is reached on, made of a scheme and a value — for example a Belgian enterprise number or a VAT number with a country prefix. One legal entity can register several identifiers, but every identifier must be registered before documents addressed to it can arrive.
SMP and the Peppol directory: The Service Metadata Publisher holds the record that links an identifier to its access point. The public directory is the searchable view of those records. If a supplier is not in the SMP, delivery fails — which is why onboarding a trading partner starts with their identifier, not their email address.
Four-corner model: The topology Peppol uses: sender to sender's access point, across the network, to the receiver's access point and on to the receiver. It keeps each party's internal systems private while the exchange in the middle stays standardised.

02 · Formats & standards

EN 16931: The European semantic standard for e-invoicing. It defines which pieces of information an invoice must carry — parties, references, VAT breakdown, payment terms — without prescribing a file format. National formats are profiles of it, which is what makes one well-designed mapping reusable across countries.
Peppol BIS Billing 3.0: The Peppol profile of EN 16931 used in Belgium and several other countries. It specifies the allowed UBL syntax plus Belgian business rules, such as the required buyer reference and the VAT category codes accepted in practice.
UBL: Universal Business Language, the XML syntax Peppol BIS Billing uses. An invoice arrives as an XML document with defined elements and cardinalities, not as a rendered PDF — the readable view is produced by the receiver's system.
Factur-X, ZUGFeRD and XRechnung: German and French profiles of EN 16931. XRechnung is a pure XML format used for German public-sector invoices; Factur-X and ZUGFeRD are hybrid PDFs that carry machine-readable XML inside a human-readable document, useful when a counterparty still needs to look at the invoice.
Structured versus unstructured invoice: A structured invoice is machine-readable data with defined fields. An unstructured one is a PDF or scan that someone has to interpret. E-invoicing mandates generally apply to structured documents only, which is why a PDF sent by email does not satisfy them.

03 · Compliance & operations

Continuous transaction controls (CTC): A model in which invoices are reported to, validated by or cleared through a tax authority in real or near-real time. It replaces periodic VAT reporting with a per-invoice interaction, so the integration is an API call against a government platform rather than a message to a counterparty.
Clearance model: The strictest form of CTC: the authority validates and registers the invoice before the buyer may receive it. Slovakia and Poland operate national systems on this basis. If the clearance step fails, the invoice has no legal effect, so retry and rejection handling become part of the invoice flow itself.
Validation: Checking a document against syntax rules, the semantic model and national business rules before it is sent. Most rejections are mundane: a missing buyer reference, a wrong VAT identifier, or a rounding difference between line totals and the invoice total.
Rejection handling: What happens when a receiver or authority refuses a document. A durable flow parks the rejected invoice, surfaces the reason to a person who can fix the master data, and resends without manual re-keying. Undefined rejection handling is the most common reason an e-invoicing project stalls right after go-live.
ViDA: VAT in the Digital Age, the European package that moves VAT reporting towards digital, transaction-level obligations and introduces domestic e-invoicing requirements for member states. Its timetable has been revised more than once; treat any date you read as provisional and confirm before planning a build.
Archiving obligation: The requirement to retain invoices, and often the technical evidence of their transmission, for a defined period — commonly seven to ten years depending on the country. Keeping the payload, delivery status and response together is what makes an audit answerable years later.

Go deeper

A definition is easy. The flow behind it is the work.

If a term above describes something you have to comply with, send us the countries you invoice in and what you run today. You will hear what is required, what is not, and what it takes.