Annahme verweigert weil Vorlagefrist nicht eingehalten

der Wunsch hinter der Anfrage ist verständlich, zumal div. Punkte in Sachen SEPA (und nicht dort) mehr oder weniger sinnfrei sind, ua. die Information bzgl. Gläubiger-ID usw.
diese wird in der Regel im Vorfeld evtl. über den bisherigen Einzug mitgeteilt und zusätzlich per (normalen) Brief.
Im Streitfall wird das Gericht die Frage klären müssen, ob das Schreiben zuging, wenn es vom Zahlungspflichtigen bestritten wird.
Um rechtssicher das ganze abzuwickeln, hätten diese per Einschreiben oder durch neue Aufträge mit Unterschrift erfolgen müssen.

es gibt ähnliche Probleme, wo man auch nur mit dem Kopf schütteln kann:
Unternehmer wollte rückwirkend das Produkte DATEV UnternehmenOnline (UO), aufgrund der Digitalisierung/Abgleich und langfristiger Archivierung einsetzen - Abruf der Konto-Daten erfolgt per PIN/TAN über DATEV WebGUI. (kein manueller Import möglich)
hierbei wurden nur 90Tage rückwirkend eingelesen, obwohl per Online-Banking-Software (bspw. Starmoney) ca. 1 Jahr technisch realisierbar war.
Auf Anfrage bei der DATEV, hatte man mitgeteilt, dass man sich an die BPD halte und diese den max.-Wert angibt. Wenn sich nun eine Software hierüber hinweg setzt, sei dies deren Sachen, von Seiten der DATEV wird dies nicht erfolgen, weil sonst könne man ja gleich auf die BPD verzichten.

Um wieder auf die og. SEPA-Problematik zurück zu kommen:
verständlich ist das ganze, nur sind Vorgaben erstmal da, nach denen man sich bis auf weiteres richten muss/sollte + ob und wann eine Aufweichung erfolgt, ist was anderes

Gegenfrage: Wo steht denn konkret, dass die Bank am Auftrag des Kunden was verändern darf?

In der Inkassovereinbarung, wenn sie denn so formuliert ist.

Hallo,

um vllt. auch hier wieder auf die Ursprungsfrage zurückzukommen - Annahme verweigern ja/nein.

@kontex
Ich würde hier den Kontoinhaber bitten, an seine Bank heranzutreten und klären zu lassen, ob beide Parameter (Hochsetzen oder Ablehnung) gesetzt werden können und wenn ja, was zu tun ist, um z.B. das Hochsetzen zu aktivieren (z.B. mit gesonderter schriftlicher Vereinbarung). Grundsätzlich wundert es mich, wenn die Bank erst mal die Verarbeitung zugelassen hat und dann einfach (von heute auf morgen) auf "Ablehnung" umstellt. Vllt. wurden auch nur technische oder administrative Änderungen vorgenommen, die den ungewünschten Nebeneffekt mit sich brachten. Wenn es denn eine geschäftspolitische (global für die Bank) geltende Regelung ist, hilft vermutlich nur ein klärendes Gespräch mit der Bankrechtsabteilung und dem Vorstand ...

Nichtdestotrotz - es wurde schon alles klar definiert, auch wenn das jetzt komisch klingt. In erster Linie jedoch sind damit die klaren Regelungen gemeint, an die sich die Banken untereinander zu halten haben. Bei der Kunde-Bank-Beziehung sieht das leider etwas anders aus. Viele, auch ich - waren überrascht, dass das tschechische SEPA-Format doch anders aussehen darf als das deutsche. Es ist aber leider so. Die Banken müssen Sorge tragen, dass das jeweilige vorgebenene Kunden-Bank-Format (unseres ist im DFÜ-Abkommen Anlage 3 geregelt), so umgesetzt werden kann, dass es auch die tschechische Bank wieder "versteht". Was dann dort mit der Weitergabe, sprich der dortigen Kunden-Bank-Beziehung, passiert, regelt das SEPA-Gesetz nicht, sondern deren geltende gestzlichen Rahmenbedingungen der Tschechei. Eine klare Vereinheitlichung wäre schön, aber im Anfang der großen SEPA-Realisierung/Umsetzung einfach Utopie. Schließlich sind im Hintergrund immer noch unterschiedliche Zahlungssysteme im Einsatz.

