Daten-Template: Kreditorenrechnungsverarbeitung

SAP S/4HANA
Daten-Template: Kreditorenrechnungsverarbeitung

Ihre Datenvorlage für die Rechnungsbearbeitung der Kreditorenbuchhaltung

Diese Vorlage ist Ihre kompakte Anleitung, um die erforderlichen Daten für die Analyse Ihrer Kreditoren‑Rechnungsverarbeitung zu sammeln. Sie beschreibt die wichtigsten Attribute und Aktivitäten, die Sie für ein belastbares Event Log benötigen. Zudem erhalten Sie praxisnahe Hinweise zur Extraktion aus Ihren Quellsystemen – für einen reibungslosen Start in Ihre Process‑Mining‑Analyse.
  • Empfohlene Attribute für eine umfassende Analyse
  • Die wichtigsten Prozessaktivitäten zur effektiven Nachverfolgung
  • Schritt-für-Schritt-Anleitung zur Datenextraktion
Neu bei Event Logs? Erfahren Sie wie man ein Process Mining Event Log erstellt.

Attribute der Kreditoren-Rechnungsverarbeitung

Dies sind die wesentlichen Datenfelder, die Sie in Ihr Event Log aufnehmen sollten, um Ihren Accounts‑Payable‑Prozess fundiert und aussagekräftig zu analysieren.
5 Erforderlich 6 Empfohlen 10 Optional
NameBeschreibung
Aktivität
ActivityName
Bezeichnung des konkreten Ereignisses bzw. Prozessschritts im Lebenszyklus der Rechnungsverarbeitung.
Beschreibung

Eine Activity steht für einen klar abgegrenzten Schritt im Kreditorenprozess, z. B. 'Invoice Received', 'Invoice Posted' oder 'Payment Executed'. Diese Schritte sind die Bausteine der Process Map.

Die Analyse der Activities ist der Kern von Process Mining: Sie macht den Prozessfluss sichtbar, zeigt häufige Pfade, erkennt Abweichungen vom Standard und misst Häufigkeit sowie Dauer der einzelnen Schritte. Die Abfolge der Activities für eine Rechnung bildet deren Prozessverlauf.

Warum es wichtig ist

Es definiert die Prozessschritte und ermöglicht, den Prozessfluss zu visualisieren und zu analysieren, Engpässe zu erkennen und Nacharbeitsschleifen aufzudecken.

Woher erhalten

Abgeleitet aus unterschiedlichen Quellen wie Belegstatusänderungen (z. B. BKPF‑BSTAT), Änderungsbelegen (Tabellen CDHDR/CDPOS) oder Workflow‑Logs. Dafür ist in der Regel eine kundenspezifische Extraktionslogik nötig.

Beispiele
Rechnung eingegangenRechnung freigegebenZahlung ausgeführtRechnung für Zahlung gesperrt
Ereigniszeit
EventTime
Das genaue Datum und die Uhrzeit, zu der die Aktivität stattgefunden hat.
Beschreibung

Event Time ist der Timestamp, der jeder Aktivität zugeordnet ist, und bildet die chronologische Abfolge der Events einer Rechnung ab. Diese Daten sind entscheidend, um den Prozessfluss zu verstehen und jede zeitbasierte Analyse durchzuführen.

In Analysen wird Event Time verwendet, um Aktivitäten korrekt zu sortieren, Durchlaufzeiten zwischen Schritten zu berechnen, Wartezeiten zu erkennen und die Prozessleistung über verschiedene Zeiträume hinweg zu bewerten (z. B. von Monat zu Monat). Sie ist die Grundlage aller zeitbasierten KPIs.

Warum es wichtig ist

Dieser Zeitstempel ist entscheidend, um Ereignisse chronologisch zu ordnen und alle zeitbasierten Kennzahlen zu berechnen – etwa Durchlaufzeiten –, die für Process Mining grundlegend sind.

Woher erhalten

Stammt aus verschiedenen Datums-/Zeitfeldern in SAP-Tabellen, z. B. Anlagedatum (BKPF-CPUDT), Buchungsdatum (BKPF-BUDAT), Ausgleichsdatum (BSAK-AUGDT) oder Zeitstempel aus dem Änderungsprotokoll (CDHDR-UDATE/UTIME).

Beispiele
2023-10-01T09:00:00Z2023-10-05T14:30:15Z2023-10-15T11:21:05Z
Rechnung
Invoice
Die eindeutige Kennung des Rechnungsbelegs – dient als primäre Case‑ID für den Accounts‑Payable‑Prozess.
Beschreibung

Die Rechnung ist das zentrale Objekt, das alle zugehörigen Aktivitäten vom Eingang bis zur Zahlung verbindet. In SAP S/4HANA besteht der Schlüssel in der Regel aus Buchungskreis (BUKRS), Belegnummer (BELNR) und Geschäftsjahr (GJAHR).

Die Analyse auf Rechnungsebene ermöglicht einen vollständigen End‑to‑End‑Blick auf den Rechnungslebenszyklus. Das ist die Basis für Kennzahlen wie die Gesamtdurchlaufzeit, das Erkennen von Engpässen bei einzelnen Rechnungen und das Verständnis der unterschiedlichen Pfade, die eine Rechnung im Prozess nehmen kann.

Warum es wichtig ist

