Ihr Daten-Template für die Zahlungsabwicklung

ACI Worldwide
Ihr Daten-Template für die Zahlungsabwicklung

Ihr Daten-Template für die Zahlungsabwicklung

Dieses Template bietet eine strukturierte Anleitung, um Ihre Daten zur Zahlungsabwicklung für die Analyse aufzubereiten. Es beschreibt die erforderlichen Attribute, die wichtigen Aktivitäten, die Sie erfassen sollten, und gibt praktische Hinweise zum Datenexport aus Ihrem System. So schaffen Sie eine verlässliche Grundlage, um Ineffizienzen zu erkennen und Ihre Finanzprozesse zu verbessern.
  • Empfohlene Attribute für die Datenerfassung
  • Wichtige Aktivitäten für die Erfassung
  • Hinweise zum Datenexport aus ACI Worldwide
Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Attribute der Zahlungsabwicklung

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um die Zahlungsabwicklung umfassend zu analysieren.
3 Erforderlich 9 Empfohlen 7 Optional
Name Beschreibung
Aktivitätsname
ActivityName
Der konkrete Schritt oder die Statusänderung im Lebenszyklus der Zahlung.
Beschreibung

Dieses Attribut legt den Ereignisknoten in der Prozessübersicht fest, zum Beispiel „Zahlungsanfrage erstellt“ oder „Betrag überwiesen“. In ACI-Systemen wird es häufig aus Statuscodes, Vorgangstypen im Audit-Protokoll oder Änderungen des Workflow-Status abgeleitet. Damit die Visualisierung aussagekräftig ist, müssen diese technischen Zustände korrekt verständlichen Geschäftsaktivitäten zugeordnet werden.

Warum das wichtig ist

Das Attribut definiert den Prozessablauf und ist erforderlich, um die Reihenfolge der Vorgänge darzustellen.

Woher beziehen

Abgeleitet aus Statuscodes (z. B. 100=Erstellt, 200=Validiert) oder aus Aktionsspalten im Audit-Protokoll.

Beispiele
Zahlungsanforderung erstelltZahlung autorisiertZahlung abgewickeltZahlung fehlgeschlagen
Ereignis-Timestamp
EventTimestamp
Das genaue Datum und die Uhrzeit, zu der die Aktivität stattgefunden hat.
Beschreibung

Dieses Attribut erfasst den genauen Zeitpunkt eines Ereignisses in der ACI-Umgebung. Es dient zur Berechnung aller zeitbezogenen Kennzahlen, darunter Zykluszeiten, Genehmigungsdauer und Durchsatzraten. Für eine präzise Reihenfolge schnell aufeinanderfolgender automatisierter Schritte empfiehlt sich eine hohe Genauigkeit im Millisekundenbereich.

Warum das wichtig ist

Unverzichtbar, um Ereignisse zu ordnen und Leistungszeiträume zu berechnen.

Woher beziehen

Prüfen Sie die Spalten „Erstellungsdatum“ oder „Änderungsdatum“ im Transaktionsverlauf oder in den Audit-Tabellen.

Beispiele
2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z
Payment Transaction ID
PaymentTransactionId
Der eindeutige Bezeichner für den jeweiligen Zahlungsauftrag im gesamten ACI-System.
Beschreibung

Dieses Attribut dient als zentraler Schlüssel für die Process-Mining-Analyse und verknüpft alle Ereignisse zu einer einzelnen Zahlungsanfrage. In ACI Worldwide-Systemen wie MTS oder UPP entspricht es der eindeutigen Referenznummer, die einer Transaktion bei der Erfassung zugewiesen wird. Damit lässt sich der gesamte Zahlungsablauf rekonstruieren, von der ursprünglichen Anfrage über Validierung und Genehmigung bis zur abschließenden Abrechnung.

Warum das wichtig ist

Dies ist die grundlegende Case-ID, mit der einzelne Ereignisse zu Prozessinstanzen gruppiert werden.

Woher beziehen

Prüfen Sie die Transaktionskopftabellen. Die Felder heißen im Haupttransaktionsprotokoll häufig TRN_REF, REFERENCE_NUM oder UUID.

