Profiles, versions and validation rules, explained
E-invoicing rules are moving targets: KoSIT, OpenPeppol, CEN and FNFE-MPE all publish new rule sets on their own schedules, each with its own legally binding effective date. This page explains the update policy the API follows so your integration never has to chase those dates, lists the rule sets currently in force, and documents every string a developer is likely to paste into a search engine, from urn:cen.eu:en16931:2017 to BR-DE-15: what it means, where it lives in the XML, and what to do about it.
Automatic updates: no maintenance on your side
By using the API you are always compliant with the latest regulatory standards out of the box. We do the compliance monitoring for you, and changes ship automatically on the authorities' own effective dates. There is no version to select and nothing to keep up to date on your side.
Two rules govern every request:
- Currently in force, always. Every request applies the rule set that is legally effective on the day of the request, the same rules a receiving portal or access point enforces.
- What we stamp is what we validate. A created invoice always declares exactly the profile it was validated against: the
CustomizationIDin the output and the rule set applied ensures your document is 100% compliant.
Rule sets currently applied
Every artifact is the official publication of its authority, vendored unmodified and swapped on the authority's effective dates:
| Rule set | Version applied | Source |
|---|---|---|
| EN 16931 base rules | Validation artifacts 1.3.16 (UBL and CII) | CEN / European Commission |
| Peppol BIS Billing 3.0 | 3.0.20, the November 2025 release including the 2025-Q4 hotfix, mandatory on the Peppol network since 23 February 2026. Also carries the Norwegian rules used by EHF Billing 3.0. | OpenPeppol |
| XRechnung | Specification 3.0.2 (the version in force in Germany), KoSIT Schematron release 2.5.0, both CII and UBL syntax | KoSIT |
| NLCIUS | SI-UBL 2.0.3.12, the release effective since 23 February 2026 | Dutch Peppol Authority |
| Peppol PINT Billing | 1.1.2, mandatory since 9 March 2026 | OpenPeppol |
| Factur-X / ZUGFeRD profiles | Factur-X 1.0.9 per-profile schemas and rules (MINIMUM, BASIC WL, BASIC, EXTENDED; EN 16931 profile documents use the CEN rules above, XRechnung-declared ones the KoSIT rules) | FNFE-MPE / FeRD |
Upcoming and already on our calendar: the Peppol May 2026 release and SI-UBL 2.0.3.13 both become mandatory on 17 August 2026 and will be applied that day, and XRechnung 4.0 (announced by KoSIT as the German CIUS of the revised EN 16931) will be built and verified during its transition window and switched on the effective date KoSIT sets.
Specification identifiers
The URN strings inside the documents: what each declares, which rules it triggers, and what to do with a document carrying it.
Factur-X and ZUGFeRD profiles
The five profile identifiers of the Franco-German hybrid PDF format, declared in BT-24 of the embedded CII XML.
| urn:factur-x.eu:1p0:minimum | The MINIMUM profile: header data only, no line items, below the EN 16931 core. |
| urn:factur-x.eu:1p0:basicwl | BASIC WL (without lines): document-level data with VAT breakdown, still no lines. |
| urn:factur-x.eu:1p0:basic | BASIC: the first EN 16931 compliant profile, declared via the #compliant# stem form. |
| urn:factur-x.eu:1p0:en16931 | The EN 16931 (Comfort) profile: the full European core data set, the recommended default. |
| urn:factur-x.eu:1p0:extended | EXTENDED: beyond the core for complex billing, declared via the #conformant# stem form. |
The European core
The stem nearly every European specification identifier builds on.
| urn:cen.eu:en16931:2017 | The EN 16931 core identifier and the #compliant# / #conformant# grammar behind every CIUS and extension. |
National and network CustomizationIDs
The BT-24 values that route a document to a national or network rule set.
| urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0 | The XRechnung 3.0 CustomizationID, in both its xeinkauf.de and older xoev-de spellings. |
| urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0 | The Peppol BIS Billing 3.0 CustomizationID and its ProfileID companion (BT-23). |
Syntax namespaces
Identifiers that name the XML vocabulary itself rather than a profile.
| urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100 | The namespace of the CII root element, defined by CrossIndustryInvoice_100pD16B.xsd. |
Validation rule codes
The other string developers paste into a search engine: the rule code from a failed validation report. Each page explains what the rule actually checks, why it fails in practice, and shows the cryptic raw Schematron output next to the readable, field-mapped finding the InvoiceXML validators return for the same failure.
XRechnung rules (BR-DE)
The German CIUS rules from KoSIT. They fire in the cius layer when a document declares the XRechnung profile, including ZUGFeRD hybrids doing so.
| BR-DE-1 | Payment instructions (BG-16) are mandatory: an XRechnung must say how it will be paid. |
| BR-DE-2 | The seller contact group (BG-6) is mandatory: name, phone, and email of a human to ask. |
| BR-DE-15 | The buyer reference (BT-10) is mandatory: the Leitweg-ID slot of German B2G invoicing. |
| BR-DE-17 | Only specific UNTDID 1001 invoice type codes are accepted (380, 381, 384 and friends). |
| BR-DE-18 | Skonto entries in the payment terms (BT-20) must follow the strict #SKONTO# line format. |
| BR-DE-21 | The specification identifier (BT-24) must syntactically be the XRechnung one. |
EN 16931 core rules
Structural rules of the European core model. They fire in the en16931 layer, in every format and profile.
| BR-01 | A specification identifier (BT-24) is mandatory: the invoice must declare its profile. |
| BR-16 | At least one invoice line (BG-25) is mandatory: summary-only documents fail. |
| BR-CO-03 | The VAT point date (BT-7) and its code (BT-8) are mutually exclusive: send one, not both. |
| BR-CL-24 | Attached documents (BT-125) may only use the six MIME types EN 16931 allows. |
The totals chain (BR-CO)
The calculation rules that tie the document totals together, from the line sum to the amount due. One wrong cent fails the chain; documents generated via /v1/create/* compute it server-side.
| BR-CO-10 | Sum of line net amounts (BT-106) = the sum over every line's BT-131. |
| BR-CO-11 | Sum of document level allowances (BT-107) = the sum of the allowance amounts (BT-92). |
| BR-CO-13 | Total without VAT (BT-109) = lines minus allowances plus charges. |
| BR-CO-15 | Total with VAT (BT-112) = total without VAT plus the VAT total. |
| BR-CO-16 | Amount due (BT-115) = total with VAT minus prepaid plus rounding. |
VAT rules
The VAT breakdown arithmetic and the category-specific requirements, en16931 layer.
| BR-CO-14 | The invoice VAT total (BT-110) must equal the sum of the VAT breakdown amounts. |
| BR-CO-17 | Each VAT category tax amount (BT-117) = taxable amount x rate / 100, rounded. |
| BR-S-08 | Each standard-rate breakdown's taxable amount must equal the sum of its rate's lines. |
| BR-AE-10 | A reverse charge VAT breakdown needs an exemption reason (VATEX-EU-AE or text). |
| BR-E-10 | An exempt VAT breakdown needs an exemption reason code or text. |
| BR-IC-11 | An intra-community supply invoice needs a delivery date (BT-72) or invoicing period (BG-14). |
| BR-IC-12 | An intra-community supply invoice needs the deliver-to country code (BT-80). |
Peppol BIS rules
The network overlay of Peppol BIS Billing 3.0, plus the national packs riding on it. Cius layer, Peppol profile; the plain en16931 profile drops them.
| PEPPOL-EN16931-R001 | A business process type (BT-23) is mandatory: the ProfileID next to the CustomizationID. |
| PEPPOL-EN16931-R010 | A buyer electronic address (BT-49) is mandatory: the delivery endpoint on the network. |
| PEPPOL-EN16931-R020 | A seller electronic address (BT-34) is mandatory: the sender's network identity. |
| PEPPOL-EN16931-CL008 | Electronic address schemes must be EAS codes: 9930, 0204, 0088 pass, "EM" does not. |
| DE-R-001 | Domestic German invoices on Peppol need payment instructions (BG-16). |
| DE-R-002 | Domestic German invoices on Peppol need the seller contact group (BG-6). |
| DE-R-015 | Domestic German invoices on Peppol need a buyer reference (BT-10), mirroring BR-DE-15. |
Glossary
A short, plain-language reference for the standards and terms behind the identifiers and rules above. If a word in the docs is unfamiliar, it is probably explained here.
How a new specification version rolls out
Authorities announce new versions months before they become binding and define a transition window in which both versions are accepted. The API mirrors that lifecycle exactly:
| Phase | What happens |
|---|---|
| 1. Published | The authority publishes the new version (for example, KoSIT announces XRechnung 4.0). We build and verify the new rule artifacts during the official transition window, ahead of the mandatory date. |
| 2. Effective date | On the authority's effective date, the API switches: requests start producing and validating the new version automatically. The switch is announced ahead of time in the changelog and by email, and the date is the regulator's, not ours. |
| 3. Transition | Both versions remain legally valid at the receivers during the authority's transition window, so documents created before the switch stay accepted until the sunset date. |
| 4. Sunset | After the sunset date, documents still declaring the retired version are reported as retired by the validation endpoints, never silently passed. |
Most updates are not new specification versions but maintenance releases of the validation artifacts: OpenPeppol ships rule updates twice a year with stated effective dates, the CEN EN 16931 Schematron gets periodic fix releases, and SI-UBL follows the Peppol calendar. These change which documents pass validation, but never the API contract: no request field, identifier or response shape moves.
Profiles: the other axis
Versions answer "which revision of a rule set"; profiles answer "which rule set". On
POST /v1/create/ubl, options.profile selects the
CIUS: peppol-bis-3 (default), en16931,
nlcius, ehf, xrechnung
or pint. On the validation endpoints there is nothing to select at all: the
profile is detected from the document's specification identifier (BT-24), the matching rules are applied,
and the response reports what ran in data.profile and
data.customizationId. Documents declaring a profile we have no dedicated
rules for are validated against the EN 16931 base rules and flagged with a
PROFILE-DETECTION warning instead of being rejected.
Standards and formats
| Term | Definition |
|---|---|
| EN 16931 | The European standard that defines the semantic data model of an electronic invoice: what fields exist and what they mean. Every format below is a way of expressing an EN 16931 invoice. |
| CII | Cross Industry Invoice, a UN/CEFACT XML syntax for invoices. It is the XML carried inside Factur-X and ZUGFeRD files. |
| UBL | Universal Business Language, the OASIS XML syntax for invoices. The other EN 16931 syntax, used widely on the Peppol network. |
| Factur-X | A Franco-German hybrid invoice: a PDF/A-3 document with an EN 16931 CII XML file embedded inside it. |
| ZUGFeRD | The German name for the same hybrid standard as Factur-X. ZUGFeRD 2.x and Factur-X are technically identical. |
| XRechnung | The German specification for invoicing public-sector buyers (B2G). A pure XML invoice, in either CII or UBL syntax, with extra German-specific rules. |
| Peppol BIS | The Peppol Business Interoperability Specification, a UBL-based profile used to exchange invoices over the Peppol network across borders. |
| PDF/A-3 | An ISO archival PDF format that allows other files to be embedded inside it. It is what lets a hybrid invoice carry its XML. |
Terms and concepts
| Term | Definition |
|---|---|
| BT (Business Term) | A single piece of invoice data. For example, BT-1 is the invoice number and BT-5 is the currency. |
| BG (Business Group) | A group of related Business Terms. For example, BG-4 groups all the seller fields together. |
| BR (Business Rule) | A validation rule from EN 16931. For example, BR-06 requires that an invoice contain the seller name. A failed BR is what produces a validation error. |
| CIUS | Core Invoice Usage Specification, a national or sector-specific tightening of EN 16931. XRechnung and Peppol BIS are both a CIUS. |
| Schematron | The rule language the EN 16931 business rules are written in. The validation endpoints run Schematron against your invoice. |
| Profile | A Factur-X / ZUGFeRD conformance level (MINIMUM, BASIC WL, BASIC, EN 16931, EXTENDED) that determines which fields an invoice is allowed to carry. |
| Hybrid invoice | A single PDF that is both human-readable (the visible page) and machine-readable (the embedded XML). Factur-X and ZUGFeRD are hybrid invoices. |
| Leitweg-ID | The routing identifier a German public-sector buyer issues. It is carried in the buyer reference (BT-10) and is required by XRechnung. |
| Finding | One entry in the errors or warnings array of an API response, describing a single validation issue. See Error Handling. |