Bank lehnt die SEPA-Datei ab: was zuerst zu prüfen ist

ARLing s. r. o. · 6. September 2026

Eine SEPA-Sammelüberweisung wird als XML-Datei im Format pain.001 aus der Buchhaltungssoftware exportiert und im Onlinebanking hochgeladen. Weist die Bank die Datei zurück, ist die Fehlermeldung oft unspezifisch: „Datei konnte nicht verarbeitet werden" oder ein interner Fehlercode ohne Erklärung. Was dahintersteckt, lässt sich meist selbst herausfinden, weil pain.001 eine genormte XML-Struktur ist und die Regeln dafür öffentlich dokumentiert sind.

Wichtig vorab: Die folgenden Regeln stammen aus dem ISO-20022-Nachrichtenstandard und dem Rulebook für die SEPA-Überweisung des European Payments Council (EPC), sie gelten für jede Bank im SEPA-Raum. Einzelne Banken legen zusätzlich eigene, engere Grenzen fest, etwa wie viele Tage im Voraus ein Ausführungsdatum liegen darf. Solche Grenzen sind hier klar als Beispiel gekennzeichnet, nicht als allgemeine Regel.

Die häufigsten Gründe, der Reihe nach

1. NbOfTxs und CtrlSum stimmen nicht mit dem Inhalt überein

Der Kopfbereich der Datei (GrpHdr) trägt zwei Zahlen, die den Inhalt zusammenfassen: NbOfTxs ist die Anzahl der Zahlungen, CtrlSum die Summe aller Beträge. Beide Werte müssen exakt zum tatsächlichen Inhalt passen. Eine Abweichung ist einer der häufigsten Gründe für eine gescheiterte Verarbeitung, besonders wenn die Datei nach dem Export noch von Hand angepasst wurde.

So prüfen Sie es selbst: Öffnen Sie die Datei in einem Texteditor mit einer Funktion „Alle suchen" (zum Beispiel Notepad++, Strg+F, Reiter „Suchen"). Suchen Sie nach <CdtTrfTxInf> und lesen Sie die Trefferzahl ab: das ist die tatsächliche Anzahl der Zahlungen. Vergleichen Sie sie mit <NbOfTxs>. Für die Summe suchen Sie alle Vorkommen von <InstdAmt und addieren die Beträge von Hand oder in einer Tabelle, auf zwei Nachkommastellen genau, und vergleichen mit <CtrlSum>.

2. ReqdExctnDt: rückdatiert oder zu weit in der Zukunft

ReqdExctnDt ist das gewünschte Ausführungsdatum, im Format JJJJ-MM-TT. Ein Datum in der Vergangenheit akzeptiert keine Bank. Manche Banken lehnen zusätzlich ein zu weit in der Zukunft liegendes Datum ab, wie weit genau legt jede Bank selbst fest. Eine slowakische Bank nennt in ihrer Importbeschreibung als Beispiel ein Zeitfenster von 31 Tagen: das ist eine Grenze dieser einen Bank, keine SEPA-Regel, und gilt nicht automatisch in Deutschland, Österreich oder Tschechien.

So prüfen Sie es selbst: Suchen Sie nach <ReqdExctnDt> und vergleichen Sie das Datum mit dem heutigen. Liegt es davor, ist das der Fehler. Liegt es viele Wochen voraus, prüfen Sie im Onlinebanking Ihrer Bank, welches Zeitfenster dort gilt.

3. PmtMtd ist nicht TRF

Für eine SEPA-Überweisung muss das Feld PmtMtd exakt den Wert TRF tragen. Das ist ein fester Wert aus dem SEPA-Regelwerk, kein Feld zum freien Ausfüllen. Ein anderer Wert oder eine Kleinschreibung führt zur Ablehnung.

So prüfen Sie es selbst: Suchen Sie nach <PmtMtd> und prüfen Sie, dass genau TRF in Großbuchstaben zwischen den Tags steht.

4. SvcLvl/Cd ist nicht SEPA

Das Feld SvcLvl mit dem Code Cd darunter markiert eine Zahlung nach dem SEPA-Standard und muss exakt SEPA lauten. Es kann sowohl auf Ebene des Zahlungsblocks (PmtInf) als auch je Transaktion vorkommen, je nachdem wie die Buchhaltungssoftware die Datei aufbaut.

So prüfen Sie es selbst: Suchen Sie nach <SvcLvl>, dahinter folgt ein <Cd> mit dem Wert. Prüfen Sie bei jedem Vorkommen, dass dort SEPA steht.

5. ChrgBr ist nicht SLEV

ChrgBr regelt, wer die Bankgebühren trägt. Für eine SEPA-Überweisung gilt ausschließlich SLEV: jede Seite trägt ihre eigenen Gebühren. Werte wie SHAR, DEBT oder CRED gehören zu anderen Zahlungsarten und werden bei einer SEPA-Überweisung zurückgewiesen oder als Fehler markiert.

