A plain-language reference for the e-invoicing terms used across the InvoiceSpec documentation. If a term shows up in Getting Started, the API Reference, or the Invoice JSON Schema and you are not sure what it means, look it up here. The definitions focus on what a developer needs to know to build a compliant request — not on the full regulatory history.
The European standard for the semantic data model of an electronic invoice. It defines which information a compliant European e-invoice must carry (the "what"), not the file format used to carry it (the "how"). Every document InvoiceSpec generates conforms to EN 16931. See also CIUS, CII, and UBL.
A Customization of EN 16931 for a specific country, region, or industry. A CIUS narrows the European standard with extra required fields and stricter rules. XRechnung is the German public-sector CIUS of EN 16931.
Cross Industry Invoice — one of the two XML syntaxes (file formats) the EN 16931 standard allows. It is the syntax InvoiceSpec uses for XRechnung XML and the XML embedded inside a ZUGFeRD PDF. The other allowed syntax is UBL.
Universal Business Language — the second XML syntax allowed by EN 16931. It represents the same EN 16931 data model as CII but with different element names and structure. InvoiceSpec currently emits CII; UBL is the alternative XML representation.
The concrete file format used to serialize an invoice — XML (either CII or UBL) or a PDF with embedded XML (ZUGFeRD / Factur-X). Distinct from EN 16931, which defines the content; a syntax defines how that content is serialized into bytes.
The German public-sector e-invoice format — a CIUS of EN 16931. It adds German-specific rules on top of the European standard (for example a required buyer reference, the Leitweg-ID) and is mandatory for invoices to German federal authorities. InvoiceSpec generates XRechnung as CII XML via the XRechnung generation API.
Zentraler Unterausschuss Gebühren- und Finanzdaten-erhebung Rechnungs-Daten — a German e-invoice format that ships a human-readable PDF/A-3 with a machine-readable CII XML invoice embedded inside it. One file serves both accounts-payable humans and automated systems. InvoiceSpec generates ZUGFeRD PDFs via the ZUGFeRD generation API. Structurally compatible with Factur-X.
The French equivalent of ZUGFeRD: the same PDF/A-3 + embedded CII XML structure, governed by a Franco-German agreement. A ZUGFeRD file and a Factur-X file are structurally compatible — the difference is the national naming and governance.
An ISO-standardized archival PDF format that allows embedding arbitrary files (an "attachment") inside the PDF. ZUGFeRD and Factur-X use PDF/A-3 to carry the XML invoice as an embedded attachment alongside the visible, human-readable PDF.
A named level of a format that defines which fields and rules apply. ZUGFeRD/Factur-X defines profiles — MINIMUM, BASIC WL, BASIC, COMFORT (EN16931), EXTENDED, and XRECHNUNG — that range from a minimal set of fields to the full EN 16931 model. The profile controls what a recipient can expect in the document and which BRs are enforced.
An EN 16931 field identifier (for example BT-1 is the invoice number). Every piece of invoice data the standard recognizes has a stable BT code. The Invoice JSON Schema explorer maps each InvoiceSpec request field to its BT so you can see exactly which standard field you are setting.
An EN 16931 container identifier (for example BG-32 is the invoice line group). A BG groups related BTs into a logical block such as a seller, a line item, or a payment. Object and array fields in the InvoiceSpec request map to BGs.
An EN 16931 validation rule (for example BR-1 requires an invoice
number). BRs are the base-level checks every compliant EN 16931 invoice must
pass. A CIUS such as XRechnung adds further rules on top
(for example the German BR-DE-15 that requires a
Leitweg-ID).
A rule language used to validate XML documents beyond what an XSD schema can express. EN 16931 and XRechnung ship Schematron rule sets that encode the BRs and CIUS-specific rules. InvoiceSpec runs these rules after generation and reports any failures in the response.
The German federal Koordinierungsstelle für IT-Standards (Coordination Office for IT Standards). KoSIT publishes and maintains the XRechnung standard and its validation artifacts (XSD and Schematron).
A Business Interoperability Specification used over the Peppol network for cross-border e-invoice delivery in Europe. Peppol BIS Billing 3.0 is based on EN 16931. It is a delivery-network profile, not a new file format — the document payload is still CII or UBL.
A standardized German routing identifier used to address an invoice to the
correct recipient in the public sector. It is required on
XRechnung invoices to German federal authorities, enforced by the
BR-DE-15 BR.
BR-DE-15 checks only that a buyerReference (BT-10) is present and
non-blank — it does not verify the Leitweg-ID's format or checksum. InvoiceSpec
does not perform Leitweg-ID format or checksum validation today, and neither
does KoSIT's official XRechnung validation artifact (the
Schematron rule set that ships with the standard). This is a
shared gap across standard e-invoicing tooling, not an InvoiceSpec-specific
defect: no widely used e-invoicing validator enforces the Leitweg-ID checksum.
The XRechnung Invoice JSON Schema explorer carries
this same clarification inline on the buyerReference field. If you need strict
routing validation, validate the Leitweg-ID format in your own integration
before sending the request.
An InvoiceSpec request mode where the engine derives line net amounts, document totals, and tax amounts from the values you do provide, so you don't have to compute and send every total yourself. Fields marked Engine calculated in the Invoice JSON Schema can be omitted in AUTO mode.
The automatic activation and sunset schedule InvoiceSpec applies to each spec
version. When a new version of XRechnung, ZUGFeRD,
or EN 16931 is published by the governing authority, InvoiceSpec
deploys it in advance and it becomes available on the authority's effective
date — no action required on your side. During the coexistence window both the
old and new versions are usable; after the old version's sunset date it is
rejected with UNSUPPORTED_SPEC because the recipient system no longer
accepts it. The List Supported Specs
endpoint exposes effectiveDate and sunsetDate
on each entry so you can see the schedule. Omit config.version (or send
"latest") and you always get the newest resolvable version — this is the
recommended approach.
The date on which a spec version becomes available for generation and
validation. Returned as an ISO-8601 string (YYYY-MM-DD) on each entry in the
List Supported Specs response, or
null when the version has been available since launch. A version with a
future effectiveDate is not yet resolvable — it will not appear in the
catalog and cannot be used until that date. See version lifecycle.
The last date on which a spec version remains available for generation and
validation. Returned as an ISO-8601 string (YYYY-MM-DD) on each entry in the
List Supported Specs response, or
null when no sunset is planned. After this date the version is rejected with
UNSUPPORTED_SPEC because the recipient system no longer accepts it. If you
pin a version, plan to migrate before the sunset date. See
version lifecycle.
Sending an explicit config.version string (for example "3.0.2") instead of
omitting it or sending "latest". This forces InvoiceSpec to use that exact
version rather than the newest one. Pinning is an escape hatch for when you
need to target a specific version during the version lifecycle
coexistence window — for example, while migrating from XRechnung 3.0.2 to
3.1.0. After the pinned version's sunsetDate the request is
rejected with UNSUPPORTED_SPEC. The recommended approach is to omit
config.version and always use the latest resolvable version.