Zurück
— SEPA

SEPA-Basis-Lastschrift in der Hausverwaltung: pain.008, Sequence-Types und der Lebenszyklus eines Mandats

ImmoGenio ·

Der Erste eines Monats ist in jeder Hausverwaltung der unangenehmste Tag im Kalender. Hausgelder, Mieten und Vorauszahlungen werden fällig, gleichzeitig laufen Versicherungsprämien, Wartungsverträge und Energieabschläge ab. Wer an diesem Stichtag noch Überweisungen einzeln einsammelt, finanziert die WEG faktisch aus der Rücklage zwischen, weil zwischen Soll und Ist regelmäßig fünf bis zehn Tage liegen. Genau diese Lücke schließt die SEPA-Basis-Lastschrift, sofern Mandat, Vorlauffrist und Sequence-Type sauber sitzen. Der Beitrag erklärt, wie pain.008.001.08, der Mandatslebenszyklus und die Rücklaufgründe in einer Verwaltungssoftware zusammenspielen müssen, damit der Sammellauf nicht zur Belastungsprobe für die Liquidität wird.

SEPA Direct Debit Core als Rechtsrahmen

Die SEPA Direct Debit Core (SDD CORE) ist kein Banken-internes Format, sondern ein europaweit harmonisiertes Verfahren auf Basis des EPC-Rulebooks des European Payments Council und der ISO-20022-Nachrichtenfamilie. Rechtlicher Anker im deutschen Recht ist § 675f BGB für den Zahlungsdienstrahmenvertrag und § 675x BGB für den Erstattungsanspruch des Zahlers bei autorisierten Lastschriften. Voraussetzung jeder Lastschrift ist ein gültiges, vom Schuldner erteiltes Mandat, das den Verwalter respektive die WEG ermächtigt, Beträge einzuziehen, und gleichzeitig die Bank des Zahlers anweist, diese einzulösen.

Wer Lastschriften einzieht, benötigt eine Gläubiger-Identifikationsnummer (Creditor-ID), die in Deutschland zentral von der Deutschen Bundesbank vergeben wird. Sie ist 18-stellig, beginnt mit der Länderkennung DE und einer zweistelligen Prüfziffer, gefolgt von einer Geschäftsbereichskennung und einer eindeutigen Kennung des Gläubigers. Diese Nummer ist gemeinsam mit der Mandatsreferenz die Klammer, die jeden einzelnen Einzug eindeutig einer Mandatsbeziehung zuordnet — und die Grundlage für jeden Rückerstattungsanspruch nach § 675x BGB.

Vom Schemawechsel zu pain.008.001.08

ISO 20022 trennt Nachrichten nach Geschäftsbereich: pain (Payments Initiation) für die Beauftragung, pacs für Interbankenverkehr, camt für Kontoauszüge. Lastschrifteinreichungen laufen über pain.008. Bis November 2025 war pain.008.001.02 der Standard, seither erwarten alle deutschen Banken pain.008.001.08 als Eingangsformat. Der wesentliche Unterschied liegt nicht in der fachlichen Logik, sondern in zusätzlichen strukturierten Adress- und Identifikationsfeldern, einer strikteren Validierung von Charaktersätzen und der Vorbereitung auf strukturierte Remittance-Information nach ISO 20022.

Praktisch heißt das: Wer noch pain.008.001.02 erzeugt, läuft seit Ende 2025 in Ablehnungen auf Bankebene, bevor der Einzug überhaupt am Schuldnerkonto ankommt. Software, die diesen Schemawechsel begleitet, muss XSD-validierend exportieren, sonst landet der Sammler im Fehlerprotokoll der Bank statt auf dem Konto der WEG. Die gleiche Disziplin gilt übrigens für eingehende Rechnungen: wir haben das Thema Formatumstieg bei E-Rechnung, ZUGFeRD und XRechnung ausführlich beschrieben — die Mechanik ist dieselbe, nur die Richtung der Nachricht ist eine andere.

Sequence-Types: FRST, RCUR, FNAL, OOFF

Jede Lastschrift trägt im Feld SeqTp einen Sequence-Type, der ihre Position innerhalb der Mandatsbeziehung definiert. Vier Werte sind zulässig:

Die Vorlauffristen waren bis 2016 für FRST und OOFF mit fünf Bankarbeitstagen (D-5) belegt, für RCUR und FNAL mit zwei (D-2). Mit der EPC-Reform 2016/2018 wurden FRST und OOFF auf D-1 vereinheitlicht, damit der gesamte SDD-CORE-Lauf einheitlich einen Bankarbeitstag Vorlauf benötigt. Aktueller Stand des EPC-Rulebooks ist eine Vorlauffrist von einem Bankarbeitstag (D-1) für alle Sequence-Types, sofern die Bank des Gläubigers das Verfahren COR1-konform abwickelt — das ist im SEPA-Raum heute der Regelfall. Wer in älteren Beiträgen noch D-5 oder D-6 für FRST liest, arbeitet mit Stand vor 2016.

