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.

Why does BR-DE-25-b happen?

The most common of the three b-rules: the seller's own bank account sits in every invoice as BG-17 out of habit — with a direct debit it has no business there, since collection is from the buyer's account. CII's list of forbidden elements is longer than UBL's: besides the payee account and the card group it also names the payee's and the payer's financial institution, because CII carries those beside the account rather than inside it.

What the validator checks

The expression the official KoSIT rule set evaluates — not paraphrased, but read from the Schematron file it ships. UBL and CII address different document trees, so the same rule reads differently in each.

UBL

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

CII

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

Source: rule set v2026-08-31

How do you fix BR-DE-25-b?

With direct debit, transmit BG-19 only and drop the payee bank account (BG-17) for this invoice. This rule looks at that one payment route alone: two routes side by side — a transfer and a direct debit as separate cac:PaymentMeans elements — are not forbidden by it. In CII such an invoice still fails, but on 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>