Wenn die Bank eine Zahlungsdatei ablehnt oder der pain.001-Validator Befunde zeigt, steht dahinter eine konkrete Regel: die Geschäftsregeln des SEPA-Verfahrens, die Prüfgrundlage der deutschen Kreditwirtschaft (DK-TVS GBIC_5) oder das ISO-20022-Schema selbst. Jeder Eintrag erklärt den Hintergrund und den schnellsten Weg zur Lösung. Codes wie PAY_… und PAIN_… stammen aus der Sofortprüfung (Stufe 1), die Einträge zur Bank-Schema-Prüfung erklären die englischen XSD-Meldungen der Stufe 2. Zur Umstellung selbst: pain.001.001.09-Umstellung, DTAZV-Abschaltung und AWV-Meldepflicht.
PAIN_MISSING_HEADER Pflichtfelder im Nachrichtenkopf fehlenJede pain.001-Datei beginnt mit dem Nachrichtenkopf (GrpHdr). MsgId, CreDtTm und NbOfTxs sind dort Pflicht. Fehlt eines dieser Felder, lehnen Banken die Datei ab, bevor sie eine einzelne Zahlung ansehen.
Lösung: Die Datei neu aus der erzeugenden Software exportieren. Bleibt der Kopf unvollständig, liegt der Fehler in deren Export, nicht in den Zahlungsdaten.
PAIN_VERSION_03 Altes Format pain.001.001.03Die deutsche Kreditwirtschaft ist auf pain.001.001.09 umgestiegen. Das ältere .03-Format wird von vielen Banken nur noch übergangsweise oder gar nicht mehr angenommen; die Prüfgrundlage der Anlage 3 (DK-TVS) existiert für .03 nicht.
Lösung: In der erzeugenden Software auf pain.001.001.09 umstellen. Wenn die Software das nicht anbietet: die Datei in finisma Zahlungen importieren, dort erfolgt der Export immer als .09.
PAIN_COUNT_MISMATCH Deklarierte Transaktionszahl stimmt nichtNbOfTxs im Nachrichtenkopf muss der tatsächlichen Anzahl Zahlungen entsprechen. Banken vergleichen beide Werte und weisen die Datei bei Abweichung als inkonsistent ab.
Lösung: Die Datei wurde vermutlich von Hand verändert oder der Export brach ab. Neu exportieren statt nachbessern: der Zähler wird von der Software gesetzt.
PAIN_SUM_MISMATCH Kontrollsumme stimmt nichtCtrlSum im Nachrichtenkopf ist die Summe aller Beträge. Weicht sie von der tatsächlichen Summe ab, wurde die Datei nach dem Export verändert oder die Software rechnet falsch.
Lösung: Beträge gegen den Zahllauf prüfen und die Datei neu erzeugen. Händische Korrekturen an einzelnen Beträgen machen die Kontrollsumme ungültig.
PAIN_STRUCTURED_REMITTANCE Strukturierter VerwendungszweckDer Verwendungszweck liegt strukturiert vor (RmtInf/Strd, z. B. mit Gläubiger-Referenz nach ISO 11649). Der Import übernimmt ihn nur als Text; die Struktur geht dabei verloren.
Lösung: Für reine Überweisungen ist das unkritisch. Muss die strukturierte Referenz erhalten bleiben (z. B. RF-Referenz), die Datei unverändert bei der Bank einreichen statt sie zu konvertieren.
PAIN_UNSUPPORTED_PMTMTD Zahlungsmethode wird nicht unterstütztpain.001 kennt neben der Überweisung (TRF) auch Scheck (CHK). Verarbeitet wird hier nur die Überweisung; Zeilen mit anderer Methode werden übernommen, aber als Überweisung behandelt.
Lösung: Prüfen, ob die betroffenen Zeilen wirklich überwiesen werden sollen. Scheckzahlungen gehören nicht in einen SEPA-Zahllauf.
PAIN_MULTIPLE_DEBTORS Mehrere Auftraggeber in einer DateiDie Datei enthält mehrere PmtInf-Blöcke mit unterschiedlichen Auftraggebern. Das ist formal zulässig, beim Import wird aber nur der erste Auftraggeber übernommen.
Lösung: Je Auftraggeberkonto eine eigene Datei erzeugen. Die meisten Bankportale erwarten das ohnehin.
PAY_IBAN_INVALID IBAN-Prüfziffer falschDie IBAN besteht die Prüfziffernrechnung (Modulo 97) nicht. Ein Tippfehler oder Zahlendreher reicht; Banken lehnen die Zahlung in jedem Fall ab.
Lösung: Die IBAN Zeichen für Zeichen gegen die Rechnung oder den Briefkopf des Empfängers prüfen. Häufig sind zwei Ziffern vertauscht oder ein Zeichen fehlt.
PAY_IBAN_MISSING IBAN fehltEine Überweisungszeile ohne Empfänger-IBAN kann nicht ausgeführt werden. Im SEPA-Raum ist die IBAN die einzige zulässige Kontokennung.
Lösung: Die IBAN des Empfängers nachtragen. Sie steht auf der Rechnung, im Briefkopf oder im Impressum des Empfängers.
PAY_IBAN_FORMAT Kontoangabe unbrauchbar (DTAZV-Import)Beim Einlesen einer DTAZV-Datei enthielt das Kontofeld nur Füllzeichen. Ohne verwendbare Kontoangabe lässt sich keine Auslandszahlung erzeugen.
Lösung: Die Kontonummer oder IBAN des Empfängers in der Quelldatei ergänzen oder die Zeile nach dem Import von Hand vervollständigen.
PAY_BIC_FORMAT BIC hat kein gültiges FormatEin BIC hat 8 oder 11 Zeichen: Bankcode, Länderkennung, Ortscode, optional die Filiale (z. B. MARKDEF1100). Andere Längen oder Kleinbuchstaben weisen Banken zurück.
Lösung: Den BIC gegen die Angabe des Empfängers prüfen. Innerhalb des SEPA-Raums darf der BIC meist ganz entfallen; dann das Feld leeren statt raten.
PAY_ACCOUNT_OTHER_SCT Kontonummer statt IBAN im SEPA-ProfilSEPA-Überweisungen (SCT) verlangen zwingend eine IBAN. Nationale Kontonummern (Othr/Id) sind nur im Auslandszahlungsverkehr (AXZ) zulässig, etwa für Ziele außerhalb des IBAN-Raums.
Lösung: Für SEPA-Ziele die IBAN verwenden. Handelt es sich um eine echte Auslandszahlung, die Datei im AXZ-Profil prüfen und einreichen.
PAY_ACCOUNT_CONFLICT IBAN und Kontonummer gleichzeitigJe Zahlung ist genau eine Kontoangabe zulässig: IBAN oder nationale Kontonummer. Beides zusammen ist widersprüchlich und wird abgewiesen.
Lösung: Eine der beiden Angaben entfernen. Innerhalb des SEPA-Raums die IBAN behalten, außerhalb die dort übliche Kontokennung.
PAY_CREDITOR_AGENT_REQUIRED Empfängerbank ohne BIC unvollständigBei Auslandszahlungen ohne BIC müssen Name und Adresse der Empfängerbank (mindestens Ort und Land) angegeben sein, damit die Zahlung geroutet werden kann.
Lösung: Den BIC der Empfängerbank ergänzen. Ist keiner bekannt, Bankname, Ort und Land vollständig erfassen.
PAY_DEBTOR_CCY_DEFAULT Kontowährung des Auftraggebers fehltIm AXZ-Profil gehört die Währung des belasteten Kontos in die Datei (DbtrAcct/Ccy). Fehlt sie, wird EUR angenommen — bei Fremdwährungskonten führt das zu falschen Belastungen.
Lösung: Nur handeln, wenn das Konto nicht in EUR geführt wird: dann die tatsächliche Kontowährung angeben.
PAY_EXECUTION_DATE_PAST Ausführungstermin liegt in der VergangenheitDer gewünschte Ausführungstermin (ReqdExctnDt) ist abgelaufen. Das passiert fast immer beim Prüfen älterer Bestandsdateien: die Datei war beim Erzeugen korrekt, nur der Termin ist inzwischen vorbei. Viele Bankportale weisen solche Dateien ab, andere ziehen den Termin stillschweigend auf den nächsten Bankarbeitstag.
Lösung: Die Datei in finisma Zahlungen öffnen: beim Export wird der Ausführungstermin automatisch auf den nächsten Bankarbeitstag gesetzt. Alternativ den Termin in der erzeugenden Software anpassen und neu exportieren.
PAY_AMOUNT_INVALID Betrag ungültigBeträge müssen größer als 0 sein und dürfen höchstens zwei Nachkommastellen haben. Null- und Negativbeträge sind in Überweisungsdateien nicht zulässig.
Lösung: Den Betrag der betroffenen Zeile korrigieren. Gutschriften laufen nicht als negative Überweisung, sondern als eigene Zahlung in Gegenrichtung.
PAY_AMOUNT_MISSING Kein Betrag gefundenBeim Übernehmen einer Rechnung wurde weder ein offener Betrag (BT-115) noch ein Bruttobetrag (BT-112) gefunden. Ohne Betrag entsteht keine Überweisungszeile.
Lösung: Den zu zahlenden Betrag von Hand in der Zeile erfassen.
PAY_DUPLICATE Mögliche DoppelzahlungZwei oder mehr Zeilen tragen dieselbe Kombination aus IBAN, Betrag und Verwendungszweck. Das ist das typische Muster einer versehentlich doppelt erfassten Zahlung.
Lösung: Die betroffenen Zeilen vergleichen und Dubletten entfernen. Sind beide Zahlungen gewollt (z. B. zwei gleiche Raten), die Verwendungszwecke unterscheidbar machen.
PAY_AWV_HINT AWV-Meldepflicht möglichAuslandszahlungen über 50.000 Euro sind nach der Außenwirtschaftsverordnung meldepflichtig (Z4-Meldung an die Bundesbank, Meldeschwelle seit 2025). Der Hinweis blockiert nichts, die Meldung ist Sache des Zahlenden.
Lösung: Die Zahlung kann ausgeführt werden; die Z4-Meldung erfolgt separat über das Meldeportal der Bundesbank, in der Regel bis zum 7. Kalendertag des Folgemonats.
PAY_CURRENCY_SCT Fremdwährung im SEPA-ProfilSEPA-Überweisungen sind auf EUR festgelegt; die DK-TVS lässt im SCT-Profil keine andere Währung zu. Fremdwährungen laufen über den Auslandszahlungsverkehr.
Lösung: Die Zahlung im AXZ-Profil prüfen und einreichen. Der Validator schlägt das Profil anhand der Datei-Indizien bereits vor.
PAY_REMITTANCE_LENGTH Verwendungszweck fehlt oder ist zu langDer Verwendungszweck (RmtInf/Ustrd) darf höchstens 140 Zeichen haben, gezählt nach der Umsetzung in den SEPA-Zeichensatz. Ein leerer Verwendungszweck ist ebenfalls unzulässig; der Empfänger könnte die Zahlung nicht zuordnen.
Lösung: Den Text auf 140 Zeichen kürzen, am besten mit Rechnungsnummer und Kundennummer am Anfang. Umlaute zählen nach der Konvertierung teils doppelt (ä wird ae).
PAY_ENDTOEND_LENGTH End-to-End-Referenz zu langDie End-to-End-Referenz (EndToEndId) darf höchstens 35 Zeichen haben. Sie wandert unverändert bis zum Empfänger und dient der automatischen Zuordnung.
Lösung: Die Referenz kürzen. Ohne eigene Referenz ist NOTPROVIDED der zulässige Platzhalter.
PAY_CHARSET_REPLACED Zeichen für den SEPA-Zeichensatz ersetztSEPA erlaubt nur einen eingeschränkten Zeichensatz (Buchstaben, Ziffern und wenige Sonderzeichen). Zeichen außerhalb davon (z. B. §, „ oder Emojis) wurden automatisch ersetzt.
Lösung: Meist ist nichts zu tun; die Ersetzungen stehen im Hinweis. Nur prüfen, ob Namen und Verwendungszweck lesbar geblieben sind.
PAY_NAME_MISSING Name fehltAuftraggeber und Empfänger brauchen zwingend einen Namen (Dbtr/Nm bzw. Cdtr/Nm). Ohne Namen weisen Banken die Datei ab.
Lösung: Den fehlenden Namen erfassen, wie er beim Konto geführt wird.
PAY_ADDRESS_INCOMPLETE Adresse unvollständig (AXZ)Im AXZ-Profil sind Ort und Länderkennung von Auftraggeber und Empfänger Pflicht. Seit der Umstellung auf pain.001.001.09 verlangen die Banken strukturierte Adressen für Auslandszahlungen.
Lösung: Ort und Zwei-Buchstaben-Ländercode ergänzen (z. B. Zürich, CH). In finisma Zahlungen lassen sich fehlende Adressteile je Zeile nachtragen, auf Wunsch mit KI-Unterstützung aus der unstrukturierten Anschrift.
PAY_ADDRESS_LINES Adresszeilen verletzen die DK-RegelErlaubt sind höchstens zwei Adresszeilen mit je 70 Zeichen. Außerdem darf die Straße nicht doppelt stehen: entweder strukturiert (StrtNm) oder als Adresszeile, nicht beides.
Lösung: Die Adresse auf die strukturierten Felder verteilen (Straße, Ort, PLZ, Land) und die freien Adresszeilen leeren, oder umgekehrt.
PAY_CHARGEBEARER_AXZ Entgeltregelung SLEV im AXZ-ProfilSLEV (Service Level) ist die Entgeltregelung der SEPA-Überweisung. Im Auslandszahlungsverkehr gelten stattdessen SHAR, DEBT oder CRED, die festlegen, wer die Gebühren trägt.
Lösung: Für Auslandszahlungen die Entgeltregelung auf SHAR umstellen (üblicher Standard: geteilte Gebühren). DEBT und CRED nur nach Vereinbarung mit dem Empfänger.
PAY_SERVICE_LEVEL_SCT Ausführungspriorität im SEPA-ProfilEine gesonderte Ausführungspriorität (z. B. URGP) gehört nicht in eine SEPA-Standardüberweisung; die DK-TVS lässt sie im SCT-Profil nicht zu.
Lösung: Das Prioritätsfeld entfernen. Eilige Zahlungen laufen als Echtzeitüberweisung über einen eigenen Einreichungsweg, nicht über dieses Feld.
PAY_DIRECT_DEBIT Rechnung ist als Lastschrift gekennzeichnetDie übernommene Rechnung nennt Lastschrift als Zahlungsweg (BT-81). Der Betrag wird dann vom Empfänger eingezogen; eine zusätzliche Überweisung führt zur Doppelzahlung.
Lösung: Prüfen, ob ein SEPA-Mandat besteht. Wenn ja, die Zeile aus dem Zahllauf entfernen.
PAY_DTAZV_RECORD_UNREADABLE T-Satz nicht lesbarEin Transaktionssatz der DTAZV-Datei entspricht nicht dem Festformat (Satzlängenfeld, Feldgrenzen). Solche Sätze entstehen durch abgeschnittene Exporte oder nachträgliches Editieren.
Lösung: Die Datei neu aus der Quellsoftware exportieren. DTAZV wird von den Banken nicht mehr angenommen; der Import dient der Umstellung auf pain.001 (AXZ).
XSD_TVS_ENUM Wert von der DK-Prüfgrundlage nicht zugelassenMeldungen wie 'Value … is not facet-valid with respect to enumeration' bedeuten: das generische ISO-20022-Schema erlaubt den Wert, die Prüfgrundlage der deutschen Kreditwirtschaft (DK-TVS GBIC_5) schränkt ihn aber ein. Typisch: eine Fremdwährung oder eine andere Entgeltregelung als SLEV im SEPA-Profil.
Lösung: Zuerst das Profil prüfen: Auslandszahlungen gehören ins AXZ-Profil, dort sind diese Werte der Normalfall. Ist es wirklich eine SEPA-Überweisung, den beanstandeten Wert auf den zugelassenen umstellen.
XSD_PATTERN Feld verletzt das vorgeschriebene Muster'not facet-valid with respect to pattern' heißt: der Inhalt passt nicht zum vorgeschriebenen Aufbau des Feldes, etwa eine IBAN mit Kleinbuchstaben, ein BIC mit Sonderzeichen oder ein unzulässiges Zeichen im Verwendungszweck.
Lösung: Das in der Meldung genannte Feld korrigieren; die Zeilenangabe führt zur Stelle in der Datei. Stufe 1 dieses Validators zeigt für die häufigsten Fälle bereits die verständliche Meldung.
XSD_MAXLENGTH Feld zu lang'not facet-valid with respect to maxLength' bedeutet: der Inhalt überschreitet die zulässige Feldlänge, häufig beim Verwendungszweck (140 Zeichen) oder bei Namen (70 Zeichen).
Lösung: Den genannten Inhalt kürzen und die Datei neu erzeugen.
XSD_ELEMENT Element unerwartet oder an falscher StelleMeldungen wie 'Invalid content was found starting with element …' zeigen ein Element, das an dieser Stelle nicht stehen darf. Häufigste Ursache: die Datei mischt Versionen (Elemente aus .03 in einer .09-Datei) oder die erzeugende Software hält die Reihenfolge des Schemas nicht ein.
Lösung: Exportversion der Software prüfen und die Datei neu erzeugen. Bei Eigenentwicklungen die Elementreihenfolge des XSD einhalten; sie ist nicht frei wählbar.
Datei zur Hand? Der pain.001-Validator prüft sie kostenlos in zwei Stufen: sofort im Browser gegen die Geschäftsregeln, auf Wunsch gegen dieselben Schemas, die auch die deutschen Banken verwenden. Zum Korrigieren übernimmt finisma Zahlungen die Datei mit einem Klick.