Die saubere Berechnung dieses Sequence-Types ist eine der häufigsten Fehlerquellen. Wird ein Mandat einmal genutzt und liegt der nächste Einzug innerhalb der 36-Monats-Frist, ist RCUR korrekt. Wird ein Mandat reaktiviert, weil zwischenzeitlich kein Einzug erfolgte, ist wieder FRST zu setzen. Bei einem Eigentümerwechsel oder einer Bankverbindungsänderung des Schuldners wird ein neues Mandat mit eigener Mandatsreferenz erteilt, der erste Einzug darunter ist erneut FRST. Wer das in einer Excel-Liste pflegt, verliert diesen Status früher oder später aus dem Blick.

Mandatslebenszyklus und Aufbewahrung

Ein SEPA-Mandat hat einen klar definierten Lebenszyklus. Es entsteht durch Erteilung in Schriftform oder qualifizierter elektronischer Form, erhält eine eindeutige Mandatsreferenz (frei wählbar, maximal 35 Zeichen) und tritt in Kraft, sobald der Schuldner unterzeichnet hat. Mit dem ersten Einzug wechselt der interne Status von aktiv auf genutzt, der nächste Einzug ist RCUR. Erfolgt 36 Monate lang kein Einzug, verfällt das Mandat automatisch nach den Regeln des EPC-Rulebooks und muss neu eingeholt werden. Diese Frist ist nicht verhandelbar, sie ist Teil der Banken-seitigen Validierung.

Mandate sind mindestens 14 Monate über den Tag des letzten Einzugs hinaus aufzubewahren, weil bis zu 13 Monate später Erstattungen wegen nicht autorisierter Lastschriften (R-Code MD07) möglich sind. In der Praxis bedeutet das eine Aufbewahrungsfrist von effektiv drei Jahren, weil zusätzlich die handelsrechtlichen und steuerlichen Pflichten greifen. Wer Mandate digital verwaltet, sollte nicht nur das PDF speichern, sondern auch Hash, Erteilungsdatum, IP-Adresse bei elektronischer Erteilung und gegebenenfalls qualifizierte Signatur-Container revisionssicher ablegen.

Sammellauf, Pre-Notification und Cashflow

Der monatliche Sammellauf ist der Punkt, an dem aus Mandaten eine Liquiditätsplanung wird. Vor jedem Einzug ist eine SEPA-Pre-Notification an den Schuldner Pflicht, die Betrag, Fälligkeitsdatum und Mandatsreferenz mindestens 14 Kalendertage im Voraus mitteilt. Diese Frist kann durch Vereinbarung verkürzt werden — bei monatlichen Hausgeldern reicht in der Regel ein Vorlauf von einem Tag oder eine generische Ankündigung in der Hausgeldabrechnung respektive im Wirtschaftsplan nach § 28 WEG, die alle künftigen Einzüge dem Grunde nach angekündigt.

Der eigentliche Sammler wird als pain.008.001.08-XML erzeugt, in der Regel mit einem PmtInf-Block je Sequence-Type. Theoretisch lassen sich FRST- und RCUR-Sätze in derselben Nachricht mischen, praktisch trennen die meisten Banken sie sauber. Eingereicht wird üblicherweise ein bis zwei Bankarbeitstage vor Fälligkeit, damit die Bank Zeit hat, die Datei zu plausibilisieren und an die Schuldnerbanken weiterzureichen. Eine fundierte Liquiditätsplanung kombiniert diesen Soll-Zufluss mit dem Ist aus dem Konto-Abruf — ein Mechanismus, den wir im Beitrag zum Mieteingangs-Matching via Open Banking detailliert beschrieben haben.

Rückläufer und R-Transactions

Kein Sammellauf läuft ohne Rückläufer. Die Banken melden diese als R-Transactions zurück, der Verwalter erhält camt.054-Nachrichten oder direkte Reject/Return-Avise mit standardisierten Codes:

Reagiert wird codespezifisch: AC04 zieht eine Mandatssperre nach sich, AM04 setzt eine zweite Einzugsrunde mit Frist auf, MD06 löst eine Hausgeld-Mahnung aus, MD07 erzwingt eine rechtliche Prüfung, weil der Schuldner die Autorisierung grundsätzlich bestreitet. Diese Differenzierung ist die Brücke zum dreistufigen Mahnwesen mit Verzugszinsen nach § 288 BGB — ein Rückläufer ist kein Mahngrund, ein nachgewiesener Verzug schon.

Wie ImmoGenio das umsetzt

Die SEPA-Funktion in ImmoGenio basiert auf zwei Tabellen, die mit den Migrationen 049 und 050 eingeführt wurden: sepa_mandate für die digitale Mandatsverwaltung mit Status, Mandatsreferenz, Erteilungsdatum, Sequence-Type-Hinweis und Verfallsdatum, sowie sepa_creditor_bank für die Verwaltung der eigenen Gläubiger-Identifikationsnummer und der Bank-IBAN je Mandant. Mandate können entweder hochgeladen (PDF mit Hash-Speicherung) oder direkt im Portal vom Eigentümer signiert werden — die Signatur wird mit Zeitstempel und Identitätsnachweis archiviert.

