What is BT-24 (Specification Identifier)?
BT-24 is one of the most consequential fields in an EN 16931 e-invoice. It carries a URN-like identifier that declares which specification the invoice was generated against — the base EN 16931 standard, a national CIUS (such as XRechnung or Factur-X), a sector-specific profile (Peppol BIS 3.0), or an extension.
In the EN 16931 semantic model, BT-24 is defined as:
> An identification of the specification containing the total set of rules regarding semantic content, cardinalities and business rules to which the data contained in the instance document conforms.
BT-24 is mandatory (cardinality 1..1). Every EN 16931-compliant invoice — UBL or CII — must include exactly one BT-24 value.
Why BT-24 Matters
BT-24 is the first field a validator reads. It determines which rule set the validation engine applies:
An invoice that uses a XRechnung-specific feature (e.g., the Leitweg-ID in BT-10) but declares urn:cen.eu:en16931:2017 as its BT-24 will fail — the XRechnung rules that require the Leitweg-ID are never loaded, and unrelated rules may fire incorrectly.
Conversely, an invoice that declares XRechnung in BT-24 but omits the Leitweg-ID will be rejected for violating BR-DE-15 — a rule that the invoice author didn't realize they had opted into.
Pick the wrong BT-24 value and your invoice is validated against the wrong rulebook. This is one of the most common root causes of "why did this invoice pass validation on my system but fail downstream" incidents.
Well-Known BT-24 Values
The following values are the most common in EU e-invoicing. Exact strings matter — a typo invalidates the declaration.
urn:cen.eu:en16931:2017 urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_3.0 urn:cen.eu:en16931:2017#conformant#urn:xoev-de:kosit:standard:xrechnung_3.0 urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basicurn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:en16931 urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extendedurn:cen.eu:en16931:2017#compliant#urn:zugferd.de:2p1:basic urn:cen.eu:en16931:2017#compliant#urn:zugferd.de:2p1:en16931urn:cen.eu:en16931:2017#compliant#urn:fdc:nen.nl:nlcius:v1.0 urn:cen.eu:en16931:2017#compliant#urn:cen.eu:en16931:2017:extended:urn:fattura-pa.it:FatturaPA:v1.2.1The #compliant# vs #conformant# Distinction
Note the two separators:
#compliant# indicates a CIUS — a restriction of EN 16931. The CIUS narrows cardinalities, adds business rules, or restricts code lists, but never adds new data elements. An invoice that is compliant with the CIUS is also compliant with EN 16931.#conformant# indicates an extension — EN 16931 plus additional data elements. A conformant extension may add fields that are not in the base standard. An invoice using extension fields is not strictly EN 16931.Getting the separator right matters: mixing them up silently changes how downstream systems interpret the document.
XML Mapping
UBL Syntax
In UBL 2.1 (used by XRechnung, Peppol BIS, NLCIUS), BT-24 is carried in the element at the root of the invoice:
urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0
urn:fdc:peppol.eu:2017:poacc:billing:01:1.0
INV-2026-0001
...
Note the related BT-23 (ProfileID) — this identifies the business process, not the specification. The two are frequently confused.
CII Syntax
In UN/CEFACT Cross Industry Invoice (used by ZUGFeRD, Factur-X), BT-24 is carried in the GuidelineSpecifiedDocumentContextParameter:
urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:en16931
Common Validation Errors
BR-01 fires when BT-24 is missing entirely — a common mistake when converting from legacy formats or when the CustomizationID element is empty.
PEPPOL-EN16931-R004 is stricter: it requires BT-24 to exactly match the Peppol BIS 3.0 identifier. An invoice declaring generic EN 16931 (urn:cen.eu:en16931:2017) will be rejected by a Peppol Access Point even though the invoice is otherwise valid.
BT-24 vs. BT-23 (Profile Identifier)
BT-24 and BT-23 are often confused:
urn:fdc:peppol.eu:2017:poacc:billing:01:1.0 for a standard Peppol billing process).Treat them as orthogonal. BT-24 answers "how was this generated?"; BT-23 answers "what is this for?"
What ERP Developers Need to Know
1. Always populate BT-24. Empty or missing values fail BR-01 immediately. Default to the most specific CIUS your target network requires.
2. Match the rulebook your customer expects. If your customer's Peppol Access Point enforces PEPPOL-EN16931-R004, you must declare the exact Peppol BIS 3.0 URN — generic EN 16931 is not enough.
3. Keep a versioned lookup table. Hard-coding BT-24 values is fragile. Maintain a central table of valid URNs per CIUS version, per country, and bump versions as CIUS releases evolve (e.g., XRechnung 2.3 → 3.0).
4. Validate with the correct rule set. If you run Schematron validation internally, load the rule set that matches the BT-24 value. Validating a Peppol invoice against base EN 16931 rules will miss Peppol-specific failures.
5. Never lie about BT-24. Declaring Peppol BIS when the invoice omits required Peppol fields (like BT-10) will be rejected at the Access Point. Declare what you actually produce — and produce what you declare.
6. Inspect BT-24 on receipt. When your ERP receives an invoice, read BT-24 first to determine how to interpret optional fields, code lists, and extension elements. Don't assume every inbound EN 16931 invoice follows the same profile.