E-invoicing is a field where three professions talk past each other: bookkeeping, IT and tax law use the same words for different things. This glossary explains the terms that actually turn up in validation reports, contracts and emails from your accountant — briefly, with a pointer to where it is covered in full.
Formats and standards
| E-invoice | An invoice in a structured electronic format that can be processed by machine. A PDF without structured data is not one, even when it arrives by email. |
| EN 16931 | The European standard that defines the semantic data model of an invoice: which items exist and what they are called. Everything else is a flavour of it — see EN 16931. |
| ZUGFeRD | The German hybrid format: a PDF/A-3 file with embedded XML, readable by people and machines in one file — see ZUGFeRD. |
| Factur-X | The French name for the same hybrid format; technically the same specification, maintained jointly — see Factur-X. |
| XRechnung | The German standard for plain XML with no visible page, used above all with public bodies. E-Rechnung Pro validates it but does not produce it. |
| Hybrid format | Visible page and structured data in the same file. Where they diverge, the structured side prevails. |
| UBL | An XML syntax (OASIS) the standard can be expressed in. The mandatory syntax on the Peppol network. |
| CII | Cross Industry Invoice, the second permitted syntax (UN/CEFACT). The XML inside ZUGFeRD and Factur-X is CII. |
| PDF/A-3 | The archival flavour of PDF that may embed arbitrary files — the precondition for a hybrid format, see PDF/A-3. |
| CIUS | “Core Invoice Usage Specification”: a narrowing of the standard that adds nothing new. Examples: XRechnung, Peppol BIS Billing 3.0. |
| Extension | The opposite: additional fields the standard does not know — which is how the EXTENDED profile works. |
| FeRD | The German forum that publishes ZUGFeRD, hosted by the AWV and founded in 2010. |
How an invoice is built: BT and BG
| BT-… | “Business term” — a single field of the standard, such as the invoice total or the delivery date. The number is fixed; the element name differs per syntax. |
| BG-… | “Business group” — a group of related fields, such as an invoice line (BG-25) or a VAT breakdown (BG-23). |
| BT-23 | The business process. Files built here carry the usual identifier of the standard billing process. |
| BT-24 | The specification identifier. Every validation reads it to tell which profile it is dealing with and whether the file follows the standard. |
| BT-10 | The buyer reference. In Germany, public bodies put the Leitweg-ID there. |
| BT-72 / BG-14 | Delivery date and invoicing period. For intra-community supplies one of the two becomes mandatory. |
| BT-118 / BT-151 | The VAT category code in the breakdown and on the line — see VAT. |
| BT-120 / BT-121 | The exemption reason as text and as a code. |
| Leitweg-ID | The routing identifier of a German public authority. It sits inside the invoice as BT-10 and doubles as the delivery address on the Peppol network. |
| Document type (BT-3) | A numeric code rather than a word: 380 invoice, 381 credit note, 384 corrected invoice, 386 prepayment invoice. The heading does not decide, the code does. |
| Credit note | A document of its own with code 381 referring back to the original invoice — not an invoice with a minus sign. |
Where these fields sit in the XML tree is covered under the structure of the XML.
Profiles
| MINIMUM | A cut-down header only. Does not count as an e-invoice, because the mandatory items are missing. |
| BASIC WL | “Without lines” — no invoice lines. Likewise not an e-invoice. |
| BASIC | The simple compliant case: lines and tax information present. |
| EN 16931 | The full core model — the choice that gets stuck nowhere. |
| EXTENDED | An extension for fields beyond the standard. Needed only where the standard genuinely has no place for something — see profiles. |
Validation and rules
| Schema (XSD) | The first layer: is the XML built correctly at all? A file failing here is technically broken. |
| Schematron | The second layer: rules about content, written as test expressions. Every validation tool in this field runs on it. |
| Business rule (BR-…) | A single requirement of the standard, such as an invoice needing a date. The code appears in every error message — see business rules. |
| BR-CO-… | Rules about arithmetic: totals, rounding, how the amounts hang together. |
| BR-DE-… | German add-on rules that go beyond the standard. |
| PEPPOL-EN16931-… | Add-on rules of the Peppol network. They only apply once the invoice is submitted there. |
| Validation | Checking against schema, rules and code lists. It proves conformity of form, not correctness of content — see validation. |
| Mustang | An open-source Java library and command-line tool for ZUGFeRD and Factur-X, widely used for validation — see Mustang. |
VAT
| Category code | The letter that says why a rate applies: S standard, Z zero rated, E exempt, AE reverse charge, K intra-community supply, G export, O outside the scope. |
| Reverse charge | The buyer accounts for the tax. In the file: code AE, rate zero, plus an exemption reason. |
| Intra-community supply | An exempt supply of goods to another EU state. Code K — and delivery date and delivery country become mandatory. |
| VATEX | The code list of exemption reasons, such as VATEX-EU-AE. Each code belongs to exactly one category. |
| VAT identifier | The VAT number with a country prefix. For intra-community supplies its validity is a substantive condition of the exemption. |
| VIES | The European Commission's lookup for VAT numbers. It answers one question: valid or not. |
| Qualified confirmation request | The German Federal Central Tax Office request that also compares name and address. Its result is the evidence you keep. |
| EC Sales List | The report of intra-community turnover to the tax administration. Since 2020 a condition of the exemption, not a formality. |
| Input tax deduction | The right to reclaim VAT paid. It is the reason the form of an incoming invoice matters at all. |
| Small business (§ 19 UStG) | A German business invoicing exempt under § 19. It must be able to receive e-invoices but need not issue them — see VAT. |
Delivery and networks
| Peppol | A delivery network on the four-corner model, not a format — see Peppol. |
| Peppol BIS Billing 3.0 | The invoice specification carried on that network: a CIUS of the standard, in UBL. |
| Access point | The accredited provider through which you reach the network. Nobody connects directly. |
| SMP / SML | The directories saying who is reachable where, and which document types they accept. |
| AS4 | The network's transport protocol, in a Peppol-specific flavour. |
| Peppol ID | A participant's network address, written as scheme and value — a VAT identifier or a GLN, for instance. |
| Five-corner model | The four corners plus the tax administration, which receives the invoice data. |
| E-reporting | Reporting invoice data to the administration — a second obligation alongside sending the invoice. |
Law, retention, workflow
| BMF letter | The German finance ministry's administrative view. Not a statute, but what an audit goes by. |
| GoBD | The German requirements for electronic books and documents: tamper-evidence, machine readability, findability, process documentation. |
| Process documentation | The description of how your archive works. The item most often missing — see retention. |
| “Other invoice” | The counterpart to an e-invoice: paper, or a plain PDF without structured data. |
| Small-amount invoice | An invoice up to €250 gross. The e-invoicing obligation does not apply to it — issuing one is still allowed. |
| Document | The invoice itself as a file — what your accountant needs. |
| Booking batch | Finished journal entries out of accounting software. An entirely different delivery — see handing over to your accountant. |
| ViDA | The EU package “VAT in the Digital Age”, which drives the national calendars for e-invoicing and digital reporting — see deadlines. |
Frequently asked questions
Is XRechnung better than ZUGFeRD?
Neither is better. XRechnung is plain XML and customary with public bodies; ZUGFeRD is a hybrid with a visible page as well. Both satisfy the obligation.
If ZUGFeRD is a PDF, why is it called an e-invoice?
Because the governing data sits inside it as XML. A PDF without that XML is an “other invoice”, not a structured document.
What is the difference between a profile and a syntax?
The syntax is the language (UBL or CII), the profile is the scope (MINIMUM through EXTENDED). Both are stated in the file, independently of each other.
Do I need Peppol if I already produce ZUGFeRD?
Not necessarily. Peppol is a delivery route; in Germany the route is free to choose and email is enough.
What does a rule code like BR-CO-15 mean in a report?
It names exactly the requirement the file failed. The code is the fastest way to the spot — the most frequent ones are listed under business rules.
If you take away only five terms
- EN 16931 is the model; everything else is a flavour of it.
- Syntax (UBL or CII) and profile (MINIMUM to EXTENDED) are two different questions.
- BT and BG are the field numbers everyone involved talks in.
- The category code says why a VAT rate applies — not the rate itself.
- Peppol is the route, not the format.
Want to look a term up in a real file? Upload an invoice — the report names the field number and the rule in plain words.