BR-DE – XRechnung

BR-DE-23-b: Überweisung mit Karten- oder Lastschriftdaten kombiniert

FehlerGeschäftsregel XRechnung (KoSIT)

Originaltext der Regel

[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.

Quelle: KoSIT XRechnung, Version 3.0.2 (Schematron 2.6.0)

Bedeutung der Regel

Ihre Rechnung gibt als Zahlungsweg eine Überweisung an (Code 30 oder 58) und liefert gleichzeitig Angaben, die zu einer anderen Zahlungsart gehören: Kartendaten oder ein Lastschriftmandat. XRechnung erlaubt je Zahlungsangabe nur die Daten, die zum gewählten Weg passen, damit die empfangende Software nicht raten muss, wie gezahlt werden soll. Meist stammt der überflüssige Block aus einer Vorlage, die alle Zahlungsdaten des Kunden unabhängig vom Zahlungsweg schreibt.

Korrektur im XML

Entfernen Sie bei Code 30 oder 58 die Gruppen BG-18 und BG-19: in UBL cac:CardAccount und cac:PaymentMandate innerhalb von cac:PaymentMeans, in CII die Kartenangaben und die Mandatsreferenz. Soll die Lastschrift möglich bleiben, legen Sie dafür eine eigene Zahlungsangabe mit Code 59 an.

Vorher – fehlerhaft

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

Nachher – korrigiert

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

Fragen und Antworten

Darf eine Rechnung mehrere Zahlungswege anbieten?

Ja, aber jeder in einer eigenen Zahlungsangabe: eine mit Code 58 und Kontodaten, eine mit Code 59 und Mandat. Gemischt in einem Block ist es ungültig.

Gilt die Regel auch für Gutschriften?

Ja. Die Prüfung liest in Rechnungen und Gutschriften jede Zahlungsangabe mit Code 30 oder 58; in beiden Dokumenttypen dürfen daneben keine Karten- oder Mandatsdaten stehen.

Weitere typische Ursachen

Die Vorlage schreibt Mandatsdaten aus dem Kundenstamm, obwohl per Überweisung gezahlt wird.
Kartendaten einer früheren Zahlung blieben im Zahlungsblock stehen.
Zwei Zahlungswege wurden in einem PaymentMeans-Element zusammengefasst statt getrennt.

Felder der EN 16931

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

Siehe auch

Rechnung prüfen

Der XRechnung-Validator meldet diese Regel mit Zeilennummer und Fundstelle – direkt in Ihrem Browser, ohne Upload.

Zum XRechnung-Validator

Die Regel im Detail

UBL · Kontext (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 · Kontext (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)

Erklärung erstellt am 14.09.2026