- Thema
- VB.NET
- SDK-Mitglieder
- AddPaymentMeans() AddTradePaymentTerms() CreditorReferenceID
- Business Terms
- BT-91 Kennung des zu belastenden Kontos BT-81 Code für die Zahlungsart BT-89 Kennung der Mandatsreferenz BT-90 Kennung des Gläubigers BG-19 Lastschriftverfahren
- Codebeispiele
- VB.NET, XML
- Veröffentlicht
Kurz: Bei einer SEPA-Lastschrift (Zahlungsart 59, BT-81) kennen EN 16931 und XRechnung für das belastete Konto des Kunden nur die IBAN (BT-91, PayerPartyDebtorFinancialAccount/IBANID). Stehen dort zusätzlich der Kontoinhaber (AccountName) und die BIC der Bank des Zahlers (PayerSpecifiedDebtorFinancialInstitution), meldet der Validator einen Schemafehler bei ram:AccountName und die Warnungen CII-SR-382 und CII-SR-464; die Rechnung ist ungültig. Ab Version 11 lässt das Aloaha ZUGFeRD SDK beide Angaben bei Lastschrift außerhalb von EXTENDED automatisch weg. In älteren Versionen übergeben Sie Kontoinhaber und BIC in AddPaymentMeans leer.
Gesucht wird das oft als „Einzugsermächtigung Validierungsfehler“, „Lastschrift XRechnung ungültig“, „Bankeinzug E-Rechnung AccountName“ oder „Debitor-Konto BIC nicht erlaubt“.
Die Meldungen im Prüfbericht
| Meldung | Bedeutung |
|---|---|
Schemafehler: cvc-complex-type.2.4.d: Ungültiger Content wurde beginnend mit Element 'ram:AccountName' gefunden | Im Konto des Zahlers ist nach der IBAN kein weiteres Element erlaubt – die Datei verletzt das XML-Schema und ist damit ungültig. |
[CII-SR-382] - AccountName should not be present | Kontoinhaber im belasteten Konto ist in EN 16931 nicht vorgesehen. |
[CII-SR-464] - PayerSpecifiedDebtorFincancialInstitution shall not be used. | Die Bank (BIC) des Zahlers ist in EN 16931 nicht vorgesehen. |
Die beiden CII-SR-Regeln sind nur Warnungen; ungültig wird die Rechnung durch den Schemafehler. Alle drei Meldungen verschwinden gemeinsam, sobald Kontoinhaber und BIC des Zahlers fehlen.
Auf einen Blick: Konto des Zahlers bei Lastschrift
| Angabe | EN 16931 / XRechnung | SDK ab Version 11 |
|---|---|---|
| IBAN des Kunden (BT-91) | Pflicht (XRechnung: BR-DE-31) | wird geschrieben |
Kontoinhaber (AccountName) | nicht erlaubt | wird weggelassen (nur EXTENDED schreibt ihn) |
| BIC, Bankleitzahl, Bankname des Zahlers | nicht erlaubt | werden weggelassen (nur EXTENDED schreibt sie) |
| Mandatsreferenz (BT-89), Gläubiger-ID (BT-90) | Pflicht bei Lastschrift (XRechnung: BR-DE-30) | unverändert |
Lösung im Aloaha ZUGFeRD SDK
Ab Version 11 ist nichts zu tun: Ist isDirectDebit in AddPaymentMeans gesetzt, schreibt das SDK in ZUGFeRD/EN 16931 und XRechnung nur die IBAN. Die übergebenen Werte bleiben im Objekt erhalten und erscheinen nur im XML nicht. Das Update ist mit gültigem Wartungsvertrag kostenlos; welche Version eine Rechnung erzeugt hat, steht im Kommentar am Anfang der XML-Datei (AssemblyFileVersion) – siehe Welche SDK-Version ist installiert?
In älteren Versionen übergeben Sie bei der Lastschrift Kontoinhaber und BIC leer:
Dim alo As New Aloaha_ZUGFeRD.XML(Aloaha_ZUGFeRD.iXML.ZUGFeRDProfile.comfort, False, "IHR-LIZENZSCHLUESSEL")
' ... Rechnungskopf, Verkäufer, Käufer ...
' vorher (ungültig): Kontoinhaber und BIC des Zahlers übergeben
' alo.AddPaymentMeans(Aloaha_ZUGFeRD.iXML.Payment_Means.SEPA_direct_debit, "Einzugsermächtigung", _
' ibanKunde, "Muster GmbH", "", "DEUTDEDBXXX", "", "", True)
' nachher: nur die IBAN des Kunden (BT-91), letzter Parameter True = Lastschrift
alo.AddPaymentMeans(Aloaha_ZUGFeRD.iXML.Payment_Means.SEPA_direct_debit, "Einzugsermächtigung", _
ibanKunde, "", "", "", "", "", True)
alo.CreditorReferenceID = "DE98ZZZ09999999999" ' BT-90, Ihre Gläubiger-ID
alo.AddTradePaymentTerms("Der Betrag wird am Fälligkeitstag per SEPA-Lastschrift eingezogen.", _
"20261118", "102", mandatsreferenz) ' BT-89Ergebnis im XML:
<ram:SpecifiedTradeSettlementPaymentMeans>
<ram:TypeCode>59</ram:TypeCode>
<ram:Information>Einzugsermächtigung</ram:Information>
<ram:PayerPartyDebtorFinancialAccount>
<ram:IBANID>DE02120300000000202051</ram:IBANID>
</ram:PayerPartyDebtorFinancialAccount>
</ram:SpecifiedTradeSettlementPaymentMeans>IBAN und Gläubiger-ID sind Muster-Werte. Die vollständige Anleitung zur Lastschrift steht unter Wie gebe ich eine SEPA-Lastschrift in der E-Rechnung richtig an?
Typischer Fehler: das eigene Konto statt des Kundenkontos
In BT-91 gehört das Konto des Kunden, von dem abgebucht wird. Steht als Kontoinhaber Ihre eigene Firma, wurde oft versehentlich das eigene Bankkonto übergeben – wie bei einer Überweisung. Bei einer Lastschrift steht Ihr eigenes Konto nicht in der Rechnung; Sie werden über Ihre Gläubiger-ID (BT-90) identifiziert. Prüfen Sie deshalb, aus welchem Feld Ihrer Anwendung die IBAN kommt.
Häufige Fragen
Was bedeutet CII-SR-382 bei einer Lastschrift?
„AccountName should not be present“: Im Konto des Zahlers (PayerPartyDebtorFinancialAccount) steht ein Kontoinhaber. EN 16931 und XRechnung erlauben dort nur die IBAN (BT-91). Lassen Sie den Kontoinhaber weg; ab SDK-Version 11 geschieht das automatisch.
Was bedeutet CII-SR-464?
„PayerSpecifiedDebtorFinancialInstitution shall not be used“: Die Bank bzw. BIC des Zahlers ist in EN 16931 nicht vorgesehen. Übergeben Sie bei der Lastschrift keine BIC; ab Version 11 lässt das SDK sie außerhalb von EXTENDED weg.
Warum ist die Rechnung ungültig, obwohl CII-SR-382 nur eine Warnung ist?
Ungültig wird sie durch den Schemafehler „Ungültiger Content wurde beginnend mit Element ram:AccountName gefunden“. Er entsteht durch denselben Kontoinhaber und verschwindet zusammen mit den Warnungen.
Muss ich bei einer Lastschrift die BIC des Kunden angeben?
Nein. In ZUGFeRD/EN 16931 und XRechnung genügt die IBAN des Kunden (BT-91), dazu Mandatsreferenz (BT-89) und Ihre Gläubiger-ID (BT-90).
Welche SDK-Version behebt den Fehler?
Version 11. Dort schreibt das SDK bei Lastschrift außerhalb von EXTENDED nur die IBAN. Das Update ist mit gültigem Wartungsvertrag kostenlos. In älteren Versionen übergeben Sie Kontoinhaber und BIC in AddPaymentMeans leer.
Business Terms in diesem Artikel: BT-91 BT-81 BT-89 BT-90 BG-19