Beispiele
TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981
Abteilung
Department
Die interne Abteilung, die für die aktuelle Aktivität verantwortlich ist.
Beschreibung

Ordnet den EventUser oder die Warteschlange einer übergeordneten Organisationseinheit zu, zum Beispiel „Zahlungsabwicklung“, „Compliance“ oder „Treasury“. So zeigt die Engpassanalyse nach Aktivität, welche Teams den Prozess verzögern.

Warum das wichtig ist

Fasst die Leistung nach Geschäftsbereich zusammen.

Woher beziehen

Abgeleitet aus Benutzertabellen oder einer Zuordnung zur Organisationshierarchie.

Beispiele
BetriebComplianceTreasuryIT-Support
Ereignisbenutzer
EventUser
Die Benutzer-ID oder der Systemagent, der für die Aktivität verantwortlich ist.
Beschreibung

Erfasst, wer die Aktion ausgeführt hat, ob ein Benutzer, etwa bei einer Genehmigung, oder ein Systemkonto, etwa bei einer automatisierten Abrechnung. Dieses Attribut ist für die Engpassanalyse wichtig, um überlastete Benutzer oder Warteschlangen zu erkennen.

Warum das wichtig ist

Ermöglicht die Ressourcenanalyse und die Prüfung der Funktionstrennung.

Woher beziehen

Audit-Protokolle oder Spalten wie „UpdatedBy“ in Transaktionstabellen.

Beispiele
SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS
Fälligkeitstermin der Zahlung
PaymentDueDate
Das Datum, bis zu dem die Zahlung abgerechnet sein muss, damit sie als fristgerecht gilt.
Beschreibung

Speichert das vertraglich vereinbarte oder angeforderte Ausführungsdatum. Durch den Vergleich mit dem tatsächlichen Abrechnungsdatum lässt sich die KPI „Anteil fristgerechter Zahlungen“ berechnen und das Dashboard „Einhaltung des Fälligkeitstermins“ unterstützen.

Warum das wichtig ist

Der Maßstab für die Messung der SLA-Einhaltung und der fristgerechten Ausführung.

Woher beziehen

Zahlungsaufträge, üblicherweise mit VALUE_DATE, EXECUTION_DATE oder DUE_DATE.

Beispiele
2023-11-012023-11-05
Fehlercode
ErrorCode
Der Code, der bei einer fehlgeschlagenen oder zu korrigierenden Zahlung erzeugt wird.
Beschreibung

Erfasst den konkreten Grund für ein Ereignis wie „Zahlung fehlgeschlagen“ oder „Zahlungsfehler erkannt“. Durch die Gruppierung nach diesem Attribut im Dashboard „Analyse von Zahlungsfehlern und Nacharbeit“ lassen sich die häufigsten Fehlerursachen ermitteln, etwa „Unzureichende Deckung“ oder „Ungültiges Konto“.

Warum das wichtig ist

Unverzichtbar für die Ursachenanalyse bei Prozessfehlern.

Woher beziehen

Fehlerprotokolle oder Spalten mit Statusgründen, häufig REASON_CODE oder RETURN_CODE.

Beispiele
R01AM04BE05TECH_ERR_001
Nacharbeit erfolgt
IsRework
Kennzeichen dafür, ob bei der Zahlung Aktivitäten wiederholt wurden.
Beschreibung

Ein boolesches Kennzeichen, das bei der Datenverarbeitung berechnet wird. Es wird auf „true“ gesetzt, wenn Aktivitäten wie „Zahlungsdetails validiert“ mehr als einmal auftreten oder eine Fehlerschleife erkannt wird. Dieser Wert fließt in die KPI „Nacharbeitsquote bei Zahlungen“ ein.

Warum das wichtig ist

Erkennt ineffiziente Fälle schnell, ohne komplexe Prozessabfragen.

Woher beziehen

Wird in der Datenpipeline berechnet, indem doppelte Aktivitäten pro Case ermittelt werden.

