pain.002 – Schmerz für Unternehmen bei VOP?

Die ISO-20022 Nachrichtenformate pain stehen eigentlich für Payments Initiation, aber die pain.002 dient der Rückmeldung zu Zahlungsaufträgen. Mit Verification of Payee bekommt die pain.002 nochmals eine neue Bedeutung.

pain.002 Definition nach ISO 20022

Die Nachricht pain.002.001.xx trägt den offiziellen Namen “Customer Payment Status Report”. Sie informiert den Einreicher eines Zahlungsauftrags (i. d. R. ein Unternehmen) über den Status dieses Auftrags – etwa ob er angenommen, abgelehnt oder teilweise verarbeitet wurde. Dabei wird sowohl ein Gesamtstatus als auch ein Status pro Einzeltransaktion (z. B. bei Sammelüberweisungen) zurückgegeben.

Die pain.002 enthält:

• Referenzen zum ursprünglichen pain.001-Auftrag (z. B. Message ID, Payment Information ID)
• Statusangaben auf Auftrags- und Transaktionsebene
• Fehlercodes und optionale Fehlermeldungstexte (z. B. „ACCP“, „RJCT“, „PDNG“)

Unterschiedliche Nutzung der pain.002

Ein häufiger Stolperstein: Die Bedeutung und Nutzung von pain.002 ist nicht überall gleich. Insbesondere bei Firmenkunden führt das zu Unsicherheit: Was signalisiert mir eine „ACCP“-Antwort – ist der Auftrag gebucht oder nur angenommen? Antwort: Leider kommt es darauf an, wie die Bank das interpretiert.

Standard- vs. Echtzeitüberweisung: Unterschiede bei pain.002

Auch zwischen klassischen SEPA-Überweisungen und SCT Inst-Zahlungen gibt es Unterschiede: die meisten Banken geben bei einer Standardüberweisung keine positive Bestätigung, sondern melden nur eine Ablehnung als pain.002 zurück.

Mit der zunehmenden Bedeutung der Echtzeitzahlungen (SEPA Instant Payments) wollen Unternehmen oft auch unmittelbar eine Bestätigung der Überweisung, aber dies ist weder als pain.002 noch als vergleichbare Nachricht für Banken verpflichtend. Die Regulatorik zu den SEPA Instant Payments legt fest, dass der Betrag beim Empfänger umgehend verfügbar sein muss, aber der Zahlende hat keinen Anspruch auf eine aktive Benachrichtigung.

pain.002 im Kontext von Verification of Payee (VoP)

Ab Oktober 2025 ist Verification of Payee verpflichtend im Euro–Raum und die pain.002 wird hier ebenfalls genutzt:

• Viele VoP-Prozesse nutzen den Statusreport, um zurückgewiesene Zahlungen aufgrund fehlender Namensübereinstimmung (analog beim ID-Abgleich) zu signalisieren (close match, no match). Ein positiver Namensabgleich (match) führt zu einer positiven pain.002.
• Die Rückmeldung kann auf Einzelebene (pro Zahlung) erfolgen – dies führt bei Sammelüberweisungen zu komplexer Verarbeitung. Banken in Deutschland weisen den Sammler meist insgesamt zurück, wenn VoP-Ergebnisse einzelner Transaktionen negativ sind.
• Bei Einzeltransaktionen als CCU ist die pain.002-Analyse einfacher, aber auch hier muss die Weiterverarbeitung im ERP-System abgestimmt sein.

Für Unternehmen heißt das:

• pain.002 muss ausgewertet werden, wenn VoP aktiv ist
• der Umgang mit VoP muss für jede Bankverbindung geprüft und abgestimmt werden
• Fehler in einer Transaktion dürfen nicht die ganze Datei blockieren
• Die Umsetzung erfordert oft individuelle Schnittstellen oder Skripte

Fazit: pain.002 – Schmerz ist vermeidbar

Die pain.002 ist ein mächtiges, aber komplexes Werkzeug. In einer idealen Welt liefert sie verlässliche Rückmeldungen über alle Zahlungen – in der Realität hängt ihr Nutzen von vielen Faktoren ab:

• Bankenseitige Implementierung
• Kanal (EBICS, API, Webportal)
• Zahlungsart (SCT vs. SCT Inst)
• VoP-Nutzung und Verarbeitungstiefe im Unternehmen

Unternehmen, die sich auf VoP oder auf Echtzeitzahlungen einstellen, sollten die Verarbeitung der pain.002 frühzeitig einplanen, um keinen „Schmerz“ in der Buchhaltung zu erleben.

Sie haben Fragen zur Integration von pain.002 in Ihre ZV-Prozesse?
Unsere Experten bei CPG Finance Systems unterstützen Sie gerne bei Analyse, Mapping, Testing und Automatisierung Ihrer SEPA-Schnittstellen und freuen sich auf Ihre Kontaktaufnahme.