BR-DE-21: Spezifikationskennung BT-24 entspricht nicht XRechnung
BT-24 sagt dem Empfänger, nach welchem Regelwerk die Rechnung erstellt wurde. BR-DE-21 meldet, dass dort keine der Kennungen steht, die das XRechnung-Schematron 2.6.0 für XRechnung 3.0 kennt.
[BR-DE-21] Das Element "Specification identifier" (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen.
Betroffen:BT-24
Was die Regel prüft
Geprüft wird die Spezifikationskennung (BT-24): in UBL cbc:CustomizationID, in CII rsm:ExchangedDocumentContext/ram:GuidelineSpecifiedDocumentContextParameter/ram:ID. Der Wert muss Zeichen für Zeichen einer dieser Kennungen entsprechen:
| Variante | Kennung in BT-24 |
|---|---|
| CIUS XRechnung | urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0 |
| Extension XRechnung | urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0#conformant#urn:xeinkauf.de:kosit:extension:xrechnung_3.0 |
| XRechnung CVD | urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0#compliant#urn:xeinkauf.de:kosit:xrechnung:cvd_0.9 |
Die Version lautet in der Kennung nur 3.0, obwohl die aktuelle Fassung 3.0.2 heißt. Patch-Stände tauchen nicht auf; das Schematron setzt XR-MAJOR-MINOR-VERSION auf 3.0. Verglichen wird ohne Normalisierung, ein Leerzeichen oder Zeilenumbruch im Element reicht für die Meldung.
BR-DE-21 ist als Warnung eingestuft, das eigentliche Problem wiegt aber schwerer. Die Validator-Konfiguration 2026-08-31 wählt das Prüfszenario anhand genau dieser Kennung (Datei scenarios.xml). Bei urn:cen.eu:en16931:2017 prüft sie nur nach EN 16931 ohne die deutschen Regeln. Bei jedem anderen Wert findet sie kein Szenario und empfiehlt „reject“. Die Meldung BR-DE-21 selbst sehen Sie daher vor allem in Werkzeugen, die die XRechnung-Regeln unabhängig von BT-24 anwenden.
Typische Ursachen
xrechnung_3.0.2oderxrechnung_3.0.1stattxrechnung_3.0: Die Software setzt die vollständige Versionsnummer ein.- Eine Kennung aus XRechnung 2.x wie
…kosit:xrechnung_2.3, weil die Exportvorlage beim Wechsel auf 3.0 nicht angepasst wurde. - Verwechslung mit BT-23: Die Prozesskennung
urn:fdc:peppol.eu:2017:poacc:billing:01:1.0auscbc:ProfileIDbzw.ram:BusinessProcessSpecifiedDocumentContextParametersteht in BT-24. - Eine ZUGFeRD- oder Factur-X-Profilkennung in einer Datei, die als XRechnung gelten soll. Welche Profile es gibt, steht unter ZUGFeRD-Profile.
- Eine Vorlage mit Einrückung schreibt Leerraum vor oder hinter die Kennung in das Element.
- Extension-Inhalte wie Unterpositionen werden genutzt, BT-24 nennt aber nur die CIUS-Kennung. Dann prüft der Validator gegen die falschen Regeln und meldet Folgefehler an anderer Stelle.
Beispiel aus der KoSIT-Testsuite
Testdatei 01.01a ist eine einfache Rechnung nach CIUS XRechnung. BT-23 (cbc:ProfileID) und BT-24 stehen in UBL direkt untereinander, genau hier passieren die meisten Verwechslungen:
<?xml version="1.0" encoding="UTF-8"?>
<ubl:Invoice xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
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>123456XX</cbc:ID>Quelle: KoSIT XRechnung-Testsuite 2026-08-31, Datei instances/standard/01.01a-INVOICE_ubl.xml (Apache 2.0)
<rsm:ExchangedDocumentContext>
<ram:BusinessProcessSpecifiedDocumentContextParameter>
<ram:ID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</ram:ID>
</ram:BusinessProcessSpecifiedDocumentContextParameter>
<ram:GuidelineSpecifiedDocumentContextParameter>
<ram:ID>urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>Quelle: KoSIT XRechnung-Testsuite 2026-08-31, Datei instances/standard/01.01a-INVOICE_uncefact.xml (Apache 2.0)
Die Rechnungen mit Unterpositionen in der Testsuite, etwa 04.01a, tragen die längere Extension-Kennung mit #conformant#urn:xeinkauf.de:kosit:extension:xrechnung_3.0 am Ende.
Lösung
In der Rechnungssoftware
- Wählen Sie beim Export ausdrücklich XRechnung 3.0 als Format. Viele Programme bieten EN 16931, ZUGFeRD und XRechnung als getrennte Ausgaben an.
- Prüfen Sie nach einem Update der Software, ob der Export noch die Kennung
xrechnung_3.0schreibt.
Im XML
- UBL:
cbc:CustomizationIDmit einer der drei Kennungen aus der Tabelle füllen, ohne Leerraum davor oder dahinter. - CII: denselben Wert in
ram:GuidelineSpecifiedDocumentContextParameter/ram:IDschreiben, nicht in den Business-Process-Parameter. - Hinterlegen Sie die Kennung als feste Zeichenkette im Code, statt sie aus Versionsnummern zusammenzusetzen.
- Prüfen Sie die Datei danach mit XRechnung prüfen; mit korrekter Kennung laufen alle deutschen BR-DE-Regeln, und Folgefehler aus anderen Regeln werden erst jetzt sichtbar.
Quellen
- XRechnung-Schematron 2.6.0 (Release v2.6.0, kompatibel mit XRechnung 3.0)KoSIT (GitHub itplr-kosit), 2. September 2026 · geprüft am 7. November 2026
- Validator-Konfiguration XRechnung 2026-08-31 (Release v2026-08-31)KoSIT (GitHub itplr-kosit), 2. September 2026 · geprüft am 7. November 2026
- Spezifikation XRechnung 3.0.2 (CIUS und Extension), Abschnitt 11.27 „Gruppe PROCESS CONTROL“ (BT-24) und Abschnitt 12.6KoSIT (xeinkauf.de), 20. Juni 2024 · geprüft am 7. November 2026
- XRechnung-Testsuite 2026-08-31 (Release v2026-08-31)KoSIT (GitHub itplr-kosit), 2. September 2026 · geprüft am 7. November 2026