Es identifiziert den Verlauf jeder Rechnung eindeutig, sodass ihr kompletter Lebenszyklus nachverfolgt und die Prozessleistung fallbezogen analysiert werden kann.

Woher erhalten

Dies ist ein zusammengesetzter Schlüssel aus den Tabellen BKPF (Belegkopf Buchhaltungsbeleg) bzw. RBKP (Belegkopf: Rechnungseingang) mit den Feldern BUKRS, BELNR und GJAHR.

Beispiele
1000-1900000001-20231710-1900000002-20232000-5100000003-2024
Letzte Datenaktualisierung
LastDataUpdate
Der Zeitstempel, der angibt, wann die Daten für diesen Datensatz zuletzt aus dem Quellsystem aktualisiert wurden.
Beschreibung

Dieses Attribut enthält Datum und Uhrzeit der letzten Datenextraktion bzw. der letzten Aktualisierung aus SAP S/4HANA. Es ist ein Metadatenfeld und entscheidend, um die Aktualität der analysierten Daten einzuschätzen.

Diese Information zeigt Anwender:innen, wie aktuell die Prozessanalyse ist. Sie hilft, Erwartungen zur Datenlatenz zu steuern, unterstützt die Planung von Datenaktualisierungen und ist wichtig für die Sicherung der Datenintegrität.

Warum es wichtig ist

Kennzeichnet die Aktualität der Daten, damit Nutzer sehen, wie aktuell ihre Prozessanalyse ist.

Woher erhalten

Dieser Wert wird zum Zeitpunkt der Datenextraktion aus dem Quellsystem erzeugt und in jedem Datensatz vermerkt.

Beispiele
2024-05-20T04:00:00Z2024-05-21T04:00:00Z
Quellsystem
SourceSystem
Das System, aus dem die Daten extrahiert wurden.
Beschreibung

Dieses Attribut kennzeichnet die Herkunft der Prozessdaten. In dieser Ansicht lautet der Wert in der Regel 'SAP S/4HANA'.

In Umgebungen mit mehreren ERPs oder integrierten Systemen ist dieses Feld für Data Lineage und die Trennung von Datenbeständen wichtig. Es stellt sicher, dass die Analyse auf dem richtigen Datensatz erfolgt, und hilft, Datenqualitätsprobleme bis zur Quelle nachzuvollziehen.

Warum es wichtig ist

Ermittelt die Herkunft der Daten – entscheidend für Data Governance, Troubleshooting und in Multi‑System‑Umgebungen.

Woher erhalten

In der Regel ein statischer Wert, der bei der Datenextraktion vergeben wird, um die Herkunft des Datensatzes zu kennzeichnen.

Beispiele
SAP S/4HANASAP ECC 6.0S4H_PROD_100
Benutzername
UserName
Die User‑ID der Person, die die Aktivität ausgeführt hat.
Beschreibung

Dieses Attribut erfasst die SAP‑Benutzer‑ID der Person, die eine Aktivität wie das Buchen, Genehmigen oder Ausgleichen einer Rechnung ausführt. So lassen sich Prozessschritte einzelnen Benutzer:innen zuordnen.

Auswertungen nach Benutzernamen sind wichtig, um die Arbeitslast zu verstehen, Leistungsträger:innen zu erkennen und Schulungsbedarf zu identifizieren. In Dashboards ist es zudem zentral, Genehmigungsengpässe sichtbar zu machen und die Genehmiger:innen zu finden, die Verzögerungen verursachen.

Warum es wichtig ist

Ordnet Aktivitäten bestimmten Personen zu und ermöglicht Analysen zu Bearbeiterleistung, Auslastung und der Einhaltung der Funktionstrennung.

Woher erhalten

Typischerweise in Kopftabellen wie BKPF-USNAM (Erfasst von) oder in der Änderungsbelegtabelle CDHDR-USERNAME (Geändert von) zu finden.

Beispiele
ABROWNJSMITHAP_AUTOMATION
Bestellnummer
PurchaseOrderNumber
Die eindeutige Kennung der mit der Rechnung verknüpften Bestellung (falls vorhanden).
Beschreibung

Dieses Attribut verknüpft eine Rechnung mit einer vorab genehmigten Bestellung (PO). Das Vorhandensein einer PO‑Nummer ist die Grundlage für den 3‑Way‑Match (PO–Rechnung–Wareneingang).

Es ist ein zentrales Attribut für Compliance‑ und Effizienzanalysen. Damit wird die KPI 'Anteil Rechnungen ohne PO' berechnet, die die Einhaltung von Beschaffungsrichtlinien misst. Zudem ist es grundlegend für das Dashboard '3‑Way‑Match Performance', um den Abgleichprozess für PO‑gestützte Rechnungen zu analysieren.

Warum es wichtig ist

Wichtig, um die Effizienz des 3‑Wege‑Abgleichs (3‑Way‑Match) zu bewerten und die Einhaltung der Beschaffungsrichtlinien zu messen, indem Rechnungen ohne Bestellbezug (PO) identifiziert werden.

Woher erhalten

Zu finden in den Rechnungspositionstabellen, z. B. RSEG‑EBELN (für MM‑Rechnungen) oder BSEG‑EBELN (für FI‑Rechnungen).

Beispiele
45000012344500005678
Buchungskreis
CompanyCode
Die Organisationseinheit, für die die Rechnung bearbeitet wird.
Beschreibung

