Startseite › Wissen › BR-DE-21

BR-DE-21: Spezifikationskennung (BT-24) passt nicht zu XRechnung

Die Spezifikationskennung (BT-24, UBL cbc:CustomizationID, CII ram:GuidelineSpecifiedDocumentContextParameter/ram:ID) sagt dem Empfänger, nach welchem Standard die Rechnung aufgebaut ist. Für XRechnung 3.0 lautet sie urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0. Wichtig: Im offiziellen KoSIT-Validator wird das Prüfszenario anhand genau dieser Kennung ausgewählt. Bei einer abweichenden Kennung erscheint deshalb meist nicht BR-DE-21, sondern die Meldung, dass kein passendes Prüfszenario gefunden wurde.

Originaltext der Regel

Warnung BR-DE-21 · Herkunft: XRechnung (deutsche Regel der KoSIT)

Das Element "Specification identifier" (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen.

Technische Prüfung (Schematron/XPath)

Regelwerk	Kontext	Test
XRechnung, UBL	`/ubl:Invoice \| /cn:CreditNote`	`cbc:CustomizationID = $XR-CIUS-ID or cbc:CustomizationID = $XR-EXTENSION-ID or cbc:CustomizationID = $XR-CVD-ID`
XRechnung, CII	`/rsm:CrossIndustryInvoice/rsm:ExchangedDocumentContext`	`ram:GuidelineSpecifiedDocumentContextParameter/ram:ID = $XR-CIUS-ID or ram:GuidelineSpecifiedDocumentContextParameter/ram:ID = $XR-EXTENSION-ID or ram:GuidelineSpecifiedDocumentContextParameter/ram:ID = $XR-CVD-ID`

Aus der offiziellen XRechnung 3.0.2 (KoSIT-Konfiguration 2026-08-31).

Typische Ursachen

Veraltete Kennung aus XRechnung 2.x (urn:xoev-de:kosit:standard:xrechnung_2.x).
Tippfehler, Leerzeichen oder eine zusätzliche Versionsnummer in der Kennung.
Eine ZUGFeRD-Kennung (z. B. EN-16931-Profil) bei einer Datei, die als XRechnung verschickt werden soll.

So beheben Sie den Fehler

Kennung für XRechnung 3.0 exakt übernehmen (siehe Beispiel).
Software auf eine Version mit XRechnung 3.0 aktualisieren – ältere Versionen erzeugen oft noch die 2.x-Kennung.
Für ZUGFeRD-Dateien ist die Kennung des jeweiligen Profils korrekt; dann gelten die EN-16931-Regeln statt der XRechnung-Regeln.

Beispiel: vorher und nachher

Fehlerhaft

           xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
           xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_2.3</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
<cbc:ID>RE-2026-0042</cbc:ID>

Korrigiert

           xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
           xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>
<cbc:ID>RE-2026-0042</cbc:ID>

Ausschnitt aus einer vollständigen XRechnung 3.0 (UBL). Ergebnis mit dem KoSIT-Validator: Für die fehlerhafte Variante wird kein Prüfszenario gefunden (die Datei wird abgewiesen); die korrigierte Variante wird akzeptiert.

Häufige Fragen

Was macht dieser Prüfer bei einer veralteten Kennung?

Er prüft XRechnung-2.x-Dateien gegen die Regeln von XRechnung 3.0 und weist im Bericht deutlich darauf hin, dass die Kennung veraltet ist.

Hintergrund: XRechnung vs. ZUGFeRD: Welches Format passt?