Glossary Term

BT-24 Specification Identifier

BT-24 is the mandatory EN 16931 field that declares which specification — the base standard, a CIUS (like XRechnung or Peppol BIS), or an extension — an invoice claims to conform to. Validators use it to choose which rule set to apply, so an incorrect value leads to the wrong validation or outright rejection.

Quick Facts

Name
Specification identifier
CII path
ExchangedDocumentContext/GuidelineSpecifiedDocumentContextParameter/ID
UBL path
/Invoice/cbc:CustomizationID
Data type
Identifier (URN)
Cardinality
1..1 (mandatory)
Parent group
BG-1 (Invoice, root)
Business term
BT-24
Primary purpose
Declares which rulebook (CIUS/extension) applies
Key validation rule
BR-01

Definition

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:

  • If BT-24 declares Peppol BIS 3.0, the validator loads Peppol-specific Schematron rules.

  • If BT-24 declares XRechnung 3.0, the validator loads the XRechnung rule set (including BR-DE-* rules).

  • If BT-24 declares Factur-X EN16931, the validator applies the base EN 16931 rules plus Factur-X constraints.

  • If BT-24 declares the base EN 16931 without a CIUS, only the core EN 16931 rules apply.
  • 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.

    Specification BT-24 Value ----------------------------
    EN 16931 (base, no CIUS) urn:cen.eu:en16931:2017 Peppol BIS Billing 3.0 urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0
    XRechnung 3.0 (UBL) urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_3.0 XRechnung 3.0 (CII) same value; applies to both UBL and CII syntaxes
    XRechnung extension urn:cen.eu:en16931:2017#conformant#urn:xoev-de:kosit:standard:xrechnung_3.0 Factur-X BASIC urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:basic
    Factur-X EN 16931 urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:en16931 Factur-X EXTENDED urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended
    ZUGFeRD 2.x BASIC urn:cen.eu:en16931:2017#compliant#urn:zugferd.de:2p1:basic ZUGFeRD 2.x EN 16931 urn:cen.eu:en16931:2017#compliant#urn:zugferd.de:2p1:en16931
    NLCIUS (Netherlands) urn:cen.eu:en16931:2017#compliant#urn:fdc:nen.nl:nlcius:v1.0 Italian FatturaPA urn:cen.eu:en16931:2017#compliant#urn:cen.eu:en16931:2017:extended:urn:fattura-pa.it:FatturaPA:v1.2.1

    The #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

    Error Code Rule Description
    ------------------------------
    BR-01 EN 16931 An Invoice shall have a Specification identifier (BT-24)
    PEPPOL-EN16931-R001 Peppol Business process (BT-23) must be provided
    PEPPOL-EN16931-R004 Peppol Specification identifier (BT-24) must have a prescribed value

    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:

  • BT-24 (Specification identifier)which rulebook does this invoice follow? Identifies the format/CIUS/extension.

  • BT-23 (Business process type)what business process is this invoice part of? Identifies the role of the document in a workflow (e.g., 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.

    XML Examples

    UBL (Peppol, XRechnung)

    <!-- BT-24: Specification Identifier in UBL -->
    <!-- Example 1: Peppol BIS 3.0 -->
    <Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
      <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0</cbc:CustomizationID>
      <cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
      ...
    </Invoice>
    
    <!-- Example 2: XRechnung 3.0 (CIUS) -->
    <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_3.0</cbc:CustomizationID>
    
    <!-- Example 3: Base EN 16931 (no CIUS) -->
    <cbc:CustomizationID>urn:cen.eu:en16931:2017</cbc:CustomizationID>
    
    <!-- Example 4: XRechnung extension (adds fields beyond EN 16931) -->
    <cbc:CustomizationID>urn:cen.eu:en16931:2017#conformant#urn:xoev-de:kosit:standard:xrechnung_3.0</cbc:CustomizationID>

    CII (ZUGFeRD, Factur-X)

    <!-- BT-24: Specification Identifier in CII -->
    <!-- Example 1: Factur-X EN 16931 profile -->
    <rsm:ExchangedDocumentContext>
      <ram:GuidelineSpecifiedDocumentContextParameter>
        <ram:ID>urn:cen.eu:en16931:2017#compliant#urn:factur-x.eu:1p0:en16931</ram:ID>
      </ram:GuidelineSpecifiedDocumentContextParameter>
    </rsm:ExchangedDocumentContext>
    
    <!-- Example 2: ZUGFeRD 2.1 BASIC -->
    <rsm:ExchangedDocumentContext>
      <ram:GuidelineSpecifiedDocumentContextParameter>
        <ram:ID>urn:cen.eu:en16931:2017#compliant#urn:zugferd.de:2p1:basic</ram:ID>
      </ram:GuidelineSpecifiedDocumentContextParameter>
    </rsm:ExchangedDocumentContext>
    
    <!-- Example 3: Factur-X EXTENDED (conformant extension) -->
    <ram:ID>urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended</ram:ID>

    Related Content