Ihr Daten-Template für den Order-to-Cash-Prozess: Fakturierung und Rechnungsstellung
Ihr Daten-Template für den Order-to-Cash-Prozess: Fakturierung und Rechnungsstellung
- Empfohlene Attribute für die Datenerfassung
- Wichtige Aktivitäten für die Nachverfolgung
- Hinweise zur Datenextraktion aus SAP S/4HANA
Attribute für den Order-to-Cash-Prozess: Fakturierung und Rechnungsstellung
| Name | Beschreibung | ||
|---|---|---|---|
| Rechnungsnummer InvoiceNumber | Die eindeutige Kennung eines Fakturabelegs. Sie dient als primäre Case-ID für den Rechnungsstellungsprozess. | ||
| Beschreibung Die Rechnungsnummer, in SAP als Fakturabelegnummer bezeichnet, identifiziert jeden Fakturierungsvorgang eindeutig. Sie ist der zentrale Schlüssel, der alle zugehörigen Aktivitäten von der Rechnungserstellung und -buchung bis zum Zahlungseingang und -abgleich miteinander verknüpft. Im Process Mining ist dieses Attribut für die Zuordnung von Cases unverzichtbar. Alle Events mit derselben Rechnungsnummer werden zu einer Prozessinstanz zusammengefasst. So lässt sich der Fakturierungsprozess für jede einzelne Rechnung vollständig von Anfang bis Ende analysieren. Dadurch können Sie Zykluszeiten verfolgen, Abweichungen erkennen und den Ablauf jeder Rechnung nachvollziehen. Warum das wichtig ist Diese grundlegende Kennung fasst alle zugehörigen Fakturierungsaktivitäten in einem Case zusammen und ermöglicht so die End-to-End-Prozessanalyse. Woher beziehen SAP-Tabelle: VBRK, Feld: VBELN Beispiele 900012349000567890009012 | |||
| Aktivitätsname ActivityName | Der Name der geschäftlichen Aktivität oder des Events im Fakturierungsprozess, zum Beispiel „Rechnung erstellt“ oder „Zahlung eingegangen“. | ||
| Beschreibung Der Aktivitätsname bezeichnet einen bestimmten Schritt oder Meilenstein im Fakturierungsprozess. Die Aktivitäten werden aus verschiedenen Datenpunkten in SAP abgeleitet, etwa aus Transaktionscodes, Änderungen des Belegstatus oder bestimmten Protokolleinträgen. Daraus entsteht ein sequenzieller Prozessablauf. Die Analyse der Abfolge und Häufigkeit dieser Aktivitäten bildet den Kern des Process Mining. Sie hilft dabei, den Prozessablauf zu visualisieren, häufige und seltene Prozessvarianten zu erkennen, Engpässe zwischen Schritten aufzudecken und den Anteil nicht wertschöpfender Aktivitäten wie Nacharbeit oder Stornierungen zu messen. Warum das wichtig ist Dieses Attribut legt die Prozessschritte fest und ermöglicht die Visualisierung von Prozessabläufen sowie die Analyse von Prozessfluss, Varianten und Engpässen. Woher beziehen Abgeleitet aus verschiedenen Quellen, darunter Transaktionscodes (SY-TCODE), Änderungsbelegstatus (Tabellen CDHDR/CDPOS) oder Protokolle aus Geschäfts-Workflows (z. B. SWW_WI2OBJ). Beispiele Rechnung erstelltRechnung in der Finanzbuchhaltung gebuchtKundenzahlung eingegangenRechnung storniert | |||
| Event-Zeit EventTime | Der genaue Timestamp, der angibt, wann eine Aktivität oder ein Event stattgefunden hat. | ||
| Beschreibung Die Event-Zeit enthält Datum und Uhrzeit jeder Aktivität und bildet damit die chronologische Grundlage des Prozesses. Dieser Timestamp ist entscheidend für die Berechnung von Dauer, Zykluszeiten und Wartezeiten zwischen den einzelnen Schritten der Fakturierung. In der Analyse dient die Event-Zeit dazu, Aktivitäten chronologisch zu ordnen, wichtige Kennzahlen wie Days Sales Outstanding und die Zykluszeit der Rechnungserstellung zu berechnen und zeitabhängige Engpässe zu erkennen. Sie zeigt, wie sich die Prozessleistung im Zeitverlauf verändert und wie lange die einzelnen Phasen des Fakturierungszyklus dauern. Warum das wichtig ist Sie gibt die chronologische Abfolge der Events an. Das ist die Grundlage für alle zeitbasierten Kennzahlen, etwa Zykluszeiten und Dauer. Woher beziehen Je nach Aktivität aus verschiedenen Datums- und Zeitfeldern extrahiert, etwa aus Erstellungsdatum und -zeit (VBRK-ERDAT, VBRK-ERZET), Änderungs-Timestamps (CDHDR-UDATE, CDHDR-UTIME) oder dem Buchungsdatum (BKPF-BUDAT). Beispiele 2023-04-15T10:30:00Z2023-04-20T14:00:00Z2023-05-10T09:15:00Z | |||
| Benutzername UserName | Die Benutzer-ID des Mitarbeitenden, der die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut erfasst die SAP-Benutzer-ID, die für ein bestimmtes Event verantwortlich ist, etwa für die Erstellung einer Rechnung, die Buchung eines Belegs oder den Ausgleich einer Zahlung. So werden Prozessschritte mit den ausführenden Personen oder Teams verknüpft. Die Analyse nach Benutzernamen hilft dabei, leistungsstarke Mitarbeitende, Schulungsbedarf oder eine unausgewogene Arbeitsverteilung zu erkennen. Sie ist auch für die Compliance-Analyse wichtig, da sie zeigt, wer kritische Aktivitäten ausgeführt hat und wie unterschiedlich Benutzer denselben Prozess bearbeiten. Warum das wichtig ist Das Attribut verknüpft Prozessaktivitäten mit bestimmten Benutzern. So lassen sich Arbeitsbelastung, Leistung und Compliance auf Ebene einzelner Personen oder Teams analysieren. Woher beziehen Bei Erstellungs-Events steht die Benutzer-ID in VBRK-ERNAM. Für spätere Änderungen findet sie sich in Änderungshistorientabellen wie CDHDR-USERNAME oder in Workflow-Protokollen. Beispiele CBURNSHSIMPSONLLEONARD | |||
| Endzeit EndTime | Der genaue Timestamp, zu dem eine Aktivität oder ein Ereignis abgeschlossen wurde. | ||
| Beschreibung Die Endzeit kennzeichnet den Abschluss einer Aktivität. Beim Process Mining wird sie häufig aus der Startzeit der nachfolgenden Aktivität im Case abgeleitet. Alternativ kann sie direkt aus dem System stammen, wenn dieses sowohl Start- als auch Endereignisse protokolliert. Dieses Attribut ist für die Berechnung der Verarbeitungszeit einzelner Aktivitäten unverzichtbar. Wird die Startzeit von der Endzeit abgezogen, ergibt sich die Dauer des jeweiligen Schritts. Das ist wichtig für die Engpassanalyse, etwa um Verzögerungen bei der Rechnungsfreigabe zu erkennen. Warum das wichtig ist Damit lässt sich die genaue Dauer, also die Verarbeitungszeit, jeder Aktivität berechnen. Das ist eine wichtige Grundlage für die Engpassanalyse. Woher beziehen Dieses Attribut wird für das Process Mining abgeleitet. Üblicherweise entspricht es der Startzeit des nächsten Ereignisses in der Case-Sequenz. In manchen Fällen enthalten bestimmte Tabellen auch Abschlusszeiten. Beispiele 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| Kundenname CustomerName | Der Name des Kunden, an den die Rechnung ausgestellt wurde. | ||
| Beschreibung Dieses Attribut gibt den offiziellen Namen des Kunden an, dem die Rechnung gestellt wird. Die Daten stammen aus dem zentralen Kundenstamm in SAP. Die Analyse nach Kunden macht kontospezifische Muster sichtbar. Sie zeigt beispielsweise, welche Kunden regelmäßig verspätet zahlen, besonders häufig Reklamationen einreichen oder bei denen der Fakturierungsprozess besonders ineffizient ist. Das ermöglicht ein gezieltes Kundenbeziehungsmanagement und passende Strategien für den Forderungseinzug. Warum das wichtig ist Das Attribut ermöglicht eine kundenbezogene Analyse. So lassen sich Zahlungsverhalten, Häufigkeit von Reklamationen und Prozessineffizienzen für einzelne Kundenkonten erkennen. Woher beziehen Abgerufen aus der Kundenstammdatentabelle KNA1 (Feld: NAME1) und über die Zahler-ID im Rechnungskopf (VBRK-KUNRG) verknüpft. Beispiele Kraftwerk SpringfieldKwik-E-MartCyberdyne Systems | |||
| Rechnungsbetrag InvoiceAmount | Der Netto-Gesamtbetrag der Rechnung. | ||
| Beschreibung Dieses Attribut gibt den Gesamtwert der fakturierten Waren oder Dienstleistungen ohne Steuern an. Es ist eine grundlegende Finanzkennzahl für jeden Rechnungs-Case. Der Rechnungsbetrag fließt in zahlreiche Analysen ein. Er ermöglicht eine wertbasierte Segmentierung des Prozesses, etwa um zu prüfen, ob Rechnungen mit hohem Betrag anders bearbeitet werden oder häufiger Verzögerungen aufweisen. Außerdem bildet er die Grundlage für die Finanzberichterstattung und die Berechnung des Gesamtwerts offener Forderungen. Warum das wichtig ist Das Attribut beziffert den finanziellen Wert jeder Rechnung. So werden wertbasierte Analysen, die Priorisierung des Forderungseinzugs und die Bewertung finanzieller Auswirkungen möglich. Woher beziehen SAP-Tabelle: VBRK, Feld: NETWR Beispiele 1500.0025000.50125.75 | |||
| Rechnungsdatum InvoiceDate | Das offizielle Datum, an dem die Rechnung an den Kunden ausgestellt wurde. | ||
| Beschreibung Das Rechnungsdatum, in SAP auch Fakturadatum genannt, ist die Grundlage für viele finanzielle Berechnungen. Anhand dieses Datums werden Zahlungsbedingungen, Fälligkeitstermine und das Alter der Forderung bestimmt. Für die Finanzanalyse ist es ein wichtiges Attribut auf Case-Ebene. Es dient als Basis für die Berechnung der Kennzahl Days Sales Outstanding (DSO) und für Berichte zur Altersstruktur offener Rechnungen. Diese Berichte sind wichtige Werkzeuge für das Cashflow- und Forderungsmanagement. Warum das wichtig ist Das Rechnungsdatum ist die zentrale Grundlage für finanzielle Berechnungen, darunter DSO, Zahlungsfälligkeiten und die Analyse der Altersstruktur von Rechnungen. Woher beziehen SAP-Tabelle: VBRK, Feld: FKDAT Beispiele 2023-03-202023-04-012023-05-18 | |||
| Region Region | Die geografische Region des Kunden. | ||
| Beschreibung Das Attribut „Region“ gibt das geografische Gebiet, etwa einen Bundesstaat oder eine Provinz, an, das mit der Kundenadresse verknüpft ist. Diese Daten sind in der Regel Teil des Kundenstamms. Das Attribut ist wichtig für das Dashboard zur regionalen Fakturierungsleistung. Es ermöglicht den Vergleich wichtiger Kennzahlen wie Zykluszeiten, Fehlerquoten und DSO zwischen Regionen. So werden regionale Unterschiede bei der Prozessausführung, Compliance oder Effizienz sichtbar. Darauf aufbauend können Sie gezielte Verbesserungen umsetzen und bewährte Verfahren standardisieren. Warum das wichtig ist Das Attribut ermöglicht den Vergleich der Fakturierungsleistung zwischen geografischen Gebieten. So lassen sich regionale Unterschiede erkennen und Prozesse standardisieren. Woher beziehen Abgerufen aus der Kundenstammdatentabelle KNA1 (Feld: REGIO) und über die Zahler-ID im Rechnungskopf (VBRK-KUNRG) verknüpft. Beispiele CANYTXBA | |||
| Zahlungsziel PaymentDueDate | Das Datum, bis zu dem der Kunde die Rechnung voraussichtlich bezahlt. | ||
| Beschreibung Das Zahlungsziel wird anhand des Rechnungsdatums und der vereinbarten Zahlungsbedingungen berechnet. Es bezeichnet den letzten Tag, an dem die Zahlung eingehen kann, ohne dass die Rechnung überfällig wird. Dieses Attribut ist wichtig, um die Wirksamkeit des Forderungseinzugs zu überwachen und den Cashflow zu prognostizieren. Es fließt direkt in die Berechnung der Kennzahl für pünktliche Zahlungen ein und dient zur Einteilung von Rechnungen in Berichten zur Altersstruktur. Der Vergleich von Fälligkeitsdatum und tatsächlichem Zahlungsdatum zeigt, wie wirksam die verschiedenen Zahlungsbedingungen sind. Warum das wichtig ist Das Zahlungsziel legt die Frist für die Kundenzahlung fest. Es ist daher entscheidend für die Berechnung pünktlicher Zahlungen und das Forderungsmanagement. Woher beziehen Dieses Datum wird nicht direkt gespeichert, sondern anhand des Rechnungsdatums (VBRK-FKDAT) und des Zahlungsbedingungsschlüssels (VBRK-ZTERM) mit den standardmäßigen SAP-Funktionen zur Datumsermittlung berechnet. Beispiele 2023-04-192023-05-012023-06-17 | |||
| Buchungskreis CompanyCode | Die Organisationseinheit, für die der Geschäftsvorfall erfasst wird. | ||
| Beschreibung Der Buchungskreis ist eine grundlegende Organisationseinheit in SAP Financials. Er steht für ein rechtlich selbstständiges Unternehmen, für das Abschlüsse erstellt werden. Jeder Fakturabeleg ist einem bestimmten Buchungskreis zugeordnet. In Unternehmensgruppen mit mehreren Gesellschaften ist die Analyse nach Buchungskreis wichtig, um Prozessleistung, Finanzkennzahlen wie DSO und Compliance zwischen den rechtlichen Einheiten zu vergleichen. Der Buchungskreis dient als übergeordneter Organisationsfilter für alle Prozess-Dashboards. Warum das wichtig ist Damit lässt sich die Prozessanalyse nach rechtlicher Einheit aufschlüsseln. So können Leistungen verglichen und Finanzdaten unternehmensweit konsolidiert werden. Woher beziehen SAP-Tabelle: VBRK, Feld: BUKRS Beispiele 10002000US01 | |||
| Fakturabelegart BillingDocumentType | Ein Code zur Klassifizierung des Fakturabelegs, zum Beispiel als Rechnung, Gutschrift oder Stornierung. | ||
| Beschreibung Die Fakturabelegart ist ein wichtiges Feld zur Kategorisierung von Geschäftsvorfällen im Fakturierungsprozess. Sie steuert die Verarbeitung des Belegs, einschließlich Nummernkreis und Buchungsregeln. Mit diesem Attribut lässt sich der Prozess nach bestimmten Geschäftsvorfallarten filtern. So kann beispielsweise eine eigene Prozesssicht für Gutschriften erstellt werden, um deren Gründe und Ablauf bei finanziellen Korrekturen zu untersuchen. Standardrechnungen lassen sich getrennt von Stornierungen analysieren, um den regulären Fakturierungsprozess besser zu verstehen. Warum das wichtig ist Das Attribut klassifiziert Geschäftsvorfälle und ermöglicht eine gezielte Analyse bestimmter Belegflüsse, etwa von Standardrechnungen, Gutschriften oder Stornierungen. Woher beziehen SAP-Tabelle: VBRK, Feld: FKART Beispiele F2G2S1L2 | |||
| Gutschriftgrund CreditMemoReason | Der Ursachencode, der angibt, warum eine Gutschrift ausgestellt wurde. | ||
| Beschreibung Ist eine Rechnung fehlerhaft und muss gutgeschrieben werden, wird dem Gutschriftsbeleg üblicherweise ein Grund zugeordnet. So lassen sich die Ursachen von Fakturierungsfehlern systematisch kategorisieren. Dieses Attribut unterstützt direkt die Kennzahl zur Fehlerquote bei der Fakturierung. Durch die Zusammenfassung und Analyse der Gutschriftgründe kann ein Unternehmen die häufigsten Fehlerarten ermitteln, etwa Preisfehler oder Warenrücksendungen. Die Erkenntnisse helfen dabei, Prozesse zu verbessern und finanzielle Korrekturen sowie Nacharbeit zu reduzieren. Warum das wichtig ist Das Attribut kategorisiert die Gründe für Gutschriften. So lassen sich die häufigsten Ursachen von Fakturierungsfehlern ermitteln und gezielte Qualitätsverbesserungen anstoßen. Woher beziehen SAP-Tabelle: VBRK, Feld: AUGRU (Auftragsgrund). Dieses Feld wird für Gutschrifts- und Lastschriftanforderungen verwendet, die anschließend fakturiert werden. Beispiele 001 - Preisdifferenz002 - Mangelhafte Qualität005 - Kundenretoure | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp, der angibt, wann die Daten für dieses Event zuletzt extrahiert oder aktualisiert wurden. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit des letzten Datenabrufs aus dem Quellsystem. Als Metadatenfeld ist es wichtig, um die Aktualität der analysierten Daten einzuschätzen. Diese Information dient dazu, die Aktualität der Analyse zu prüfen und Datenaktualisierungen zu planen. So wissen die Beteiligten, wie aktuell die Daten sind, auf denen ihre Entscheidungen anhand der Process-Mining-Dashboards und Erkenntnisse beruhen. Warum das wichtig ist Das Attribut zeigt, wie aktuell die Daten sind. Das ist wichtig, um den Analyseergebnissen zu vertrauen und ihre Relevanz für den aktuellen Betriebszustand einzuschätzen. Woher beziehen Dieser Timestamp wird während der Datenextraktion und -ladung (ETL) erzeugt und jedem Datensatz hinzugefügt. Beispiele 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
| Pünktlich bezahlt IsPaidOnTime | Ein boolesches Kennzeichen, das angibt, ob die Rechnung am oder vor dem Fälligkeitstag bezahlt wurde. | ||
| Beschreibung Dieses berechnete Attribut vergleicht das tatsächliche Zahlungsdatum mit dem vereinbarten Fälligkeitstag. Es hat den Wert „true“, wenn die Zahlung pünktlich eingegangen ist, und „false“, wenn sie verspätet war. Das Kennzeichen vereinfacht die Berechnung und Darstellung der Kennzahl für die pünktliche Zahlung. Rechnungen lassen sich damit einfach filtern und danach aufschlüsseln, ob sie verspätet oder pünktlich bezahlt wurden. So können Muster im Zusammenhang mit bestimmten Kunden, Regionen oder Zahlungsbedingungen sichtbar werden, die zu verspäteten Zahlungen führen. Warum das wichtig ist Das Kennzeichen vereinfacht die Leistungsmessung, indem es jede Rechnung eindeutig als „pünktlich“ oder „verspätet“ ausweist. Damit unterstützt es direkt die Kennzahl für die pünktliche Zahlung. Woher beziehen Dies ist ein berechnetes Feld. Die Logik vergleicht den Timestamp der Aktivität „Kundenzahlung eingegangen“ mit dem Wert des Attributs „PaymentDueDate“. Beispiele truefalse | |||
| Quellsystem SourceSystem | Gibt das Quellsystem an, aus dem die Daten extrahiert wurden. | ||
| Beschreibung Dieses Attribut gibt die Herkunft der Daten an. Das ist besonders in Umgebungen mit mehreren SAP-Instanzen oder anderen integrierten Systemen hilfreich. Es enthält in der Regel die System-ID und die Mandantennummer. In der Analyse hilft es, Prozesse und deren Leistung über verschiedene Systeme oder Organisationseinheiten hinweg zu unterscheiden. Außerdem unterstützt es die Nachverfolgung der Datenherkunft und liefert Kontext, wenn Daten aus mehreren Quellen für eine umfassende Prozessansicht zusammengeführt werden. Warum das wichtig ist Das Attribut liefert wichtigen Kontext zur Herkunft der Daten, schafft Klarheit in Umgebungen mit mehreren Systemen und unterstützt die Data Governance. Woher beziehen In der Regel ein statischer Wert, der bei der Datenextraktion festgelegt wird und häufig die System-ID (SY-SYSID) und den Mandanten (SY-MANDT) kombiniert. Beispiele S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| Reklamationsgrund CustomerDisputeReason | Der vom Kunden angegebene Grund für die Beanstandung einer Rechnung. | ||
| Beschreibung Beanstandet ein Kunde eine Rechnung, wird häufig der Grund dafür erfasst. Mögliche Ursachen sind Preisfehler, falsche Mengen oder beschädigte Waren. Diese Informationen können im SAP-Modul Dispute Management oder als Textnotiz gespeichert sein. Die Analyse der Reklamationsgründe ist eine wichtige Grundlage für die Kennzahl zur Fehlerquote bei der Fakturierung und die zugehörige Fehleranalyse. Sie hilft, die Ursachen für fehlerhafte Rechnungen zu erkennen. So kann das Unternehmen systematische Probleme in vorgelagerten Prozessen beheben, die Rechnungsqualität verbessern und die Kundenzufriedenheit steigern. Warum das wichtig ist Das Attribut zeigt, warum Rechnungen beanstandet werden, und gibt direkten Aufschluss über die Ursachen von Fakturierungsfehlern und Unzufriedenheit bei Kunden. Woher beziehen Wird SAP Dispute Management verwendet, finden sich diese Informationen in Tabellen wie UDM_DISPUTE. Andernfalls lassen sie sich möglicherweise aus Ursachencodes zugehöriger Belege oder aus Textfeldern ableiten. Beispiele Falscher PreisAbweichende MengeBeschädigte Ware erhalten | |||
| Verkaufsauftragsnummer SalesOrderNumber | Die Kennung des ursprünglichen Verkaufsauftrags, aus dem die Rechnung hervorgegangen ist. | ||
| Beschreibung Die Verkaufsauftragsnummer verknüpft den Fakturabeleg mit den vorangegangenen Vertriebsaktivitäten. Aus einem Verkaufsauftrag können eine oder mehrere Rechnungen entstehen. Über diese Verknüpfung lässt sich der gesamte Belegfluss nachvollziehen. Dieses Attribut ist für eine durchgängige Order-to-Cash-Analyse unverzichtbar. Damit lässt sich die Prozesssicht auf vorgelagerte Schritte ausweiten und Probleme bei der Fakturierung mit möglichen Ursachen in der Auftragserfassung oder Auftragsabwicklung in Verbindung bringen. So kann beispielsweise die gesamte Durchlaufzeit bis zur Rechnungserstellung ab dem Zeitpunkt berechnet werden, an dem der Auftrag erfüllt wurde. Warum das wichtig ist Das Attribut verknüpft die Rechnung mit dem ursprünglichen Verkaufsauftrag und ermöglicht so eine durchgängige Sicht auf den Order-to-Cash-Prozess, die über die Fakturierung hinausgeht. Woher beziehen SAP-Tabelle: VBRP (Fakturabelegpositionen), Feld: AUBEL Beispiele 100001231000045610000789 | |||
| Währung Currency | Der Währungscode des Rechnungsbetrags. | ||
| Beschreibung Dieses Attribut gibt an, in welcher Währung die Rechnungsbeträge ausgewiesen sind, etwa USD, EUR oder JPY. Es liefert den nötigen Kontext für alle Geldbeträge. In einem global tätigen Unternehmen ist die Währung für korrekte Finanzanalysen und Berichte unverzichtbar. Sie ermöglicht es, Finanzdaten durch Umrechnung in eine gemeinsame Berichtswährung korrekt zusammenzufassen und die Fakturierungsleistung in Regionen mit unterschiedlichen Landeswährungen zu vergleichen. Warum das wichtig ist Das Attribut liefert den nötigen Kontext für alle Geldbeträge und unterstützt so korrekte Finanzanalysen und Berichte, insbesondere bei international tätigen Unternehmen. Woher beziehen SAP-Tabelle: VBRK, Feld: WAERK Beispiele USDEURGBP | |||
| Zahlungsbedingungen PaymentTerms | Der Code, der die Zahlungsbedingungen festlegt, zum Beispiel die Zahlungsfrist. | ||
| Beschreibung Zahlungsbedingungen sind vorab festgelegte Vereinbarungen mit einem Kunden, die bestimmen, wann eine Rechnung fällig ist. Beispiele sind „Netto 30“ (Zahlung innerhalb von 30 Tagen) oder „2/10 Netto 30“ (2 % Skonto bei Zahlung innerhalb von 10 Tagen, andernfalls Zahlung innerhalb von 30 Tagen). Die Analyse nach Zahlungsbedingungen zeigt, wie wirksam diese sind. Werden die einzelnen Bedingungen mit der tatsächlichen Dauer bis zum Zahlungseingang verglichen, lässt sich feststellen, welche Vereinbarungen eine pünktliche Zahlung am besten fördern. Auf dieser Grundlage kann ein Unternehmen seine Zahlungsbedingungen anpassen und den Cashflow verbessern. Warum das wichtig ist Sie legt den vereinbarten Zahlungszeitraum fest und ermöglicht die Analyse, welche Bedingungen Kunden am wirksamsten zu pünktlicher Zahlung bewegen. Woher beziehen SAP-Tabelle: VBRK, Feld: ZTERM Beispiele Z030Z060ZB60 | |||
| Zahlungsstatus PaymentStatus | Der aktuelle Zahlungsstatus der Rechnung, zum Beispiel Offen, Bezahlt oder Überfällig. | ||
| Beschreibung Der Zahlungsstatus zeigt, an welcher Stelle des Forderungseinzugs sich eine Rechnung befindet. In SAP gibt es dafür kein einzelnes Feld. Der Status wird anhand des Ausgleichsstatus des zugehörigen Buchhaltungsbelegs ermittelt. Dieses Attribut ist für das Dashboard zum Alter offener Rechnungen unverzichtbar. Damit lassen sich alle offenen Rechnungen nach Status und Alter aufschlüsseln, sodass das Forderungsmanagement seine Arbeit gezielt priorisieren kann. Auch die Übergänge zwischen den Statuswerten geben Aufschluss über den Ablauf des Forderungseinzugs. Warum das wichtig ist Das Attribut zeigt auf einen Blick den Status des Forderungseinzugs für eine Rechnung. Das ist wichtig, um Forderungen zu verwalten und den Forderungseinzug zu priorisieren. Woher beziehen Ermittelt anhand des Ausgleichsstatus des Buchhaltungsbelegs (VBRK-BELNR) in Finanzbuchhaltungstabellen wie BSID (offene Posten) und BSAD (ausgeglichene Posten). Beispiele OffenBezahltÜberfälligTeilweise bezahlt | |||
Aktivitäten im Order-to-Cash-Prozess: Fakturierung und Rechnungsstellung
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Kundenzahlung eingegangen | Diese Aktivität kennzeichnet die Buchung einer eingehenden Kundenzahlung im Finanzsystem. Zu diesem Zeitpunkt ist die Zahlung möglicherweise noch keiner bestimmten Rechnung zugeordnet, der Zahlungseingang wurde jedoch bereits erfasst. | ||
| Warum das wichtig ist Ein wichtiger Meilenstein für die Berechnung von Days Sales Outstanding (DSO). Er zeigt an, dass das Geld eingegangen ist, auch wenn der Abgleich noch aussteht. Woher beziehen Erfasst anhand des Buchungsdatums (BKPF-BUDAT) des Kundenzahlungsbelegs, in der Regel mit der Belegart „DZ“ in der Tabelle BKPF. Erfassung Das Event basiert auf der Erstellung des Zahlungsbelegs in BKPF/BSEG. Ereignistyp explicit | |||
| Rechnung abgeschlossen | Diese Aktivität kennzeichnet den Endstatus einer vollständig bezahlten Rechnung. Funktional entspricht sie „Zahlung zugeordnet und abgeglichen“ und zeigt an, dass der Prozess für diese Rechnung abgeschlossen ist. | ||
| Warum das wichtig ist Dies ist das zentrale End-Event des Happy Path. Die gesamte Zykluszeit bis zu diesem Punkt zeigt den vollständigen End-to-End-Ablauf der Fakturierung und Rechnungsstellung. Woher beziehen Abgeleitet aus dem Status des Debitorenpostens im Buchhaltungsbeleg. Ein Posten gilt als ausgeglichen, wenn die Felder für das Ausgleichsdatum (BSEG-AUGDT) und den Ausgleichsbeleg (BSEG-AUGBL) befüllt sind. Erfassung Abgeleitet aus dem Eintrag des Ausgleichsdatums (AUGDT) in der Tabelle BSEG/ACDOCA für den Rechnungsposten. Ereignistyp inferred | |||
| Rechnung erstellt | Diese Aktivität kennzeichnet die Erstellung des Fakturabelegs im System. Sie wird als explizites Event erfasst, wenn ein Benutzer beispielsweise die Transaktion VF01 ausführt oder ein Hintergrundjob die Rechnung erstellt. Dabei entsteht ein neuer Eintrag in der Fakturabeleg-Kopftabelle. | ||
| Warum das wichtig ist Dies ist das primäre Start-Event des Fakturierungsprozesses. Die Zeit zwischen der Auftragserfüllung und dieser Aktivität ist entscheidend, um die Zykluszeit der Rechnungserstellung zu messen und Verzögerungen zu Beginn des Prozesses zu erkennen. Woher beziehen Bei der Erstellung in der Tabelle VBRK von SAP S/4HANA (Fakturabeleg: Kopfdaten) erfasst. Erstellungsdatum (VBRK-ERDAT) und Erstellungszeit (VBRK-ERZET) dienen als Timestamp. Erfassung Das Event wird anhand des Erstellungs-Timestamps des Fakturabelegs in der Tabelle VBRK erfasst. Ereignistyp explicit | |||
| Rechnung in der Finanzbuchhaltung gebucht | Dieses Event steht für die erfolgreiche Buchung des Fakturabelegs im Modul Finanzbuchhaltung. Damit wird die Rechnung zu einer offiziellen Forderung und es entstehen Buchungen im Hauptbuch. | ||
| Warum das wichtig ist Diese Aktivität bestätigt, dass die Rechnung ein rechtsgültiges Finanzdokument ist. Die Zeit zwischen Erstellung und Buchung ist eine wichtige Kennzahl für die Effizienz der internen Verarbeitung. Woher beziehen Das Event wird erfasst, wenn der zugehörige Buchhaltungsbeleg erstellt wird. Der Fakturabeleg (VBRK-VBELN) ist über VBRK-BELNR mit dem Buchhaltungsbeleg (BKPF-BELNR) verknüpft. Das Buchungsdatum steht in BKPF-BUDAT. Erfassung Erfasst anhand des Buchungsdatums (BUDAT) des mit dem Fakturabeleg verknüpften Buchhaltungsbelegs in der Tabelle BKPF. Ereignistyp explicit | |||
| Zahlung zugeordnet und abgeglichen | Dieses Event kennzeichnet den Zeitpunkt, an dem die eingegangene Kundenzahlung zugeordnet und zum Ausgleich des offenen Rechnungspostens im Debitoren-Nebenbuch verwendet wird. Aus finanzieller Sicht ist der Vorgang damit abgeschlossen. | ||
| Warum das wichtig ist Misst die Effizienz der Zahlungszuordnung. Verzögerungen können den tatsächlichen Stand der Kundenkonten verfälschen und bei den Forderungsteams unnötigen Aufwand verursachen. Woher beziehen Das Event wird anhand des Ausgleichsdatums (BSEG-AUGDT) im Einzelposten des Buchhaltungsbelegs der ursprünglichen Rechnung erfasst. Dieses Datum wird eingetragen, wenn ein Ausgleichsbeleg den Posten ausgleicht. Erfassung Erfasst anhand des Felds für das Ausgleichsdatum (AUGDT) in der Tabelle BSEG/ACDOCA für den Rechnungsposten. Ereignistyp explicit | |||
| Gutschrift erstellt | Diese Aktivität steht für die Erstellung einer Gutschrift, die einem Kunden zum Ausgleich einer Überberechnung oder für zurückgesendete Waren ausgestellt wird. Häufig ist sie mit einer ursprünglichen Rechnung verknüpft. | ||
| Warum das wichtig ist Das Event macht finanzielle Anpassungen nach der Fakturierung sichtbar. Die Analyse von Gutschriften kann Preisfehler, Produktprobleme oder andere Ursachen für Umsatzverluste aufdecken. Woher beziehen Wird explizit als neuer Fakturabeleg in VBRK mit einer bestimmten Belegart für Gutschriften erstellt, beispielsweise „G2“. Häufig verweist der Beleg auf den ursprünglichen Kundenauftrag oder die Rechnung. Erfassung Erfasst, wenn in VBRK ein Fakturabeleg mit einer Gutschrift-Belegart erstellt wird. Ereignistyp explicit | |||
| Kundenreklamation eröffnet | Diese Aktivität tritt ein, wenn ein Kunde eine Rechnung beanstandet und der Vorgang anschließend formell im System erfasst wird. Dafür ist das SAP-Modul Dispute Management erforderlich. | ||
| Warum das wichtig ist Das Event macht Probleme bei der Rechnungsgenauigkeit, der Produktqualität oder der Leistungserbringung sichtbar, die zu Zahlungsverzögerungen führen. Die Analyse der Reklamationsgründe kann helfen, Ursachen zu beheben und die Kundenzufriedenheit zu verbessern. Woher beziehen Erfasst, wenn ein Reklamationsfall in den Tabellen von Dispute Management (z. B. UDM_CASE) angelegt und mit dem Einzelposten des Buchhaltungsbelegs verknüpft wird. Erfassung Erfasst anhand des Erstellungs-Timestamps des mit der Rechnung verknüpften Reklamationsfalls. Ereignistyp explicit | |||
| Nacharbeit bei der Fakturierung erkannt | Ein berechnetes Event, das eine Nacharbeitsschleife erkennt: Eine Rechnung wurde storniert und anschließend für denselben Kundenauftrag neu erstellt. Es handelt sich nicht um eine einzelne Transaktion, sondern um ein Muster aus mehreren Events. | ||
| Warum das wichtig ist Das Event unterstützt direkt die Kennzahl zur Nacharbeitsquote bei der Fakturierung, indem es Korrekturfälle quantifiziert. So lassen sich Ineffizienzen erkennen und die Kosten mangelhafter Qualität im Fakturierungsprozess messen. Woher beziehen Dieses Muster wird berechnet, indem auf ein Event „Rechnung storniert“ ein neues Event „Rechnung erstellt“ folgt und beide auf dasselbe Quelldokument, etwa eine Kundenauftragsnummer, zurückgehen. Erfassung Abgeleitet aus der Abfolge „Rechnung storniert“ und „Rechnung erstellt“ mit demselben Kundenauftragsbezug. Ereignistyp calculated | |||
| Rechnung an Kunden gesendet | Diese Aktivität kennzeichnet den Versand der Rechnung an den Kunden, beispielsweise per Post, E-Mail oder EDI. Wie der Versand erfasst wird, hängt von der Ausgabeverwaltungskonfiguration in SAP ab. | ||
| Warum das wichtig ist Aus Kundensicht beginnt damit offiziell die Zahlungsfrist. Verzögerungen beim Rechnungsversand wirken sich direkt auf Days Sales Outstanding (DSO) und Cashflow aus. Woher beziehen Der Versand kann explizit in den Ausgabesteuerungstabellen protokolliert werden, etwa in NAST bei älteren Verfahren oder in der entsprechenden Tabelle in S/4HANA. Fehlt ein expliziter Eintrag, wird der Versand häufig zum Zeitpunkt von „Rechnung in der Finanzbuchhaltung gebucht“ angenommen. Erfassung Prüfen Sie die Verarbeitungsprotokolle in den Tabellen der Ausgabeverwaltung auf einen Timestamp für die Ausgabeart der Rechnung. Ereignistyp explicit | |||
| Rechnung storniert | Dieses Event tritt ein, wenn eine zuvor erstellte Rechnung storniert wird. Dazu wird in der Regel ein entsprechender Stornobeleg angelegt. Damit werden die ursprüngliche Rechnung und ihre buchhalterischen Auswirkungen rückgängig gemacht. | ||
| Warum das wichtig ist Das Event weist auf Nacharbeit, Korrekturen oder Fehler bei der Fakturierung hin. Häufige Stornierungen deuten auf erhebliche vorgelagerte Probleme bei der Erfassung von Kundenaufträgen oder der Fakturierungskonfiguration hin. Woher beziehen Erfasst, wenn ein Stornofakturabeleg erstellt wird, beispielsweise mit der Belegart „S1“. Dieser neue Beleg in VBRK verweist über das Feld VBRK-SFAKN auf die ursprüngliche Rechnungsnummer. Erfassung Das Event wird anhand des Erstellungsdatums des Stornobelegs in VBRK erfasst, der auf die ursprüngliche Rechnung verweist. Ereignistyp explicit | |||
| Rechnungsbuchung gesperrt | Dieses Event tritt ein, wenn eine Rechnung erstellt, aber aus verschiedenen Gründen, etwa wegen einer Kreditprüfung oder widersprüchlicher Daten, automatisch für die Buchung in der Finanzbuchhaltung gesperrt wird. Der Status wird aus dem Buchungsstatusfeld des Fakturabelegs abgeleitet. | ||
| Warum das wichtig ist Das Event zeigt Engpässe auf, bei denen Rechnungen zwar erstellt, aber nicht sofort für die Finanzbuchhaltung freigegeben werden. Dadurch verzögert sich der gesamte Zahlungseingang. Es ist ein wichtiger Hinweis auf Probleme mit der Datenqualität oder dem Kreditmanagement. Woher beziehen Abgeleitet aus dem Buchungsstatusfeld in der Fakturabeleg-Kopftabelle (VBRK-RFBSK). Ein Status wie „A“ (Fakturabeleg für die Weiterleitung an FI gesperrt) weist auf eine Sperre hin. Erfassung Abgeleitet aus dem Wert des Buchungsstatusfelds (VBRK-RFBSK), der unmittelbar nach der Rechnungserstellung geprüft wird. Ereignistyp inferred | |||
| Zahlungserinnerung versendet | Dieses Event steht für den Versand einer Zahlungserinnerung oder Mahnung an einen Kunden mit einer überfälligen Rechnung. Es wird explizit durch den automatisierten Mahnlauf erzeugt. | ||
| Warum das wichtig ist Damit lässt sich die Wirksamkeit des Mahnprozesses analysieren. Sie können feststellen, ob Zahlungserinnerungen den Zahlungseingang beschleunigen und welche Mahnstufen besonders wirksam sind. Woher beziehen Wird in den Mahnhistorientabellen (MAHNV, MHND) erfasst, wenn der Mahnlauf (Transaktion F150) für den offenen Posten der Rechnung ausgeführt wird. Erfassung Erfasst anhand des Ausführungsdatums der Mahnung in den Mahnhistorientabellen. Ereignistyp explicit | |||
| Zahlungsziel erreicht | Ein berechnetes Event für das Datum, an dem die Zahlung laut vereinbarten Zahlungsbedingungen fällig ist. Es handelt sich nicht um ein Transaktions-Event, sondern um einen aus den Rechnungsdaten abgeleiteten Wert. | ||
| Warum das wichtig ist Dieses Datum bildet eine wichtige Grundlage, um pünktliche Zahlungen zu messen und das Zahlungsverhalten der Kunden zu analysieren. So lassen sich fristgerechte und überfällige Zahlungen unterscheiden. Woher beziehen Berechnet anhand des Basisdatums für die Zahlung (BSEG-ZFBDT) und der Zahlungsbedingungen im Debitorenposten des Buchhaltungsbelegs. Erfassung Abgeleitet, indem die Tage der Zahlungsfrist zum Basiszahlungsdatum im Einzelposten des Buchhaltungsbelegs (BSEG) addiert werden. Ereignistyp calculated | |||
Extraktionsanleitungen
Schritte
- Voraussetzungen: Stellen Sie sicher, dass Sie über ein Benutzerkonto in SAP S/4HANA mit den erforderlichen Berechtigungen zum Abfragen von Core Data Services (CDS) Views verfügen. Sie benötigen insbesondere Lesezugriff auf Views wie I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase und I_DunningHistory.
- Datenextraktionstool aufrufen: Melden Sie sich bei Ihrem SAP-S/4HANA-System an. Für SQL-Abfragen auf CDS Views stehen verschiedene Tools zur Verfügung, etwa SAP HANA Studio, DBeaver mit Verbindung über den SAP HANA Client oder das SAP Analysis for Microsoft Excel Plugin. In dieser Anleitung gehen wir von einem gängigen SQL-Client aus.
- Systemparameter ermitteln: Legen Sie vor der Abfrage die relevanten Buchungskreise und den Zeitraum für Ihre Analyse fest. Beginnen Sie am besten mit einem begrenzten Zeitraum, zum Beispiel den letzten 3 bis 6 Monaten. So bleibt die Abfragezeit überschaubar.
- SQL-Abfrage vorbereiten: Kopieren Sie die vollständige SQL-Abfrage aus dem Abschnitt „query“ dieses Dokuments in den gewünschten SQL-Client.
- Platzhalter anpassen: Ändern Sie die Platzhalterwerte in der Abfrage. Ersetzen Sie
'YYYY-MM-DD'durch das gewünschte Start- und Enddatum. Ersetzen Sie'XXXX'durch den oder die betreffenden Buchungskreise. Je nach Systemkonfiguration müssen Sie außerdem den Platzhalter für die Gutschriftarten anpassen, zum Beispiel auf'G2'. - Abfrage ausführen: Führen Sie die angepasste SQL-Abfrage für die SAP-S/4HANA-Datenbank aus. Die Ausführungszeit hängt vom Datenvolumen im gewählten Zeitraum ab.
- Ergebnisse prüfen: Prüfen Sie nach Abschluss der Abfrage die Ausgabe. Das Ergebnis sollte eine flache Tabelle sein, in der jede Zeile eine einzelne Aktivität im Fakturierungsprozess darstellt. Diese Tabelle ist Ihr Event Log.
- Daten umwandeln (falls erforderlich): Die Abfrage erstellt ein Event Log in einem bereinigten Format. Prüfen Sie dennoch, ob das Timestamp-Format mit Ihrem Process-Mining-Tool kompatibel ist. Die Abfrage verwendet
ABAP_SYSTEM_UTCL_TO_TIMESTAMP, um die Werte in ein standardisiertes UTC-Timestamp-Format umzuwandeln, das mit den meisten Tools kompatibel sein sollte. - Event Log exportieren: Exportieren Sie das vollständige Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Achten Sie auf die UTF-8-Kodierung, damit Zeichen korrekt dargestellt werden.
- In ProcessMind hochladen: Laden Sie die erstellte CSV-Datei in ProcessMind hoch. Ordnen Sie die Spalten der Datei, etwa InvoiceNumber, ActivityName und EventTime, den entsprechenden Feldern im Tool zu.
Konfiguration
- Zeitraum: Legen Sie das Start- und Enddatum in der
WHERE-Klausel der ersten Common Table Expression (CTE) fest. Für eine erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten, um Datenvolumen und Abfrageleistung auszubalancieren. Der Filter bezieht sich aufBillingDocumentDate. - Buchungskreis: Filtern Sie nach einem oder mehreren Werten für
CompanyCode, um die Extraktion auf relevante Rechtseinheiten zu begrenzen. Dieser Filter ist entscheidend, um den Umfang der Daten zu steuern. - Belegarten: Die Abfrage ermittelt Gutschriften anhand von
BillingDocumentType. Passen Sie den Platzhalter, zum Beispiel('G2', 'CR'), an die in Ihrer Organisation verwendeten Gutschriftarten an. - Voraussetzungen: Der Zugriff auf die zugrunde liegenden CDS Views ist erforderlich. Ihr SAP-Sicherheitsteam muss Ihnen dafür bestimmte Rollen und Berechtigungen zuweisen. Außerdem müssen die entsprechenden SAP-Module SAP Dispute Management und SAP Financials Dunning in Ihrem System aktiv genutzt werden, damit Aktivitäten wie „Kundenreklamation eröffnet“ oder „Zahlungserinnerung versendet“ erfasst werden.
- Leistung: Die Abfrage verwendet mehrere Joins und Unions. Bei sehr großen Datenmengen, etwa Daten aus mehreren Jahren, sollten Sie die Abfrage außerhalb der Spitzenzeiten ausführen oder die Filter einschränken, um den ersten Datenabruf zu begrenzen.
a Beispielabfrage sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime;Schritte
- Prüfen Sie, ob direkter Lesezugriff auf das SAP-HANA-Schema mit den Fakturierungs- und zugehörigen Finanzdaten verfügbar ist. Lassen Sie sich vom Systemverantwortlichen den Schemanamen, die Verbindungsdaten, den zulässigen Zeitraum, den Umfang der Buchungskreise, die Fakturabelegarten sowie gegebenenfalls Kunden- oder Regionsfilter nennen. Ersetzen Sie in der Abfrage ausschließlich die Platzhalter für Verbindung und Filter.
- Prüfen Sie die relevanten SAP-S/4HANA-Datenquellen und ihre Feldzuordnungen im Zielsystem. Die Abfrage verwendet VBRK und VBRP für Fakturierungsdaten. Außerdem müssen Quellen für Buchhaltung, Output Management, Dispute Management, Mahnwesen, Zahlungseingänge, Ausgleich und Belegbeziehungen konfiguriert sein. Ersetzen Sie Platzhalter in eckigen Klammern für Quellen und Felder erst, nachdem Sie sie anhand des Systemdatenverzeichnisses geprüft haben.
- Legen Sie den Extraktionszeitraum mit einem eingeschlossenen Start- und einem ausgeschlossenen End-Timestamp fest. Für den ersten Lauf empfiehlt sich ein Zeitraum von drei bis sechs Monaten. Begrenzen Sie die Extraktion nach Buchungskreis und gegebenenfalls Fakturaart, um das Datenvolumen zu steuern und unterschiedliche Fakturierungsprozesse nicht zu vermischen.
- Führen Sie die Abfrage mit einem schreibgeschützten HANA-Datenbankbenutzer aus. Für jede ausdrücklich extrahierte Aktivität wird eine Ereigniszeile erstellt. ProcessMind leitet keine Ereignisse ab. Berechnete Aktivitäten wie „Fälligkeitsdatum der Zahlung erreicht“ und „Nachbearbeitung der Fakturierung erkannt“ werden durch SQL-Logik erzeugt und als Zeilen ausgegeben.
- Prüfen Sie das zurückgegebene Schema. Das Event Log muss InvoiceNumber, ActivityName, EventTime, UserName, InvoiceDate, PaymentDueDate, InvoiceAmount, CustomerName, Region und EndTime enthalten. Stellen Sie sicher, dass InvoiceNumber, ActivityName und EventTime in jeder Zeile ausgefüllt sind.
- Prüfen Sie die Bedeutung und Beziehungen der Ereignisse. Vergleichen Sie Zeilen zu „Rechnung erstellt“ mit den Daten zur Anlage des Fakturakopfs, Zeilen zu „Rechnung in der Buchhaltung gebucht“ mit dem Buchungsstatus, Zeilen zu „Rechnung an Kunden gesendet“ mit den Output-Datensätzen, Zahlungszeilen mit den Buchhaltungsbelegen und Ausgleichszeilen mit den ausgeglichenen Rechnungsposten. Prüfen Sie alle von Platzhaltern abhängigen Abschnitte, bevor Sie die Abfrage produktiv einsetzen.
- Bereiten Sie das Ergebnis für ProcessMind auf. Verwenden Sie eine Zeile pro Ereignis, einheitliche Timestamp-Datentypen und eine konsistente Zeitzone. Speichern Sie InvoiceNumber als Text, damit führende Nullen erhalten bleiben, und achten Sie darauf, dass die Werte in ActivityName exakt den erforderlichen Aktivitätsnamen entsprechen. Sortieren Sie nach InvoiceNumber und EventTime. Falls mehrere Ereignisse denselben Timestamp haben, verwenden Sie eine eindeutige sekundäre Sortierung.
- Exportieren Sie das Ergebnis als UTF-8-CSV oder in einem anderen von ProcessMind unterstützten Tabellenformat. Ordnen Sie InvoiceNumber der Case-ID, ActivityName der Aktivitätsspalte und EventTime dem Ereignis-Timestamp zu. Fügen Sie verfügbare empfohlene Attribute hinzu, laden Sie die Datei anschließend über den konfigurierten ProcessMind-Importprozess hoch und prüfen Sie abschließend die Zeilen- und Aktivitätsanzahl.
Konfiguration
- Zeitraum: Beginnen Sie mit drei bis sechs Monaten. Verwenden Sie einen eingeschlossenen Start- und einen ausgeschlossenen End-Timestamp, damit bei inkrementellen Läufen keine Ereignisse doppelt erfasst werden.
- Case-ID: Verwenden Sie InvoiceNumber aus dem Fakturabelegkopf. Speichern Sie den Wert als Zeichenfolge, da SAP-Belegnummern führende Nullen enthalten können.
- Erforderliche Aktivitäten: Die Extraktion muss explizite Zeilen für folgende Aktivitäten zurückgeben: Rechnung erstellt, Fakturabeleg für Buchung gesperrt, Rechnung in der Buchhaltung gebucht, Rechnung an Kunden gesendet, Fälligkeitsdatum der Zahlung erreicht, Kundenreklamation eröffnet, Zahlungserinnerung versendet, Kundenzahlung eingegangen, Zahlung zugeordnet/abgeglichen, Rechnung geschlossen, Rechnung storniert, Gutschrift erstellt und Nachbearbeitung der Fakturierung erkannt.
- Filter: Wenden Sie Filter für Buchungskreis, Fakturabelegart, Verkaufsorganisation, Kunde, Region und Datum erst an, nachdem Sie die entsprechenden Felder und den fachlichen Umfang im Zielsystem geprüft haben. Gehen Sie nicht davon aus, dass für alle Fakturabelegarten derselbe Buchhaltungs- oder Output-Prozess gilt.
- Quellenkonfiguration: VBRK und VBRP sind die primären Fakturierungsquellen. Quellen für Buchhaltung, Output, Dispute Management, Mahnwesen, Zahlungen, Ausgleich und Belegfluss müssen entsprechend der eingesetzten SAP-S/4HANA-Version und den aktivierten Modulen konfiguriert werden. Ersetzen Sie Quellenverweise in eckigen Klammern durch geprüfte Objekte und Felder.
- Berechnete Ereignisse: „Fälligkeitsdatum der Zahlung erreicht“ wird aus den Zahlungsbedingungen und Fälligkeitsdaten abgeleitet. „Nachbearbeitung der Fakturierung erkannt“ wird anhand von Stornierungen und anschließenden Rechnungserstellungen ermittelt. Diese Ereigniszeilen werden durch SQL erzeugt und sind keine nativen Transaktionsdatensätze.
- Leistung: Übernehmen Sie Filter für Datum, Buchungskreis, Fakturaart und Belegnummer in jede Quellenabfrage. Wählen Sie nur erforderliche Spalten aus, vermeiden Sie uneingeschränkte Joins mit großen Buchhaltungstabellen und verarbeiten Sie den Zeitraum in Monats- oder Wochenabschnitten. Ermitteln Sie mit Datenbank-Ausführungsplänen aufwendige Joins.
- Inkrementelle Extraktion: Verwenden Sie einen stabilen Wasserstand auf Basis von Erstellungs- oder Buchungs-Timestamps der Quelldaten. Verarbeiten Sie einen kurzen überlappenden Zeitraum erneut, um verspätet eintreffende Output-, Zahlungs-, Reklamations- und Ausgleichsdatensätze zu erfassen. Entfernen Sie anschließend Duplikate anhand von InvoiceNumber, ActivityName und EventTime sowie dem relevanten Quelldokumentschlüssel.
- Berechtigungen: Der Extraktionsbenutzer benötigt Leseberechtigungen für die ausgewählten Objekte und Felder im HANA-Schema. Prüfen Sie, ob der direkte Datenbankzugriff gemäß den Sicherheitsrichtlinien Ihrer Organisation zulässig ist und ob die Anforderungen zum Umgang mit personenbezogenen Daten und Kundendaten erfüllt sind.
- Fachliche Voraussetzungen: Daten zu Output Management, Buchhaltungsintegration, Dispute Management, Mahnwesen, Zahlungseingängen und Ausgleich sind nur verfügbar, wenn die entsprechenden Funktionen im System konfiguriert und in Gebrauch sind. Fehlen Module oder Quelldatensätze, fehlen auch die Aktivitäten. Sie werden nicht abgeleitet.
- Zeitzone: Vereinheitlichen Sie die Timestamps entsprechend der von ProcessMind benötigten Zeitzone. Dokumentieren Sie, ob die Quell-Timestamps in UTC, lokaler Systemzeit oder einer anderen konfigurierten Zeitzone gespeichert sind.
a Beispielabfrage sql
WITH
billing_headers AS (
SELECT
h.VBELN AS InvoiceNumber,
h.FKDAT AS InvoiceDate,
h.NETWR AS InvoiceAmount,
h.KUNAG AS CustomerNumber,
h.ERDAT AS BillingCreatedDate,
h.ERZET AS BillingCreatedTime,
h.ERNAM AS BillingCreatedBy,
h.BUKRS AS CompanyCode,
h.FKART AS BillingType,
h.FKSTO AS CancellationIndicator,
h.RFBSK AS AccountingPostingStatus,
h.ZTERM AS PaymentTerms,
h.ZFBDT AS BaselineDate,
h.NETDT AS PaymentDueDate,
h.VBELV AS PrecedingDocument
FROM [Your HANA schema].VBRK h
WHERE h.ERDAT >= '[Start date, YYYY-MM-DD]'
AND h.ERDAT < '[End date, YYYY-MM-DD]'
AND h.BUKRS IN ([Company code filter])
AND h.FKART IN ([Billing document type filter])
),
customer_data AS (
SELECT
c.KUNNR AS CustomerNumber,
c.NAME1 AS CustomerName,
c.REGION AS Region
FROM [Your customer master source] c
),
invoice_base AS (
SELECT
b.InvoiceNumber,
b.InvoiceDate,
b.InvoiceAmount,
b.CustomerNumber,
c.CustomerName,
c.Region,
b.BillingCreatedDate,
b.BillingCreatedTime,
b.BillingCreatedBy,
b.CompanyCode,
b.BillingType,
b.CancellationIndicator,
b.AccountingPostingStatus,
b.PaymentTerms,
b.BaselineDate,
b.PaymentDueDate,
b.PrecedingDocument
FROM billing_headers b
LEFT JOIN customer_data c
ON c.CustomerNumber = b.CustomerNumber
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Generated' AS ActivityName,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EventTime,
i.BillingCreatedBy AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EndTime
FROM invoice_base i
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posting blocked status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
a.StatusTimestamp AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
a.StatusTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posted status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
o.SentTimestamp AS EventTime,
o.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
o.SentTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your output management source] o
ON o.InvoiceNumber = i.InvoiceNumber
AND o.OutputStatus = '[Successfully sent status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM invoice_base i
WHERE i.PaymentDueDate IS NOT NULL
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
d.OpenedTimestamp AS EventTime,
d.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
d.OpenedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dispute management source] d
ON d.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
r.IssuedTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.IssuedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dunning or payment reminder source] r
ON r.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Payment Received' AS ActivityName,
p.ReceivedTimestamp AS EventTime,
p.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
p.ReceivedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your incoming payment source] p
ON p.CustomerNumber = i.CustomerNumber
AND p.CompanyCode = i.CompanyCode
AND p.ReceivedTimestamp >= TO_TIMESTAMP(TO_VARCHAR(i.InvoiceDate))
UNION ALL
SELECT
i.InvoiceNumber,
'Cash Applied/Reconciled' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Closed' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
x.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
LEFT JOIN [Your billing cancellation or document flow source] x
ON x.InvoiceNumber = i.InvoiceNumber
WHERE i.CancellationIndicator = '[Cancellation indicator value]'
OR x.InvoiceNumber IS NOT NULL
UNION ALL
SELECT
cm.ReferenceInvoiceNumber AS InvoiceNumber,
'Credit Memo Created' AS ActivityName,
cm.CreatedTimestamp AS EventTime,
cm.UserName,
i.InvoiceDate,
i.PaymentDueDate,
cm.Amount AS InvoiceAmount,
i.CustomerName,
i.Region,
cm.CreatedTimestamp AS EndTime
FROM [Your credit memo source] cm
INNER JOIN invoice_base i
ON i.InvoiceNumber = cm.ReferenceInvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
r.ReworkTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.ReworkTimestamp AS EndTime
FROM invoice_base i
INNER JOIN (
SELECT
old_invoice.InvoiceNumber,
new_invoice.InvoiceNumber AS ReplacementInvoiceNumber,
new_invoice.BillingCreatedDate AS ReworkTimestamp,
new_invoice.BillingCreatedBy AS UserName
FROM invoice_base old_invoice
INNER JOIN invoice_base new_invoice
ON new_invoice.PrecedingDocument = old_invoice.InvoiceNumber
AND new_invoice.BillingCreatedDate > old_invoice.BillingCreatedDate
WHERE old_invoice.CancellationIndicator = '[Cancellation indicator value]'
) r
ON r.InvoiceNumber = i.InvoiceNumber
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
InvoiceDate,
PaymentDueDate,
InvoiceAmount,
CustomerName,
Region,
EndTime
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName;Möchten Sie loslegen?
Mit diesem Template bereiten Sie Ihre Daten schneller auf und können die Fakturierung und Rechnungsstellung im Order-to-Cash-Prozess gezielt verbessern. Wandeln Sie Ihre SAP-S/4HANA-Daten noch heute in konkrete Erkenntnisse um.
Die Fakturierung im Order-to-Cash-Prozess optimieren und den Cashflow um 30 % beschleunigen
Beseitigen Sie Ineffizienzen und verkürzen Sie Ihren Fakturierungszyklus ab heute um 30 %.
Keine Kreditkarte erforderlich. In wenigen Minuten startklar.