BR-02: Rechnungsnummer (BT-1) fehlt

Ohne Rechnungsnummer ist eine Rechnung weder steuerlich gültig noch maschinell zuordenbar. Entsprechend kompromisslos ist die Prüfung: kein Wert, keine gültige E-Rechnung.

Was die Regel prüft

BT-1 (BT = Business Term, das nummerierte Feld der Norm EN 16931) muss vorhanden und nicht leer sein. Die Rechnungsnummer identifiziert die Rechnung eindeutig und steht in der CII-Syntax in rsm:ExchangedDocument/ram:ID. Über das Format sagt BR-02 nichts: Buchstaben, Ziffern, Binde- und Schrägstriche sind erlaubt. Die deutschen Anforderungen aus §14 UStG (fortlaufend, einmalig vergeben) prüft der Validator nicht, sie gelten aber trotzdem.

Warum sie in der Praxis fehlschlägt

Der Klassiker ist ein Export im falschen Moment: Viele Systeme vergeben die Rechnungsnummer erst beim Festschreiben. Wird vorher ein Entwurf als XML exportiert oder ein Testlauf verschickt, ist das Feld noch leer. Der zweite häufige Fall sind Eigenentwicklungen und Konverter, bei denen das Mapping auf ram:ID fehlt oder auf ein falsches Quellfeld zeigt, etwa die interne Belegnummer statt der Rechnungsnummer. Drittens: Das Element ist vorhanden, aber leer (<ram:ID/>), weil das Template es immer anlegt. Dann melden PEPPOL-Profile zusätzlich PEPPOL-EN16931-R008.

So behebst du den Fehler

Stell sicher, dass die Rechnung vor dem Export festgeschrieben ist und eine Nummer trägt. Bei eigenem Mapping: Quellfeld prüfen und leere Werte hart abfangen, statt ein leeres Element zu schreiben. Eine Rechnung ohne Nummer sollte dein System gar nicht erst erzeugen, denn nachträgliches Ergänzen im XML ändert nichts daran, dass auch das archivierte Original die Nummer braucht.

XML-Beispiel: vorher und nachher

<rsm:ExchangedDocument>
  <ram:ID></ram:ID><!-- verletzt BR-02: Rechnungsnummer leer -->
  <ram:TypeCode>380</ram:TypeCode>
  <!-- … -->
</rsm:ExchangedDocument>

<rsm:ExchangedDocument>
  <ram:ID>RE-2026-0142</ram:ID>
  <ram:TypeCode>380</ram:TypeCode>
  <!-- … -->
</rsm:ExchangedDocument>