Desweiteren werden alle (Kunden-)Vorgaben in den (Inkasso/EBICS-)Vereinbarungen und Kundenbedingungen geregelt, die jede Bankgruppe oder jedes Kreditinstitut nach besten Wissen und Gewissen vorgibt. So kann es eben auch sein, dass einige Banken die Vorlageregeln D-5, D-2 und D-1 am Einreichungstag bis zu einer Uhrzeit x gewährleisten, andere jedoch D-6, D-3, D-2 inkl. dem Einreichungstag vorgeben. Auch bei den Banken mit D-6, D-3, D-2 können die Vorlagefristen D-5, D-2 und D-1 genutzt werden, wenn man halt ganz früh am Tag einreicht. Aber da kann man die Daten auch am Vorabend einreichen ...

Zum Thema TARGET - hier sollte sich der Programmieraufwand in Grenzen halten. Es gibt nur 2 Dinge zu beachten - die Wochenenden und die 6 internationalen Feiertage (Neujahr, Karfreitag, Ostermontag, 1. Mai, 1. + 2. Weihnachtsfeiertag). Alle anderen Tage können Fälligkeitstage sein. "Trifft" das Fälligkeitsdatum auf den ein oder anderen nationalen Bundesfeiertag oder regionalen Feiertag, so ist bei den meisten Kreditinstituten in Deutschland geregelt, dass a) in der Inkassovereinbarung (Seite des Zahlungsempfänger) und b) in den Kundenbedingungen (Seite des Zahlungspflichtigen) steht, dass, wenn das Fälligkeitsdatum kein (Bank-)Geschäftstag ist, automatisch der folgende Geschäftstag dieser Bank/Sparkasse gilt.

Bsp.: Bank A (Bank des Zahlungspflichtigen) - kein Geschäftstag, weil 6.1. Allerheiligen . Bank B (Bank des Zahlungsempfänger) kein Feiertag, darf also arbeiten. Die Belastung erfolgt am 7.1., trotz Vorabankündigung zum 6.1. Der Zahlungspflichtige kann jetzt nicht auf Rückgabe wg. Verletztung Fälligkeitsdatum "pochen" - er hat ja den Kundenbedingungen für die SEPA-Lastschrifteinzug auf seinem Konto zugestimmt. Der Zahlungsempfänger erhält sein Geld ordnungsgemäß am 6.1.

Zum Thema Hochsetzen - Auch wir setzen automatisch hoch. Begründung: SEPA-Großstart zum 1. Februar 2014. Wenn da alle Banken ablehnen und rein theoretisch der Einreicher neu prenotifizieren sollte, die Datei neu erstellen soll, seine OPK korrigiert, die Datei neu unterschreiben lässt, vllt. feststellt, dass jetzt schon einige Mandatsänderungen bei x Zahlungspflichtigen greifen und so weiter und so fort, bin auch ich der Meinung, dass in den Anfängen ein Hochsetzen die bessere Alternative zwischen Pest und Cholera ist ...

Ein striktes Prüfen und Einhalten aller Parameter ist - zumindest jetzt nicht sinnvoll. Beispiel dafür sind die Lastschriftsequenzen. Würde auch hier hart geprüft - ich glaube nach dem ersten großen Ablehnungslauf der Lastschriften bei den Banken der Zahlungspflichtigen kommen alle Lastschrifteinreicher zu dem Entschluß: Künftig soll der Zahlungspflichtige selber überweisen ...

Oder BatchBooking - an sich künftig ein sehr sehr gutes Steuerungselement bei der Darstellung der Kontoumsätze bei eingereichten SEPA-Sammler (Buchung in einer Summe oder Anzeige aller Einzelumsätze). Ohne Abstimmung mit dem Kunden freischalten? Steht doch im DFÜ-Abkommen drin, was passiert? Der erste Gehalts-Sammelauftrag mit BatchBooking = false und die Bank überträgt bei nächsten Kontoinformationsabruf schön das Gehalt eines jeden Mitarbeiters...

Es gibt also Dinge zwischen "SEPA-Himmel und -Hölle", die gleich von Anfang an sinnvoll sind und manche Dinge eben nicht. Klar ist, dass auch nach der SEPA-Einführung immer wieder neue Fragen entstehen werden, z.B. dann wenn eine RCUR-Lastschrift eine FRST-Lastschrift nicht mehr "überholen" darf ...

Viele Grüße
Frank