Beispiele
truefalse
Verarbeitungskanal
ProcessingChannel
Der Kanal, über den die Zahlung eingeleitet wurde.
Beschreibung

Gibt den Eingangskanal der Zahlung an, zum Beispiel Mobile App, Webportal, API oder Datei-Upload. Mit der Variantenanalyse des Zahlungsprozesses lässt sich feststellen, ob bestimmte Kanäle häufiger zu Fehlern oder Verzögerungen führen.

Warum das wichtig ist

Vergleicht die Leistung nach Eingabemethode.

Woher beziehen

Transaktionskopf, häufig mit Spalten wie CHANNEL, SOURCE_TYPE oder INPUT_METHOD.

Beispiele
SWIFTOnlinebankingMobile AppDatei-Upload
Zahlungsart
PaymentType
Die Klassifizierung des Zahlungsinstruments.
Beschreibung

Kategorisiert die Zahlung, zum Beispiel als Wire, ACH, SEPA oder RTGS. Die Service-Level-Agreements und Prozessabläufe unterscheiden sich je nach Zahlungsart oft erheblich. Dieses Attribut ist eine zentrale Dimension für Filter im Dashboard „End-to-End-Zykluszeit von Zahlungen“.

Warum das wichtig ist

Wichtig, um schnelle Zahlungsabläufe von Sammelverarbeitungen zu unterscheiden.

Woher beziehen

Transaktionskopf, mit Feldern wie PMT_TYPE, INSTRUMENT_TYPE oder SERVICE_ID.

Beispiele
InlandsüberweisungInternationale ÜberweisungACH-GutschriftEchtzeitzahlung
Zahlungsbetrag
PaymentAmount
Der Geldwert der Zahlungstransaktion.
Beschreibung

Gibt den überwiesenen Geldbetrag an. Dieses Kontextattribut ist wichtig, um den „Zahlungsdurchsatz“ zu analysieren und Engpässe zu priorisieren. Bei Zahlungen mit hohem Wert sind häufig strengere Genehmigungsabläufe erforderlich als bei automatisierten Abläufen für kleinere Beträge. Das lässt sich durch eine Variantenanalyse untersuchen.

Warum das wichtig ist

Ermöglicht die Segmentierung nach Betrag und die Berechnung des insgesamt verarbeiteten Volumens.

Woher beziehen

Transaktionsdetailtabellen, üblicherweise mit Feldern wie AMT, TRANS_AMOUNT oder PRINCIPAL_AMOUNT.

Beispiele
1500.00250000.5050.001000000.00
Zahlungswährung
PaymentCurrency
Der ISO-Währungscode des Zahlungsbetrags.
Beschreibung

Gibt an, in welcher Währung der PaymentAmount ausgewiesen ist, zum Beispiel USD, EUR oder GBP. Das ist erforderlich, um Daten in Dashboards zu vereinheitlichen, die Volumen aus verschiedenen Regionen zusammenfassen. Außerdem hilft das Attribut, die Besonderheiten grenzüberschreitender Zahlungen zu verstehen.

Warum das wichtig ist

Erforderlich, um den Zahlungsbetrag korrekt zu interpretieren.

Woher beziehen

Transaktionsdetailtabellen, üblicherweise mit Feldern wie CCY, CURRENCY_CODE oder ISO_CODE.

Beispiele
USDEURGBPJPY
Abgleich-ID
ReconciliationId
Bezeichner, der die Zahlung mit dem Hauptbuch oder dem Abstimmungsdatensatz verknüpft.
Beschreibung

Diese ID wird eingetragen, wenn die Aktivität „Zahlung abgeglichen“ stattfindet. Sie stellt sicher, dass die Zahlung in der Verarbeitungs-Engine mit dem Eintrag im Buchhaltungssystem übereinstimmt. Fehlt die ID bei abgerechneten Zahlungen, deutet das auf Fehler beim Abgleich hin.

Warum das wichtig ist

Wichtig für das Dashboard „Effizienz des Zahlungsabgleichs“.

Woher beziehen

Abgleichstabellen oder bestimmte Felder wie RECON_REF oder GL_REF.

