BR-DE-26: Rechnungskorrektur (384) ohne Verweis auf die…

StandardXRechnung 3.0.2 (KoSIT, deutsche CIUS der EN 16931)SchweregradWarnung: die Rechnung wird angenommen, sollte aber korrigiert werdenSyntaxUBL, CIIGeschäftsbegriffe

BG-3 Preceding invoice reference
BT-3 Invoice type code

Gilt fürXRechnung in UBL- oder CII-Syntax, einschließlich ZUGFeRD-/Factur-X-PDFs mit dem Profil XRECHNUNG. Rechnungen an deutsche öffentliche Auftraggeber (Bund, Länder, Kommunen) müssen sie bestehen.

Offizieller Regeltext

[BR-DE-26] Wenn im Element "Invoice type code" (BT-3) der Code 384 (Corrected invoice) übergeben wird, soll PRECEDING INVOICE REFERENCE BG-3 mind. einmal vorhanden sein.

Warum dieser Fehler auftritt

Ist der Rechnungstyp-Code (BT-3) 384 (Rechnungskorrektur), erwartet XRechnung mindestens einen Verweis auf die Vorgängerrechnung (BG-3), damit der Empfänger die Korrektur dem Original zuordnen kann. Die Regel sucht cac:BillingReference/cac:InvoiceDocumentReference (UBL) bzw. ram:ApplicableHeaderTradeSettlement/ram:InvoiceReferencedDocument (CII), sobald der Typcode 384 ist. Sie schlägt fehl, wenn die ursprüngliche Rechnungsnummer nur in einer Bemerkung oder im Positionstext erwähnt wird.

So beheben Sie den Fehler

In UBL cac:BillingReference/cac:InvoiceDocumentReference mit cbc:ID (Nummer der korrigierten Rechnung, BT-25) und cbc:IssueDate (BT-26) nach cac:OrderReference ergänzen. In CII ram:InvoiceReferencedDocument mit ram:IssuerAssignedID und ram:FormattedIssueDateTime/qdt:DateTimeString format="102" innerhalb von ram:ApplicableHeaderTradeSettlement anlegen. Ein Verweis je korrigierter Rechnung; bei nur teilweiser Stornierung ggf. stattdessen eine Gutschrift (381) mit demselben Verweis senden. Es ist eine Warnung, Behörden bestehen aber in der Regel darauf.

Beispiel (gültig)

<cbc:InvoiceTypeCode>384</cbc:InvoiceTypeCode>
...
<cac:BillingReference>
  <cac:InvoiceDocumentReference>
    <cbc:ID>RE-2026-00100</cbc:ID>
    <cbc:IssueDate>2026-09-30</cbc:IssueDate>
  </cac:InvoiceDocumentReference>
</cac:BillingReference>

Was der Validator prüft

Geprüftes Element (Kontext):

UBL

/ubl:Invoice | /cn:CreditNote

Test (XPath):

((not(normalize-space(cbc:InvoiceTypeCode) = '384' or normalize-space(cbc:CreditNoteTypeCode) = '384') or                     (cac:BillingReference/cac:InvoiceDocumentReference)))

CII

/rsm:CrossIndustryInvoice

Test (XPath):

not(normalize-space(rsm:ExchangedDocument/ram:TypeCode) = '384') or                     (rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:InvoiceReferencedDocument)

Rechnung prüfen

Legen Sie Ihre XML- oder PDF-Datei im Validator ab; jede verletzte Regel ist mit ihrer Seite hier verlinkt. Kostenlos, ohne Konto, die Datei wird nicht gespeichert.

Rechnung prüfen →

Dieselbe Prüfung per API:

curl -F file=@invoice.xml https://einvoicechecker.com/v1/validate

Häufige Fragen

Was bedeutet BR-DE-26?

BR-DE-26 ist eine XRechnung-Regel: Wenn im Element "Invoice type code" (BT-3) der Code 384 (Corrected invoice) übergeben wird, soll PRECEDING INVOICE REFERENCE BG-3 mind. einmal vorhanden sein.

Wird meine Rechnung wegen BR-DE-26 abgelehnt?

Nein. BR-DE-26 ist eine Warnung: Die Rechnung wird angenommen, der Empfänger sieht aber den Hinweis. Beheben Sie ihn trotzdem, Warnungen werden in späteren Versionen oft zu Fehlern.

Für welche Formate gilt BR-DE-26?

XRechnung in UBL- oder CII-Syntax, einschließlich ZUGFeRD-/Factur-X-PDFs mit dem Profil XRECHNUNG. Rechnungen an deutsche öffentliche Auftraggeber (Bund, Länder, Kommunen) müssen sie bestehen. Syntax: UBL und CII.

Quelle: XRechnung 3.0.2, schematron 2.6.0 (KoSIT, September 2026). Katalog erzeugt aus dem offiziellen Schematron am 2026-10-14.

BR-DE-26: Rechnungskorrektur (384) ohne Verweis auf die Vorgängerrechnung