Ein Buchungskreis ist die kleinste Organisationseinheit, für die ein in sich abgeschlossenes Rechnungswesen für die externe Berichterstattung geführt wird. Im AP-Kontext steht er für die juristische Einheit, die dem Lieferanten Geld schuldet.

Die Analyse nach Buchungskreis ermöglicht den Vergleich der Prozessleistung über verschiedene Rechtseinheiten hinweg. So wird sichtbar, welche Bereiche Standardprozesse einhalten und wo höhere Effizienz, längere Durchlaufzeiten oder erhöhte Nacharbeitsquoten vorliegen.

Warum es wichtig ist

Ermöglicht den Leistungsvergleich des Prozesses über verschiedene Gesellschaften hinweg und hilft, regionale bzw. bereichsspezifische Probleme und Best Practices zu erkennen.

Woher erhalten

Zu finden in Belegkopftabellen, insbesondere BKPF‑BUKRS für FI‑Rechnungen und RBKP‑BUKRS für MM‑Rechnungen.

Beispiele
10001710US01DE01
Lieferantenname
VendorName
Name des Lieferanten, der die Rechnung eingereicht hat.
Beschreibung

Dieses Attribut enthält den offiziellen Namen des Lieferanten. Die Verknüpfung erfolgt über die auf dem Rechnungsbeleg hinterlegte Lieferantennummer.

Die Lieferantenanalyse ist entscheidend für das Lieferantenmanagement und um prozessuale Auffälligkeiten bei bestimmten Lieferanten zu erkennen. Sie beantwortet Fragen wie: 'Welche Lieferanten reichen die meisten Rechnungen mit Abweichungen ein?' oder 'Zahlen wir strategisch wichtige Lieferanten konsequent pünktlich?'. Zusammen mit Rechnungsnummer und -betrag ist dies zudem ein zentrales Feld zur Identifikation potenzieller Doppelzahlungen.

Warum es wichtig ist

Ermöglicht die Analyse der Prozessleistung je Lieferant, identifiziert problematische Lieferanten und unterstützt das effektive Management strategischer Lieferantenbeziehungen.

Woher erhalten

Aus der Kreditoren-Stammdatentabelle LFA1 (Feld NAME1) über die Kreditorennummer (LIFNR) verknüpft, wie sie in BKPF oder RBKP hinterlegt ist.

Beispiele
Office Supplies Inc.Global Consulting GroupMachine Parts GmbH
Rechnungsbetrag
InvoiceAmount
Der Bruttogesamtbetrag der Rechnung in der ursprünglichen Belegwährung.
Beschreibung

Dies ist der Gesamtwert der vom Lieferanten eingereichten Rechnung. Er umfasst Waren‑ bzw. Dienstleistungskosten, Steuern und weitere Gebühren – vor Abzügen oder Skonti.

Der Rechnungsbetrag ist ein zentrales Finanzattribut für vielfältige Analysen. Er hilft, Rechnungen mit hohem Betrag zu priorisieren, die finanziellen Auswirkungen von Prozessverzögerungen zu bewerten (z. B. Säumnisgebühren bei großen Beträgen) und den Prozess zu segmentieren (z. B. 'Folgen Rechnungen mit hohem Betrag einem anderen Genehmigungsweg?'). Außerdem ist er essenziell, um mögliche Doppelzahlungen zu finden.

Warum es wichtig ist

Liefert finanziellen Kontext zum Prozess, ermöglicht wertbasierte Analysen, die Priorisierung von Rechnungen mit hohem Betrag und die Quantifizierung finanzieller Auswirkungen.

Woher erhalten

Zu finden in Tabellen wie RBKP‑RMWWR (Bruttorechnungsbetrag) für MM‑Rechnungen oder aus Positionen in BSEG (Feld WRBTR) für FI‑Rechnungen berechnet.

Beispiele
1500.00250.7512345.50
Rechnungsfälligkeitsdatum
InvoiceDueDate
Das Datum, bis zu dem die Rechnung zu zahlen ist.
Beschreibung

Das Fälligkeitsdatum der Rechnung ist die Zahlungsfrist an den Lieferanten – wichtig, um Säumniszuschläge zu vermeiden und die Lieferantenbeziehung zu pflegen. Es wird aus dem Basisdatum der Rechnung und den mit dem Lieferanten vereinbarten Zahlungsbedingungen berechnet.

Dieses Datum ist zentral für das Dashboard 'Zahlungskompliance & Altersstruktur' sowie die KPI 'Quote pünktlicher Zahlungen'. Durch den Vergleich von Fälligkeit und tatsächlichem Zahlungsdatum zeigt die Analyse, ob Zahlungen pünktlich, frühzeitig oder verspätet erfolgen – mit direkten finanziellen Auswirkungen und Effekten auf die Geschäftsbeziehung.

Warum es wichtig ist

Dies ist der zentrale Treiber für die Analyse pünktlicher Zahlungen. So lässt sich die Zahlungstreue messen und deren Einfluss auf Lieferantenbeziehungen sowie Säumnisgebühren bewerten.

Woher erhalten

Dieses Datum wird häufig berechnet. Das Nettofälligkeitsdatum steht im Feld BSEG-NETDT. Es kann auch aus dem Basisdatum für die Zahlung (BSEG-ZFBDT) und den Zahlungsbedingungen (BSEG-ZTERM) abgeleitet werden.

