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. Die Gläubigerreferenz (CdtrRefInf/Ref, z. B. RF18…) steht danach als Text im Verwendungszweck, so erkennen die meisten Empfängersysteme sie weiterhin.
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_EXECUTION_TIME Ausführungstermin mit UhrzeitDas SEPA-Schema erlaubt den Ausführungstermin als Datum oder als Zeitpunkt mit Uhrzeit (ReqdExctnDt/DtTm), etwa für Echtzeitüberweisungen zu einer bestimmten Stunde. Der Import übernimmt den Tag; eine neu exportierte Datei nennt den Termin ohne Uhrzeit.
Lösung: Für gewöhnliche Überweisungen ist das ohne Bedeutung. Muss die Zahlung zu einer bestimmten Uhrzeit ausgeführt werden, die Originaldatei unverändert verwenden.
PAIN_PAYMENT_TYPE_DROPPED Angaben zur Zahlungsart werden nicht übernommenPmtTpInf und Purp beschreiben, wie eine Zahlung laufen soll: Zahlverfahren (LclInstrm, etwa INST für die Echtzeitüberweisung), Zahlungskategorie (CtgyPurp), Priorität (InstrPrty) und Zahlungszweck (Purp). Der Import übernimmt davon die Kategorie SALA für Gehaltszahlungen und das Kennzeichen INST für Echtzeitüberweisungen (beides nur in SEPA-Dateien), die Priorität HIGH und den Zweckcode Purp/Cd; die Priorität NORM ist der Standardwert und braucht keine Übernahme. Alles andere fehlt danach, auch in einer daraus exportierten Datei. Achtung bei SALA: Als Zweckcode (Purp/Cd) ist es nur ein Hinweis an den Empfänger und wird so durchgereicht; nur als Kategorie (PmtTpInf/CtgyPurp) kennzeichnet es einen Gehaltslauf für die Bank.
Lösung: Der Befund nennt Feld, Wert und die Zahl der betroffenen Zahlungen. INST erscheint hier nur, wenn die Datei nach einer Auslandszahlung aussieht; eine AXZ-Datei kennt keine Echtzeitüberweisung. Braucht die Bank eine dieser Angaben, die Originaldatei unverändert 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 Inlandszahlungen laufen als SEPA-Echtzeitüberweisung: dieselbe pain.001, aber mit dem Kennzeichen INST (LclInstrm) und unter einer eigenen Auftragsart eingereicht, per EBICS CIP (mit Empfängerüberprüfung CIV) statt CCT. In finisma unter Zahlungsdateien den Schalter „Echtzeitüberweisung“ für die SEPA-Datei setzen.
PAY_CATEGORY_PURPOSE_AXZ Gehaltszahlung im AXZ-ProfilDie Kennzeichnung als Gehaltszahlung (CtgyPurp SALA) schreibt finisma nur in SEPA-Dateien. Eine Auslandszahlungsdatei (AXZ) aus finisma enthält kein CtgyPurp; die Kennzeichnung ginge beim Erzeugen verloren.
Lösung: Die Kennzeichnung bei Auslandszahlungen entfernen. Ob Gehaltszahlungen ins Ausland eine eigene Kennzeichnung brauchen, mit der Bank klären.
PAY_LOCAL_INSTRUMENT_AXZ Echtzeitüberweisung im AXZ-ProfilDas Kennzeichen INST (LclInstrm) gibt es nur für SEPA-Überweisungen in Euro. Eine Auslandszahlungsdatei (AXZ) kennt keine Echtzeitüberweisung; die Kennzeichnung ginge beim Erzeugen verloren.
Lösung: Das Kennzeichen bei Auslandszahlungen entfernen. Eilige Auslandszahlungen über die Ausführung Eilig (URGP) kennzeichnen.
PAY_INST_AMOUNT Echtzeitüberweisung über 100.000 EuroFür Echtzeitüberweisungen galt lange eine Obergrenze von 100.000 Euro je Zahlung. Viele Banken begrenzen den Betrag weiter selbst, und auch Kunden können eigene Limits festlegen. Eine Zahlung über der Grenze lehnt die Bank ab, im Sammler betrifft das nur diese Zahlung.
Lösung: Die Grenze vorab mit der Bank klären. Liegt sie darunter, die Zahlung als normale SEPA-Überweisung in einer eigenen Datei ohne Echtzeit-Kennzeichen einreichen.
PAY_INSTR_PRTY_AXZ Priorität HIGH im AXZ-ProfilDie Priorität (InstrPrty HIGH) schreibt finisma nur in SEPA-Dateien. Eine Auslandszahlungsdatei (AXZ) aus finisma enthält kein InstrPrty; dort kennzeichnet die Ausführung URGP (SvcLvl) eine eilige Zahlung.
Lösung: Die Priorität bei Auslandszahlungen entfernen und stattdessen die Ausführung auf Eilig (URGP) stellen.
PAY_FIELD_AXZ_ONLY Angabe aus dem Auslandszahlungsverkehr in einer SEPA-DateiEinige Angaben gibt es nur im Auslandszahlungsverkehr: das Sitzland einer Partei (CtryOfRes), die eindeutige Transaktionsreferenz UETR, Korrespondenzbanken (IntrmyAgt), die Clearing-Kennung der Empfängerbank (ClrSysMmbId) und Weisungen an die Banken (InstrForCdtrAgt, InstrForDbtrAgt). Die Prüfgrundlage der deutschen Banken für SEPA-Dateien (DK-TVS) kennt diese Elemente nicht. Der Import behält die Werte, der SEPA-Export lässt sie weg, der AXZ-Export schreibt sie.
Lösung: Für SEPA-Zahlungen sind diese Angaben entbehrlich, der Hinweis ist dann nur eine Information. Braucht die Bank oder der Empfänger sie, die Zahlung als Auslandszahlung (AXZ) exportieren.
PAY_COUNTRY_OF_RESIDENCE_FORMAT Sitzland ohne gültigen LändercodeDas Sitzland (CtryOfRes) ist ein Ländercode nach ISO 3166 aus zwei Großbuchstaben, zum Beispiel NL oder US. Das Schema prüft das Muster streng; ein ausgeschriebener Ländername, Kleinbuchstaben oder drei Buchstaben führen zur Ablehnung der Datei.
Lösung: Den Code auf zwei Großbuchstaben korrigieren. In der CSV-Vorlage steht er in der Spalte sitzland_empfaenger.
PAY_UETR_FORMAT UETR ist keine gültige UUIDDie eindeutige Transaktionsreferenz UETR ist eine UUID der Version 4 in Kleinbuchstaben (8-4-4-4-12 Hexadezimalzeichen, dritte Gruppe beginnt mit 4, vierte mit 8, 9, a oder b). Banken reichen sie unverändert durch die gesamte Zahlungskette; ein anderes Format lehnt das Schema ab.
Lösung: Die UETR in Kleinbuchstaben und im UUID-Format angeben oder das Feld leer lassen; dann vergibt die Bank selbst eine. In der CSV-Vorlage steht sie in der Spalte uetr.
PAY_EQUIVALENT_AMOUNT_SCT Gegenwertzahlung in einer SEPA-DateiBei einer Gegenwertzahlung (Amt/EqvtAmt) steht der Betrag in Kontowährung, überwiesen wird der Gegenwert in einer anderen Währung (CcyOfTrf), etwa 800 EUR Gegenwert in USD. Eine SEPA-Überweisung kennt das nicht: Sie würde den Betrag direkt in Euro überweisen, die Zahlung änderte ihre Bedeutung.
Lösung: Die Zahlung als Auslandszahlung (AXZ) exportieren. Soll stattdessen ein Euro-Betrag überwiesen werden, die Gegenwertangabe in der Ausgangsdatei entfernen.
PAY_TRANSFER_CURRENCY_FORMAT Zielwährung der Gegenwertzahlung ungültigDie Währung, in der der Gegenwert beim Empfänger ankommt (CcyOfTrf), ist ein Code nach ISO 4217 aus drei Großbuchstaben, zum Beispiel USD oder CHF. Das Schema der Banken prüft das Muster streng.
Lösung: Den Währungscode auf drei Großbuchstaben korrigieren.
PAY_INTERMEDIARY_AGENTS Zu viele KorrespondenzbankenEine Auslandszahlung kann über eine oder zwei Korrespondenzbanken laufen (IntrmyAgt1, IntrmyAgt2), etwa bei Zahlungen in US-Dollar. Das AXZ-Schema der deutschen Banken erlaubt höchstens zwei, jeweils nur mit BIC.
Lösung: Die Korrespondenzbanken mit der Empfängerbank abstimmen und auf höchstens zwei BICs beschränken.
PAY_CLEARING_MEMBER_FORMAT Clearing-Kennung der Empfängerbank ungültigOhne BIC lässt sich eine Bank über ihre Kennung in einem nationalen Clearingsystem bestimmen (ClrSysMmbId), etwa die ABA-Routing-Nummer in den USA (Systemcode USABA) oder den Sort Code in Großbritannien (GBDSC). Der Systemcode hat höchstens fünf Zeichen, die Kennung höchstens 35.
Lösung: Systemcode und Kennung beim Empfänger erfragen und vollständig eintragen. Ist ein BIC bekannt, reicht der BIC.
PAY_AGENT_INSTRUCTION_INVALID Weisung an eine Bank ungültigAn die Empfängerbank gehen höchstens zwei Weisungen (InstrForCdtrAgt) mit den Codes CHQB, HOLD, PHOB oder TELB und einem Text bis 140 Zeichen, an die eigene Bank ein Text bis 140 Zeichen (InstrForDbtrAgt). Andere Codes oder längere Texte lehnt das AXZ-Schema ab.
Lösung: Code und Länge korrigieren. Weisungen sind selten nötig; im Zweifel weglassen und mit der eigenen Bank klären.
PAY_ADDRESS_FIELD_LENGTH Adressfeld zu langNeben Straße, Ort und Postleitzahl kennt die Adresse weitere Felder mit festen Längen: Abteilung, Etage und Raum bis 70 Zeichen, Gebäudename, Ortsteil, Bezirk und Bundesstaat bis 35 Zeichen, Postfach bis 16 Zeichen. Längere Werte lehnt das Schema der Banken ab.
Lösung: Den genannten Wert kürzen oder in eine Adresszeile verlegen.
PAY_PURPOSE_CODE_FORMAT Zweckcode hat kein gültiges FormatDer Zweckcode (CdtTrfTxInf/Purp/Cd) ist ein Code aus der ISO-20022-Liste ExternalPurpose1Code: ein bis vier Großbuchstaben oder Ziffern, etwa SUPP für Lieferantenzahlung, SALA für Gehalt oder TAXS für Steuern. Er richtet sich an den Empfänger; die Bank reicht ihn durch, ohne die Ausführung zu ändern.
Lösung: Den Code gegen die veröffentlichte Liste prüfen und in Großbuchstaben eintragen, oder das Feld leer lassen. Ob der Code inhaltlich zur Liste gehört, prüft erst die Bank-Schema-Prüfung (Stufe 2).
PAY_ULTIMATE_NAME_AXZ Abweichende Partei ohne Namen im AXZ-ProfilEin abweichender Auftraggeber oder Empfänger (UltmtDbtr, UltmtCdtr) braucht im Auslandszahlungsverkehr zwingend einen Namen; das DK-AXZ-Schema lässt dort keine Partei nur mit Kennung zu. In SEPA-Dateien reicht eine Kennung.
Lösung: Den Namen der abweichenden Partei eintragen oder die Partei entfernen.
PAY_ULTIMATE_NAME_LENGTH Name der abweichenden Partei zu langDer Name eines abweichenden Auftraggebers oder Empfängers ist auf 70 Zeichen (SEPA) bzw. 140 Zeichen (AXZ) begrenzt, gezählt nach der Zeichensatz-Konvertierung.
Lösung: Den Namen kürzen, etwa Rechtsform abkürzen oder Zusätze weglassen.
PAY_PARTY_ID_INVALID Kennung einer Partei ist formal ungültigKennungen (Dbtr/Id, Cdtr/Id, InitgPty/Id oder die Kennung einer abweichenden Partei) folgen der ISO-Struktur Party38Choice: eine Organisation trägt BIC, LEI oder eine sonstige Kennung, eine Privatperson Geburtsangaben oder eine sonstige Kennung. Der Befund nennt den konkreten Verstoß, etwa eine LEI ohne 20 Zeichen oder Geburtsangaben ohne Datum.
Lösung: Die Kennung so eintragen, wie die Meldung es beschreibt. Kennungen entstehen in finisma nur aus importierten Dateien; stimmt die Quelle nicht, dort korrigieren oder die Kennung in der Zeile entfernen.
PAY_INSTRUCTION_ID_LENGTH Auftragsreferenz zu langDie Auftragsreferenz (PmtId/InstrId) ist eine Referenz des Einreichers für die eigene Zuordnung, höchstens 35 Zeichen nach der Zeichensatz-Konvertierung. Anders als die End-to-End-Referenz hat sie keinen Standardwert.
Lösung: Die Referenz auf 35 Zeichen kürzen oder leer lassen.
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.