Zum Inhalt springen

BR-DE-30: Gläubiger-ID fehlt bei SEPA-Lastschrift

Wer per SEPA-Lastschrift einzieht, muss in der XRechnung seine Gläubiger-Identifikationsnummer angeben (BT-90, „Gläubiger-ID“). BR-DE-30 ist eine Fehlerregel und schlägt an, wenn Lastschriftdaten vorhanden sind, diese Nummer aber fehlt.

Stand:

BR-DE-30· XRechnung-Schematron 2.6.0 (XRechnung 3.0.2, Validator-Konfiguration XRechnung 2026-08-31)
[BR-DE-30] Wenn "DIRECT DEBIT" BG-19 vorhanden ist, dann muss "Bank assigned creditor identifier" BT-90 übermittelt werden.

Betroffen:BG-19BT-90

Was die Regel prüft

UBL: BG-19 gilt als vorhanden, sobald irgendein cac:PaymentMeans/cac:PaymentMandate existiert. Dann muss es cac:AccountingSupplierParty/cac:Party/cac:PartyIdentification/cbc:ID[@schemeID='SEPA'] beim Verkäufer oder cac:PayeeParty/cac:PartyIdentification/cbc:ID[@schemeID='SEPA'] beim Zahlungsempfänger geben. Entscheidend ist das Attribut schemeID="SEPA", eine Kennung ohne dieses Attribut zählt nicht.

CII: Für BG-19 gibt es keine eigene Klammer. Das Schematron wertet deshalb drei Felder aus: Mandatsreferenz ram:SpecifiedTradePaymentTerms/ram:DirectDebitMandateID (BT-89), Gläubiger-ID ram:ApplicableHeaderTradeSettlement/ram:CreditorReferenceID (BT-90) und Kunden-IBAN ram:PayerPartyDebtorFinancialAccount/ram:IBANID (BT-91). Kommt keines vor, ist die Regel erfüllt. Kommt eines vor, müssen BT-90 und mindestens eines der beiden anderen vorhanden sein.

Bedingung von BR-DE-30 im CII-Schematron
(($BT-89-path or $BT-91-path) and $BT-90-path) or $BG-19-not-existing

Daraus folgt eine Besonderheit: Steht in einer CII-Rechnung nur ram:CreditorReferenceID, etwa als fester Teil der Firmendaten auf einer Überweisungsrechnung, meldet der Validator BR-DE-30, obwohl die Gläubiger-ID vorhanden ist. Die Bedingung verlangt neben BT-90 auch BT-89 oder BT-91.

Den Aufbau der Gläubiger-ID prüft die Regel nicht. Die Testdateien verwenden Platzhalter wie [Bank assigned creditor identifier] oder ID123456.

Typische Ursachen

  • UBL: Die Gläubiger-ID wird als cac:PartyIdentification/cbc:ID ohne schemeID oder mit einem anderen Schema wie 0088 ausgegeben.
  • UBL: Die Gläubiger-ID landet in cac:PaymentMandate/cbc:ID statt der Mandatsreferenz oder im Verwendungszweck cbc:PaymentID.
  • Ein abweichender Zahlungsempfänger (BG-10) zieht die Lastschrift ein. Das Programm exportiert aber nur die Verkäuferdaten, die Gläubiger-ID des Zahlungsempfängers fehlt.
  • CII: Die Gläubiger-ID steht nur im Freitext der Zahlungsbedingungen.
  • CII: Die Gläubiger-ID ist in allen Rechnungen hinterlegt, auch bei Zahlungsart 58. Dann melden sich BR-DE-30 und BR-DE-31, obwohl keine Lastschrift gemeint ist, und zusätzlich BR-DE-23.

Beispiel aus der KoSIT-Testsuite

Testdatei 03.01a ist eine Rechnung mit Lastschrift (Code 59). In UBL trägt der Verkäufer drei Kennungen; nur die dritte hat schemeID="SEPA" und erfüllt damit BR-DE-30.

UBL: Gläubiger-ID als Verkäuferkennung mit schemeID SEPA
<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="EM">[email protected]</cbc:EndpointID>
    <cac:PartyIdentification>
      <cbc:ID>[Seller identifier 1]</cbc:ID>
    </cac:PartyIdentification>
    <cac:PartyIdentification>
      <cbc:ID>[Seller identifier 2]</cbc:ID>
    </cac:PartyIdentification>
    <cac:PartyIdentification>
      <cbc:ID schemeID="SEPA">[Bank assigned creditor identifier]</cbc:ID>
    </cac:PartyIdentification>

Quelle: KoSIT XRechnung-Testsuite 2026-08-31, Datei instances/standard/03.01a-INVOICE_ubl.xml (Apache 2.0)

CII: Gläubiger-ID als ram:CreditorReferenceID
<ram:ApplicableHeaderTradeSettlement>
  <ram:CreditorReferenceID>[Bank assigned creditor identifier]</ram:CreditorReferenceID>
  <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
  <ram:SpecifiedTradeSettlementPaymentMeans>
    <ram:TypeCode>59</ram:TypeCode>
    <ram:PayerPartyDebtorFinancialAccount>
      <!-- dies ist eine nicht existerende aber valide IBAN als test dummy -->
      <ram:IBANID>DE79000000001234567890</ram:IBANID>
    </ram:PayerPartyDebtorFinancialAccount>
  </ram:SpecifiedTradeSettlementPaymentMeans>

Quelle: KoSIT XRechnung-Testsuite 2026-08-31, Datei instances/standard/03.01a-INVOICE_uncefact.xml (Apache 2.0)

In der CII-Datei folgt die Mandatsreferenz weiter unten in ram:SpecifiedTradePaymentTerms. Alle drei Felder sind da, BR-DE-30 und BR-DE-31 sind erfüllt.

Lösung

In der Rechnungssoftware

  1. Tragen Sie die Gläubiger-ID, die Sie für das SEPA-Lastschriftverfahren erhalten haben, in das dafür vorgesehene Feld der Firmenstammdaten ein.
  2. Zieht ein anderer Zahlungsempfänger ein, hinterlegen Sie dessen Gläubiger-ID beim Zahlungsempfänger.

Im XML

  1. UBL: <cac:PartyIdentification><cbc:ID schemeID="SEPA">…</cbc:ID></cac:PartyIdentification> beim Verkäufer oder bei cac:PayeeParty ergänzen.
  2. CII: ram:CreditorReferenceID in ram:ApplicableHeaderTradeSettlement vor ram:PaymentReference und ram:InvoiceCurrencyCode schreiben (Reihenfolge laut Schema), aber nur bei Rechnungen, die per Lastschrift bezahlt werden.
  3. Prüfen Sie mit XRechnung prüfen, ob BR-DE-30 verschwunden ist und keine der benachbarten Lastschriftregeln neu auftaucht.

XRechnung prüfen

Quellen

  1. 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
  2. Spezifikation XRechnung 3.0.2 (CIUS und Extension), Abschnitt 11.9 „Gruppe DIRECT DEBIT“ und Abschnitt 12.6KoSIT (xeinkauf.de), 20. Juni 2024 · geprüft am 7. November 2026
  3. XRechnung-Testsuite 2026-08-31 (Release v2026-08-31)KoSIT (GitHub itplr-kosit), 2. September 2026 · geprüft am 7. November 2026

Weiterlesen

Grundlage: EN 16931 und XRechnung-Schematron 2.6.0 (XRechnung 3.0.2, Validator-Konfiguration XRechnung 2026-08-31). Stand .