Beispiele
2023-10-312023-11-152024-01-10
Ausgleichsdatum
ClearingDate
Das Datum, an dem die Zahlung erfolgte und die Rechnung aus den offenen Posten ausgebucht wurde.
Beschreibung

Das Clearing-Datum kennzeichnet den finanziellen Ausgleich der Rechnung. Es ist das Datum der Activity 'Payment Cleared' und markiert für die meisten erfolgreichen Rechnungsverläufe den letzten Schritt.

Dieses Datum dient zur Ermittlung des tatsächlichen Zahlungsdatums für den Vergleich mit dem Fälligkeitsdatum der Rechnung. Es ist daher essenziell für die KPI 'On‑Time Payment Rate' und für alle Analysen zur Zahlungspünktlichkeit. Zugleich markiert es den Endpunkt für die Berechnung der End‑to‑End‑Durchlaufzeit.

Warum es wichtig ist

Kennzeichnet den endgültigen Ausgleich einer Rechnung, dient als Endpunkt für Durchlaufzeit-Berechnungen und als Basis für die Pünktlichkeitsanalyse von Zahlungen.

Woher erhalten

Zu finden in den Tabellen für ausgeglichene Posten, z. B. BSAK‑AUGDT bei Kreditoren.

Beispiele
2023-10-282023-11-142024-01-09
Bearbeitungszeit
ProcessingTime
Die Dauer einer einzelnen Aktivität.
Beschreibung

Processing Time bzw. Aktivitätsdauer ist die Zeitspanne zwischen Start und Ende einer Aktivität. Sie wird aus den Event-Log-Daten berechnet.

Diese Kennzahl ist zentral für das Dashboard 'Activity Duration & Rework Heatmap' und hilft zu erkennen, welche konkreten Schritte im Prozess am meisten Zeit binden. Die Analyse der Bearbeitungszeiten deckt Ineffizienzen auf – etwa lange Freigaben oder aufwendige Klärungen – und lenkt gezielte Verbesserungsmaßnahmen.

Warum es wichtig ist

Quantifiziert die Zeit pro Aktivität und hilft, die zeitintensivsten Schritte und Engpässe im Prozess zu identifizieren.

Woher erhalten

Berechnet als Differenz zwischen der EventTime der aktuellen Aktivität und der EventTime der nachfolgenden Aktivität derselben Rechnung.

Beispiele
P2DT3H4MPT5HP7D
Ist automatisiert
IsAutomated
Kennzeichen, ob die Aktivität automatisch durch das System statt durch einen Benutzer ausgeführt wurde.
Beschreibung

Dieses boolesche Attribut unterscheidet zwischen manuell angestoßenen Aktivitäten und Schritten, die von System‑Jobs, Workflows oder Bots ausgeführt werden. Beispielsweise würden ein automatischer Zahlungslauf oder eine systemgenerierte Rechnungsbuchung als automatisiert gekennzeichnet.

Die Analyse dieses Attributs zeigt den Automatisierungsgrad im Prozess der Kreditorenbuchhaltung. Sie hilft, den Erfolg von Automatisierungsinitiativen zu messen, die Effizienz automatisierter gegenüber manuellen Schritten zu vergleichen und weitere Automatisierungspotenziale zu identifizieren.

Warum es wichtig ist

Hilft, den Automatisierungsgrad im Prozess zu messen, die Wirksamkeit zu analysieren und Potenziale für weitere Verbesserungen zu identifizieren.

Woher erhalten

Abgeleitet anhand des Benutzernamens (z. B. System‑User‑IDs wie 'SAP_SYSTEM' oder 'BATCHUSER') oder bestimmter Transaktionscodes, die automatisierten Jobs zugeordnet sind.

Beispiele
truefalsch
Ist verspätete Zahlung
IsLatePayment
Kennzeichen, das angibt, ob die Rechnung nach Fälligkeit bezahlt wurde.
Beschreibung

Dieses berechnete Attribut ist ein simples Ja/Nein‑Kennzeichen und zeigt, ob die Zahlung einer Rechnung nach dem offiziellen Fälligkeitsdatum erfolgte. Grundlage ist der Vergleich von 'Clearing Date' und 'Invoice Due Date'.

Dieses Kennzeichen vereinfacht die Auswertung im Dashboard 'Payment Compliance & Aging' sowie für den KPI 'On‑Time Payment Rate'. So lassen sich verspätete Zahlungen einfach zählen, der Anteil pünktlicher Zahlungen berechnen und Lieferanten oder Buchungskreise mit hohen Verspätungsquoten identifizieren.

Warum es wichtig ist

Misst direkt die Einhaltung von Zahlungszielen, erleichtert die Berechnung der On‑Time‑Payment‑KPI und zeigt Bereiche mit schwacher Zahlungstreue auf.

Woher erhalten

Berechnetes Attribut. Logik: IF ClearingDate > InvoiceDueDate THEN true ELSE false.

Beispiele
truefalsch
Lieferantenrechnungsnummer
VendorInvoiceNumber
Die vom Lieferanten auf der Rechnung angegebene Rechnungsnummer.
Beschreibung

Dies ist die Referenznummer aus dem Buchhaltungssystem des Lieferanten, wie sie auf der physischen oder elektronischen Rechnung steht. Sie wird bei Rechnungseingang manuell erfasst oder per OCR übernommen.

