BR-DE-13: Mehr als eine oder gar keine Zahlungsart angegeben

BR-DE-13 gibt es in der aktuellen XRechnung nicht mehr. Die Regel stand in den Prüfregeln bis Version 2.0 und ist mit XRechnung 2.1 weggefallen. Siehst du die Meldung heute, ist das vor allem ein Hinweis auf den Validator, nicht auf deine Rechnung.

Was die Regel prüft

Die Rechnung musste genau eine von drei Feldgruppen enthalten: Überweisung (BG-17, mit der IBAN des Zahlungsempfängers), Zahlungskarte (BG-18) oder Lastschrift (BG-19, mit Mandatsreferenz und der IBAN des Zahlers). BG steht für Business Group, eine Feldgruppe der Norm.

„Genau eine" hatte zwei Seiten. Eine Rechnung ohne jede dieser Gruppen fiel durch, ebenso eine mit zweien, etwa Überweisung und Lastschrift zugleich.

Seit XRechnung 2.1 hängt die Prüfung an der Zahlungsart. Die Rechnung braucht weiterhin Zahlungsangaben überhaupt (BR-DE-1). Die Regeln BR-DE-23 bis BR-DE-25 lesen dann den Zahlungsart-Code (BT-81) und verlangen die passende Gruppe: bei Überweisung (Code 30 oder 58) die Überweisungsdaten, bei Karte (48, 54, 55) die Kartendaten, bei Lastschrift (59) die Lastschriftdaten. Eine pauschale Regel „genau eine Gruppe für die ganze Rechnung" gibt es nicht mehr.

Warum sie in der Praxis fehlschlägt

Der häufigste Grund heute: Ein Validator oder Prüfportal arbeitet noch mit den Regeln von XRechnung 2.0. Das betrifft ältere Installationen des KoSIT-Validators, eingefrorene Prüfkonfigurationen in ERP-Systemen und Online-Prüfer, die seit Jahren niemand aktualisiert hat. Gegen die aktuelle Version 3.0 geprüft, besteht dieselbe Rechnung.

Stammt die Meldung tatsächlich aus einer Prüfung gegen 2.0, steckt meist einer von zwei Fällen dahinter:

• Die Rechnung bietet Überweisung und Lastschrift gleichzeitig an, weil die Software beide Bankverbindungen ausgibt, sobald sie im Kundenstamm hinterlegt sind.
• Die Zahlungsart ist Barzahlung oder „nicht angegeben", und keine der drei Gruppen ist gefüllt.

So behebst du den Fehler

Prüf zuerst, gegen welche XRechnung-Version validiert wird. Der KoSIT-Validator nennt die Konfiguration im Prüfbericht. Steht dort 2.0 oder älter, aktualisiere den Validator auf die aktuelle Konfiguration und prüf erneut. Eine Rechnung nach XRechnung 2.0 nimmt ohnehin kaum noch ein Empfänger an, öffentliche Auftraggeber erwarten 3.0.

Verlangt ein Empfänger trotzdem ausdrücklich 2.0, gib genau eine Zahlungsart aus: bei Lastschrift-Kunden nur die Lastschriftdaten, sonst nur die Überweisung mit deiner IBAN.

Belegschmied prüft gegen XRechnung 3.0, die Meldung BR-DE-13 kommt dort nicht vor.

XML-Beispiel: vorher und nachher

Zwei Zahlungsarten in einer Rechnung, unter XRechnung 2.0 ein Verstoß:

<!-- verletzt BR-DE-13 (nur XRechnung 2.0): Überweisung UND Lastschrift -->
<ram:SpecifiedTradeSettlementPaymentMeans>
  <ram:TypeCode>58</ram:TypeCode>
  <ram:PayeePartyCreditorFinancialAccount>
    <ram:IBANID>DE02120300000000202051</ram:IBANID>
  </ram:PayeePartyCreditorFinancialAccount>
</ram:SpecifiedTradeSettlementPaymentMeans>
<ram:SpecifiedTradeSettlementPaymentMeans>
  <ram:TypeCode>59</ram:TypeCode>
  <ram:PayerPartyDebtorFinancialAccount>
    <ram:IBANID>DE89370400440532013000</ram:IBANID>
  </ram:PayerPartyDebtorFinancialAccount>
</ram:SpecifiedTradeSettlementPaymentMeans>

Korrigiert, nur die Überweisung bleibt:

<ram:SpecifiedTradeSettlementPaymentMeans>
  <ram:TypeCode>58</ram:TypeCode>
  <ram:PayeePartyCreditorFinancialAccount>
    <ram:IBANID>DE02120300000000202051</ram:IBANID>
  </ram:PayeePartyCreditorFinancialAccount>
</ram:SpecifiedTradeSettlementPaymentMeans>