Beispiele
REC-9921GL-Entry-2023-11
Genehmigungszykluszeit
ApprovalCycleTime
Dauer der Genehmigungsphase.
Beschreibung

Berechnet die Zeit zwischen „Zahlung zur Genehmigung gesendet“ und „Zahlung genehmigt“ (oder abgelehnt). Diese Kennzahl fließt in das Dashboard „Analyse der Genehmigungszykluszeit von Zahlungen“ ein und macht Verzögerungen bei menschlichen Entscheidungen sichtbar.

Warum das wichtig ist

Grenzt den Teil des Prozesses ab, der von menschlichen Entscheidungen abhängt.

Woher beziehen

Berechnet als: Timestamp(Zahlung genehmigt) - Timestamp(Zahlung zur Genehmigung gesendet).

Beispiele
4 Stunden15 Minuten
Herkunftsregion
OriginatingRegion
Die geografische Region, aus der die Zahlungsanfrage stammt.
Beschreibung

Gibt den physischen oder logischen Standort des Anfragenden an. Mit der Variantenanalyse des Zahlungsprozesses lässt sich feststellen, ob bestimmte Regionen von den Standardabläufen abweichen oder häufiger Ablehnungen verzeichnen.

Warum das wichtig ist

Liefert den geografischen Kontext für die Prozessleistung.

Woher beziehen

Transaktionskopf, häufig abgeleitet aus Branch Code oder Country Code.

Beispiele
NordamerikaEMEAAPAC
Letzte Datenaktualisierung
LastDataUpdate
Der Timestamp der letzten Extraktion oder Aktualisierung des Datensatzes im Datenmodell.
Beschreibung

Zeigt, wie aktuell die für die Analyse verwendeten Daten sind. Dieser Wert bezeichnet nicht den Zeitpunkt eines Prozessereignisses, sondern den technischen Zeitpunkt der Datenübernahme. So erkennen Analysten, ob sie Echtzeitdaten oder historische Datenstände betrachten.

Warum das wichtig ist

Zeigt, ob die Daten aktuell sind, und hilft dabei, veraltete Daten in Dashboards zu erkennen.

Woher beziehen

Systemzeit zum Zeitpunkt der Ausführung des ETL-Skripts.

Beispiele
2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z
Name des Zahlungsempfängers
BeneficiaryName
Der Name der Einheit, die die Zahlung erhält.
Beschreibung

Identifiziert den Geschäftspartner der Transaktion. Die Analyse dieses Feldes kann bestimmte Lieferanten oder Kunden aufzeigen, bei denen häufig Nacharbeit oder Verzögerungen auftreten. Das unterstützt die „Analyse von Zahlungsfehlern und Nacharbeit“.

Warum das wichtig ist

Gibt den Zahlungsempfänger an und eignet sich für kundenbezogene Analysen.

Woher beziehen

Zahlungsdetailzeilen, mit Feldern wie CREDITOR_NAME, BENE_NAME oder PAYEE.

Beispiele
Acme CorpGlobal Supplies LtdJohn Smith
Quellsystem
SourceSystem
Der Name des Systems, aus dem die Ereignisdaten stammen.
Beschreibung

Gibt die konkrete Anwendung oder das Modul im ACI Worldwide-Ökosystem an, etwa ACI MTS oder ACI UPF, oder ein externes System, das am Ablauf beteiligt ist. Das ist besonders wichtig, wenn Daten aus mehreren Hauptbüchern zusammengeführt werden oder die Zahlung über externe Clearingstellen läuft.

Warum das wichtig ist

Zeigt, aus welchem System die Daten extrahiert wurden, und erleichtert so die Fehlersuche in der Datenherkunft.

Woher beziehen

Bei der Extraktion fest vorgegeben oder aus einer SystemID-Spalte abgeleitet, wenn mehrere Instanzen vorhanden sind.

Beispiele
ACI MTSACI UPPSAP GLSwift Gateway
Zahlung verspätet
IsPaymentLate
Kennzeichen dafür, ob die Zahlung nach dem Fälligkeitstermin abgerechnet wurde.
Beschreibung