Dieses Feld ist im Betrieb und in der Analyse äußerst wichtig, insbesondere für das Dashboard 'Potential Duplicate Invoice Payments'. Ein gängiger Ansatz zur Erkennung von Dubletten ist die Suche nach mehreren internen Rechnungsbelegen mit identischem Lieferantennamen, Lieferanten‑Rechnungsnummer und Rechnungsbetrag. Es ist die wichtigste externe Referenz einer Rechnung.

Warum es wichtig ist

Es ist ein zentrales Feld, um mögliche Doppelzahlungen zu erkennen, und dient als wichtigste externe Referenz in der Kommunikation mit Lieferanten.

Woher erhalten

Gespeichert im Feld 'Referenz' des Belegkopfs, typischerweise BKPF-XBLNR.

Beispiele
INV-2023-9876733401120231015-001
Rechnungsbelegart
InvoiceDocumentType
Eine Klassifizierung des Rechnungsdokuments, die steuert, wie es in SAP verarbeitet wird.
Beschreibung

Die Belegart ist ein zentrales Konfigurationselement in SAP und kategorisiert Buchhaltungsbelege. Beispielsweise steht 'KR' üblicherweise für Kreditorenrechnungen, 'RE' für MM‑Rechnungen und 'KG' für Lieferantengutschriften. Die Belegart steuert unter anderem den Nummernkreis und welche Felder verpflichtend sind.

In der Prozessanalyse ermöglicht das Filtern nach Belegart den Vergleich der Prozessverläufe unterschiedlicher Rechnungstypen. So kann etwa der Freigabeprozess für eine Gutschrift anders aussehen als für eine Standardrechnung. Das ist besonders hilfreich für das Dashboard 'Varianten der Rechnungsfreigabewege'.

Warum es wichtig ist

Ermöglicht die Segmentierung des Prozesses je nach Behandlung unterschiedlicher Rechnungstypen und macht Abweichungen in Prozesspfaden und Durchlaufzeiten sichtbar.

Woher erhalten

Direkt aus der Belegkopftabelle, Feld BKPF‑BLART.

Beispiele
KRREKG
Rechnungswährung
InvoiceCurrency
Der Währungscode für den Rechnungsbetrag (z.B. USD, EUR).
Beschreibung

Dieses Attribut gibt die Währung an, in der der Rechnungsbetrag ausgewiesen ist. Es liefert wichtigen Kontext für alle finanziellen Werte.

In internationalen Organisationen kann eine Analyse ohne Berücksichtigung der Währung in die Irre führen. Dieses Feld ermöglicht eine saubere Handhabung der Finanzdaten – entweder durch Umrechnung in eine einheitliche Berichtswährung oder durch eine segmentierte Analyse nach Währung, um regionale Aktivitäten besser zu verstehen.

Warum es wichtig ist

Liefert den notwendigen Kontext zum Rechnungsbetrag und ermöglicht präzise Finanzanalysen und Berichte – insbesondere in internationalen Umgebungen.

Woher erhalten

Zu finden in Belegkopftabellen, insbesondere BKPF‑WAERS oder RBKP‑WAERS.

Beispiele
USDEURGBPJPY
Skonto gezogen
DiscountTaken
Kennzeichen, das angibt, ob ein Skonto erfolgreich gezogen wurde.
Beschreibung

Dieses Attribut zeigt an, ob beim Bezahlen der Rechnung tatsächlich Skonto gezogen wurde. Es ist ein zentraler Baustein zur Messung der finanziellen Effizienz im AP‑Prozess.

Dieses Flag ist der Kern der KPI 'Skonto‑Nutzungsquote'. Indem man auf Rechnungen filtert, bei denen Skonto möglich war (gemäß Zahlungsbedingungen), und dann dieses Flag auswertet, lässt sich genau berechnen, wie viel Geld gespart und wie viele Sparchancen verpasst wurden. Das liefert eine klare, quantifizierbare Messgröße für die Leistung der Kreditorenbuchhaltung.

Warum es wichtig ist

Misst direkt, wie erfolgreich verfügbare Skonti genutzt werden – mit unmittelbarem Effekt auf das Ergebnis.

Woher erhalten

Abgeleitet, indem geprüft wird, ob das Feld für den Skontobetrag (BSEG‑SKNTO) im Zahlungsbeleg größer als Null ist.

Beispiele
truefalsch
Sperrgrund
BlockingReason
Der Grund für den Zahlungsblock einer Rechnung – ein Hinweis auf eine Abweichung.
Beschreibung

Schlägt eine Rechnung bei der Prüfung im 3‑Way‑Match oder in anderen Kontrollschritten fehl, wird sie für die Zahlung gesperrt. Der Sperrgrund beschreibt die Art des Problems, etwa Mengenabweichung, Preisabweichung oder fehlender Wareneingang.

Dieses Attribut ist zentral für das Dashboard 'Invoice Discrepancy Rework Analysis'. Die Analyse der Häufigkeit einzelner Sperrgründe hilft, die Ursachen von Prozessineffizienzen zu erkennen. Häuft sich beispielsweise der Sperrgrund 'Preisabweichung', deutet das auf Probleme in den Stammdaten des Einkaufs hin.

Warum es wichtig ist

