Every EN 16931 data element, and the rules that check it
111 business terms and business groups —
89 BT elements and 22
BG groups — each listed with every rule id that names it. That is
682 term-to-rule links, recovered from the
1,792 assertions the European Commission publishes
for CII and UBL. Look up BT-126 and you get its name and the rules that
fail when it is missing; look up BR-CO-17 and you get every element it
touches.
The index
Nothing matches everything in the box. The search needs every word to appear somewhere in a row, so try dropping one — or search a rule id, which works too.
How this index was built, and where its names come from
Every assertion says which elements it is about, in parentheses:
[BR-02]-An Invoice shall have an Invoice number (BT-1). Those references
are collected mechanically from all 1,792 assertions,
so the fourth column is not editorial — it is exactly the set of rule ids whose text
names that term, with an id counted once whether it appears in the CII file, the UBL
file or both.
The names in the second column are the artefacts' own wording,
recovered from those same sentences: for each term, the phrase sitting in front of its
references, with the wording the assertions use most often winning. This page does not
reproduce the EN 16931 term model spreadsheet and does not paraphrase it into its
own house style. That has two consequences worth knowing. A name here can differ
slightly from the model document, because the assertions themselves differ slightly —
BT-106 is Sum of Invoice line net amount in the rules. And a term no assertion
names is absent: BT-4, the business process type code, is named by no
assertion of the norm, so it has no rule ids to list and does not appear.
Two artefacts of the CII datatype rules name BT-125-1 and
BT-125-2, which are not model terms; they are excluded rather than folded
into BT-125. Four assertions cite a term bare — “Only one BT-41 element is allowed
on an invoice” — and contribute a rule id but no wording. Both choices are in
scripts/build-terms.mjs,
which is what generated terms.json and
terms.csv below.
These are the norm's assertions only. Germany's XRechnung and Peppol BIS Billing 3.0 cite the same elements in rules of their own; the rule-set comparison counts what they add, and the validator runs all of it.
The data
terms.csv and
terms.json are the files these rows
are built from: 111 records with id,
kind, name, ruleCount, rules and
syntaxes. The JSON keeps the rule list as a list; the CSV writes it
space-separated for a spreadsheet. Both are generated from
rules.json, which is the
1,792-assertion list on the
rule reference page, so an element index and a rule
list can never be a release apart from each other.
The assertions these names come from are the European Commission's EN 16931 Schematron artefacts (EUPL 1.2), embedded unmodified in the invoicekit.go v0.2.9 engine this site runs. Keep that attribution if you republish the wording.
Questions people ask about this list
What is the difference between a BT and a BG?
A BT (business term) is one value: BT-1 is the invoice
number, BT-126 the invoice line identifier. A BG (business
group) is a bundle of terms that repeats: BG-25 is the invoice line, and
each line carries its own BT-126, BT-153,
BT-129 and so on. In XML, a BG is the parent element and its BTs are the
child elements or attributes under it — which is why a rule can complain about a group
being absent (BG-23, the VAT breakdown) as well as about a single value
inside it.
Where do these names come from?
From the assertions. Every published rule names the elements it checks, so “An Invoice shall have an Invoice number (BT-1)” is both the rule and the name. For each term the index takes the phrase that sits in front of its references and keeps the wording the artefacts repeat most often. That is deliberate: we quote the artefacts rather than retyping the term model, so a name here is traceable to a rule id you can look up in rules.csv.
A term I expected is missing. Is the list incomplete?
It is complete for what the norm's assertions name, and no more than that. Some
elements of the model are checked by no assertion that mentions them —
BT-4, the business process type code, is the usual example — so there is no
rule id to print against them and they are left out rather than padded with a name and
an empty column. Elements that a national profile or Peppol requires are the same
elements: see what XRechnung and Peppol BIS add.
Why does one element have 60 rules and another only one?
Because the norm checks some values from several directions. BT-118, the
VAT category code, is constrained by the cardinality rules, the decimal rules, and a
family of consistency rules (BR-CO-17, BR-IC-01,
BR-Z-01…) that compare the VAT breakdown with the lines, allowances and
charges. Each id is counted once, whether it appears in the CII Schematron, the UBL one
or both; the “Applies to” column says which.
Can I download this index?
Yes — terms.csv and terms.json above, generated on every build from rules.json. Quote the artefact version rather than the page: the Commission renumbers and rewords assertions between releases, which is why the engine this page is built from is pinned to an exact version.
Can I check my invoice against these elements?
Yes — the validator runs the assertions listed here against a CII or UBL file in the browser and reports the rule ids, not a generic “invalid XML”. It also converts between the two syntaxes and checks Factur-X PDF/A-3 attachments. The engine is MIT licensed in Go if you would rather run it yourself.