Ein boolesches Kennzeichen, das das tatsächliche Abrechnungsdatum mit PaymentDueDate vergleicht. Es dient zur Berechnung von Kennzahlen im Dashboard „Einhaltung des Fälligkeitstermins“ und zur Erkennung von SLA-Verstößen.

Warum das wichtig ist

Vereinfacht die Compliance-Berichterstattung.

Woher beziehen

Berechnet als: SettlementDate > PaymentDueDate.

Beispiele
truefalse
Erforderlich Empfohlen Optional

Aktivitäten der Zahlungsabwicklung

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, damit Sie den Ablauf der Zahlungsabwicklung präzise nachvollziehen können.
6 Empfohlen 8 Optional
Aktivität Beschreibung
Gelder überwiesen
Zeigt an, dass das Zahlungsnetzwerk bestätigt hat, dass die Gelder erfolgreich vom Konto des Zahlers abgebucht wurden. Dies wird üblicherweise anhand einer eingehenden Statusnachricht des Netzwerks erfasst.
Warum das wichtig ist

Bestätigt die erfolgreiche Ausführung der Zahlung durch das externe Netzwerk. Damit beginnt die Abwicklungsdauer. Das Ereignis ist eine wichtige Grundlage für den KPI „Average Payment Settlement Time“.

Woher beziehen

Dieses explizite Ereignis wird durch eine eingehende Statusnachricht ausgelöst, beispielsweise eine MT103-Nachricht von SWIFT oder eine ACH-Bestätigung, die den Zahlungseintrag aktualisiert.

Erfassung

Wird beim Eingang einer externen Bestätigungsnachricht des Clearing-Netzwerks erfasst.

Ereignistyp explicit
Zahlung abgewickelt
Die abschließende Bestätigung, dass der Zahlungsvorgang beendet und das Geld dem Zahlungsempfänger gutgeschrieben wurde. Damit ist die Transaktion abgeschlossen. Dieses wichtige Ereignis kennzeichnet den erfolgreichen Abschluss des Zahlungslebenszyklus.
Warum das wichtig ist

Dies ist das primäre End-Event für einen erfolgreichen Prozessabschluss. Es dient zur Berechnung der gesamten Zykluszeit und des Durchsatzes und ist für fast alle Dashboards zur durchgängigen Prozessleistung wichtig.

Woher beziehen

Wird üblicherweise als explizites Ereignis erfasst, wenn eine abschließende Abwicklungsbestätigung des Netzwerks eingeht oder das interne Hauptbuch aktualisiert wird, um den Abschluss der Transaktion festzuhalten.

Erfassung

Wird erfasst, sobald eine abschließende Abrechnungsdatei oder -nachricht eingeht, und setzt den Status auf „Abgerechnet“.

Ereignistyp explicit
Zahlung autorisiert
Bezeichnet die Autorisierung der Zahlung auf Systemebene nach der Freigabe durch einen Menschen. Dabei werden die verfügbaren Mittel geprüft oder Betrugsregeln angewendet. Dies kann als expliziter Protokolleintrag erfasst oder aus einer Statusänderung abgeleitet werden, die die Ausführungsbereitschaft anzeigt.
Warum das wichtig ist

Dies ist ein wichtiger Kontrollpunkt, bevor die Überweisung der Gelder veranlasst wird. Verzögerungen in dieser Phase können auf Leistungsprobleme des Systems oder Schwierigkeiten mit Compliance- und Betrugsprüfungen hinweisen.

Woher beziehen

Suchen Sie nach einem expliziten Eintrag in einem Systemverarbeitungs- oder Sicherheitsprotokoll. Alternativ lässt sich der Vorgang aus einer Statusänderung von „Approved“ zu „Authorized for Payment“ ableiten.

Erfassung

Wird von der Zahlungs-Engine des Systems erfasst, nachdem die abschließenden internen Prüfungen bestanden wurden.