Bietet direkten Einblick in die Ursachen von Rechnungsabweichungen sowie Nacharbeit und ermöglicht gezielte Prozessverbesserungen.

Woher erhalten

Gespeichert in Tabellen der Rechnungspositionen wie RSEG, in Feldern beginnend mit SPGR* (z. B. SPGRP, SPGRQ, SPGRT). Auch in RBKP_BLOCKED zu finden.

Beispiele
PreisabweichungMengenabweichungFehlender Wareneingang
Zahlungsbedingungen
PaymentTerms
Die mit dem Lieferanten vereinbarten Zahlungsbedingungen, häufig einschließlich Skonto.
Beschreibung

Zahlungsbedingungen definieren Fälligkeiten und mögliche Skonti. Beispiel: Eine Bedingung wie 'Z001' kann 'zahlbar innerhalb von 30 Tagen, 2 % Skonto bei Zahlung innerhalb von 10 Tagen' bedeuten.

Dieses Attribut ist die Grundlage für das Dashboard 'Skonto-Nutzungsrate'. Durch die Analyse der Zahlungsbedingungen lassen sich alle skontofähigen Rechnungen identifizieren. Der Vergleich mit tatsächlich gezogenen Skonti zeigt verpasste Einsparungen und misst die Effizienz des Zahlungsprozesses.

Warum es wichtig ist

Es ist entscheidend, um Skonto-Chancen zu analysieren, die Leistung des Zahlungsprozesses zu messen und verpasste Einsparpotenziale zu erkennen.

Woher erhalten

Zu finden in Kreditorenposten, Tabelle BSEG‑ZTERM, oder im Rechnungskopf in RBKP‑ZTERM.

Beispiele
Z0010001NT30
Erforderlich Empfohlen Optional

Aktivitäten der Kreditoren-Rechnungsverarbeitung

Dies sind die zentralen Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten, um den Prozess präzise zu erfassen und zu optimieren.
7 Empfohlen 8 Optional
AktivitätBeschreibung
Rechnung eingegangen
Diese Aktivität kennzeichnet die Anlage eines Rechnungsbelegs in SAP – manuell oder über eine automatisierte Schnittstelle wie OCR/VIM. Dieses Event wird typischerweise über das Anlagedatum und die -uhrzeit des Belegkopfs erfasst.
Warum es wichtig ist

Als Startpunkt des Prozesses ist diese Aktivität entscheidend, um die End‑to‑End‑Durchlaufzeit von Rechnungen zu berechnen und den Durchsatz des gesamten Kreditorenprozesses zu messen.

Woher erhalten

Dieses Ereignis wird aus der Kopftabelle des Buchungsbelegs (BKPF) ermittelt – anhand des Anlagedatums (CPUDT) und der Uhrzeit (CPUTM).

Erfassen

Verwenden Sie den Erstellungszeitstempel (BKPF-CPUDT, BKPF-CPUTM) für das Rechnungsdokument.

Ereignistyp explicit
Rechnung freigegeben
Die Rechnung hat im Workflow alle erforderlichen Freigaben erhalten. Das ist oft der letzte Schritt, bevor eine Rechnung gebucht oder für die Zahlung entsperrt werden kann.
Warum es wichtig ist

Dieser Meilenstein markiert das Ende des Genehmigungszyklus. Die Zeit zwischen Weiterleitung und Genehmigung ist eine zentrale Effizienzkennzahl.

Woher erhalten

Aus den SAP Business Workflow‑Logs als Abschluss- oder endgültiger Freigabeschritt übernommen. Alternativ lässt es sich aus der Aufhebung einer Zahlungssperre nach dem Routing ableiten.

Erfassen

Extrahieren Sie Workflow‑Abschluss‑Events aus den SAP‑Workflow‑Logs oder identifizieren Sie das finale 'release'-Event.

Ereignistyp explicit
Rechnung für Zahlung gesperrt
Das System hat automatisch oder manuell einen Zahlungsblock auf die Rechnung gesetzt und verhindert damit die Zahlung. Typische Ursachen sind Preis‑ oder Mengenabweichungen oder fehlende Freigaben.
Warum es wichtig ist

Dies ist ein zentraler Indikator für Probleme und Nacharbeit. Die Analyse von Sperrgründen und -dauern hilft, die Ursachen von Zahlungs­verzögerungen und Prozessineffizienzen aufzudecken.

Woher erhalten

Dies ist ein expliziter Status im Feld Zahlungssperrschlüssel (ZLSPR) auf der Kreditorenzeile des Buchungsbelegs (Tabelle BSEG).

Erfassen

Über Änderungsbelege protokolliert, wenn das Feld BSEG-ZLSPR mit einem Sperrgrund gefüllt ist.

Ereignistyp explicit
Rechnung gebucht
Die Rechnung wird im Hauptbuch verbucht und begründet damit eine Verbindlichkeit. Ein geparkter Beleg wird zum gebuchten Beleg – oder es erfolgt eine Direktbuchung.
Warum es wichtig ist

Das ist ein wichtiger finanzieller Meilenstein. Er bestätigt die Zahlungsverpflichtung des Unternehmens und ist oft Voraussetzung, um Zahlungen einzuplanen.

Woher erhalten

Dieses Ereignis wird über das Buchungsdatum (BUDAT) im Belegkopf (BKPF) identifiziert. Ein gebuchter Beleg hat im Feld Belegstatus (BKPF-BSTAT) keinen Eintrag.