Der Sammellauf-Generator erzeugt aus den offenen Sollstellungen einer Periode automatisch die XML-Datei. Dabei wird der Sequence-Type je Mandat berechnet: Liegt kein Einzug unter dem Mandat vor, wird FRST gesetzt; existiert mindestens ein erfolgreicher Einzug innerhalb der 36-Monats-Frist, wird RCUR verwendet; bei Mandatskündigung wird der letzte Einzug als FNAL markiert. Einmaleinzüge — etwa Sonderumlagen oder Mahnkosten — laufen als OOFF durch.

Der Status-Flow eines Sammellaufs ist bewusst dreistufig: entwurf für die Erfassung und Plausibilisierung, xml_erzeugt nach erfolgreicher XSD-Validierung gegen das pain.008.001.08-Schema, exportiert nach Übergabe an die Bank. Die XML-Datei wird in der bestehenden MinIO-Instanz revisionssicher abgelegt, jeder Statuswechsel wird in der Audit-Tabelle protokolliert. Die Trennung zwischen xml_erzeugt und exportiert ist kein Schönheitsfehler, sondern ein Schutz: Erst wenn der Sachbearbeiter aktiv den Versand bestätigt, gilt der Lauf als verbucht — vorher kann er folgenlos verworfen und neu erzeugt werden.

Was bewusst nicht gebaut wird

Drei Funktionen sind in v1 ausgeschlossen, obwohl sie technisch denkbar wären. Erstens: keine Mandatserteilung per API ohne menschliche Bestätigung. Ein Eigentümer muss aktiv unterzeichnen, sonst ist die Autorisierung im Streitfall vor Gericht angreifbar. Zweitens: keine automatische R-Transaction-Behandlung, die Rückläufer ohne Zutun des Sachbearbeiters reaktiviert. Die Codes MD06 und MD07 berühren Eigentümerrechte direkt, eine stille Wiedereinreichung wäre fahrlässig. Drittens: keine SEPA-B2B-Lastschrift, weil dieses Verfahren in der WEG-Verwaltung praktisch keine Rolle spielt — Eigentümer treten nicht als Unternehmen auf, der CORE-Pfad ist der einzig relevante.

Diese Grenzen sind Teil eines bewussten Architekturansatzes, der auch andere Bereiche prägt — siehe unseren Beitrag zu offenen API-Schnittstellen im DATEV-, Messdienst- und Smartlock-Ökosystem. Schnittstellen müssen offen, aber nicht beliebig sein. Auch der nachgelagerte DATEV-Export im Format 7 profitiert davon, dass jede Buchung aus dem SEPA-Lauf eindeutig auf Mandatsreferenz und Sequence-Type rückführbar bleibt.

Reifegrad und produktiver Einsatz

Das Modul ist seit dem Banken-seitigen Schemawechsel im November 2025 produktiv im Einsatz. XSD-Validierung gegen pain.008.001.08, Sequence-Type-Berechnung, MinIO-Archivierung und der dreistufige Status-Flow laufen stabil. Die Anbindung an das Mahnwesen, die Verzinsung der Mietkaution nach § 551 BGB und der Wirtschaftsplan-Sollstellungslauf nutzen denselben Mandatsstamm, sodass ein einmal erfasstes Mandat alle relevanten Einzugskanäle abdeckt.

Offene Punkte gibt es weiterhin im Bereich der R-Transaction-Auswertung: Heute werden Rückläufer aus dem camt-Import erkannt und einem Mandat zugeordnet, die Folgereaktion erfolgt aber manuell. Eine assistierte Behandlung — etwa Vorschlag „AM04 erneut einreichen“ oder „MD07 Mandat sperren, juristische Prüfung anstoßen“ — ist für eine kommende Iteration vorgesehen, ohne den Sachbearbeiter aus der Verantwortung zu nehmen.

Abschluss

Wer den Sammellauf beherrscht, gewinnt mehr als nur Bequemlichkeit. Er gewinnt eine planbare Liquidität, eine revisionssichere Mandatsverwaltung und einen sauberen Audit-Pfad von der Sollstellung über die XML-Datei bis zur Buchung auf dem Konto. Die formalen Anforderungen — pain.008.001.08, Sequence-Types, Vorlauffristen, Rücklaufgründe — wirken auf den ersten Blick technisch, sind in Summe aber ein Schutz für beide Seiten: für den Eigentümer, weil seine Rechte aus § 675x BGB durchgesetzt werden, und für die Verwaltung, weil jeder Einzug rechtssicher dokumentiert ist.

Fragen, Rückmeldungen oder eigene Erfahrungen aus dem Sammellauf in Ihrer Verwaltung nehmen wir gerne entgegen unter kontakt@immogenio.de.


— Voriger Beitrag
GoCardless für SEPA-Mandate: Digitale Unterzeichnung im Browser und der Doppel-Einzug-Schutz im pain.008-Sammellauf
— Naechster Beitrag
Bonitätsprüfung in der Vermietung: SCHUFA und Bonify rechtssicher einsetzen — Einwilligung, Retention, Provider-Strategy