15 häufige SEPA-XML-Fehler und wie man sie behebt
Ein umfassender Leitfaden zu den häufigsten Validierungsfehlern in SEPA pain.001 und pain.008, mit praktischen Lösungen für jeden Fehler.
Warum SEPA-XML-Dateien abgelehnt werden
SEPA-XML-Dateien (pain.001 für Überweisungen und pain.008 für Lastschriften) folgen strengen ISO-20022-Schemata des European Payments Council (EPC). Selbst kleinste Abweichungen von der erwarteten Struktur führen dazu, dass Banken gesamte Zahlungsstapel ablehnen. Das Verständnis häufiger Fehler spart Zeit und verhindert kostspielige Zahlungsverzögerungen.
Dieser Leitfaden behandelt die 15 häufigsten SEPA-XML-Fehler, die Treasury-Teams, Buchhalter und Entwickler in ganz Europa begegnen. Jeder Fehler umfasst die Grundursache, das beteiligte XML-Element und eine geprüfte Lösung.
Ob Sie SAP, Oracle oder ein individuelles ERP verwenden – diese Muster gelten universell für alle SEPA-konformen Zahlungsdateien.
Schema- und Strukturfehler
Diese Fehler treten auf, wenn die XML-Struktur nicht mit dem EPC-XSD-Schema übereinstimmt.
1. Falscher Namespace oder falsche Schemaversion
Das Root-Element <Document> muss den korrekten Namespace für Ihre pain.001-Version deklarieren (z.B. urn:iso:std:iso:20022:tech:xsd:pain.001.001.09). Das Mischen von Namespaces verschiedener Versionen führt zu einem sofortigen XSD-Validierungsfehler.
2. Fehlende Pflichtfelder in GrpHdr
Der GroupHeader (GrpHdr)-Block erfordert MsgId, CreDtTm, NbOfTxs, CtrlSum und InitgPty. Das Weglassen eines dieser Felder – insbesondere CtrlSum – führt dazu, dass die Datei die Schemavalidierung nicht besteht, bevor die Bank die Zahlungsanweisungen überhaupt verarbeitet.
3. Ungültige XML-Kodierung oder BOM
SEPA-XML muss UTF-8-Kodierung verwenden. Dateien mit einem BOM (Byte Order Mark), UTF-16 oder Windows-1252-Kodierung werden abgelehnt. Stellen Sie sicher, dass Ihr Exporttool reines UTF-8 ohne BOM schreibt.
4. Elemente in falscher Reihenfolge
ISO-20022-Schemata erzwingen eine strenge Element-Reihenfolge. Zum Beispiel muss in PmtInf die PmtMtd vor ReqdExctnDt erscheinen. Das Vertauschen von Elementpositionen – auch wenn alle Daten vorhanden sind – führt zu einem Schemavalidierungsfehler.
5. Doppelte MsgId über Dateien hinweg
Jede SEPA-Datei muss eine eindeutige MsgId haben. Wenn Ihr System dieselbe MsgId für verschiedene Zahlungsstapel wiederverwendet, lehnt die Bank das Duplikat als potenziellen Replay-Angriff ab. Verwenden Sie Zeitstempel oder UUIDs, um Eindeutigkeit zu gewährleisten.
IBAN- und BIC-Fehler
Fehler bei Kontokennungen sind der häufigste Grund für SEPA-Ablehnungen.
6. Ungültige IBAN-Prüfsumme (mod-97)
IBANs verwenden einen mod-97-Algorithmus für ihre Prüfziffern (Positionen 3-4). Ein einzelner ZifferFehler lässt die Prüfsumme scheitern. Validieren Sie IBANs immer programmgesteuert, bevor Sie sie in Ihre SEPA-Datei aufnehmen. ValidateFin prüft jede IBAN in Ihrer Datei automatisch.
7. IBAN-Längenfehler für das Land
Jedes Land hat eine feste IBAN-Länge (z.B. DE=22, FR=27, BE=16, NL=18). Eine IBAN mit der falschen Anzahl von Zeichen für ihr Länderpräfix ist sofort ungültig.
8. Veralteter oder ungültiger BIC
BIC/SWIFT-Codes können nach Bankfusionen veraltet sein. Die Verwendung eines veralteten BIC verursacht Routing-Fehler. Für SEPA-Zahlungen innerhalb des EWR ist BIC seit 2016 optional – erwägen Sie, ihn wegzulassen und die Bank ihn aus der IBAN ableiten zu lassen.
Betrags- und Währungsfehler
Finanzielle Validierungsfehler, die zu stapelweiser Ablehnung führen.
9. CtrlSum stimmt nicht mit der Transaktionssumme überein
Die CtrlSum in GrpHdr muss exakt der Summe aller InstdAmt-Werte in der Datei entsprechen. Selbst ein Rundungsunterschied von 0,01 € führt zur Ablehnung der gesamten Datei. Verwenden Sie dezimalgenaue Arithmetik, keine Gleitkommazahlen.
10. Nicht-EUR-Währung in der SEPA-Datei
SEPA Credit Transfers unterstützen nur EUR. Wenn Ihre Datei Beträge in GBP, CHF oder anderen Währungen enthält, lehnt die Bank sie ab. Verwenden Sie einen separaten internationalen Zahlungskanal für Nicht-EUR-Überweisungen.
11. Betragsformat mit falschem Dezimaltrennzeichen
SEPA-XML verwendet einen Punkt (.) als Dezimaltrennzeichen, kein Komma. Der Wert muss genau 2 Dezimalstellen haben: <InstdAmt Ccy="EUR">1500.00</InstdAmt>. Werte wie "1500" oder "1.500,00" sind ungültig.
Datums- und Kennungsfehler
Häufige Fehler bei Datumsangaben und Referenzfeldern.
12. Vergangenes oder ungültiges Ausführungsdatum
Das ReqdExctnDt muss ein aktueller oder zukünftiger Geschäftstag sein. Die meisten Banken lehnen Daten in der Vergangenheit und Daten mehr als 30 Tage im Voraus ab. Wochenenddaten werden auf Montag verschoben, aber einige Banken lehnen sie direkt ab.
13. Ungültige Zeichen in EndToEndId
Das EndToEndId-Feld (max. 35 Zeichen) erlaubt nur einen eingeschränkten Zeichensatz: a-z, A-Z, 0-9 und einige Sonderzeichen (/, -, ?, :, (, ), ., +, Leerzeichen). Zeichen wie #, @, é, ü werden abgelehnt.
14. Fehlende Gläubiger-Identifikation für SDD
SEPA Direct Debit (pain.008) erfordert eine gültige Gläubiger-Identifikation (CI) in CdtrSchmeId. Dies ist eine länderspezifische Registrierung (z.B. ICS in Frankreich, Gläubiger-ID in Deutschland). Ohne sie schlägt der gesamte SDD-Stapel fehl.
15. NbOfTxs-Anzahl stimmt nicht überein
Das NbOfTxs-Feld in GrpHdr muss der tatsächlichen Anzahl von CdtTrfTxInf- (oder DrctDbtTxInf-)Elementen in der Datei entsprechen. Eine Diskrepanz – oft verursacht durch teilweise Dateigenerierung – führt zu sofortiger Ablehnung.
Validieren Sie Ihre SEPA-Dateien sofort
ValidateFin erkennt alle 15 oben aufgeführten Fehler – und mehr. Laden Sie Ihre pain.001- oder pain.008-Datei hoch und erhalten Sie sofortiges Feedback zu Schema-Konformität, IBAN-Validierung, Betragskonsistenz und Zeichenkodierung.
SEPA-Validator öffnenHäufig gestellte Fragen
Was ist der häufigste SEPA-XML-Fehler?
Der häufigste Fehler ist eine ungültige IBAN-Prüfsumme (mod-97-Fehler). Dieser macht etwa 30 % aller SEPA-Dateiablehnungen aus. Validieren Sie IBANs immer, bevor Sie Ihre Zahlungsdatei erstellen.
Kann ich SEPA-Fehler beheben, ohne die gesamte Datei neu zu generieren?
Es hängt vom Fehler ab. Einfache Korrekturen wie das Korrigieren einer IBAN oder das Anpassen von CtrlSum können durch direktes Bearbeiten der XML-Datei vorgenommen werden. Strukturelle Fehler (falsche Elementreihenfolge, fehlender Namespace) erfordern jedoch in der Regel eine Neugenerierung aus dem Quellsystem.
Prüft ValidateFin alle 15 Fehler?
Ja. ValidateFin validiert Ihre SEPA-Datei gegen EPC-XSD-Schemata, prüft jede IBAN mit mod-97, verifiziert die CtrlSum-Konsistenz, validiert die Zeichenkodierung und kennzeichnet alle strukturellen Probleme. Die Validierung läuft vollständig in Ihrem Browser – keine Datei wird hochgeladen.
Warum lehnt meine Bank eine Datei ab, die die XSD-Validierung bestanden hat?
XSD-Validierung prüft nur die XML-Struktur. Banken wenden auch Geschäftsregeln an: gültige Ausführungsdaten, korrekte CtrlSum, eindeutige MsgId und korrekte IBAN/BIC. ValidateFin prüft sowohl Schema als auch Geschäftsregeln.
Sind SEPA-Fehlercodes standardisiert?
Ja. Banken verwenden ISO-20022-Grundcodes (z.B. AC01 für falsche IBAN, AM05 für Duplikat, AG01 für verbotenen Transaktionstyp). Der EPC pflegt eine vollständige Liste im SEPA-Grundcode-Dokument.
Wie verhindere ich SEPA-Fehler in meinem ERP?
Implementieren Sie IBAN-Validierung bei der Dateneingabe, verwenden Sie eine SEPA-XML-Bibliothek (keine String-Konkatenation) zur Dateigenerierung, validieren Sie die Ausgabedatei vor dem Versand und testen Sie immer zuerst mit dem Validierungstool Ihrer Bank.
Was passiert, wenn eine SEPA-Datei abgelehnt wird?
Die Bank gibt einen pain.002-Statusbericht mit Ablehnungsgrundcodes für jede fehlgeschlagene Transaktion zurück. Sie müssen die Fehler beheben und die gesamte Datei oder den betroffenen Zahlungsblock erneut einreichen.
Können Zeichenkodierungsprobleme unsichtbar sein?
Ja. Einige Zeichen (wie typografische Anführungszeichen " " oder Em-Dashes —) sehen auf dem Bildschirm korrekt aus, liegen aber außerhalb des SEPA-Zeichensatzes. Sie verursachen Ablehnungen ohne offensichtlichen visuellen Hinweis. ValidateFin kennzeichnet diese unsichtbaren Kodierungsprobleme.
Gibt es einen Unterschied bei der Fehlerbehandlung zwischen pain.001.001.03 und .09?
Die neueren Versionen (09, 11) haben strengere Validierung. Einige Felder, die in 03 optional waren, sind jetzt obligatorisch. Die Zeichensatzbeschränkungen sind dieselben. ValidateFin validiert gegen die in Ihrer Datei deklarierte spezifische Version.
Wie lange habe ich Zeit, eine abgelehnte SEPA-Datei zu korrigieren?
Es gibt keine Standardfrist, aber Zahlungsverzögerungen häufen sich an. Die meisten Treasury-Teams streben an, innerhalb von 4 Geschäftsstunden zu korrigieren und neu einzureichen. Die Vorab-Validierung mit ValidateFin eliminiert die meisten Ablehnungsszenarien.