BR-DE – XRechnung

BR-DE-25-b: direct debit combined with account or card data

ErrorXRechnung business rule (KoSIT)

Official message

[BR-DE-25-b] Wenn 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.

Source: KoSIT XRechnung, version 3.0.2 (Schematron 2.6.0)

What the message means

Your invoice provides for a direct debit (code 59) and at the same time lists data of other means of payment: the payee account for a credit transfer, or card details. XRechnung allows in one payment entry only the data that belongs to the stated method. The most frequent cause is the seller's bank details, written into every invoice out of habit, even when the amount is collected by direct debit and nobody should transfer anything.

Common causes

The seller's bank details are output with every invoice, even for direct debit.
Card data of an earlier payment was left in the payment entry.
Two means of payment were merged into one block instead of two.

How to fix it

With code 59 remove the groups BG-17 and BG-18: in UBL cac:PayeeFinancialAccount and cac:CardAccount in the same cac:PaymentMeans, in CII the creditor account, the financial institution and the card details. Keep only the mandate with the debited account.

Before – invalid

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>59</cbc:PaymentMeansCode>
  <cac:PayeeFinancialAccount>
    <cbc:ID>DE02120300000000202051</cbc:ID>
  </cac:PayeeFinancialAccount>
  <cac:PaymentMandate>
    <cbc:ID>MANDATE-2024-0031</cbc:ID>
    <cac:PayerFinancialAccount>
      <cbc:ID>DE75512108001245126199</cbc:ID>
    </cac:PayerFinancialAccount>
  </cac:PaymentMandate>
</cac:PaymentMeans>

After – corrected

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>59</cbc:PaymentMeansCode>
  <cac:PaymentMandate>
    <cbc:ID>MANDATE-2024-0031</cbc:ID>
    <cac:PayerFinancialAccount>
      <cbc:ID>DE75512108001245126199</cbc:ID>
    </cac:PayerFinancialAccount>
  </cac:PaymentMandate>
</cac:PaymentMeans>

Frequently asked

The customer should be allowed to transfer instead, how does that work?

With a second payment entry: one with code 59 and the mandate, one with code 58 and your account. Each entry carries only its own data.

Why does the rule exist at all if the data is harmless?

Because the receiving software processes the means of payment automatically. Contradictory data in one block leads to wrong payments or to manual rework.

Fields concerned

BT-81
BG-17
BG-18
BG-19

Related rules

Check your invoice

The XRechnung validator reports this rule with the line number and location – right in your browser, without upload.

Open the XRechnung validator

Technical details

UBL · Context (XPath): /ubl:Invoice/cac:PaymentMeans[normalize-space(cbc:PaymentMeansCode) = '59'] | /cn:CreditNote/cac:PaymentMeans[normalize-space(cbc:PaymentMeansCode) = '59']
UBL · Schematron test: not(cac:PayeeFinancialAccount) and not(cac:CardAccount)
CII · Context (XPath): /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeSettlementPaymentMeans[normalize-space(ram:TypeCode) = '59']
CII · Schematron test: not(ram:PayeePartyCreditorFinancialAccount) and not(ram:PayeeSpecifiedCreditorFinancialInstitution) and not(ram:PayerSpecifiedDebtorFinancialInstitution) and not(ram:ApplicableTradeSettlementFinancialCard)

Explanation written on 14 September 2026