Erfassen

Verwenden Sie das Buchungsdatum (BKPF-BUDAT) für Belege, die nicht geparkt sind (BKPF-BSTAT ist leer).

Ereignistyp explicit
Rechnung storniert
Der Rechnungsbeleg wurde storniert; seine finanzielle Wirkung ist damit aufgehoben. Dies ist ein alternativer Endzustand des Prozesses, häufig aufgrund von Falscherfassungen oder Streitfällen mit Lieferanten.
Warum es wichtig ist

Das Nachverfolgen von Stornierungen hilft, Ursachen für Prozessfehler zu erkennen – etwa doppelte Einreichungen oder falsche Rechnungsdaten – und damit vorgelagerte Probleme sichtbar zu machen.

Woher erhalten

Dies wird explizit erfasst, wenn ein Stornobeleg angelegt wird. Im ursprünglichen Belegkopf (BKPF) sind die Stornobelegnummer (STBLG) und der Stornogrund ausgefüllt.

Erfassen

Ermitteln Sie das Buchungsdatum des Stornobelegs, der im Kopf des Originalbelegs verknüpft ist (BKPF‑STBLG).

Ereignistyp explicit
Zahlung ausgeführt
Gegen die Rechnung wurde eine Zahlung geleistet. Dies wird erfasst, wenn der Zahlungslauf abgeschlossen ist und ein Zahlungsbeleg erstellt und gebucht wurde.
Warum es wichtig ist

Diese Aktivität ist zentral für die Cashflow‑Analyse und die Messung der KPI 'Quote pünktlicher Zahlungen', indem dieses Datum mit dem Fälligkeitsdatum der Rechnung verglichen wird.

Woher erhalten

Dies wird über das Buchungsdatum des Zahlungsbelegs ermittelt, mit dem die Rechnung ausgeglichen wurde. Die Nummer des Zahlungsbelegs ist im Feld Ausgleichsbeleg (AUGBL) der Rechnungszeile (BSEG) verknüpft.

Erfassen

Ermitteln Sie das Buchungsdatum (BUDAT) des Zahlungsbelegs, der die Rechnungsposition ausgleicht.

Ereignistyp explicit
Zahlung freigegeben
Diese Aktivität markiert den finalen Abschluss der Rechnung: Zahlung und Rechnung werden im Nebenbuch miteinander abgeglichen. Damit ist der Prozess beendet.
Warum es wichtig ist

Als klarer Prozessabschluss ist diese Aktivität unerlässlich für die korrekte End-to-End-Durchlaufzeitberechnung. Sie bestätigt, dass die Verbindlichkeit ausgeglichen ist.

Woher erhalten

Dies ist ein explizites Ereignis, erkennbar daran, dass das Ausgleichsdatum (AUGDT) auf der Kreditorenzeile des Rechnungsbelegs (Tabelle BSEG) ausgefüllt ist.

Erfassen

Verwenden Sie das Ausgleichsdatum (BSEG-AUGDT) aus der Rechnungsposition.

Ereignistyp explicit
Abweichung behoben
Diese Aktivität zeigt, dass ein zuvor festgestelltes Problem – oft Ursache eines Zahlungsblocks – geprüft und gelöst wurde. Erfasst wird dies, wenn der Zahlungsblock auf einer Rechnung aufgehoben wird.
Warum es wichtig ist

Das Nachverfolgen dieser Nacharbeitsschleife ist zentral für das Dashboard 'Invoice Discrepancy Rework Analysis'. So lassen sich Zeit und Aufwand für die Fehlerbehebung quantifizieren.

Woher erhalten

Dies wird aus Änderungsbelegen abgeleitet, die die Aufhebung einer Zahlungssperre zeigen. Primäre Quelle ist das Änderungsprotokoll zum Feld BSEG-ZLSPR.

Erfassen

Identifizieren Sie Änderungsbelege für Tabelle BSEG, bei denen das Feld ZLSPR von einem Wert auf leer geändert wurde.

Ereignistyp inferred
Bestellung abgeglichen
Diese Aktivität zeigt, dass die Rechnung erfolgreich einer passenden Bestellung zugeordnet wurde. Das ist ein zentraler Schritt im 3‑Way‑Match für beschaffungsbezogene Rechnungen.
Warum es wichtig ist

Die Analyse dieser Aktivität misst die Effizienz des Abgleichs und ist grundlegend für die KPIs '3-Way Matching Performance' und 'PO-Less Invoice Percentage'.

Woher erhalten

Dies wird angenommen, wenn eine Rechnungszeile in BSEG oder ACDOCA eine gültige Bestellnummer (EBELN) und Position (EBELP) enthält.

Erfassen

Abgeleitet aus einem Bestellbezug (BSEG‑EBELN) im Rechnungsbeleg beim Anlegen.

Ereignistyp inferred
Fälligkeitsdatum der Rechnung überschritten
Ein berechnetes Event, das anzeigt, dass das Nettofälligkeitsdatum der Rechnung verstrichen ist, ohne dass eine Zahlung dagegen ausgeglichen wurde. Das weist auf eine verspätete bzw. überfällige Zahlung hin.
Warum es wichtig ist