Ereignistyp explicit
Zahlung freigegeben
Ein wichtiger Meilenstein: Ein autorisierter Benutzer gibt die Zahlung frei, sodass sie ausgeführt werden kann. Üblicherweise wird dies als explizites Ereignis erfasst, wenn die freigebende Person die entsprechende Aktion in der Benutzeroberfläche des Systems ausführt.
Warum das wichtig ist

Diese Aktivität ist ein wichtiger Kontrollpunkt und häufig ein erheblicher Engpass. Die Analyse der Wartezeiten vor diesem Schritt und der Dauer des Freigabezyklus zeigt, wo sich Zahlungen beschleunigen lassen.

Woher beziehen

Suchen Sie nach einem expliziten Ereignis in einer Freigabeprotokolltabelle oder nach einer Statusänderung zu „Approved“ in der zentralen Transaktionstabelle, die einer bestimmten Benutzeraktion und einem Timestamp zugeordnet ist.

Erfassung

Wird erfasst, wenn ein autorisierter Benutzer die Freigabe im System abschließt.

Ereignistyp explicit
Zahlungsanforderung erstellt
Diese Aktivität kennzeichnet den Beginn einer neuen Zahlungstransaktion im System von ACI Worldwide. Üblicherweise wird sie als explizites Ereignis erfasst, wenn ein Benutzer oder ein vorgelagertes System eine Zahlungsanforderung übermittelt und dadurch einen neuen Transaktionsdatensatz mit einer eindeutigen ID anlegt.
Warum das wichtig ist

Dies ist das primäre Start-Event des Zahlungsprozesses. Die Zeitspanne von dieser Aktivität bis zum Abschluss ergibt die durchgängige Zykluszeit und ist entscheidend für die Messung der Gesamteffizienz des Prozesses.

Woher beziehen

Dieses Ereignis ist wahrscheinlich explizit in der zentralen Transaktionstabelle oder in einem eigenen Event Log von ACI erfasst. Suchen Sie nach einem Erstellungs-Timestamp zur Payment Transaction ID.

Erfassung

Erkennbar am Erstellungsdatensatz oder an einem expliziten „Create“-Ereignis im Transaktionsprotokoll.

Ereignistyp explicit
Zahlungsfehler erkannt
Zeigt an, dass das System zu einem bestimmten Zeitpunkt ein Problem mit der Zahlung erkannt hat, etwa ungültige Daten oder einen Compliance-Hinweis. Dieses Ereignis wird in der Regel ausdrücklich mit einem zugehörigen Fehlercode protokolliert.
Warum das wichtig ist

Diese Aktivität ist der Ausgangspunkt für alle Analysen zu Nacharbeit und Ausnahmebehandlung. Sie ist für die Dashboards „Analyse von Zahlungsfehlern und Nacharbeit“ sowie „Zykluszeit der Fehlerbehebung“ unverzichtbar.

Woher beziehen

Suchen Sie nach ausdrücklichen Einträgen in einer Fehlerprotokolltabelle oder nach einer Statusänderung zu „Fehler“ oder „Korrektur erforderlich“ in der Transaktionstabelle. Verknüpfen Sie diese Ereignisse mit der Payment Transaction ID.

Erfassung

Ein ausdrückliches Ereignis wird protokolliert, wenn die Validierungs- oder Verarbeitungs-Engine des Systems einen Fehler meldet.

Ereignistyp explicit
Zahlung abgeglichen
Bezeichnet den abschließenden Buchhaltungsschritt, bei dem die in ACI erfasste Zahlungstransaktion mit Kontoauszügen oder Hauptbucheinträgen abgeglichen wird. Dies kann als ausdrückliches Ereignis aus einem Abstimmungsmodul vorliegen oder aus einer Statusänderung abgeleitet werden.
Warum das wichtig ist

Diese Aktivität misst die Effizienz des Abstimmungsprozesses im Backoffice. Verzögerungen können die Genauigkeit der Finanzberichterstattung beeinträchtigen und dazu führen, dass nicht abgerechnete Zahlungen unentdeckt bleiben.

Woher beziehen

Diese Informationen können aus einem eigenen Abstimmungsmodul in ACI oder einem externen ERP-System stammen. Erfasst werden sie beispielsweise durch eine Statusänderung des Zahlungsdatensatzes zu „Abgeglichen“.

