01 — Warum
Der eine Fehler, den die Bank nicht für Sie abfängt
Die meisten Fehler in einer Zahlungsdatei fängt jemand ab. Eine kaputte Datei wird beim Hochladen abgewiesen. Eine Kontrollsumme, die nicht aufgeht, wird abgewiesen, bevor sich etwas bewegt. Ärgerlich, aber ungefährlich.
Dieselbe Rechnung zweimal zu bezahlen ist beides nicht. In der Datei sieht die zweite Zahlung genauso aus wie die erste: gültige IBAN, gültiger Betrag, gültige Struktur. Die Bank hat keinen Grund, sie abzulehnen — also tut sie es nicht. Auffallen wird es, wenn der Lieferant sich meldet, oder beim Abstimmen des Kontos. Ob das Geld zurückkommt, hängt dann vom guten Willen der Gegenseite ab.
Es passiert ganz unspektakulär: ein Stapel zweimal exportiert, eine Zahlung von Hand ergänzt, während die ursprüngliche noch im Lauf war, eine Freigabeschleife, die zwei Dateien erzeugt hat. Genau deshalb sucht niemand danach.
02 — Und der teure Zahlendreher
Eine IBAN trägt ihre Prüfziffer bei sich
Die Stellen drei und vier einer IBAN sind eine Prüfsumme über den Rest (ISO 13616, Modulo 97-10). Eine falsche Ziffer irgendwo in der Nummer, und die Rechnung geht nicht mehr auf — ein Zahlendreher lässt sich also hier abfangen, offline, ohne irgendwo nachzufragen.
Ist die Nummer falsch und trotzdem gültig, landet das Geld auf einem echten Konto, das nicht Ihrem Lieferanten gehört. Ist sie falsch und ungültig, kommt die Zahlung Tage später zurück und die Rechnung ist still überfällig geworden. Beides ist zwei Sekunden Rechnen wert.
Was geprüft wird
- IBAN-Prüfziffern, beim eigenen Konto und bei jedem Empfängerkonto.
- Kontrollsumme und Anzahl, auf Dateiebene und je Sammler — aus den Posten neu gerechnet statt geglaubt. Eine Datei, deren Kopf den Inhalt nicht wiedergibt, weist die Bank als Ganzes zurück.
- Dieselbe Zahlung zweimal: gleiche Empfänger-IBAN, gleicher Betrag, gleicher Verwendungszweck. Als Hinweis, nicht als Urteil — zwei gleiche Rechnungen eines Lieferanten an einem Tag gibt es, und nur Sie wissen, welcher Fall vorliegt.
- Dieselbe Zahlung wie im letzten Monat. Jede geprüfte Datei hinterlässt auf diesem Rechner einen Fingerabdruck, die nächste wird dagegen gehalten. Gespeichert werden sechzehn Zeichen und ein Datum — keine Kontonummern, keine Beträge, keine Verwendungszwecke. Eine Zahlungsdatei enthält sämtliche Lieferanten eines Unternehmens; so etwas gehört nicht im Klartext in den Browserspeicher.
- Doppelte End-to-End-IDs, die eindeutig sein müssen und an denen Banken einen zweimal eingereichten Stapel erkennen.
- Zeichen, die SEPA nicht überträgt. Erlaubt sind nur Buchstaben, Ziffern,
Leerzeichen und
/ - ? : ( ) . , ' +. Einöoderßim Empfängernamen wird entweder abgewiesen oder stillschweigend umgeschrieben — und das Umschreiben ist schlimmer, weil das Geld fließt und der Name nicht mehr passt. - Beträge, die negativ oder null sind oder mehr als zwei Nachkommastellen haben.
- Ein Ausführungstermin in der Vergangenheit, den jede Bank anders behandelt und keine so, wie es gemeint war.
Bewusst nicht geprüft: ob Ihre Bank zusätzliche eigene Vorgaben hat — die sind von Haus zu Haus verschieden, und Raten erzeugt Fehlalarme — und ob eine Zahlung überhaupt geleistet werden soll. Das ist die Entscheidung eines Menschen, nicht die einer Datei.
Legen Sie die Rechnungen gleich mit dazu
Alles bisher Genannte prüft die Datei gegen sich selbst: passt der Kopf zum Inhalt, gehen die Prüfziffern auf, steht etwas zweimal darin. Eine Frage kann die Datei allein nicht beantworten — ist das der Betrag, den die Rechnung verlangt?
Eine Null zu viel im ERP erzeugt eine völlig gültige Zahlung. 12.000 und 1.200 sind beide wohlgeformte Beträge, beide bestehen jede Formatprüfung, und die Bank führt aus, was in der Datei steht. Auffallen wird es beim Abstimmen — dann liegt das Geld schon auf einem fremden Konto.
Legen Sie die Rechnungen also mit der Zahlungsdatei zusammen ab. Zugeordnet wird über
die Rechnungsnummer im Verwendungszweck — so macht es die Gegenseite beim
Ausziffern auch — und dann werden die Beträge gegeneinander gehalten. Trennzeichen sind
egal: RE-2026/0417 und RE20260417 sind dieselbe Nummer.
Lieber gar nicht zuordnen als falsch zuordnen: Rechnungsnummern unter fünf Zeichen bleiben außen vor (sie treffen in jedem Text), und ein Verwendungszweck, der zwei Rechnungen nennt, wird übergangen. Unterschiedliche Währungen werden gemeldet statt umgerechnet — einen Kurs zu raten, um jemandem einen Fehler vorzuwerfen, lohnt nicht.
Lastschriften
Ein Lastschriftlauf (pain.008) läuft durch dieselben Prüfungen, weil darin dieselben Dinge schiefgehen — nur trifft es jemand anderen. Eine falsche IBAN heißt, dass diese Einzugsposition Tage später zurückkommt, während die Rechnung längst draußen ist. Und denselben Kunden zweimal zu belasten ist nicht einfach ein Betrag zu viel: es ist eine Beschwerde, eine Rücklastschrift, und im SEPA-Raum kann der Kunde acht Wochen lang ohne Angabe von Gründen zurückfordern. Das Geld geht zurück. Die Gebühr nicht.
Zwei Dinge werden hier bewusst nicht beurteilt: die Mandatsdaten und die Frage, ob die Sequenzart (FRST / RCUR / FNAL) die richtige ist. Beides hängt davon ab, ob dieser Kunde schon einmal belastet wurde, und das steht nicht in der Datei. Nichts zu sagen ist besser als zu raten.
Nichts wird hochgeladen
Ein Zahlungslauf enthält jeden Lieferanten, den Sie haben, was Sie ihm zahlen und seine Kontonummer. So eine Datei gibt man nicht in ein Webformular. Sie wird im Browser gelesen: Entwicklertools öffnen, Reiter Netzwerk, Datei hineinziehen — es geht keine Anfrage hinaus. Oder: Seite laden, Netzwerkverbindung trennen, Datei trotzdem hineinziehen. Es funktioniert weiter.
Für den Rest dieser Seite gilt dasselbe: Rechnungen in eine Tabelle, eine Rechnung gegen EN 16931 prüfen und die vollständige Regelliste.