Ihr Daten-Template für Kreditmanagement und Forderungseinzug
Ihr Daten-Template für Kreditmanagement und Forderungseinzug
- Empfohlene Attribute für die Datenerhebung
- Wichtige Aktivitäten für die Nachverfolgung
- Hinweise zur Datenextraktion aus SAP ECC
Attribute für Kreditmanagement und Forderungseinzug
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivitätsname
ActivityName
|
Der Name der geschäftlichen Aktivität oder des Ereignisses, das zu einem bestimmten Zeitpunkt im Lebenszyklus einer Rechnung stattgefunden hat. | ||
|
Beschreibung
Dieses Attribut beschreibt einen bestimmten Schritt oder ein Ereignis im Kredit- und Forderungsmanagement, zum Beispiel 'Rechnung gebucht', 'Mahnlauf ausgeführt' oder 'Eingehender Zahlungsbeleg gebucht'. Diese Aktivitäten bilden die Knoten der Prozesslandkarte. Anhand der Reihenfolge, Häufigkeit und Dauer zwischen den Aktivitäten können Unternehmen den tatsächlichen Prozessablauf visualisieren, Abweichungen von Standardverfahren erkennen und Engpässe lokalisieren. Die Analyse des Pfads nach 'Mahnlauf ausgeführt' kann beispielsweise zeigen, wie wirksam die Mahnstrategie ist.
Warum das wichtig ist
Aktivitäten sind die Bausteine der Prozesslandkarte. Sie ermöglichen es, den Prozessablauf, Varianten und Ausnahmen zu visualisieren und zu analysieren.
Woher beziehen
Dieses abgeleitete Attribut wird in der Regel erstellt, indem Transaktionscodes (TCODE), Belegarten (BLART) oder bestimmte Feldänderungen aus verschiedenen SAP-Tabellen, zum Beispiel BKPF, BSID, MHNK und UDM_CASE, benutzerfreundlichen Aktivitätsnamen zugeordnet werden.
Beispiele
Rechnung gebuchtMahnlauf ausgeführtZahlungszusage erfasstEingehender Zahlungsbeleg gebuchtRechnung ausgeglichen
|
|||
|
Ereigniszeit
EventTime
|
Der Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis stattgefunden hat. | ||
|
Beschreibung
Die Ereigniszeit erfasst Datum und Uhrzeit jeder Aktivität im Prozess. Sie bildet die chronologische Grundlage des Event Log und ermöglicht es, Aktivitäten zu ordnen und Zeitspannen zwischen ihnen zu berechnen. Für die Analyse ist dieser Timestamp entscheidend, um zeitbezogene Kennzahlen wie die Zykluszeit bis zur Klärung eines Streitfalls, die Verzögerung bei der Zahlungsbuchung und die durchschnittliche Zeit zwischen Fälligkeit und Zahlung zu berechnen. Lange Wartezeiten zwischen aufeinanderfolgenden Schritten machen Engpässe sichtbar.
Warum das wichtig ist
Dieses Attribut ist unverzichtbar, um Ereignisse korrekt zu ordnen und alle zeitbezogenen Leistungskennzahlen wie Zykluszeiten und Zeitspannen zu berechnen.
Woher beziehen
Die Daten stammen aus verschiedenen Datums- und Zeitfeldern in SAP-Tabellen, etwa BUDAT (Buchungsdatum) oder CPUDT/CPUTM (Erfassungsdatum und -uhrzeit des Belegs) in BKPF sowie aus ereignisspezifischen Tabellen.
Beispiele
2023-01-15T09:30:00Z2023-02-10T14:00:00Z2023-02-28T11:25:10Z
|
|||
|
Rechnungsnummer
InvoiceNumber
|
Die eindeutige Kennung der Kundenrechnung. Sie dient als primäre Case-ID für den Kreditmanagementprozess. | ||
|
Beschreibung
Die Rechnungsnummer, in SAP als Belegnummer (BELNR) bezeichnet, identifiziert jeden Debitorenbeleg eindeutig. Im Process Mining ist sie entscheidend, weil sie alle zugehörigen Aktivitäten von der Buchung und Mahnung bis zur Zahlung oder Abschreibung zu einem zusammenhängenden Case verknüpft. Wird die Rechnungsnummer als Case-ID verwendet, lässt sich der gesamte Lebenszyklus einer Rechnung analysieren. So können Sie Kennzahlen wie die Days Sales Outstanding (DSO) verfolgen, Engpässe im Forderungsmanagement erkennen und die Wirksamkeit verschiedener Mahnstrategien für einzelne Rechnungen beurteilen.
Warum das wichtig ist
Dieser zentrale Schlüssel verbindet alle Ereignisse im Verlauf einer Rechnung und ermöglicht es, den gesamten Kredit-bis-Zahlung-Prozess nachzuverfolgen und zu analysieren.
Woher beziehen
Das Feld BELNR ist in verschiedenen Tabellen der Finanzbuchhaltung in SAP ECC zu finden, vor allem in BKPF (Belegkopf) und BSEG (Belegsegment).
Beispiele
190000000119000000451900000102
|
|||
|
Benutzername
UserName
|
Die Benutzer-ID der Person, die die Aktivität ausgeführt hat. | ||
|
Beschreibung
Dieses Attribut gibt an, welcher Benutzer für ein Ereignis verantwortlich war, etwa für die Buchung einer Rechnung oder die Erstellung eines Streitfalls. In SAP ist diese Information häufig in Feldern wie ERNAM (Erstellt von) oder USNAM gespeichert. Die Auswertung nach Benutzern hilft, die Arbeitsverteilung zu verstehen, Schulungsbedarf zu erkennen und mögliche Compliance-Probleme aufzudecken. So wird beispielsweise sichtbar, ob bestimmte Benutzer regelmäßig mit Prozessabweichungen oder Verzögerungen verbunden sind oder ob besonders leistungsstarke Mitarbeitende einer effizienteren Prozessvariante folgen.
Warum das wichtig ist
Das Attribut ermöglicht die Analyse menschlicher Leistung und Verhaltensweisen im Prozess. So lassen sich besonders leistungsstarke Mitarbeitende, Schulungsbedarf und eine unausgewogene Arbeitsverteilung erkennen.
Woher beziehen
Das Attribut ist in der Regel in Kopftabellen wie BKPF als USNAM (Benutzername) oder ERNAM (Name der Person, die das Objekt erstellt hat) zu finden.
Beispiele
SMITHJRDOECFO-ADMIN
|
|||
|
Fälligkeitsdatum
NetDueDate
|
Das Datum, an dem die Rechnung laut Vereinbarung zu bezahlen ist. | ||
|
Beschreibung
Das Fälligkeitsdatum ist der Termin, bis zu dem der Kunde die Rechnung bezahlen soll. Es wird anhand des Basisdatums der Rechnung und der Zahlungsbedingungen berechnet. In SAP ist das Nettofälligkeitsdatum häufig im Feld FAEDT verfügbar. Dieses Datum ist für das Kreditmanagement grundlegend. Es dient als Maßstab für die Pünktlichkeit von Zahlungen und wird zur Berechnung von Kennzahlen wie 'Durchschnittliche Zeit zwischen Fälligkeit und Zahlung' verwendet. Nach Ablauf des Datums können Aktivitäten im Forderungsmanagement ausgelöst werden. Die Analyse von Verzögerungen im Verhältnis zu diesem Datum gehört zu den Kernaufgaben der Forderungsanalyse.
Warum das wichtig ist
Dieses Datum ist der wichtigste Maßstab für die Pünktlichkeit von Zahlungen und unverzichtbar, um Verzugstage und zugehörige Kennzahlen zu berechnen.
Woher beziehen
Dieses Datum ist häufig direkt in Tabellen der Kundenpositionen wie BSID im Feld FAEDT (Nettofälligkeitsdatum) verfügbar. Es kann auch aus dem Basisdatum (ZFBDT) und den Zahlungsbedingungen (ZTERM) berechnet werden.
Beispiele
2023-02-142023-03-312023-04-15
|
|||
|
Kundennummer
Kunnr
|
Die eindeutige Kennung des Kunden. | ||
|
Beschreibung
Die Kundennummer (KUNNR in SAP) ist der eindeutige Schlüssel für ein Kundenkonto. Sie verknüpft einen Geschäftsvorgang mit den Stammdaten eines bestimmten Kunden, darunter Zahlungshistorie, Kreditinformationen und Kontaktdaten. Im Process Mining ist dieses Attribut wichtig, um Analysen nach Kundengruppen aufzuschlüsseln. So können Sie die Prozessleistung verschiedener Kunden vergleichen, dauerhaft verspätete Zahler erkennen und untersuchen, wie sich Mahnstrategien für strategische und nicht strategische Kunden unterscheiden. Das Attribut ist eine wichtige Grundlage für Dashboards wie Rechnungsfälligkeiten und Einhaltung von Zahlungsbedingungen.
Warum das wichtig ist
Das Attribut ermöglicht kundenbezogene Analysen. So lassen sich Verhaltensmuster einzelner Kunden oder Kundengruppen erkennen und Mahnstrategien gezielt anpassen.
Woher beziehen
Das Standardfeld KUNNR in den Tabellen der Kundenpositionen (BSID, BSAD) und in Belegkopftabellen (BKPF, sofern befüllt).
Beispiele
10002050CUST-7890
|
|||
|
Kundensegment
CustomerSegment
|
Die Einordnung des Kunden, zum Beispiel nach Unternehmensgröße, Branche oder strategischer Bedeutung. | ||
|
Beschreibung
Das Kundensegment gruppiert Kunden mit ähnlichen Merkmalen. In SAP wird es häufig aus der Kontengruppe des Kunden (KTOKD) oder aus anderen benutzerdefinierten Feldern in den Kundenstammdaten abgeleitet. Die Aufschlüsselung der Prozessanalyse nach diesem Attribut liefert wichtige Erkenntnisse. Sie zeigt beispielsweise, ob bestimmte Segmente längere Zahlungszyklen oder mehr Streitfälle aufweisen oder besser auf bestimmte Mahnaktivitäten reagieren. Diese Informationen sind entscheidend, um Mahnstrategien zu optimieren und die Kundenansprache anzupassen.
Warum das wichtig ist
Das Attribut ermöglicht gezielte Analysen der Prozessleistung für verschiedene Kundentypen. So lassen sich Strategien und Ressourceneinsatz entsprechend anpassen.
Woher beziehen
Das Attribut wird häufig aus dem Feld für die Kontengruppe des Kunden (KTOKD) in der Kundenstammdatentabelle KNA1 oder aus anderen benutzerdefinierten Feldern abgeleitet.
Beispiele
SchlüsselkundenKleine und mittlere UnternehmenÖffentliche VerwaltungIntern
|
|||
|
Mahnstufe
Mahns
|
Die höchste Mahnstufe, die für die Rechnung erreicht wurde. | ||
|
Beschreibung
Die Mahnstufe (MAHNS in SAP) gibt an, wie viele Mahnungen für eine überfällige Rechnung versendet wurden, und damit auch, wie intensiv das Mahnverfahren bereits ist. Dieses Attribut ist entscheidend für die Bewertung des Mahnprozesses. Im Dashboard „Wirksamkeit der Mahnungen nach Stufe“ wird damit gemessen, welcher Anteil der Rechnungen nach dem Versand der jeweiligen Mahnung bezahlt wird. Die Analyse hilft, die Mahnstrategie anzupassen, etwa indem Sie den Versandzeitpunkt oder den Inhalt von Mahnungen auf wenig wirksamen Stufen ändern.
Warum das wichtig ist
Misst direkt die Intensität der Einzugsbemühungen und ist damit entscheidend für die Analyse der Wirksamkeit der Mahnstrategie.
Woher beziehen
Als Feld MAHNS im Kunden-Einzelposten der Tabelle BSID. Der Verlauf der Mahnläufe ist in den Tabellen MHNK (Kopf) und MHND (Daten) gespeichert.
Beispiele
1234
|
|||
|
Mitarbeiter im Forderungsmanagement
Sachp
|
Der für das Kundenkonto zuständige Sachbearbeiter oder Mitarbeiter im Forderungsmanagement. | ||
|
Beschreibung
Dieses Attribut gibt an, welche Person oder Gruppe für das Forderungsmanagement eines bestimmten Kundenkontos zuständig ist. In SAP ist dies häufig der im Kundenstammsatz hinterlegte Buchungskreis-Sachbearbeiter (SACHP). Diese Dimension ist wichtig für die Leistungssteuerung des Teams im Forderungsmanagement. Sie ermöglicht Dashboards wie „Überblick über das Alter offener Rechnungen“, gefiltert nach zuständigem Mitarbeiter. So lassen sich Arbeitslasten steuern und die Ergebnisse verschiedener Mitarbeitender oder Teams vergleichen. Außerdem zeigt die Analyse, welche Mitarbeitenden überfällige Rechnungen am erfolgreichsten klären.
Warum das wichtig ist
Ermöglicht die Leistungsanalyse und Arbeitslaststeuerung im Forderungsmanagement, indem Fälle und Ergebnisse bestimmten Personen oder Gruppen zugeordnet werden.
Woher beziehen
Üblicherweise in den Buchungskreisdaten des Kundenstamms (Tabelle KNB1, Feld SACHP).
Beispiele
J. SmithTeam AINTL-COLL
|
|||
|
Rechnungsbetrag
Dmbtr
|
Der Gesamtbetrag der Rechnung in der Landeswährung. | ||
|
Beschreibung
Dieses Attribut gibt den Gesamtbetrag der Rechnung an. In SAP ist der Betrag in Landeswährung häufig im Feld DMBTR gespeichert. Der Rechnungsbetrag ist eine wichtige Analysedimension. Damit können Sie die Bearbeitung von Rechnungen mit hohen Beträgen priorisieren und untersuchen, ob der Rechnungswert mit Zahlungsverzögerungen oder Streitfällen zusammenhängt. Sie können die Prozesslandkarte nach diesem Attribut filtern und sich auf Rechnungen oberhalb eines bestimmten Schwellenwerts konzentrieren.
Warum das wichtig ist
Das Attribut liefert den finanziellen Kontext des Prozesses. Es ermöglicht wertbezogene Analysen und hilft, die Bearbeitung von Rechnungen mit hohen Beträgen zu priorisieren.
Woher beziehen
Das Standardfeld DMBTR (Betrag in Landeswährung) in Tabellen wie BSEG, BSID und BSAD.
Beispiele
1500.0012500.50750.25
|
|||
|
Überfällige Tage
DaysOverdue
|
Die berechnete Zahl der Tage, um die eine Rechnung nach ihrem Fälligkeitsdatum überfällig ist. | ||
|
Beschreibung
Diese Kennzahl berechnet die Zahl der Tage zwischen dem Fälligkeitsdatum einer Rechnung und ihrem Ausgleich. Bei offenen Rechnungen wird das aktuelle Datum zugrunde gelegt. Die Zahl der überfälligen Tage ist eine grundlegende Kennzahl für die Analyse von Forderungen. Sie ist die zentrale Messgröße im Dashboard „Überblick über das Alter offener Rechnungen“ und dient dazu, Aktivitäten im Forderungseinzug zu priorisieren. Die Entwicklung dieser Kennzahl auf aggregierter Ebene gibt Aufschluss über den Gesamtzustand der Forderungen eines Unternehmens.
Warum das wichtig ist
Diese zentrale Leistungskennzahl misst Zahlungsverzögerungen direkt. Sie hilft, Einzugsbemühungen zu priorisieren und die Prozessgesundheit zu bewerten.
Woher beziehen
Berechnetes Attribut. Die Berechnung lautet: (Ausgleichsdatum oder aktuelles Datum) - Nett Fälligkeitsdatum.
Beispiele
0153295
|
|||
|
Abgeschrieben
IsWrittenOff
|
Ein boolesches Kennzeichen, das angibt, ob die Rechnung letztlich als uneinbringliche Forderung abgeschrieben wurde. | ||
|
Beschreibung
Dieses abgeleitete Kennzeichen wird üblicherweise auf „true“ gesetzt, wenn eine Rechnung mit einem bestimmten Grundcode oder einer Belegart ausgeglichen wird, die eine Abschreibung kennzeichnet. Es identifiziert Fälle, die einen finanziellen Verlust darstellen. Das Attribut ist wichtig für die Berechnung der KPI „Abschreibungsquote uneinbringlicher Forderungen“ und für zugehörige Dashboards. Es ermöglicht eine Ursachenanalyse zu den Merkmalen von Rechnungen und Kunden, bei denen häufig Abschreibungen anfallen. Die Ergebnisse können dazu beitragen, Kreditrichtlinien und die Wirksamkeit des Forderungseinzugs zu verbessern.
Warum das wichtig ist
Kennzeichnet Prozessergebnisse mit finanziellen Verlusten. So lassen sich Ursachen für uneinbringliche Forderungen analysieren und Kreditrichtlinien verbessern.
Woher beziehen
Abgeleitetes Attribut. Die Berechnung basiert üblicherweise auf bestimmten Ausgleichsgrundcodes (BSEG-RSTGR) oder Belegarten (BKPF-BLART), die für Abschreibungen verwendet werden.
Beispiele
truefalse
|
|||
|
Ausgleichsbeleg
Augbl
|
Die Nummer des Belegs, mit dem die Rechnung ausgeglichen wurde, in der Regel eine Zahlung oder Gutschrift. | ||
|
Beschreibung
Die Nummer des Ausgleichsbelegs (AUGBL in SAP) verknüpft einen offenen Posten, etwa eine Rechnung, mit dem Beleg, durch den er ausgeglichen wurde. Bei einer Zahlung wird die Nummer des Zahlungsbelegs als Ausgleichsbeleg der Rechnung gespeichert. Dieses Feld ist wichtig, um den Ausgleich einer Rechnung zu bestätigen und sie mit dem konkreten Zahlungs- oder Gutschriftvorgang zu verknüpfen. Es bildet die Grundlage für die Aktivität „Rechnung ausgeglichen“ und stellt sicher, dass der End-to-End-Prozess korrekt erfasst wird.
Warum das wichtig ist
Verknüpft eine Rechnung eindeutig mit dem zugehörigen Ausgleichsbeleg. Das ist entscheidend, um Ausgleichsvorgänge korrekt abzubilden.
Woher beziehen
Standardfeld AUGBL in den Kunden-Einzelpostentabellen BSID (bei offenen Posten leer) und BSAD (nach dem Ausgleich befüllt).
Beispiele
140000000114000000551400000120
|
|||
|
Belegart
Blart
|
Die Art des Finanzbelegs, zum Beispiel Rechnung, Gutschrift oder Zahlung. | ||
|
Beschreibung
Die Belegart (BLART in SAP) klassifiziert Buchhaltungsbelege. „RV“ kann beispielsweise für eine Kundenrechnung stehen, „DZ“ für eine Kundenzahlung und „DG“ für eine Gutschrift. Für Process Mining werden Aktivitäten abgeleitet. Die ursprüngliche Belegart liefert dazu wichtigen Kontext und kann zur Überprüfung oder für detailliertere Finanzanalysen herangezogen werden. Sie hilft, die Art der verarbeiteten Transaktionen zu verstehen und die Analyse auf bestimmte Belegarten, etwa Kundenrechnungen, einzugrenzen.
Warum das wichtig ist
Liefert durch die Klassifizierung von Transaktionen den finanziellen Kontext. Damit lässt sich die Analyse filtern oder die Ableitung der Aktivitätsnamen überprüfen.
Woher beziehen
Standardfeld BLART in der Belegkopftabelle BKPF.
Beispiele
RVDZDGAB
|
|||
|
Buchungskreis
Bukrs
|
Die Kennung der rechtlichen Einheit (Buchungskreis), zu der die Rechnung gehört. | ||
|
Beschreibung
Der Buchungskreis (BUKRS in SAP) bezeichnet eine eigenständige rechtliche Einheit, für die Abschlüsse erstellt werden. Er ist eine grundlegende Organisationseinheit in SAP Financials. Dieses Attribut ist wichtig, um die Prozessleistung verschiedener rechtlicher Einheiten eines Unternehmens zu filtern und zu vergleichen. Damit lässt sich prüfen, ob die Prozesse zum Forderungseinzug einheitlich ablaufen oder ob sich die Ergebnisse deutlich unterscheiden, beispielsweise bei DSO oder Streitfallquoten.
Warum das wichtig ist
Ermöglicht die Prozessanalyse nach rechtlicher Einheit. Das ist für große, international tätige Unternehmen wichtig, um die Leistung zu vergleichen.
Woher beziehen
Standardfeld BUKRS in nahezu allen Finanzbuchhaltungstabellen, darunter BKPF, BSEG, BSID und BSAD.
Beispiele
10002000US01
|
|||
|
Kreditlimit
Klimk
|
Der dem Kunden zugewiesene Gesamtkreditrahmen. | ||
|
Beschreibung
Das Kreditlimit (KLIMK in SAP) ist der maximale Kreditbetrag, der einem Kundenkonto eingeräumt wird. Es ist ein wichtiger Bestandteil des Kreditrisikomanagements. Dieses Attribut ist für das Dashboard „Genauigkeit des Kreditlimits im Vergleich zu Forderungsausfällen“ entscheidend. Durch die Analyse des Zusammenhangs zwischen dem eingeräumten Kreditlimit und Abschreibungen kann ein Unternehmen die Wirksamkeit seiner Kreditrichtlinien bewerten. Außerdem unterstützt es KPIs wie „Änderungsquote des Kreditlimits“, mit denen sich prüfen lässt, ob die ursprünglichen Einschätzungen zutreffen.
Warum das wichtig ist
Liefert Kontext zum Kreditrisiko. So lässt sich analysieren, ob Kreditrichtlinien Forderungsausfälle verhindern, ohne den Umsatz zu beeinträchtigen.
Woher beziehen
In den zentralen Kreditmanagementdaten eines Kunden in Tabelle KNKK, Feld KLIMK.
Beispiele
10000.0050000.00250000.00
|
|||
|
Letzte Datenaktualisierung
LastDataRefreshTimestamp
|
Der Timestamp der letzten Extraktion oder Aktualisierung der Daten im Process-Mining-Tool. | ||
|
Beschreibung
Dieses Attribut erfasst Datum und Uhrzeit des letzten Datenimports. Es zeigt Fachanwendern, wie aktuell die Daten sind, die sie analysieren. Bei der Prüfung von Dashboards und Analysen hilft dieser Timestamp einzuschätzen, ob die neuesten Transaktionen bereits enthalten sind oder eine bekannte Verzögerung besteht. Diese Metadaten sind wichtig, damit Benutzer den Analyseergebnissen vertrauen können.
Warum das wichtig ist
Das Attribut informiert Benutzer darüber, wie aktuell die Daten sind. Das ist entscheidend, wenn Entscheidungen auf Grundlage der neuesten verfügbaren Prozessinformationen getroffen werden.
Woher beziehen
Dieser Wert wird bei der Aktualisierung der Daten von der ETL-Pipeline für Extraktion und Laden erzeugt und gespeichert.
Beispiele
2023-03-01T02:00:00Z2023-03-02T02:00:00Z2023-03-03T02:00:00Z
|
|||
|
Quellsystem-ID
SourceSystemId
|
Die Kennung des Quellsystems, aus dem die Daten extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut gibt das Ursprungssystem an, zum Beispiel eine bestimmte SAP-ECC-Instanz wie 'ECCPRD100'. Das ist wichtig, wenn mehrere ERP-Systeme im Einsatz sind oder Daten aus verschiedenen Quellen zusammengeführt werden. Damit lassen sich Prozesse aus unterschiedlichen Systemen oder Regionen filtern und vergleichen. Außerdem bleibt die Datenherkunft nachvollziehbar, was die Fehlersuche bei Problemen mit der Datenextraktion erleichtert.
Warum das wichtig ist
Das Attribut liefert wichtige Informationen zur Datenherkunft, insbesondere in komplexen IT-Landschaften. So bleibt die Datenherkunft nachvollziehbar und Analysen lassen sich auf bestimmte Systeme beschränken.
Woher beziehen
Das Attribut wird in der Regel während der Datenextraktion ergänzt. In SAP kann dafür der Name des logischen Systems (LOGSYS) verwendet werden.
Beispiele
SAPECC_PROD_100ECC_EU_200US_FIN_ERP
|
|||
|
Risikokategorie
Ctlpc
|
Eine Einstufung des Kreditrisikos des Kunden. | ||
|
Beschreibung
Die Risikokategorie (CTLPC in SAP) gruppiert Kunden anhand ihrer Kreditwürdigkeit und Zahlungshistorie. Sie dient als Grundlage für automatisierte Kreditprüfungen und die Ausrichtung der Einzugsstrategie. Die Analyse nach Risikokategorie liefert wichtige Erkenntnisse. Sie zeigt, ob Kunden mit hohem Risiko andere Prozesspfade durchlaufen oder deutlich längere Zahlungszyklen haben. Diese Informationen helfen, die Genauigkeit der Risikoeinstufung zu überprüfen und die Intensität des Forderungseinzugs an das jeweilige Risiko anzupassen.
Warum das wichtig ist
Ermöglicht eine risikobasierte Analyse des Forderungseinzugs. So können Sie Risikomodelle überprüfen und Einzugsstrategien gezielt anpassen.
Woher beziehen
In den zentralen Kreditmanagementdaten eines Kunden in Tabelle KNKK, Feld CTLPC.
Beispiele
001002HOHES RISIKO
|
|||
|
Streitfall-ID
DisputeCaseId
|
Die eindeutige Kennung eines mit der Rechnung verknüpften Streitfalls. | ||
|
Beschreibung
Wenn ein Kunde eine Rechnung beanstandet, kann im SAP-Modul Dispute Management ein formeller Streitfall angelegt werden. Diese ID identifiziert den Fall eindeutig. Mit dieser Kennung lässt sich der Prozess zur Klärung von Streitfällen detailliert analysieren. Sie ist wichtig für die Berechnung der KPI „Durchlaufzeit der Streitfallklärung“ und hilft zu verstehen, warum Streitfälle entstehen, wie sie bearbeitet werden und welche Ergebnisse häufig auftreten. So lässt sich der Teilprozess für Streitfälle vom regulären Forderungseinzug abgrenzen.
Warum das wichtig ist
Verknüpft Aktivitäten im Forderungseinzug mit formellen Streitfällen. Dadurch lassen sich die Effizienz und Ursachen des Klärungsprozesses gezielt analysieren.
Woher beziehen
In Tabellen des SAP Dispute Management, etwa UDM_CASE_ATTR00. Die Verwendung setzt das SAP-Modul Dispute Management voraus.
Beispiele
400000000021400000000157400000000305
|
|||
|
Zahlungsbedingungen
Zterm
|
Der Code für die mit dem Kunden vereinbarten Zahlungsbedingungen. | ||
|
Beschreibung
Der Zahlungskonditionsschlüssel (ZTERM in SAP) legt die Zahlungsbedingungen fest, etwa das Fälligkeitsdatum und mögliche Skonti bei vorzeitiger Zahlung. Üblicherweise wird er in den Kundenstammdaten hinterlegt und in Rechnungen übernommen. Die Analyse nach Zahlungskonditionen zeigt, wie sich unterschiedliche Bedingungen auf das Zahlungsverhalten auswirken. Das Dashboard „Einhaltung und Auswirkungen von Zahlungskonditionen“ veranschaulicht beispielsweise, wie stark die vereinbarten Bedingungen eingehalten werden und welchen Einfluss dies auf die Zahl überfälliger Tage hat. Diese Erkenntnisse helfen bei der Entscheidung, welche Zahlungskonditionen Sie den verschiedenen Kundensegmenten anbieten.
Warum das wichtig ist
Beschreibt die vertraglich vereinbarten Zahlungsbedingungen und hilft zu analysieren, ob bestimmte Konditionen zu pünktlicheren Zahlungen oder mehr Streitfällen führen.
Woher beziehen
Standardfeld ZTERM in den Kundenstammdaten (KNB1) und den Tabellen für Finanzbelege (BSEG).
Beispiele
0001NT30ZD60
|
|||
Aktivitäten im Kreditmanagement und Forderungseinzug
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Mahnlauf ausgeführt
|
Diese Aktivität steht für die Ausführung des automatischen Mahnprogramms für eine überfällige Rechnung. Das System protokolliert für jede Rechnung in einem Mahnlauf die Mahnstufe, das Datum und weitere Angaben. | ||
|
Warum das wichtig ist
Die Nachverfolgung von Mahnaktivitäten ist wichtig, um die Wirksamkeit der Forderungsmanagementstrategie zu bewerten. Sie zeigt, welche Mahnstufen am ehesten eine Zahlung auslösen und welche Kunden nicht reagieren.
Woher beziehen
Dies ist ein explizites Ereignis. Angaben zu Mahnläufen werden in den Mahndatentabellen gespeichert, vor allem in MHNK (Mahndaten). Die Tabelle enthält für jede gemahnte Rechnung das Laufdatum (LAUFD) und die Mahnstufe (MAHNS).
Erfassung
Extrahieren Sie Datensätze aus der Tabelle MHNK und verknüpfen Sie Buchungskreis, Konto und Mahndatum.
Ereignistyp
explicit
|
|||
|
Rechnung abgeschrieben
|
Dieses Ereignis steht für die Entscheidung, eine unbezahlte Rechnung als Verlust zu verbuchen und als Forderungsausfall einzustufen. Erfasst wird dies durch eine bestimmte Finanzbuchung, die die ursprüngliche Rechnung ausgleicht und den Betrag auf ein Konto für Forderungsausfälle umbucht. | ||
|
Warum das wichtig ist
Dies ist das primäre negative End-Event. Es weist auf ein Scheitern des Kredit- oder Forderungsmanagements und einen direkten finanziellen Verlust hin. Die Analyse dieser Fälle ist entscheidend, um Kreditrichtlinien und Mahnstrategien zu verbessern.
Woher beziehen
Dabei handelt es sich in der Regel um eine explizite Buchung oder ein aus dem Ausgleichsvorgang abgeleitetes Ereignis. Der Ausgleich erfolgt mit einem bestimmten Transaktionscode und einem Grundcode, der die Abschreibung kennzeichnet. Der Ausgleichsbeleg kann zur Bestätigung der Abschreibung analysiert werden.
Erfassung
Ermitteln Sie Ausgleichsbelege, bei denen ein bestimmter Grundcode für Abschreibungen (BSEG-RSTGR) verwendet wird oder die Gegenbuchung auf ein Aufwandskonto für Forderungsausfälle erfolgt.
Ereignistyp
inferred
|
|||
|
Rechnung ausgeglichen
|
Dieses Ereignis markiert den erfolgreichen Abschluss einer Rechnung, in der Regel nachdem der vollständige Betrag eingegangen und zugeordnet wurde. Es wird abgeleitet, wenn die Rechnungsposition aus der Tabelle der offenen Posten (BSID) in die Tabelle der ausgeglichenen Posten (BSAD) wechselt. | ||
|
Warum das wichtig ist
Dies ist das primäre positive End-Event des Prozesses. Die Zeit bis zu dieser Aktivität ist ein zentraler Bestandteil der DSO. Die Analyse der Pfade, die zu diesem Ereignis führen, hilft dabei, bewährte Vorgehensweisen zu erkennen.
Woher beziehen
Dieses Ereignis wird abgeleitet. Der Ausgleich lässt sich anhand des Ausgleichsbelegs (AUGBL) und des Ausgleichsdatums (AUGDT) der Rechnungsposition erkennen, die in der Tabelle der ausgeglichenen Posten BSAD geführt wird.
Erfassung
Verwenden Sie das Ausgleichsdatum (BSAD-AUGDT) der jeweiligen Rechnungsposition als Timestamp des Ereignisses.
Ereignistyp
inferred
|
|||
|
Rechnung gebucht
|
Dieses Ereignis steht für die Erstellung eines Debitorenrechnungsbelegs im Finanzbuchhaltungsmodul. Es wird explizit erfasst, wenn ein Fakturabeleg aus Sales and Distribution (SD) an die Buchhaltung übergeben oder direkt eine FI-Rechnung gebucht wird. Dabei entstehen Einträge in den Tabellen BKPF und BSEG. | ||
|
Warum das wichtig ist
Dies ist das primäre Start-Event im Lebenszyklus einer Rechnung. Die Zeitspanne von diesem Zeitpunkt bis zum Zahlungseingang ist entscheidend für die Messung der Days Sales Outstanding (DSO) und der Gesamteffizienz des Prozesses.
Woher beziehen
Dieses explizite Ereignis wird bei der Erstellung eines Finanzbelegs erfasst. Der Timestamp lässt sich für die zugehörige Rechnungsbelegnummer (BELNR) aus der Belegkopftabelle BKPF abrufen, und zwar aus dem Feld CPUDT oder BKTXT.
Erfassung
Ermitteln Sie in der Tabelle BKPF die Erstellungsereignisse von FI-Belegen mit relevanten Belegarten, zum Beispiel 'RV' oder 'DR'.
Ereignistyp
explicit
|
|||
|
Zahlungsziel überschritten
|
Dieses berechnete Ereignis zeigt an, dass die Rechnung offiziell überfällig ist. Es wird nicht als explizites Systemereignis erfasst, sondern durch den Vergleich des Nettofälligkeitsdatums der Rechnung mit dem aktuellen Datum oder dem Timestamp einer nachfolgenden Aktivität abgeleitet. | ||
|
Warum das wichtig ist
Dieses Ereignis markiert den Übergang von der regulären Rechnungsstellung zum Forderungsmanagement. Es dient als Auslöser für die Berechnung der Verzugstage und die Einleitung von Mahnverfahren und bildet die Grundlage für Fälligkeitsanalysen.
Woher beziehen
Dieses Ereignis wird berechnet. Dazu wird das Nettofälligkeitsdatum (BSID-NETDT) der offenen Rechnungsposition mit dem Systemdatum oder dem Timestamp eines anderen Ereignisses verglichen.
Erfassung
Berechnet durch den Vergleich des Nettofälligkeitsdatums der Rechnung (BSID-NETDT) mit einem Zeitverlauf.
Ereignistyp
calculated
|
|||
|
Eingehender Zahlungsbeleg gebucht
|
Dieses Ereignis steht für die erstmalige Erfassung einer Kundenzahlung im System, häufig bevor sie bestimmten Rechnungen zugeordnet wird. Es handelt sich um ein explizites Ereignis, bei dem ein Zahlungsbeleg erstellt wird, beispielsweise mit der Belegart DZ. | ||
|
Warum das wichtig ist
Dieses Ereignis markiert den Zahlungseingang. Die Zeitspanne bis zum abschließenden Ereignis 'Rechnung ausgeglichen' bildet den Zahlungsausgleichsprozess ab, der einen erheblichen Engpass darstellen kann.
Woher beziehen
Dies ist ein explizites Ereignis. Es wird bei der Erstellung eines Zahlungsbelegs in der Tabelle BKPF erfasst, der anhand bestimmter Belegarten wie 'DZ' identifiziert werden kann. Als Timestamp dient das Buchungsdatum (BKPF-BUDAT).
Erfassung
Ermitteln Sie in der Tabelle BKPF die Erstellung von Belegen mit zahlungsbezogenen Belegarten, zum Beispiel 'DZ'.
Ereignistyp
explicit
|
|||
|
Gutschrift gebucht
|
Dieses Ereignis steht für die Erstellung eines Gutschriftsbelegs auf einem Kundenkonto, häufig zur Korrektur eines Rechnungsfehlers oder zur Klärung eines Streitfalls. Der Beleg wird explizit im FI-Modul erstellt. | ||
|
Warum das wichtig ist
Gutschriften sind häufig eine direkte Folge vorgelagerter Prozessfehler, etwa falscher Preise oder Versandfehler. Ihre Häufigkeit und Ursachen zu analysieren, ist wichtig, um Prozesse zu verbessern und Umsatzverluste zu verringern.
Woher beziehen
Dieses explizite Ereignis wird bei der Erstellung eines Finanzbelegs mit einer Gutschriftsbelegart, zum Beispiel 'DG', erfasst. Der Timestamp lässt sich aus der Belegkopftabelle BKPF abrufen.
Erfassung
Ermitteln Sie in der Tabelle BKPF die Erstellungsereignisse von FI-Belegen mit Gutschriftsbelegarten, zum Beispiel 'DG' oder 'G2'.
Ereignistyp
explicit
|
|||
|
Kontakt zum Kunden protokolliert
|
Ein Mitarbeitender im Forderungsmanagement hat den Kunden wegen einer überfälligen Rechnung kontaktiert, zum Beispiel telefonisch oder per E-Mail. Diese Aktivität wird in der Regel manuell von der zuständigen Person im System protokolliert. | ||
|
Warum das wichtig ist
Diese Aktivität erfasst den manuellen Aufwand des Teams für das Forderungsmanagement. Wenn Sie Häufigkeit und Zeitpunkt der Kontakte mit späteren Zahlungseingängen vergleichen, können Sie die Wirksamkeit der Maßnahmen beurteilen.
Woher beziehen
Bei Verwendung von SAP FSCM Collections Management wird dieser Vorgang als 'Customer Contact' protokolliert. Die Angaben werden in Tabellen zur Arbeitsliste und Kontakthistorie des Forderungsmanagements gespeichert und häufig mit UDM_CASE verknüpft.
Erfassung
Extrahieren Sie die Kundenkontaktprotokolle aus den relevanten Tabellen von FSCM Collections Management.
Ereignistyp
explicit
|
|||
|
Rechnung für Zahlung gesperrt
|
Dieses Ereignis zeigt an, dass die Rechnung manuell oder automatisch für die Zahlung gesperrt wurde. Erfasst wird es über einen bestimmten Zahlungssperrvermerk in der Rechnungsposition der Tabelle BSEG. | ||
|
Warum das wichtig ist
Zahlungssperren sind eine häufige Ursache für Verzögerungen und Prozessausnahmen. Wenn Sie erkennen, wann und warum Rechnungen gesperrt werden, können Sie die Ursachen verspäteter Zahlungen aufdecken und den Cashflow verbessern.
Woher beziehen
Dieser Status wird in der Regel aus einer Änderung des Felds für die Zahlungssperre (BSEG-ZLSPR) in der Rechnungsposition abgeleitet. Änderungsbelege zu diesem Feld in den Tabellen CDHDR und CDPOS können genaue Timestamps liefern.
Erfassung
Ermitteln Sie Änderungen am Feld BSEG-ZLSPR der Rechnungsposition. Verwenden Sie dazu die Tabelle CDHDR für die Timestamps.
Ereignistyp
inferred
|
|||
|
Restposten erstellt
|
Dieses Ereignis tritt beim Zahlungsausgleich auf, wenn ein Kunde eine Rechnung nicht vollständig bezahlt und der verbleibende kleine Betrag als neuer offener Posten gebucht wird. Es wird aus den Details des Ausgleichsvorgangs abgeleitet. | ||
|
Warum das wichtig ist
Restposten weisen auf Abweichungen bei Zahlungen hin und verursachen zusätzlichen Aufwand. Ihre Nachverfolgung hilft, Kunden zu erkennen, die häufig zu wenig zahlen, und Probleme bei Preisen oder der Rechnungsstellung aufzudecken, die zu Streitfällen führen.
Woher beziehen
Dieses Ereignis wird abgeleitet. Wenn ein Ausgleichsvorgang, zum Beispiel über F-28, eine ursprüngliche Rechnung ausgleicht und zugleich einen neuen offenen Posten für den Restbetrag bucht, entsteht ein Restposten. Dies lässt sich anhand der Positionen des Ausgleichsbelegs feststellen.
Erfassung
Analysieren Sie Ausgleichsbelege (BKPF-AUGBL), um Fälle zu finden, in denen ein neuer offener Posten mit Bezug auf die ursprüngliche Rechnung erstellt wird.
Ereignistyp
inferred
|
|||
|
Streitfall erfasst
|
Dieses Ereignis steht für die formelle Erfassung eines Kundenstreitfalls zu einer Rechnung, etwa wegen einer Preis- oder Mengenabweichung. Es wird explizit im SAP-FSCM-Modul Dispute Management protokolliert. | ||
|
Warum das wichtig ist
Streitfälle halten den Zahlungsvorgang auf und binden interne Ressourcen für ihre Klärung. Die Erfassung des Streitfalls ist der erste Schritt, um die Bearbeitungsdauer, die Ursachen und die Auswirkungen auf die DSO zu analysieren.
Woher beziehen
Bei Verwendung von SAP FSCM Dispute Management wird dieses Ereignis explizit erfasst. Die Erstellung eines Streitfalls wird in Tabellen wie UDM_CASE oder SCMG_T_CASE_ATTR mit einem Erstellungs-Timestamp protokolliert.
Erfassung
Extrahieren Sie Datum und Uhrzeit der Erstellung aus den Fallmanagementtabellen, zum Beispiel UDM_CASE, für Fälle, die mit der Rechnung verknüpft sind.
Ereignistyp
explicit
|
|||
|
Streitfall geklärt
|
Der mit der Rechnung verbundene Streitfall wurde untersucht und eine Lösung gefunden. In SAP FSCM Dispute Management wird dies in der Regel durch eine Statusänderung des Streitfalls erfasst. | ||
|
Warum das wichtig ist
Die Klärung eines Streitfalls gibt den Zahlungsvorgang wieder frei. Die Zeit zwischen Erfassung und Klärung ist eine wichtige Kennzahl, um Ineffizienzen bei der Bearbeitung von Streitfällen aufzudecken.
Woher beziehen
Dieses Ereignis wird aus einer Statusänderung des Streitfalls abgeleitet. Änderungsbelege zum Statusfeld des Streitfalls in Tabellen wie UDM_CASE, etwa CDHDR/CDPOS, liefern den Timestamp.
Erfassung
Ermitteln Sie anhand der Änderungsbelege den Timestamp, zu dem der Status des Streitfalls auf 'Closed' oder 'Resolved' gesetzt wurde.
Ereignistyp
inferred
|
|||
|
Zahlungszusage erfasst
|
Ein Kunde hat die Abteilung für Forderungsmanagement kontaktiert und zugesagt, bis zu einem bestimmten Datum zu zahlen. Dieses Ereignis wird explizit protokolliert, wenn SAP FSCM Collections Management eingesetzt wird. | ||
|
Warum das wichtig ist
Zahlungszusagen sind ein wichtiges Ergebnis der Aktivitäten im Forderungsmanagement. Die Analyse ihrer Erfassung, Einhaltung und Nichterfüllung zeigt, wie wirksam die Maßnahmen der Sachbearbeitenden sind, und hilft, Zahlungseingänge vorherzusagen.
Woher beziehen
Bei Verwendung von SAP FSCM Collections Management wird dieses Ereignis explizit erfasst. Angaben zur Zahlungszusage werden in Tabellen wie UDM_P2P_ATTR gespeichert und mit dem Geschäftspartner und der Rechnung verknüpft.
Erfassung
Extrahieren Sie den Erstellungs-Timestamp aus Tabellen für Zahlungszusagen wie UDM_P2P_ATTR in SAP FSCM.
Ereignistyp
explicit
|
|||
|
Zahlungszusage nicht eingehalten
|
Dieses berechnete Ereignis zeigt an, dass ein Kunde eine vereinbarte Zahlung aus einer Zahlungszusage nicht bis zum festgelegten Datum geleistet hat. Es wird aus dem Ausbleiben einer entsprechenden Zahlung bis zum Zusagedatum abgeleitet. | ||
|
Warum das wichtig ist
Nicht eingehaltene Zahlungszusagen zu erkennen, ist entscheidend, um die Maßnahmen im Forderungsmanagement zu verstärken. Eine hohe Quote kann auf Probleme mit der Strategie oder auf eine angespannte finanzielle Lage der Kunden hindeuten.
Woher beziehen
Dieses Ereignis wird abgeleitet oder berechnet. Dazu wird das Zusagedatum aus UDM_P2P_ATTR mit dem tatsächlichen Ausgleichsdatum der Rechnung verglichen. Geht bis zum Zusagedatum keine Zahlung ein, gilt die Zusage als nicht eingehalten.
Erfassung
Vergleichen Sie das Zusagedatum in UDM_P2P_ATTR mit dem Ausgleichsdatum der Rechnung. Liegt das Ausgleichsdatum nach dem Zusagedatum, wurde die Zusage nicht eingehalten.
Ereignistyp
calculated
|
|||
Anleitungen zur Datenextraktion
Bereit für den Einstieg?
Verwenden Sie dieses Template, um die Datenaufbereitung zu vereinfachen und wertvolle Erkenntnisse zu Ihrem Kreditmanagement- und Forderungseinzug zu gewinnen. Verbessern Sie jetzt den Cashflow und senken Sie Risiken.
Schneller zu mehr Cashflow: Kreditmanagement und Forderungseinzug jetzt optimieren
Verkürzen Sie die Durchlaufzeit von der Kreditvergabe bis zum Zahlungseingang um 30 % und steigern Sie die Rentabilität.
Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.