Erfassung

Abgeleitet aus einer abschließenden Statusänderung zu „Abgeglichen“ oder aus Abstimmungsdaten, die über die Payment ID verknüpft werden.

Ereignistyp inferred
Zahlung abgelehnt
Dieses Ereignis tritt ein, wenn eine freigebende Person die Zahlungsanforderung ablehnt. Häufig muss sie daraufhin korrigiert und erneut eingereicht werden. Das explizite Ereignis unterbricht den weiteren Ablauf der Zahlung und löst eine Nacharbeitsschleife aus.
Warum das wichtig ist

Diese Aktivität macht Nacharbeit und Ineffizienzen im Prozess sichtbar. Wenn Sie die Häufigkeit von Ablehnungen verfolgen, können Sie Probleme mit der anfänglichen Datenqualität oder den Einreichungsrichtlinien erkennen und die Nacharbeit analysieren.

Woher beziehen

Wird als explizites Ereignis im Freigabeprotokoll oder als Statusänderung zu „Rejected“ in der Transaktionstabelle erfasst. Das Ereignis kann einen Ablehnungsgrund enthalten.

Erfassung

Wird erfasst, wenn eine freigebende Person die Ablehnung im System abschließt.

Ereignistyp explicit
Zahlung bestätigt
Bezeichnet die interne Bestätigung, dass die Zahlung erfolgreich verarbeitet und eine Bestätigung empfangen wurde. Sie dient häufig als Auslöser für eine Benachrichtigung des Zahlungsempfängers oder anderer interner Systeme.
Warum das wichtig ist

Dieser Meilenstein ist entscheidend, um die Einhaltung von Fälligkeitsterminen und die Quote pünktlicher Zahlungen zu messen. Er liefert einen eindeutigen Timestamp dafür, wann das Unternehmen die Zahlung als erfolgreich ausgeführt betrachtet.

Woher beziehen

Wird üblicherweise aus einer Statusänderung der Zahlungstransaktion zu „Confirmed“ oder „Completed“ abgeleitet, nachdem die Bestätigung des externen Netzwerks eingegangen ist.

Erfassung

Lässt sich aus einer Statusänderung zu „Confirmed“ oder „Processed“ ableiten.

Ereignistyp inferred
Zahlung fehlgeschlagen
Ein Endstatus, der anzeigt, dass die Zahlung aufgrund eines nicht behebbaren Problems nicht abgeschlossen werden konnte. Er unterscheidet sich von einem behebbaren Fehler und kennzeichnet das endgültige Scheitern des Vorgangs.
Warum das wichtig ist

Dieses Endereignis muss erfasst werden, um die Gesamtfehlerquote bei Zahlungen zu berechnen. Eine Analyse der Fehlerursachen kann dazu beitragen, die Datenqualität und die Prozessregeln zu verbessern.

Woher beziehen

Abgeleitet aus einem endgültigen Status wie „Fehlgeschlagen“, „Storniert“ oder „Von der Bank abgelehnt“ in den Transaktionsdaten, der sich anschließend nicht mehr ändert.

Erfassung

Abgeleitet aus einem endgültigen Fehlerstatus im Zahlungsdatensatz.

Ereignistyp inferred
Zahlung zur Freigabe eingereicht
Zeigt an, dass die Zahlung die erste Validierung bestanden hat und zur erforderlichen Freigabe durch das Management oder die Finanzabteilung weitergeleitet wurde. Dies wird üblicherweise durch eine Statusänderung im Zahlungs-Workflow erfasst.
Warum das wichtig ist

Damit beginnt der Freigabe-Teilprozess. Die Zeitspanne von diesem Zeitpunkt bis „Payment Approved“ ist eine wichtige Kennzahl für das Dashboard „Payment Approval Cycle Time Analysis“.

Woher beziehen

Lässt sich aus einer Änderung des Zahlungsstatus in den Transaktionsdaten ableiten, beispielsweise aus dem Wechsel zu „Pending Approval“.

Erfassung

