Änderungen im SEPA-Clearing

Es gibt einen weiteren SEPA-Datenformatstand (ZKA-Version 3.0).

Dieser hat speziell im Bereich der Lastschriften einige Vorteile:

• Keine Trennung mehr von Erst- und Folgelastschriften

• Einheitliche Vorlauffristen (in der Regel 1 Tag) für alle Einzugs- und Mandatsarten

Vorgehensweise für die Umstellung:

• Stellen Sie die ZKA-Version erst um, wenn sichergestellt ist, dass Ihre Bank diese Version auch verarbeiten kann.

• Stellen Sie die ZKA-Version erst um, wenn die Tabelle „Lastschriften“ leer, bzw. alle Zahlungsbelege an die Bank übertragen sind (Fettdruck).

• Grundsätzlich bleiben die bisherigen ZKA-Versionen aktiv, allerdings mit den dort noch gültigen Vorlauftagen.

Vergleich ZKA-Version 2.5 – 2.8 / ZKA-Version 3.0

In der Lastschrifttabelle waren die Mandate in der Spalte Einzugsart zu erkennen:

FM = Firmenmandat
BS = Basismandat
BV = Basismandat mit verkürzter Vorlaufzeit

In der Spalte „Folgekennung“ ist ein ‚E‘ eingetragen, wenn es sich um eine Erstlastschrift (neues Mandat)
handelte:

Open

Diese Zahlungsbelege konnten nicht zusammen verarbeitet und in einer Datei an die Bank übertragen werden, auch wenn Einzugsdatum und sogar Kundennummer gleich waren.

SEPA-Einstellungen

In den Stammdaten Banken waren die Vorlauftage für die unterschiedlichen Mandatsarten und Folgekennungen hinterlegt.
Bei den meisten Banken wurde auch das Häkchen für das getrennte Verarbeiten von Erst- und Folgelastschrift und unterschiedlichen Einzugsdaten gesetzt. Bei der Lastschrifterstellung für diese Hausbank mussten mehrere Zahlungsdateien erstellt werden (pro Einzugsdatum / Folgekennung).

Open

In der SEPA-Datei wird die pain-Nr. der ZKA-Version im Header angegeben.

Open

Die Verarbeitungsart (CORE für Standard – COR1 für verkürzte Vorlauffristen) und die Folgekennung (RCUR für Folgelastschrift – FRST für Erstlastschrift) wurde entsprechend mit übergeben.

Nach der Umstellung auf die neue ZKA-Version 3.0 sind die Vorlauftage der Tabelle nicht mehr relevant.

Open

Wird das Häkchen für die Verwendung der Standardvorlauffrist gesetzt, sind die Felder nicht mehr änderbar.
Die Standardvorlauffrist beträgt in der Regel ein (in Zahl 1) Bankarbeitstag.

Weitere Vorgehensweise:

Beim Einbuchen von neuen Lastschriftbelegen (Datenimport, manuelle Buchungen, Stapel) werden die neuen Vorlauftage berücksichtigt und der Bankabgabetermin entsprechend vorgeschlagen.

Bei bereits bestehenden Belegen wird der Bankabgabetermin nicht geändert. Dadurch kann es vorkommen, dass in der Übergangszeit Lastschriftbelege zu früh erstellt werden. Dies wirkt sich allerdings nicht auf das
Einzugsdatum aus – ein verfrühter Einzug ist daher ausgeschlossen.

Belege mit „verkürzter Vorlaufzeit COR1“ müssen manuell auf den Standard CORE umgestellt, oder vor
Umstellung auf die neue ZKA-Version eingezogen werden. Die Kennung COR1 wurde bisher nur vergeben, wenn Vorlauftage im Bereich COR1 eingetragen waren.

Das Häkchen „Die Bank erlaubt nur Einzüge mit gleichem Einzugsdatum...“ gilt ab ZKA- Version 3.0 nur für die Trennung der Belege nach Einzugsdatum.

Die gemeinsame Verarbeitung von Erst- und Folgelastschriften in einer Datei ist problemlos möglich.

Die mit ZKA 3.0 erstellte SEPA-XML-Datei enthält die pain-Nr. im Header. Bei den Vorlauffristen und den
Folgekennungen sind immer „CORE“ und „RCUR“ eingetragen, denn so schreibt es der Schnittstellenaufbau vor.

Open

Vor der Umstellung ist mit der Hausbank zu klären, ob und ab wann diese ZKA-Version im Bereich der SEPA-
Lastschriften genutzt werden kann / soll.

Die älteren ZKA-Versionen bleiben weiterhin nutzbar – allerdings bleiben die längeren Vorlauffristen wie bisher bestehen.

Kann nach einer Umstellung auf ZKA 3.0 die Datei von der Bank nicht bearbeitet werden, kann wieder auf eine ältere Version umgestellt werden.

Die Lastschriftbelege in der Tabelle Lastschriften sind zu löschen und neu zu erstellen.

Eventuell kann dann der Einzugstermin der Pre-Notification nicht pünktlich eingehalten werden und wird
entsprechend um einige Tage verschoben.