Strukturierte Verwendungszweck-Daten bei ISO 20022 enthalten maschinenlesbare, in definierte Felder aufgeteilte Zahlungsinformationen wie Rechnungsnummern, Referenzen und Beträge. Unstrukturierte Daten hingegen bestehen aus einem einzigen Freitextfeld, das zwar flexibel ist, aber die automatisierte Verarbeitung erheblich erschwert. Der entscheidende Unterschied liegt in der Verarbeitbarkeit: Strukturierte Daten ermöglichen vollautomatischen Abgleich, unstrukturierte erfordern manuelle Eingriffe. Die folgenden Abschnitte beleuchten die praktischen Konsequenzen dieser Unterscheidung für Ihren Zahlungsverkehr.
Welche Datenfelder enthält der strukturierte Verwendungszweck bei ISO 20022?
Der strukturierte Verwendungszweck bei ISO 20022 ist im Element StructuredRemittanceInformation abgebildet und enthält klar definierte Unterfelder: Referenznummern des Gläubigers und Schuldners, Dokumententypen wie Rechnungen oder Gutschriften, Fälligkeitsdaten, Beträge sowie Anpassungsdetails. Diese Felder folgen einem international standardisierten Schema, das eine maschinelle Weiterverarbeitung ohne menschliches Eingreifen ermöglicht.
Im Detail umfasst der strukturierte Block unter anderem folgende Elemente:
- ReferredDocumentInformation: Typ und Nummer des referenzierten Dokuments, etwa eine Rechnungsnummer
- ReferredDocumentAmount: Bruttobetrag, abgezogene Beträge und zu zahlender Nettobetrag
- CreditorReferenceInformation: Eindeutige Referenz des Zahlungsempfängers, zum Beispiel eine Kreditorenreferenz
- Invoicer und Invoicee: Identifikation von Rechnungssteller und Rechnungsempfänger
- AdditionalRemittanceInformation: Ergänzende Freitextinformationen innerhalb des strukturierten Rahmens
Diese Granularität ist der wesentliche Vorteil gegenüber dem Freitextfeld. Jede Information hat ihren fest definierten Platz, sodass empfangende Systeme genau wissen, wo sie welche Zahlungsdaten finden und wie sie diese interpretieren sollen.
Was sind unstrukturierte Verwendungszweck-Daten im Zahlungsverkehr?
Unstrukturierte Verwendungszweck-Daten sind Freitexteingaben im Feld UnstructuredRemittanceInformation des ISO-20022-Nachrichtenformats. Dieses Feld erlaubt bis zu 140 Zeichen Text ohne vorgegebenes Format, vergleichbar mit dem klassischen Verwendungszweckfeld im SEPA-Zahlungsverkehr. Der Inhalt ist für Menschen lesbar, aber für Systeme ohne zusätzliche Interpretationslogik kaum automatisiert auswertbar.
In der Praxis enthalten diese Felder häufig eine Mischung aus Rechnungsnummern, Kundennummern, Freitext und individuellen Abkürzungen, die jedes Unternehmen anders formatiert. Ein typischer Eintrag könnte lauten: „RE 2024-4711 / KD 98765 / Teilzahlung April“. Für das empfangende System ist nicht ohne Weiteres erkennbar, welcher Teil die Rechnungsnummer, welcher die Kundennummer und welcher ein freier Kommentar ist.
Unstrukturierte Verwendungszwecke sind historisch gewachsen und in vielen bestehenden Systemen tief verankert. Sie bieten Flexibilität, erkaufen diese jedoch mit erhöhtem manuellem Aufwand bei der Verarbeitung eingehender Zahlungen.
Wie verarbeiten Systeme strukturierte und unstrukturierte Verwendungszwecke unterschiedlich?
Systeme verarbeiten strukturierte Verwendungszwecke durch direktes Mapping: Jedes Datenfeld wird einer definierten Datenbankstelle zugeordnet, sodass der automatische Abgleich mit offenen Posten ohne menschliche Intervention erfolgt. Unstrukturierte Daten erfordern hingegen Parsing-Logik, Mustererkennung oder manuelle Prüfung, um dieselben Informationen zu extrahieren.
Automatischer Abgleich bei strukturierten Daten
Bei strukturierten Remittance-Informationen liest das ERP- oder Buchhaltungssystem die Rechnungsreferenz direkt aus dem vorgesehenen Feld. Der Abgleich mit der offenen Rechnung erfolgt in Echtzeit und ohne Fehlerrisiko durch Fehlinterpretation. Systeme wie SAP können diese Daten direkt in den automatischen Zahlungsausgleich übernehmen, was die Durchlaufzeiten erheblich verkürzt.
Regelbasiertes Parsing bei unstrukturierten Daten
Für unstrukturierte Felder müssen Unternehmen entweder manuelle Prozesse etablieren oder regelbasierte Parser entwickeln, die Muster wie „RE“ als Rechnungspräfix erkennen. Diese Regeln sind fragil: Ändert ein Geschäftspartner sein Verwendungszweckformat, schlägt die Automatisierung fehl. Der Wartungsaufwand für solche Regelwerke ist beträchtlich und wächst mit der Anzahl der Geschäftspartner.
Wann sollte man strukturierte statt unstrukturierter Verwendungszweck-Daten verwenden?
Strukturierte Verwendungszweck-Daten sollten immer dann eingesetzt werden, wenn Zahlungen automatisiert abgeglichen werden müssen, wenn mehrere Rechnungen mit einer Zahlung beglichen werden oder wenn hohe Transaktionsvolumina eine manuelle Nachbearbeitung unwirtschaftlich machen. Für einfache Einzelzahlungen mit eindeutiger Zuordnung können unstrukturierte Daten ausreichend sein.
Konkrete Szenarien, in denen strukturierte Daten klar vorzuziehen sind:
- Sammelzahlungen, die mehrere Rechnungen in einer einzigen Transaktion bündeln
- Konzerninterner Zahlungsverkehr mit hohem Volumen und standardisierten Prozessen
- Zahlungen an Lieferanten mit komplexen Skonto- oder Teilzahlungsvereinbarungen
- Cross-Border-Zahlungen, bei denen Sprachbarrieren die Interpretation von Freitext erschweren
- Branchen mit regulatorischen Anforderungen an die Nachvollziehbarkeit von Zahlungsströmen
Unstrukturierte Daten bleiben sinnvoll für individuelle Einmalzahlungen, bei denen der Kontext für beide Seiten eindeutig ist und kein automatisierter Abgleich erforderlich ist. Für professionelle Zahlungsverkehrsprozesse ist jedoch die strukturierte Variante die zukunftssicherere Wahl.
Welche Fehler entstehen durch unstrukturierte Verwendungszweck-Daten in der Praxis?
Unstrukturierte Verwendungszweck-Daten verursachen in der Praxis vor allem Fehler beim automatischen Zahlungsabgleich, erhöhten manuellen Aufwand in der Debitorenbuchhaltung, verzögerte Rechnungsklärungen und im schlimmsten Fall Doppelzahlungen oder falsch gebuchte Eingänge. Diese Fehler entstehen nicht durch Nachlässigkeit, sondern durch die strukturelle Schwäche des Freitextformats.
Typische Fehlerbilder in der Praxis umfassen:
- Fehlgeschlagener automatischer Abgleich: Die Rechnungsnummer im Freitext weicht von der im System hinterlegten Schreibweise ab, etwa durch Leerzeichen, Bindestriche oder abweichende Präfixe.
- Unvollständige Informationen: Das 140-Zeichen-Limit reicht nicht aus, um alle relevanten Referenzen bei Sammelüberweisungen unterzubringen.
- Mehrdeutige Zuordnung: Ohne klare Feldstruktur ist nicht erkennbar, ob eine Zahl eine Rechnungs-, Kunden- oder Bestellnummer darstellt.
- Systembrüche bei Weiterleitungen: Wenn Zahlungen über mehrere Banken weitergeleitet werden, kann Freitext abgeschnitten oder verändert werden.
Die Folgekosten dieser Fehler sind erheblich: Manuelle Klärungsprozesse binden Ressourcen, verzögern den Liquiditätsabgleich und erhöhen das Risiko von Mahnungen trotz erfolgter Zahlung.
Wie beeinflusst die ISO-20022-Migration die Anforderungen an Verwendungszweck-Daten?
Die ISO-20022-Migration erhöht die Anforderungen an Verwendungszweck-Daten erheblich, da das neue Format weit mehr strukturierte Informationen transportieren kann als ältere Formate wie MT103 oder SEPA-XML nach dem bisherigen Standard. Banken und Zahlungsdienstleister erwarten zunehmend, dass Unternehmen diese Kapazitäten auch tatsächlich nutzen, um Straight-Through-Processing-Raten zu verbessern.
Mit der vollständigen Umstellung auf ISO 20022 im SWIFT-Netzwerk und den fortlaufenden Anpassungen im SEPA-Raum verschieben sich die Erwartungen in der Branche: Was bislang als optionale Verbesserung galt, wird zunehmend zur Voraussetzung für effiziente Zahlungsabwicklung. Unternehmen, die weiterhin ausschließlich auf unstrukturierte Felder setzen, riskieren, dass ihre Zahlungen in Systemen von Geschäftspartnern und Banken nicht optimal verarbeitet werden.
Gleichzeitig bietet die Migration eine Chance: Wer seine Zahlungsprozesse jetzt auf strukturierte Remittance Information umstellt, schafft die Grundlage für vollautomatisierte Verarbeitungsketten. Die erweiterten Felder von ISO 20022 erlauben zudem die Übertragung von Steuerinformationen, Lieferreferenzen und weiteren Metadaten, die bislang in separaten Prozessen kommuniziert werden mussten. Die Migration ist damit nicht nur eine technische Pflichtübung, sondern ein strategischer Hebel zur Prozessoptimierung im gesamten elektronischen Zahlungsverkehr.
Wie PAYMENTS.CC Sie bei der Optimierung Ihrer Verwendungszweck-Daten unterstützt
Die Umstellung auf strukturierte Verwendungszweck-Daten im Rahmen der ISO-20022-Migration ist ein technisch und prozessual anspruchsvolles Vorhaben. Wir bei PAYMENTS.CC begleiten Sie dabei mit langjähriger Erfahrung aus mehr als 30 nationalen und internationalen Implementierungsprojekten. Unser Fokus liegt darauf, Ihre Zahlungsprozesse revisionssicher, effizient und zukunftsfähig zu gestalten.
Konkret unterstützen wir Sie bei:
- Analyse Ihrer bestehenden Verwendungszweck-Formate und Identifikation von Optimierungspotenzialen im aktuellen Zahlungsverkehr
- Implementierung strukturierter Remittance Information in Ihren SAP-Systemen, einschließlich SAP Advanced Payment Management und SAP Bank Communication Management
- Mapping und Migration bestehender Freitextformate auf ISO-20022-konforme Strukturen
- Schulung und Coaching Ihrer Teams für den sicheren Umgang mit den neuen Datenformaten
- Anbindung an Banken und Zahlungsdienstleister über EBICS, SWIFT und H2H mit korrekter Übertragung strukturierter Zahlungsdaten
Gerne zeigen wir Ihnen in einem ersten Gespräch, wie Sie durch den Wechsel auf strukturierte Verwendungszweck-Daten Ihre Straight-Through-Processing-Rate steigern und manuelle Nachbearbeitungen deutlich reduzieren können. Nehmen Sie jetzt Kontakt auf und erfahren Sie, wie wir Ihre ISO-20022-Migration schnell, kompetent und lösungsorientiert begleiten.
Ähnliche Artikel
- Was ist ISO 20022 und warum betrifft es SAP-Zahlungsprozesse?
- Was ist der Unterschied zwischen EBICS, SWIFT und Host-to-Host im Überblick?
- Was ist ein SWIFT Service Bureau und wann braucht man es?
- Was ist der Unterschied zwischen MX- und MT-Nachrichten bei SWIFT?
- Was ist SAP Multi-Bank Connectivity und wie funktioniert es?
Dieser Inhalt wurde mithilfe von KI erstellt und kann Fehler enthalten.