BR-DE – XRechnung

BR-DE-23-b: credit transfer combined with card or direct debit data

ErrorXRechnung business rule (KoSIT)

The rule's own wording

[BR-DE-23-b] Wenn BT-81 "Payment means type code" einen Schlüssel für Überweisungen enthält (30, 58), dürfen BG-18 und BG-19 nicht übermittelt werden.

Source: KoSIT XRechnung, version 3.0.2 (Schematron 2.6.0)

Meaning of the rule

Your invoice states a credit transfer as the means of payment (code 30 or 58) and at the same time delivers details that belong to another payment method: card data or a direct debit mandate. XRechnung allows per payment entry only the data that fits the chosen method, so that the receiving software does not have to guess how to pay. Usually the superfluous block comes from a template that writes all payment data of the customer.

The fix in the XML

With code 30 or 58 remove the groups BG-18 and BG-19: in UBL cac:CardAccount and cac:PaymentMandate inside cac:PaymentMeans, in CII the card details and the mandate reference. If the direct debit should remain possible, create a separate payment entry with code 59 for it.

Before – invalid

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

After – corrected

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>58</cbc:PaymentMeansCode>
  <cac:PayeeFinancialAccount>
    <cbc:ID>DE02120300000000202051</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

Questions and answers

May an invoice offer several means of payment?

Yes, but each in its own payment entry: one with code 58 and account data, one with code 59 and a mandate. Mixed in one block it is invalid.

Does the rule apply to credit notes as well?

Yes. The check reads every payment entry with code 30 or 58 in invoices and credit notes alike; in both document types no card or mandate data may stand next to it.

Other typical causes

The template writes mandate data from the customer master although payment is by transfer.
Card data of an earlier payment was left in the payment block.
Two payment methods were merged into one PaymentMeans element instead of being separated.

EN 16931 fields

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

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

The rule in detail

UBL · Context (XPath): /ubl:Invoice/cac:PaymentMeans[normalize-space(cbc:PaymentMeansCode) = ('30','58')] | /cn:CreditNote/cac:PaymentMeans[normalize-space(cbc:PaymentMeansCode) = ('30','58')]
UBL · Schematron test: not(cac:CardAccount) and not(cac:PaymentMandate)
CII · Context (XPath): /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeSettlementPaymentMeans[normalize-space(ram:TypeCode) = ('30','58')]
CII · Schematron test: not(ram:ApplicableTradeSettlementFinancialCard) and not(/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradePaymentTerms/ram:DirectDebitMandateID or /rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:CreditorReferenceID or ram:PayerPartyDebtorFinancialAccount/ram:IBANID)

Explanation written on 14 September 2026

Search