BR-DE-25-bWenn BT-81 "Payment means type code" einen Schlüssel für Lastschriften enthält (59), dürfen BG-17 und BG-18 nicht übermittelt werden.

Warum tritt BR-DE-25-b auf?

Der häufigste Fall der drei b-Regeln: die eigene Bankverbindung steht als BG-17 in jeder Rechnung, aus Gewohnheit — bei einer Lastschrift hat sie dort nichts zu suchen, eingezogen wird vom Konto des Käufers. In CII ist die Verbotsliste länger als in UBL: dort stehen neben dem Empfängerkonto und der Kartengruppe auch die Bank des Empfängers und die des Zahlers darauf, weil CII sie als eigene Elemente neben dem Konto führt statt darin.

Was der Validator prüft

Der Ausdruck, den das offizielle KoSIT-Regelwerk auswertet — nicht paraphrasiert, sondern aus der ausgelieferten Schematron-Datei gelesen. UBL und CII adressieren verschiedene Dokumentbäume, deshalb steht dieselbe Regel je Syntax anders da.

UBL

not(cac:PayeeFinancialAccount) and not(cac:CardAccount)

CII

not(ram:PayeePartyCreditorFinancialAccount) and not(ram:PayeeSpecifiedCreditorFinancialInstitution) and not(ram:PayerSpecifiedDebtorFinancialInstitution) and not(ram:ApplicableTradeSettlementFinancialCard)

Quelle: Regelwerk v2026-08-31

Wie behebt man BR-DE-25-b?

Bei Lastschrift nur BG-19 übermitteln und die Empfängerbankverbindung (BG-17) für diese Rechnung weglassen. Diese Regel sieht dabei nur den einen Zahlungsweg an: zwei Wege nebeneinander — eine Überweisung und eine Lastschrift als getrennte cac:PaymentMeans — verbietet sie nicht. In CII scheitert eine solche Rechnung trotzdem, aber an BR-DE-23-b.

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>59</cbc:PaymentMeansCode>
  <cac:PayeeFinancialAccount>
    <cbc:ID>DE02120300000000202051</cbc:ID>
  </cac:PayeeFinancialAccount>
  <cac:PaymentMandate>
    <cbc:ID>MANDAT-2026-0007</cbc:ID>
  </cac:PaymentMandate>
</cac:PaymentMeans>

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>59</cbc:PaymentMeansCode>
  <cac:PaymentMandate>
    <cbc:ID>MANDAT-2026-0007</cbc:ID>
  </cac:PaymentMandate>
</cac:PaymentMeans>