Lässt sich an einer Statusänderung zu „Pending Approval“ oder einem ähnlichen Status sowie dem zugehörigen Timestamp erkennen.

Ereignistyp inferred
Zahlungsanweisung gesendet
Kennzeichnet den Zeitpunkt, an dem die Zahlungsanweisung erstellt und an ein externes Zahlungsnetzwerk wie SWIFT, ACH oder SEPA übermittelt wird. ACI-Systeme protokollieren diese Übergabe ausdrücklich zu Prüf- und Nachverfolgungszwecken.
Warum das wichtig ist

Bei vielen Zahlungsarten ist dies der letzte Punkt, an dem sich der Ablauf noch beeinflussen lässt. Die Nachverfolgung zeigt, wie lange die interne Verarbeitung dauert, bevor externe Abhängigkeiten den weiteren Ablauf bestimmen.

Woher beziehen

Dies ist fast immer ein explizites Ereignis in den Transaktions- oder Nachrichtenprotokollen von ACI und enthält häufig eine netzwerkspezifische Referenznummer.

Erfassung

Wenn die Zahlungsnachricht an das externe Netzwerk gesendet wird, wird ein expliziter Protokolleintrag erstellt.

Ereignistyp explicit
Zahlungsdetails validiert
Diese Aktivität steht für den Abschluss automatisierter oder manueller Prüfungen, mit denen sichergestellt wird, dass Zahlungsdetails wie Angaben zum Zahlungsempfänger und Bankleitzahlen korrekt sind. Sie lässt sich häufig aus einer Statusänderung der Transaktion von „New“ zu „Validated“ oder „Pending Approval“ ableiten.
Warum das wichtig ist

Diese Aktivität zeigt, wie effizient die ersten Schritte der Datenvalidierung ablaufen. Verzögerungen an dieser Stelle können vorgelagerte Engpässe verursachen und das Risiko späterer Zahlungsfehler erhöhen.

Woher beziehen

Lässt sich aus Statusänderungsfeldern in der zentralen Zahlungstransaktionstabelle ableiten. Vergleichen Sie die Timestamps des Status „Created“ mit einem späteren Status wie „Validated“.

Erfassung

Lässt sich aus einer Änderung des Zahlungsstatus ableiten, beispielsweise von „Entered“ zu „Validated“.

Ereignistyp inferred
Zahlungsfehler behoben
Kennzeichnet den Zeitpunkt, zu dem ein Benutzer einen zuvor erkannten Fehler korrigiert und die Zahlung erneut zur Verarbeitung eingereicht hat. Häufig lässt sich dies an einer Statusänderung von einem Fehlerstatus zurück zu einem regulären Verarbeitungsstatus erkennen.
Warum das wichtig ist

Mit dieser Aktivität wird die Ausnahmebehandlung abgeschlossen. Die Zeit zwischen „Zahlungsfehler erkannt“ und diesem Ereignis ist die Zykluszeit der Fehlerbehebung und ein wichtiger Maßstab für die operative Effizienz.

Woher beziehen

Abgeleitet aus einer Statusänderung von „Fehler“ zu einem Verarbeitungsstatus wie „Genehmigung ausstehend“ oder „Validiert“. Alternativ kann ein ausdrückliches Aktionsprotokoll des Benutzers vorliegen.

Erfassung

Abgeleitet aus einer Statusänderung weg von einem Fehlerstatus, die auf eine erfolgte Korrektur hinweist.

Ereignistyp inferred
Empfohlen Optional

Anleitungen zum Datenexport

So exportieren Sie Ihre Daten aus ACI Worldwide

Möchten Sie loslegen?

Verwenden Sie dieses Template als Leitfaden für den Export Ihrer Daten zur Zahlungsabwicklung. Gewinnen Sie wertvolle Erkenntnisse und verbessern Sie noch heute die Effizienz Ihrer Finanz-Workflows.

Zahlungsabwicklung verbessern: Starten Sie jetzt Ihre kostenlose Testphase

Vermeiden Sie Zahlungsausnahmen und erreichen Sie eine Dunkelverarbeitungsquote von 98 %.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.