Technische Umsetzung der SEPA-Details – soweit das beim Benutzer / Kontoinhaber ankommt

• https://de.wikipedia.org/wiki/SEPA
• https://de.wikipedia.org/wiki/Diskussion:SEPA
• https://de.wikipedia.org/wiki/Diskussion:SEPA#Technische_Umsetzung_der_SEPA-Details_.E2.80.93_soweit_das_beim_Benutzer_.2F_Kontoinhaber_ankommt

Meinen folgenden Text habe ich heute auch als neuen Abschnitt in die Diskussionsseite zum SEPA-Artikel bei der deutschen Wikipedia eingebracht. Mal schauen, ob das irgend etwas “bewegt”! Vielleicht findet etwas davon Eingang in den Artikel selbst, vielleicht tut sich eines Tages bei den Banken etwas, vielleicht wird mein Ansatz ja von der Presse aufgegriffen.

Die SEPA-Felder (Creditor-ID, Mandatsreferenz, etc.) wurden anscheinend nicht zu HBCI- bzw. FinTS-Feldern gemacht, sie werden zumindest bei gewissen Banken (wohl eigentlich allen Banken) einfach in die tradtionellen Verwendungszweck-Felder gestopft.

Die “gewissen Banken”, von denen ich diese Verfahrensweise gesichert weiß, sind diese: die Postbank, diei Fiducia (als Volksbank/Raiffeisenbank-Dienstleister) und die Berliner Sparkasse.

Verwendungszweck-Felder haben “netto” nur für 27 Zeichen Platz. Und weil “Einreicher-ID” etc. selbst schon genügend lang sind, werden diese Felder umgebrochen und brauchen gelegentlich gleich 3 Verwendungszweck-Felder. Man kann nicht davon ausgehen, dass sie diese Verwendungszweck-Felder auch ganz ausfüllen, um möglichst wenige davon zu beanspruchen. Es gibt auch kein sichtbares Endezeichen, welches signalisiert, dass das SEPA-Feld nun zu Ende ist. Man kann auch nicht alle zu einem einzigen SEPA-Feld gehörigen Verwendungszweck-Felder einfach konkatenieren, manchmal braucht es noch ein Leerzeichen dazwischen, manchmal nicht. Das ist nicht “maschinenfreundlich”.

Ich weiß nicht, wie andere Banking-Software damit umgeht, aber Lexware Quicken hat keinen “Beautifier” für die SEPA-Felder, und alle SEPA-Lastschriften sind in Quicken total schwer lesbar. Um sie dem Steuerberater oder dem Finanzamt präsentieren zu können, muss man total viel manuellen Formatierungsaufwand hineinstecken. Eine Nachfrage bei Lexware ergab nur, dass man sich bei Lexware dieses Problems anscheinend gar nicht bewusst ist und vielleicht mal darüber nachdenken wird, da in der Zukunft vielleicht Unterstützung anzubieten.

Ich hole meine Kontoauszüge nicht nur per Quicken. Auf “der anderen Strecke” (Hibiscus/Jameica/…) mache ich Text-Dateien mit selbst-definiertem “Markup” daraus, deswegen weiß ich eben recht genau, was aus FinTS als originäre Felder und was als “nur Textfelder (memo)” kommt.

Bevor ich verarbeitungsmäßig wirklich mit den SEPA-Feldern etwas anfangen kann, muss ich “täglich” ziemlich aufwendig aus den einzelnen, aus dem Umbruch entstandenen memo-Feldern wieder jeweils ein un-umgebrochenes (langes) Text-Feld machen. Manchmal müssen Leerzeichen dazu gegeben werden.

Jede Bank hat ihre eigene Eindeutschung des jeweiligen SEPA-Feldnamens, das macht die maschinelle Verarbeitung auch nicht einfacher.

Die SEPA-Felder hätten auf jeden Fall zu originären FinTS-Feldern gemacht werden müssen, und sie müssten auf jeden Fall auch länger als 27 Zeichen lang sein dürfen. Dieses Umbrechen wirkt steinzeitmäßig.

Die Banken scheuten die Aufgabe der regulären Integration der SEPA-Felder in FinTS, vielmehr luden sie das Problem hauptsächlich auf die Schultern ihrer privaten und Firmen-Kunden. Das ist nicht zufriedenstellend.