So prüfen Sie es selbst: Suchen Sie nach <ChrgBr> und prüfen Sie den Wert dazwischen.

6. Ungültige IBAN (MOD-97)

Jede IBAN trägt eine eingebaute Prüfziffer, die sich mit dem Verfahren Modulo 97 (ISO 7064) nachrechnen lässt: Die ersten vier Zeichen wandern ans Ende, Buchstaben werden in Zahlen umgewandelt (A=10 bis Z=35), und die entstandene Zahl muss bei Division durch 97 den Rest 1 ergeben. Ein Zahlendreher beim Abtippen einer IBAN aus einer E-Mail oder einem Papierbeleg fällt genau hier auf.

So prüfen Sie es selbst: Die Rechnung von Hand ist mühsam, zwei Dinge sehen Sie aber auch so im Editor. Erstens: Die IBAN darf keine Leerzeichen enthalten, sie steht als eine Zeichenkette in <IBAN>. Zweitens: Die Länge muss zur Länderkennung passen, etwa 22 Zeichen für DE, 20 für AT, 21 für CH, 24 für CZ und SK. Für die Prüfziffer selbst ist eine automatische Prüfung praktischer als das Nachrechnen von Hand.

7. Falscher Namensraum

Ganz oben in der Datei steht das Wurzelelement <Document> mit einem Namensraum-Attribut (xmlns), das der Bank sagt, welche Formatversion sie vor sich hat. Für die verbreitete Version lautet er urn:iso:std:iso:20022:tech:xsd:pain.001.001.03. Ein fehlender Namensraum oder eine andere Version, etwa pain.001.001.09, wird von manchen Bank-Importfunktionen gar nicht oder mit unklarer Fehlermeldung angenommen, weil sie nur auf eine Version eingestellt sind. Welche Version eine Bank gerade erwartet, ändert sich mit der Zeit und ist beim Institut zu erfragen.

So prüfen Sie es selbst: Lesen Sie die erste Zeile mit dem <Document>-Tag. Der Wert hinter xmlns= muss vorhanden sein und exakt der Version entsprechen, die Ihre Bank laut eigenen Unterlagen oder Onlinebanking-Hinweisen erwartet.

8. Zeichen außerhalb des SEPA-Zeichensatzes

Für Namen, Verwendungszweck und andere Textfelder erlaubt der SEPA-Zeichensatz nur eine begrenzte Auswahl: die Buchstaben a bis z und A bis Z ohne Akzente, die Ziffern 0 bis 9, das Leerzeichen und die Zeichen / - ? : ( ) . , ' +. Für deutschsprachige Nutzer ist das praxisrelevant: Umlaute wie ä, ö, ü und das ß gehören nicht zu diesem ursprünglichen Zeichensatz. Viele Banken haben ihre Systeme um einen erweiterten Zeichensatz ergänzt, der Umlaute zulässt, das ist jedoch nicht überall und nicht in jedem Feld garantiert. Ein Name wie „Müller & Söhne GmbH" oder ein Verwendungszweck mit ß kann je nach Bank zur Ablehnung oder zu einer unerwünschten Umschreibung führen.

So prüfen Sie es selbst: Gehen Sie mit der Suchfunktion gezielt die Felder <Nm> und <Ustrd> durch, und achten Sie auf Umlaute, das ß sowie andere Anführungszeichen als den einfachen Apostroph. Ersetzen Sie im Zweifel ä durch ae, ö durch oe, ü durch ue und ß durch ss.

Wenn all das stimmt und die Bank trotzdem ablehnt

Diese acht Punkte decken die formalen SEPA- und ISO-20022-Anforderungen ab. Eine Bank kann zusätzlich eigene Regeln haben: eine maximale Zahlungsanzahl pro Datei, ein zusätzliches Pflichtfeld oder eine eigene Vorgabe zum BIC des Zahlungsempfängers. Solche Regeln stehen in der Importdokumentation der jeweiligen Bank und unterscheiden sich von Land zu Land: Was für eine slowakische Bank gilt, muss für eine deutsche nicht gelten. Bleibt die Ablehnung danach unklar, ist die Importdokumentation der eigenen Bank oder deren Support die richtige Anlaufstelle.

Kurz zusammengefasst

Die meisten Ablehnungen einer pain.001-Datei lassen sich auf einen dieser acht Punkte zurückführen, alle acht sind mit einem gewöhnlichen Texteditor nachprüfbar. Das kostet wenige Minuten und erspart oft einen Anruf beim Support. Wer die Prüfung nicht von Hand machen möchte: SEPA pain.001 Doctor prüft eine Datei kostenlos dagegen, direkt im Browser, ohne sie irgendwohin hochzuladen.