Unverzichtbar für das 'Payment Compliance & Aging'-Dashboard: Diese Aktivität hilft, überfällige Rechnungen proaktiv zu identifizieren und zu steuern sowie die Ursachen verspäteter Zahlungen zu analysieren.

Woher erhalten

Dies ist kein explizites Ereignis in SAP. Es wird berechnet, indem das aktuelle Systemdatum mit dem Nettofälligkeitsdatum verglichen wird (abgeleitet aus BSEG-ZFBDT bzw. Basisdatum und Zahlungsbedingungen).

Erfassen

Berechnetes Event, das ausgelöst wird, wenn der Zeitstempel des Events nach dem Nettofälligkeitsdatum der Rechnung liegt.

Ereignistyp calculated
Rechnung abgelehnt
Ein Genehmiger hat die Rechnung im Freigabe-Workflow abgelehnt. In der Regel wird sie damit zur Korrektur oder Klärung an den Bearbeiter zurückgegeben.
Warum es wichtig ist

Das Nachverfolgen von Ablehnungen macht Nacharbeitsschleifen im Genehmigungsprozess sichtbar und kann auf Richtlinienverstöße oder fehlerhafte Kontierungen hinweisen.

Woher erhalten

Dies wird als konkretes Ergebnisereignis in den SAP Business Workflow‑Logs zur betreffenden Rechnung erfasst.

Erfassen

Extrahieren Sie Workflow‑Events mit dem Status 'rejected' aus den SAP‑Workflow‑Logs.

Ereignistyp explicit
Rechnung geparkt
Kennzeichnet eine Rechnung, die im System erfasst, jedoch noch nicht ins Hauptbuch gebucht wurde. Häufig wird so ein unvollständiges Dokument bewusst für spätere Bearbeitung oder Freigabe gespeichert.
Warum es wichtig ist

Das Nachverfolgen geparkter Rechnungen zeigt Verzögerungen auf, noch bevor der eigentliche Buchungsprozess beginnt, und macht Probleme bei Datenvollständigkeit oder der initialen Prüfung sichtbar.

Woher erhalten

Dieser Status wird aus dem Feld Belegstatus im Belegkopf (BKPF-BSTAT = 'V' für geparkt) abgeleitet. Das Ereignis tritt ein, sobald der Status gesetzt wird.

Erfassen

Identifizieren Sie Änderungsbelege für Tabelle BKPF, bei denen das Feld BSTAT auf "V" (vorerfasst/Pre‑entered) gesetzt ist.

Ereignistyp inferred
Rechnung zur Freigabe weitergeleitet
Die Rechnung wurde gemäß Geschäftsregeln in einen Workflow zur erforderlichen Freigabe übergeben. Damit beginnt der Freigabe‑Subprozess.
Warum es wichtig ist

Diese Aktivität bildet den Startpunkt zur Messung der KPI 'Durchschnittliche Freigabedauer von Rechnungen' und zur Analyse von Engpässen im Freigabeprozess.

Woher erhalten

Kann aus den SAP Business Workflow‑Logs (SWW*-Tabellen) übernommen werden, die den Start einer Workflow‑Instanz zum Rechnungsobjekt (z. B. BUS2081) protokollieren.

Erfassen

Extrahieren Sie Workflow‑Start‑Events aus den SAP‑Workflow‑Logs (z. B. Tabelle SWW_WIHEAD), die dem Rechnungsbeleg zugeordnet sind.

Ereignistyp explicit
Wareneingang abgeglichen
Diese Aktivität zeigt, dass Mengen und Werte der Rechnung erfolgreich mit dem zugehörigen Wareneingangsbeleg abgeglichen wurden. Das ist die abschließende Validierung im 3‑Way‑Match.
Warum es wichtig ist

Das Nachverfolgen dieses Schritts hilft, Ineffizienzen im 3‑Wege‑Abgleich aufzudecken und Abweichungen zwischen Wareneingang und der vom Lieferanten berechneten Leistung zu identifizieren.

Woher erhalten

Dies wird abgeleitet aus dem Verweis auf einen Materialbeleg (Wareneingang) in der Rechnungszeile, häufig über die Bestellpositionshistorie verknüpft.

Erfassen

Abgeleitet aus dem Vorhandensein eines Wareneingangsbezugs in der Rechnungsposition (z. B. in RSEG bei MIRO‑Rechnungen).

Ereignistyp inferred
Zahlungsvorschlag erstellt
Die Rechnung wurde im Rahmen eines Zahllaufs (z. B. F110) in den Zahlungsvorschlag aufgenommen. Sie ist für die Zahlung vorgesehen, vorbehaltlich der endgültigen Ausführung des Laufs.
Warum es wichtig ist

Diese Aktivität zeigt den Übergang von einer offenen Verbindlichkeit zu einem Posten, der aktiv für die Zahlung vorbereitet wird – hilfreich, um die Effizienz der Zahlungsabwicklung zu bewerten.

Woher erhalten

Dieses Ereignis ist in den Daten der Zahlungsläufe explizit protokolliert, konkret in REGUP (Verarbeitete Posten des Zahlungsprogramms) und REGUH (Kopf).

Erfassen

Ermitteln Sie, wann eine Rechnung in der Tabelle REGUP für einen in REGUH identifizierten Zahlungslauf erscheint.

Ereignistyp explicit
Empfohlen Optional

Extraktionsleitfäden

So holen Sie Ihre Daten aus SAP S/4HANA