> Kontinuierliche Prozessverbesserung > Record to Report Prozess: Journalbuchungen > BlackLine > Daten Template

Ihr Daten-Template für den Record-to-Report-Prozess mit Buchungsbelegen

BlackLine

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute für den Record-to-Report-Prozess mit Buchungsbelegen (19) Aktivitäten im Record-to-Report-Prozess mit Buchungsbelegen (12) Anleitungen zur Datenextraktion (2)

Ihr Daten-Template für den Record-to-Report-Prozess mit Buchungsbelegen

Dieses Template zeigt Ihnen, wie Sie die passenden Daten für die Analyse Ihres Record-to-Report-Prozesses mit Buchungsbelegen erfassen. Es beschreibt die erforderlichen Attribute, die wichtigsten Aktivitäten und wie Sie diese Informationen aus BlackLine extrahieren. So stellen Sie sicher, dass alle Daten für ein aussagekräftiges Process Mining vorliegen.

Empfohlene Attribute für die Datenerfassung
Wichtige Aktivitäten für die Analyse
Anleitung zur Datenextraktion

Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Template herunterladen

Attribute für den Record-to-Report-Prozess mit Buchungsbelegen

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um Ihren Record-to-Report-Prozess mit Buchungsbelegen umfassend zu analysieren.

5 Erforderlich 6 Empfohlen 8 Optional

	Name	Beschreibung
	Aktivität ActivityName	Bezeichnung des konkreten Geschäftsereignisses, das zu einem bestimmten Zeitpunkt im Prozess der Buchungssatzerfassung stattgefunden hat.
Beschreibung Dieses Attribut beschreibt einen einzelnen Schritt oder eine Aufgabe im Lebenszyklus eines Buchungssatzes, zum Beispiel „Buchungssatz erstellt“, „Buchungssatz genehmigt“ oder „Buchungssatz gebucht“. Jede Aktivität steht für ein eigenes Ereignis im Prozess. Die Abfolge dieser Aktivitäten lässt sich analysieren, um den Prozessablauf zu visualisieren und nachzuvollziehen. Sie bildet die Grundlage, um Prozessabweichungen zu erkennen, Übergangszeiten zwischen Schritten zu messen und Nacharbeitsschleifen aufzudecken, etwa wenn ein Buchungssatz abgelehnt und erneut eingereicht wird. Warum das wichtig ist Das Attribut legt die Prozessschritte fest. Es ist wichtig, um den Prozessablauf zu visualisieren, den Ablauf zu analysieren und Abweichungen oder Engpässe zu erkennen. Woher beziehen Dieses Attribut wird üblicherweise aus Event Logs, Statusänderungen oder Audit-Trails in BlackLine abgeleitet. Dazu müssen möglicherweise Systemstatuscodes benutzerfreundlichen Aktivitätsnamen zugeordnet werden. Beispiele Journalbuchung erstelltJournalbuchung eingereichtBuchungssatz genehmigtBuchungssatz gebucht
	ID des Buchungssatzes JournalEntryId	Eindeutige Kennung eines einzelnen Buchungssatzes. Sie dient als primäre Case-ID, um den Lebenszyklus des Satzes nachzuverfolgen.
Beschreibung Die ID des Buchungssatzes identifiziert jeden Satz von Finanztransaktionen, der im Hauptbuch erfasst wird, eindeutig. Sie dient als zentraler Schlüssel, der alle zugehörigen Aktivitäten wie Erstellung, Prüfung, Genehmigung und Buchung miteinander verknüpft. Im Process Mining ist diese ID unverzichtbar, um alle Ereignisse einem einzelnen Buchungssatz zuzuordnen. Anhand dieser Kennung lässt sich der durchgängige Prozess von der Initiierung bis zur abschließenden Abstimmung rekonstruieren. So können Zykluszeiten, Engpässe und Prozessabweichungen detailliert analysiert werden. Warum das wichtig ist Diese zentrale Case-ID ermöglicht es, den gesamten Lebenszyklus eines einzelnen Buchungssatzes nachzuverfolgen und seine Leistung zu analysieren. Woher beziehen Dies ist ein Primärschlüssel in den Tabellen oder Datenexporten für Buchungssätze von BlackLine. Den genauen Feldnamen finden Sie in der BlackLine-Dokumentation. Beispiele JE2024-001234JE2024-001235JE2024-001236
	Startzeit EventTime	Der genaue Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung Der Ereigniszeitpunkt erfasst Datum und Uhrzeit eines Geschäftsereignisses. Er bildet die zeitliche Grundlage des Prozesses und legt die Reihenfolge sowie die Dauer aller Aktivitäten fest. Dieser Timestamp ist für alle zeitbasierten Process-Mining-Analysen entscheidend. Anhand seiner Werte werden Zykluszeiten, Wartezeiten und die Dauer zwischen Aktivitäten berechnet. So lassen sich Engpässe erkennen, Leistungsverläufe analysieren und die Einhaltung von Service Level Agreements beurteilen. Warum das wichtig ist Dieser Timestamp bildet die Grundlage für alle Leistungskennzahlen, darunter Zykluszeit und Engpassanalyse, und ermöglicht eine chronologische Rekonstruktion des Prozesses. Woher beziehen Diese Information ist in den Timestamp-Feldern der Event Logs oder Transaktionsdatensätze in BlackLine enthalten. Beispiele 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:05:00Z
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp der letzten Aktualisierung oder Extraktion der Daten aus dem Quellsystem.
Beschreibung Dieses Attribut enthält Datum und Uhrzeit des letzten Datenabrufs. Es zeigt, wie aktuell die analysierten Daten sind, und macht für Benutzer transparent, auf welchem Stand die Daten beruhen. Diese Metadaten sind für jedes Process-Mining-Dashboard und jede Analyse wichtig. Sie informieren Benutzer über die Aktualität der Erkenntnisse und helfen einzuschätzen, ob die neuesten Transaktionen bereits in der Ansicht enthalten sind. Warum das wichtig ist Das Attribut macht die Aktualität der Daten transparent, sodass Benutzer den zeitlichen Stand der Prozessanalyse einschätzen können. Woher beziehen Dieser Timestamp wird zum Ausführungszeitpunkt vom Datenextraktionstool oder ETL-Prozess erzeugt und dem Datensatz hinzugefügt. Beispiele 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Quellsystem SourceSystem	Das führende System, aus dem die Daten des Buchungssatzes extrahiert wurden.
Beschreibung Dieses Attribut kennzeichnet das Ursprungssystem der Ereignisdaten. In diesem Fall ist es üblicherweise „BlackLine“. Beginnt der Prozess in einem vorgelagerten ERP-System, können auch Daten aus diesem System enthalten sein. Die Angabe des Quellsystems ist wichtig für die Data Governance und hilft, den Prozesskontext zu verstehen, insbesondere wenn Daten aus mehreren Systemen zusammengeführt werden. Sie unterstützt außerdem die Fehlersuche bei der Datenübernahme und die Überprüfung der Datenherkunft. Warum das wichtig ist Das Attribut liefert wichtige Informationen zur Datenherkunft. Es gewährleistet die Rückverfolgbarkeit und unterstützt die Verwaltung von Datenintegrationen aus verschiedenen Plattformen. Woher beziehen Dieser statische Wert wird üblicherweise während der Datenextraktion und -transformation hinzugefügt, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele BlackLineSAP S/4HANAOracle NetSuite
	Ablehnungsgrund RejectionReason	Begründung, die ein Prüfender bei der Ablehnung eines Buchungssatzes angibt.
Beschreibung Wird ein Buchungssatz zur Korrektur zurückgesendet, gibt der Genehmigende üblicherweise einen Ablehnungsgrund an. Dieses Attribut erfasst die Begründung als vordefinierten Code oder Freitext. Das Attribut ist entscheidend für die Ursachenanalyse von Nacharbeiten. Anhand der häufigsten Ablehnungsgründe kann ein Unternehmen systemische Probleme erkennen, etwa unzureichende Schulungen, unklare Richtlinien oder fehlende Belege. Es unterstützt direkt das Dashboard „Analyse von Ablehnungen und Nacharbeiten bei Buchungssätzen“ und hilft, die Ablehnungsquote insgesamt zu senken. Warum das wichtig ist Das Attribut ist wichtig für die Ursachenanalyse von Nacharbeiten. Es zeigt, warum Buchungssätze abgelehnt werden, und ermöglicht gezielte Verbesserungen. Woher beziehen Diese Daten werden üblicherweise in einem Kommentar- oder Begründungscodefeld erfasst, wenn ein Benutzer in BlackLine die Aktion „Ablehnen“ ausführt. Beispiele Falscher KontocodeBelege fehlenSchwellenwert überschrittenDoppelte Buchung
	Benutzer UserName	Name oder ID des Benutzers, der die Aktivität ausgeführt hat.
Beschreibung Dieses Attribut kennzeichnet die Person, die für einen bestimmten Prozessschritt verantwortlich war, zum Beispiel für das Einreichen, Prüfen oder Genehmigen eines Buchungssatzes. Als Wert kann ein Name oder eine eindeutige Benutzer-ID dienen. Die Analyse von Aktivitäten nach Benutzer ist wichtig, um die Arbeitsverteilung und die individuelle Leistung zu verstehen sowie Schulungsbedarf zu erkennen. Sie hilft bei Fragen wie: „Ist die Arbeit gleichmäßig im Team verteilt?“ oder „Bei welchen Benutzern dauern Genehmigungen am längsten?“ Auch für Compliance-Prüfungen und die Analyse von Audit-Trails ist das Attribut entscheidend. Warum das wichtig ist Das Attribut ermöglicht die Analyse der Arbeitsauslastung und den Leistungsvergleich im Team. Außerdem hilft es, ressourcenbedingte Engpässe und Schulungsbedarf zu erkennen. Woher beziehen Diese Information ist in den Audit-Protokollen von BlackLine verfügbar und wird häufig in Feldern wie „Benutzer-ID“ oder „Geändert von“ für jedes Ereignis gespeichert. Beispiele j.doea.smithr.joness.patel
	Betrag des Buchungssatzes JournalEntryAmount	Gesamtbetrag des Buchungssatzes, üblicherweise die Summe der Sollbuchungen.
Beschreibung Dieses Attribut gibt den finanziellen Wert des Buchungssatzes an. Damit lässt sich die finanzielle Auswirkung von Prozessineffizienzen einschätzen, etwa wenn sich die Buchung von hohen Beträgen verzögert. Die Analyse nach Buchungsbetrag ermöglicht eine Bewertung nach Wesentlichkeit. So können Sie Prozessverbesserungen für Buchungssätze mit hohen Beträgen priorisieren, abweichende Genehmigungswege untersuchen oder längere Zykluszeiten erkennen. Dadurch erhält der Prozessablauf einen wichtigen geschäftlichen Kontext. Warum das wichtig ist Das Attribut liefert den finanziellen Kontext für die Analyse nach Wesentlichkeit. So können Sie Buchungssätze mit hohen Beträgen priorisieren oder wertbezogene Prozessabweichungen erkennen. Woher beziehen Dies ist ein berechnetes oder standardmäßiges Feld im Kopf des Buchungssatzes in BlackLine. Es enthält den Gesamtbetrag der Soll- oder Habenbuchungen. Beispiele 15000.00250.75125000.50500.00
	Buchungskreis CompanyCode	Eindeutige Kennung der juristischen Person oder des Unternehmens, für das der Buchungssatz erstellt wird.
Beschreibung Der Buchungskreis steht für eine bestimmte juristische Person innerhalb eines Konzerns. Als zentrale Organisationseinheit der Finanzbuchhaltung stellt er sicher, dass Transaktionen der richtigen Einheit zugeordnet werden. Im Process Mining dient der Buchungskreis als wichtige Dimension für Filter und Vergleiche. Damit lässt sich die Prozessleistung verschiedener Einheiten analysieren. So werden regionale oder unternehmensspezifische Engpässe, Unterschiede bei der Compliance und Möglichkeiten zur globalen Prozessstandardisierung sichtbar. Das Attribut unterstützt direkt das Dashboard „Analyse der Verzögerung zwischen Genehmigung und Buchung“. Warum das wichtig ist Das Attribut ermöglicht Leistungsvergleiche und unterstützt die Standardisierung von Prozessen über verschiedene juristische Personen oder Geschäftseinheiten hinweg. Woher beziehen Dies ist ein wichtiges Feld im Kopf des Buchungssatzes in BlackLine und wird häufig mit dem zugrunde liegenden ERP-System synchronisiert. Beispiele 1000US01DE012500
	Buchungssatztyp JournalEntryType	Klassifizierung des Buchungssatzes, zum Beispiel als Standard-, wiederkehrender oder Stornobuchungssatz.
Beschreibung Der Buchungssatztyp ordnet Buchungssätze nach ihrer Art oder ihrem Zweck ein. Zu den gängigen Typen zählen manuelle Standardbuchungen, automatisch vom System erzeugte Buchungen, wiederkehrende Buchungen für Abgrenzungen zum Monatsende und Stornobuchungen, die sich in der nächsten Periode automatisch umkehren. Dieses Attribut ist wichtig für Segmentierungen und Vergleichsanalysen. Damit können Sie die Prozessleistung, etwa Zykluszeiten oder Ablehnungsquoten, für verschiedene Buchungssatztypen vergleichen. So erkennen Sie, ob bestimmte Typen häufiger Probleme verursachen oder weniger effizient verarbeitet werden, und können gezielte Prozessverbesserungen einleiten. Warum das wichtig ist Das Attribut ermöglicht segmentierte Analysen, mit denen Sie erkennen, ob verschiedene Buchungssatztypen unterschiedliche Prozesspfade oder Leistungsmerkmale aufweisen. Woher beziehen Dies ist ein Standardfeld im Kopf des Buchungssatzes in BlackLine. Den genauen Feldnamen finden Sie in der BlackLine-Dokumentation. Beispiele StandardWiederkehrendStornierendAbgrenzung
	Status des Buchungssatzes JournalEntryStatus	Aktueller Status des Buchungssatzes in seinem Lebenszyklus, zum Beispiel „In Bearbeitung“, „Genehmigt“ oder „Gebucht“.
Beschreibung Dieses Attribut zeigt den aktuellen Status eines Buchungssatzes zum Zeitpunkt der Datenextraktion. Es gibt einen Überblick darüber, an welcher Stelle des Gesamtprozesses sich der Satz befindet. Process Mining rekonstruiert den Ablauf anhand der Aktivitäten. Der endgültige Status ist dennoch hilfreich, um Daten zu filtern und zusammenfassende Dashboards zu erstellen. So lassen sich Buchungssätze, deren Genehmigung noch aussteht oder die in einem bestimmten Status festhängen, schnell erkennen. Das ist besonders für die Rückstandsanalysen nützlich. Warum das wichtig ist Das Attribut zeigt den aktuellen Status der Buchungssätze. Das ist hilfreich für Rückstandsanalysen und um laufende Arbeiten nachzuvollziehen. Woher beziehen Dies ist ein Standardstatusfeld des Buchungssatzes in BlackLine. Beispiele In BearbeitungGenehmigung ausstehendGenehmigtGebuchtAbgelehnt
	Abteilung Department	Geschäftsabteilung oder Kostenstelle, der der Buchungssatz zugeordnet ist.
Beschreibung Dieses Attribut gibt die Abteilung, Kostenstelle oder den Funktionsbereich an, von dem der Buchungssatz ausgeht oder dem die Kosten zugeordnet werden. Es ergänzt den organisatorischen Kontext. Die Analyse nach Abteilung zeigt, wie verschiedene Unternehmensbereiche den Prozess der Buchungssatzerfassung nutzen. Sie kann Unterschiede bei Effizienz, Compliance oder Nacharbeitsquoten aufdecken und Bereiche sichtbar machen, die zusätzliche Unterstützung oder standardisierte Prozesse benötigen. Warum das wichtig ist Das Attribut ermöglicht den Vergleich der Prozessleistung zwischen verschiedenen Geschäftsabteilungen. So werden Unterschiede und Möglichkeiten zur Standardisierung sichtbar. Woher beziehen Diese Information ist üblicherweise in den Positions- oder Kopfdaten des Buchungssatzes in BlackLine enthalten und häufig mit dem Hauptbuchkonto verknüpft. Beispiele FinanzenMarketingVertriebBetrieb
	Automatisiert IsAutomated	Kennzeichnet, ob der Buchungssatz durch einen automatisierten Prozess erstellt oder gebucht wurde.
Beschreibung Dieses boolesche Attribut unterscheidet zwischen Buchungssätzen, die Benutzer manuell erstellen und verarbeiten, und solchen, die automatisch vom System erzeugt werden, etwa wiederkehrenden Buchungen oder Buchungen aus Systemintegrationen. Die Analyse dieses Attributs hilft, die Wirksamkeit der Automatisierung zu bewerten. Zykluszeiten, Fehlerquoten und Kosten manueller und automatisierter Prozesse lassen sich direkt vergleichen. Das ist wichtig, um weitere Automatisierungsvorhaben wirtschaftlich zu begründen und den ROI bestehender Initiativen zu messen. Warum das wichtig ist Das Attribut ermöglicht den direkten Vergleich manueller und automatisierter Prozesse. Das ist entscheidend, um die Auswirkungen und den ROI von Automatisierungsinitiativen zu messen. Woher beziehen Das Attribut lässt sich aus dem „Buchungssatztyp“ ableiten, zum Beispiel „Wiederkehrend“, oder aus dem Feld „Benutzer“, wenn für automatisierte Buchungen Systembenutzer wie „SYSTEM“ oder „BATCH“ verwendet werden. Beispiele truefalse
	Beleg angehängt IsDocumentAttached	Kennzeichnet, ob Belege an den Buchungssatz angehängt wurden.
Beschreibung Dieses boolesche Attribut gibt an, ob dem Buchungssatz ein oder mehrere Belege, etwa Rechnungen oder Berechnungen, beigefügt wurden. Dies ist häufig Voraussetzung für die Genehmigung. Die Kennzeichnung ist wichtig für das Dashboard „Compliance bei der Dokumentation von Buchungssätzen“ und die KPI „Anteil der Buchungssätze mit angehängten Belegen“. Sie hilft zu analysieren, ob fehlende Belege häufig zu Ablehnungen oder Verzögerungen führen, und unterstützt die Durchsetzung von Richtlinien, nach denen Belege vor der Einreichung zur Prüfung angehängt werden müssen. Warum das wichtig ist Das Attribut misst direkt die Einhaltung der Dokumentationsrichtlinien und hilft, eine häufige Ursache für Verzögerungen und Ablehnungen bei der Genehmigung zu ermitteln. Woher beziehen Dieses Feld wird wahrscheinlich abgeleitet. Dazu wird geprüft, ob vor der Einreichungsaktivität ein Anhangsdatensatz zur JournalEntryId vorhanden ist. Beispiele truefalse
	Buchungsdatum PostingDate	Datum, an dem der Buchungssatz offiziell im Hauptbuch gebucht wird.
Beschreibung Das Buchungsdatum ist das Wirksamkeitsdatum der Transaktion in den Finanzunterlagen. Es ist für die Buchhaltung entscheidend, da es festlegt, in welcher Geschäftsperiode die Transaktion erfasst wird. Der Ereignis-Timestamp gibt an, wann die Buchungsaktivität stattgefunden hat. Das Buchungsdatum selbst ist dagegen ein wichtiges Datenattribut. Es wird in der Finanzanalyse verwendet, um sicherzustellen, dass Buchungssätze der richtigen Periode zugeordnet sind. Außerdem lassen sich damit Verzögerungen zwischen Transaktions-, Genehmigungs- und Buchungsdatum analysieren. Warum das wichtig ist Dieses Datum ist entscheidend für die Genauigkeit der Finanzberichterstattung. Es hilft zu prüfen, ob Buchungssätze in der richtigen Buchungsperiode erfasst werden. Woher beziehen Dies ist ein Standarddatumsfeld im Kopf des Buchungssatzes in BlackLine. Beispiele 2023-10-312023-11-012023-10-30
	Konto abgestimmt AccountReconciled	Hauptbuchkontonummer des Kontos, das mit dem Buchungssatz abgestimmt wird.
Beschreibung Dieses Attribut kennzeichnet das konkrete Konto im Kontenplan, das vom Buchungssatz betroffen ist oder abgestimmt wird. Buchungssätze sind häufig Teil der Kontenabstimmung. Dieses Attribut verknüpft den Satz mit dem betreffenden Konto. Das Attribut unterstützt direkt das Dashboard „Zykluszeit der Kontenabstimmung für Buchungssätze“. Durch die Analyse nach Konto lässt sich erkennen, ob Abstimmungen für bestimmte Konten regelmäßig länger dauern. Das kann auf komplexe Sachverhalte oder Datenprobleme bei diesen Konten hinweisen. Warum das wichtig ist Das Attribut verknüpft den Prozess der Buchungssatzerfassung mit den abgestimmten Konten und ermöglicht eine gezielte Analyse von Engpässen bei der Abstimmung. Woher beziehen Diese Information ist in den Positionsdetails des Buchungssatzes in BlackLine enthalten. Betrifft ein Buchungssatz mehrere Konten, müssen die Daten möglicherweise auf Case-Ebene zusammengefasst werden. Beispiele 101000210500400100550200
	Nacharbeit IsRework	Berechnete Kennzeichnung, die angibt, ob der Buchungssatz mindestens einmal abgelehnt wurde.
Beschreibung Diese boolesche Kennzeichnung wird berechnet, um Buchungssätze mit Nacharbeit zu erkennen. Sie wird üblicherweise auf „true“ gesetzt, wenn ein Case die Aktivität „Buchungssatz abgelehnt“ und anschließend „Korrigiert und erneut eingereicht“ enthält. Das Attribut vereinfacht die Nacharbeitsanalyse, da Benutzer alle Cases mit mindestens einer Ablehnung gezielt filtern können. Es ist wichtig für die Berechnung der KPI „Ablehnungsquote bei Buchungssätzen“ und für Detailanalysen im Dashboard „Analyse von Ablehnungen und Nacharbeiten bei Buchungssätzen“. So lassen sich die zeitlichen und finanziellen Auswirkungen von Qualitätsproblemen nachvollziehen. Warum das wichtig ist Das Attribut kennzeichnet Cases mit Nacharbeit und vereinfacht so die Berechnung der Ablehnungsquote sowie die Analyse der Auswirkungen von Qualitätsproblemen. Woher beziehen Diese Kennzeichnung wird im Process-Mining-Tool berechnet, indem die Aktivitätsabfolge für jeden Case geprüft wird. Beispiele truefalse
	Verzögerung zwischen Genehmigung und Buchung ApprovalToPostingLag	Berechnete Dauer zwischen der endgültigen Genehmigung und der tatsächlichen Buchung des Buchungssatzes.
Beschreibung Diese Kennzahl misst die Verzögerung zwischen der vollständigen Genehmigung eines Buchungssatzes und seiner Buchung im Hauptbuch. Sie wird als Zeitdifferenz zwischen den Aktivitäten „Buchungssatz genehmigt“ und „Buchungssatz gebucht“ berechnet. Die KPI ist entscheidend, um Engpässe nach der Genehmigung zu erkennen, die den Finanzabschluss erheblich verzögern können. Das Dashboard „Analyse der Verzögerung zwischen Genehmigung und Buchung“ verwendet diese Kennzahl, um zu untersuchen, warum genehmigte Buchungssätze nicht zeitnah gebucht werden. So lassen sich die letzten Prozessschritte gezielt verbessern. Warum das wichtig ist Die Kennzahl misst gezielt die Effizienz nach der Genehmigung. So lassen sich Verzögerungen erkennen und beseitigen, die den Finanzabschluss verlangsamen. Woher beziehen Diese Kennzahl wird im Process-Mining-Tool berechnet, indem für jeden Case die Dauer zwischen den Ereignissen „Buchungssatz genehmigt“ und „Buchungssatz gebucht“ ermittelt wird. Beispiele P0DT1H10MP1DT2H0MP0DT0H5M
	Währung Currency	Währungscode des im Buchungssatz angegebenen Betrags.
Beschreibung Dieses Attribut gibt die Währung des Buchungssatzbetrags an, zum Beispiel USD, EUR oder GBP. Es ist erforderlich, um den finanziellen Wert der Transaktionen korrekt einzuordnen. Für multinationale Unternehmen liefert eine Analyse nach Währung hilfreichen Kontext. Sie ermöglicht es, die Prozessanalyse auf bestimmte Währungen zu beschränken, und ist für jedes Dashboard erforderlich, das Finanzbeträge zusammenfasst. Warum das wichtig ist Das Attribut liefert den erforderlichen Kontext zu den Finanzbeträgen. So lassen sich diese korrekt interpretieren und währungsspezifisch analysieren. Woher beziehen Dies ist ein Standardfeld im Kopf des Buchungssatzes in BlackLine. Es heißt üblicherweise „Belegwährung“ oder ähnlich. Beispiele USDEURGBPJPY

Erforderlich Empfohlen Optional

Aktivitäten im Record-to-Report-Prozess mit Buchungsbelegen

Erfassen Sie diese wichtigen Prozessschritte und Meilensteine in Ihrem Event Log, damit Sie Ihren Buchungsbelegprozess zuverlässig entdecken und analysieren können.

6 Empfohlen 6 Optional

	Aktivität	Beschreibung
	Buchungssatz abgestimmt	Kennzeichnet den Abschluss des Lebenszyklus: Der Buchungssatz ist in einer abgeschlossenen und zertifizierten Kontenabstimmung enthalten. In BlackLine entspricht dies der Zertifizierung der Abstimmung, in der der Buchungssatz enthalten ist.
Warum das wichtig ist Diese Aktivität bildet den Endpunkt des durchgängigen Prozesses. Die Zeit zwischen „Buchungssatz gebucht“ und „Abgestimmt“ zeigt, wie effizient die Kontenabstimmung im Rahmen des Finanzabschlusses abläuft. Woher beziehen Dieses Ereignis wird abgeleitet, indem im BlackLine-Modul Account Reconciliation erkannt wird, wann sich der Status der Kontenabstimmung mit dem betreffenden Buchungssatz zu „Zertifiziert“ ändert. Erfassung Abgeleitet, indem der Buchungssatz mit der zugehörigen Kontenabstimmung verknüpft und das Zertifizierungsdatum dieser Abstimmung erfasst wird. Ereignistyp inferred
	Buchungssatz gebucht	Bezeichnet den Zeitpunkt, zu dem der genehmigte Buchungssatz offiziell im Hauptbuch erfasst wird. In BlackLine erfolgt dies häufig über eine explizite Aktion, die den Status des Satzes anschließend auf „Gebucht“ setzt.
Warum das wichtig ist Dieser wichtige Meilenstein gilt häufig als operativer Abschluss des Prozesses. Die Zeitspanne zwischen „Buchungssatz genehmigt“ und dieser Aktivität ist ein wichtiger Indikator für die Effizienz nach der Genehmigung. Woher beziehen Das Ereignis wird üblicherweise aus einem Statuswechsel zu „Gebucht“ abgeleitet. Es kann auch explizit in einer Buchungshistorie oder einem Audit-Trail mit Buchungsdatum und Timestamp protokolliert sein. Erfassung Abgeleitet aus dem Timestamp, zu dem der Status des Buchungssatzes auf „Gebucht“ gesetzt wird. Auch das Buchungsdatum ist relevant. Ereignistyp inferred
	Buchungssatz genehmigt	Diese Aktivität zeigt an, dass der Buchungssatz alle erforderlichen Prüfungs- und Genehmigungsschritte durchlaufen hat. Sie wird erfasst, wenn der letzte autorisierte Benutzer den Satz genehmigt und dadurch den Status auf „Genehmigt“ setzt.
Warum das wichtig ist Dieser wichtige Meilenstein schließt den Genehmigungsprozess ab. Die Zeit zwischen „Buchungssatz eingereicht“ und diesem Ereignis entspricht der „Genehmigungszykluszeit“, einer zentralen KPI zur Messung der Workflow-Effizienz. Woher beziehen Das Ereignis wird aus einem Statuswechsel des Buchungssatzes zu „Genehmigt“ abgeleitet. Die Benutzer-ID des letzten Genehmigenden und der Genehmigungszeitpunkt werden üblicherweise im Audit-Verlauf von BlackLine protokolliert. Erfassung Abgeleitet aus dem Timestamp, zu dem der Status des Buchungssatzes auf „Genehmigt“ gesetzt wird. Ereignistyp inferred
	Journalbuchung abgelehnt	Diese Aktivität kennzeichnet die Ablehnung einer Journalbuchung durch eine prüfende oder freigebende Person. Sie wird erfasst, wenn ein Benutzer die Aktion „Ablehnen“ ausführt. Dadurch ändert sich der Status der Buchung zu „Abgelehnt“, und die Aktion wird im Prüfprotokoll festgehalten.
Warum das wichtig ist Diese Aktivität ist wichtig, um Nacharbeit, Qualitätsprobleme und Schulungsbedarf zu erkennen. Die Häufigkeit und Gründe von Ablehnungen sowie die anschließenden Korrekturschleifen zu analysieren, ist entscheidend für Prozessverbesserungen und kürzere Durchlaufzeiten. Woher beziehen Dieses Ereignis wird üblicherweise aus einer Statusänderung zu „Abgelehnt“ oder „Korrektur erforderlich“ in den Journalbuchungsdaten abgeleitet. BlackLine protokolliert den Timestamp und den Benutzer, der die Ablehnung vorgenommen hat, im Verlauf. Erfassung Abgeleitet aus dem Timestamp, zu dem der Status der Journalbuchung auf „Abgelehnt“ gesetzt wird. Ereignistyp inferred
	Journalbuchung eingereicht	Diese Aktivität tritt auf, wenn die vorbereitende Person die Journalbuchung offiziell zur Prüfung und Freigabe einreicht. Sie wird üblicherweise als Statusänderung erfasst, zum Beispiel von „In Vorbereitung“ zu „Eingereicht“, zusammen mit einem Timestamp.
Warum das wichtig ist Damit endet die Vorbereitungsphase und der Freigabezyklus beginnt. Dieser wichtige Meilenstein dient dazu, die Dauer der Vorbereitungs- und Freigabephasen zu messen. Woher beziehen Dieses Ereignis lässt sich wahrscheinlich aus einer Statusänderung im Journalbuchungsdatensatz in BlackLine ableiten. Der Timestamp der Änderung zu „Zur Freigabe eingereicht“ oder einem ähnlichen Wert kennzeichnet den Ereigniszeitpunkt. Erfassung Abgeleitet aus dem Timestamp, zu dem das Statusfeld der Journalbuchung auf „Eingereicht“ oder „Freigabe ausstehend“ gesetzt wird. Ereignistyp inferred
	Journalbuchung erstellt	Diese Aktivität kennzeichnet den Beginn eines Falls für eine Journalbuchung. Sie wird erfasst, wenn ein Benutzer in BlackLine einen neuen Journalbuchungsdatensatz erstellt. Dabei wird eine eindeutige Journalbuchungs-ID vergeben und der Erstellungs-Timestamp sowie der Benutzer protokolliert.
Warum das wichtig ist Dies ist das primäre Start-Event des Prozesses. Die Zeitspanne von dieser Aktivität bis zu anderen Aktivitäten zeigt die gesamte Durchlaufzeit und hilft, Verzögerungen gleich zu Beginn des Workflows zu erkennen. Woher beziehen Dieses Ereignis wird im Journalbuchungsmodul von BlackLine ausdrücklich protokolliert. Es wird anhand des Erstellungs-Timestamps und der Benutzerdaten erfasst, die für jede Journalbuchungs-ID in der Haupttabelle der Journalbuchungen oder im Prüfverlauf hinterlegt sind. Erfassung Erfasst anhand des mit dem Journalbuchungsdatensatz verknüpften Timestamps „Erstellungsdatum“. Ereignistyp explicit
	Belege angehängt	Diese Aktivität bezeichnet das Anhängen eines oder mehrerer Belege an eine Journalbuchung durch einen Benutzer. Das Ereignis wird üblicherweise in einem Prüfprotokoll oder einer mit der Journalbuchungs-ID verknüpften Anlagentabelle erfasst.
Warum das wichtig ist Die Erfassung dieser Aktivität ist wichtig, um Compliance und Effizienz zu überwachen. Sie hilft zu prüfen, ob fehlende Belege Verzögerungen im Freigabeprozess verursachen, und unterstützt die KPI „Anteil der Buchungen mit angehängten Belegen“. Woher beziehen In der Regel wird dieses Ereignis ausdrücklich in BlackLine protokolliert, etwa im Prüfpfad oder im Anlagenprotokoll. Die Daten umfassen die Journalbuchungs-ID, den Benutzer, der die Datei angehängt hat, und einen Timestamp. Erfassung Das Ereignis wird im Prüfpfad des Systems oder in einer eigenen Tabelle zum Anlagenverlauf protokolliert, sobald eine Datei an eine Journalbuchung angehängt wird. Ereignistyp explicit
	Buchung bestätigt	Bestätigt, dass ein gebuchter Buchungssatz erfolgreich im Ziel-ERP-System eingegangen und dort erfasst wurde. Dies kann durch einen automatisierten System-Handshake oder eine manuelle Bestätigung erfolgen.
Warum das wichtig ist Diese Aktivität schließt den Buchungsschritt ab und stellt die Datenintegrität zwischen den Systemen sicher. Die Dauer zwischen „Gebucht“ und „Bestätigt“ kann auf Integrationsprobleme oder Verzögerungen bei der Systemsynchronisierung hinweisen. Woher beziehen Das Ereignis kann explizit in einem Systemintegrationsprotokoll erfasst oder aus einem Statuswechsel zu einem Wert wie „Gebucht und bestätigt“ abgeleitet werden. Bei einer manuellen Bestätigung wird der Status von einem Benutzer aktualisiert. Erfassung Abgeleitet aus einer Statusänderung zu „Bestätigt“ oder aus einer Bestätigungskennzeichnung des Ziel-ERP-Systems. Ereignistyp inferred
	Buchung korrigiert und erneut eingereicht	Tritt ein, nachdem ein Buchungssatz abgelehnt wurde und die erfassende Person die erforderlichen Korrekturen vorgenommen und den Satz erneut eingereicht hat. Erkennbar ist dies an einem Statuswechsel von „Abgelehnt“ zurück zu „Zur Genehmigung eingereicht“.
Warum das wichtig ist Diese Aktivität hilft dabei, den Zeit- und Arbeitsaufwand für Nacharbeiten zu quantifizieren. Die Dauer zwischen „Buchungssatz abgelehnt“ und diesem Ereignis entspricht der Nacharbeitszeit und ist eine wichtige Kennzahl für die Effizienzanalyse. Woher beziehen Das Ereignis wird anhand einer Abfolge von Statusänderungen in den BlackLine-Daten abgeleitet. Konkret wechselt der Status desselben Buchungssatzes von „Abgelehnt“ zurück zu „Eingereicht“ oder „Genehmigung ausstehend“. Erfassung Abgeleitet aus einem Statuswechsel von „Abgelehnt“ zu „Eingereicht“ oder „Genehmigung ausstehend“. Ereignistyp inferred
	Genehmigung zurückgezogen	Diese Aktivität steht dafür, dass ein Genehmigender eine zuvor erteilte Genehmigung zurücknimmt und den Buchungssatz damit in einen früheren Status versetzt. Erkennbar ist dies an einem Statuswechsel von „Genehmigt“ zurück zu einem früheren Status wie „In Vorbereitung“.
Warum das wichtig ist Diese seltene, aber wichtige Aktivität macht Prozessausnahmen und mögliche Probleme sichtbar, die nach der Genehmigung, aber vor der Buchung entdeckt werden. Sie kann auf Datenfehler oder Richtlinienänderungen hinweisen, die den Buchungssatz betreffen. Woher beziehen Dieses Ereignis wird abgeleitet, wenn der Status von „Genehmigt“ zu einem noch nicht gebuchten, bearbeitbaren Status wechselt. Die Aktion wird in den detaillierten Audit-Protokollen von BlackLine erfasst. Erfassung Erkennbar an einem Statuswechsel von „Genehmigt“ zurück zu einem vorherigen Status wie „In Vorbereitung“ oder „Eingereicht“. Ereignistyp inferred
	Journalbuchung geprüft	Diese Aktivität bezeichnet einen formellen Prüfschritt in einem mehrstufigen Freigabeprozess, der von einer dafür zuständigen prüfenden Person abgeschlossen wird. Sie wird üblicherweise als Statusänderung oder als eigener Protokolleintrag zur Aktion der prüfenden Person erfasst.
Warum das wichtig ist Bei Unternehmen mit getrennten Prüfungs- und Freigabeschritten hilft diese Aktivität, Engpässe innerhalb der Freigabekette zu erkennen. Sie zeigt, wie lange Buchungen auf die Erstprüfung und anschließend auf die endgültige Freigabe warten. Woher beziehen In BlackLine-Workflows kann dieses Ereignis ausdrücklich im Freigabeverlauf protokolliert oder aus einer Statusänderung zu „Geprüft“ oder „Endgültige Freigabe ausstehend“ abgeleitet werden. Benutzer und Timestamp werden erfasst. Erfassung Abgeleitet aus dem Timestamp, zu dem sich der Status der Journalbuchung ändert und den Abschluss der Prüfungsphase anzeigt. Ereignistyp inferred
	Rückbuchung des Buchungssatzes verarbeitet	Diese Aktivität erfasst die Erstellung und Buchung eines neuen Buchungssatzes, der einen zuvor gebuchten Satz storniert. Sie wird üblicherweise ausgelöst, wenn nach der ursprünglichen Buchung ein Fehler entdeckt wird.
Warum das wichtig ist Dieses Ereignis ist ein deutlicher Hinweis auf Probleme mit der Datenqualität in vorgelagerten Prozessschritten. Die Rückbuchungsquote zeigt die „Anpassungsquote nach der Buchung“ und macht Bereiche sichtbar, in denen eine höhere Genauigkeit erforderlich ist. Woher beziehen Häufig wird dieses Ereignis explizit erfasst, wenn ein Benutzer in BlackLine für einen gebuchten Buchungssatz die Aktion „Stornieren“ ausführt. Das System erstellt einen neuen Stornobuchungssatz, der oft mit der ID des ursprünglichen Buchungssatzes verknüpft ist. Erfassung Erfasst, wenn eine Aktion „Stornieren“ protokolliert wird oder ein neuer Buchungssatz mit Stornokennzeichnung und Verknüpfung zur ID des ursprünglichen Buchungssatzes erstellt wird. Ereignistyp explicit

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus BlackLine

Schritte

Melden Sie sich mit einem Benutzerkonto, das über die erforderlichen Berechtigungen für Finanzberichte verfügt, bei Ihrer BlackLine-Instanz an.
Öffnen Sie das Berichtsmodul. Sie finden es üblicherweise unter einem Menüpunkt wie „Berichte“ > „Standardberichte“.
Suchen Sie in der Liste der verfügbaren Standardberichte nach „Journal Entry & Services Report“ oder einem ähnlich benannten umfassenden Bericht zu Buchungsbelegen und wählen Sie ihn aus.
Legen Sie die Berichtsparameter fest. Geben Sie den gewünschten „Datumsbereich“ für den Export an. Er sollte dem Zeitraum entsprechen, den Sie analysieren möchten. Für den Anfang empfiehlt sich ein Zeitraum von 3 bis 6 Monaten.
Wenden Sie die erforderlichen Filter an, um die Daten einzugrenzen. Filtern Sie mindestens nach den relevanten „Buchungskreisen“. Sie können außerdem nach „Buchungsstatus“ filtern, damit alle relevanten Status von der Erstellung bis zur Buchung enthalten sind.
Wählen Sie alle verfügbaren Spalten für die Ausgabe aus. So enthält der Bericht alle erforderlichen Datums-, Benutzer- und Statusfelder für die Erstellung des Event Logs. Zu den wichtigen Feldern gehören Erstellungsdatum, Einreichungsdatum, Genehmigungsdatum, Buchungsdatum und Benutzerrollen.
Führen Sie den Bericht direkt in der BlackLine-Benutzeroberfläche aus. Sobald er erstellt wurde, speichern Sie die Daten über die Funktion „Export“ oder „Download“ als CSV-Datei. Nennen Sie die Datei „blackline_report.csv“.
Richten Sie eine Python-Umgebung mit der installierten pandas-Bibliothek ein. Falls pandas noch nicht installiert ist, installieren Sie die Bibliothek mit dem Befehl: pip install pandas.
Speichern Sie das bereitgestellte Python-Skript im selben Verzeichnis wie die heruntergeladene Datei „blackline_report.csv“.
Führen Sie das Python-Skript aus. Es liest den CSV-Rohbericht ein, wandelt die Daten um, indem es für jede Geschäftsaktivität eine eigene Zeile erstellt, und erzeugt eine neue Datei namens „event_log.csv“ im erforderlichen Format.
Prüfen Sie die Datei „event_log.csv“ auf Datenqualität und Vollständigkeit, bevor Sie sie hochladen.
Laden Sie die fertige Datei „event_log.csv“ zur Analyse in ProcessMind hoch.

Konfiguration

Berichtsname: Journal Entry & Services Report. Der genaue Name kann je nach Ihrer BlackLine-Konfiguration abweichen.
Datumsbereich: Für eine erste Analyse empfiehlt sich ein Datenexport über 3 bis 6 Monate. Der Datumsfilter des Berichts bezieht sich üblicherweise auf das Erstellungs- oder Buchungsdatum des Buchungsbelegs. Klären Sie, welches Datumsfeld als Filter verwendet wird, damit der richtige Datensatz exportiert wird.
Wichtige Filter:
- Buchungskreis: Geben Sie immer die Buchungskreise an, die Sie analysieren möchten. So begrenzen Sie das Datenvolumen und richten die Analyse gezielt aus.
- Buchungsstatus: Wählen Sie alle Status aus, zum Beispiel In Vorbereitung, Eingereicht, Genehmigt, Abgelehnt und Gebucht. So erfassen Sie den gesamten Prozess.
- Buchungsbelegtyp: Filtern Sie bei Bedarf nach bestimmten Buchungsbelegtypen, etwa Standard oder Wiederkehrend, um den Analyseumfang festzulegen.
Voraussetzungen: Das Benutzerkonto, mit dem der Bericht ausgeführt wird, muss über die Berechtigung verfügen, Buchungsbelegdaten einzusehen und Standardberichte in BlackLine auszuführen. Dafür ist üblicherweise eine Rolle wie „Buchhalter“ oder „Berichtsbenutzer“ erforderlich.
Leistungshinweise: Der Export eines großen Datensatzes über einen langen Zeitraum oder für zahlreiche Buchungskreise kann viele Ressourcen beanspruchen und in der BlackLine-Benutzeroberfläche längere Zeit in Anspruch nehmen. Bei Leistungsproblemen oder Zeitüberschreitungen empfiehlt es sich, den Bericht in kleineren Abschnitten auszuführen.

a Beispielabfrage python

import pandas as pd
import numpy as np
import datetime

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Define the input file name from BlackLine
input_filename = class="hl-string">'blackline_report.csv'
class=class="hl-string">"hl-comment"># Define the output file for ProcessMind
output_filename = class="hl-string">'event_log.csv'

class=class="hl-string">"hl-comment"># --- Column Mapping ---
class=class="hl-string">"hl-comment"># Map the BlackLine report column names to the required event log attribute names.
class=class="hl-string">"hl-comment"># Adjust the keys in this dictionary to match the exact column headers in your CSV export.
column_mapping = {
    class="hl-string">'Journal ID': class="hl-string">'JournalEntryId',
    class="hl-string">'Journal Type': class="hl-string">'JournalEntryType',
    class="hl-string">'Company': class="hl-string">'CompanyCode',
    class="hl-string">'Amount': class="hl-string">'JournalEntryAmount',
    class="hl-string">'Current Status': class="hl-string">'JournalEntryStatus',
    class="hl-string">'Rejection Reason': class="hl-string">'RejectionReason',
    class="hl-string">'Preparer': class="hl-string">'PreparerUserName',
    class="hl-string">'Submitter': class="hl-string">'SubmitterUserName',
    class="hl-string">'Reviewer': class="hl-string">'ReviewerUserName',
    class="hl-string">'Approver': class="hl-string">'ApproverUserName',
    class="hl-string">'Poster': class="hl-string">'PosterUserName',
    class="hl-string">'Verifier': class="hl-string">'VerifierUserName',
    class="hl-string">'Reverser': class="hl-string">'ReverserUserName',
    class="hl-string">'Reconciler': class="hl-string">'ReconcilerUserName',
    class="hl-string">'Creation Date': class="hl-string">'CreationTimestamp',
    class="hl-string">'Attachment Date': class="hl-string">'AttachmentTimestamp',
    class="hl-string">'Submission Date': class="hl-string">'SubmissionTimestamp',
    class="hl-string">'Review Date': class="hl-string">'ReviewTimestamp',
    class="hl-string">'Rejection Date': class="hl-string">'RejectionTimestamp',
    class="hl-string">'Resubmission Date': class="hl-string">'ResubmissionTimestamp',
    class="hl-string">'Approval Date': class="hl-string">'ApprovalTimestamp',
    class="hl-string">'Rescind Date': class="hl-string">'RescindTimestamp',
    class="hl-string">'Posting Date': class="hl-string">'PostingTimestamp',
    class="hl-string">'Verification Date': class="hl-string">'VerificationTimestamp',
    class="hl-string">'Reversal Date': class="hl-string">'ReversalTimestamp',
    class="hl-string">'Reconciliation Date': class="hl-string">'ReconciliationTimestamp'
}

class=class="hl-string">"hl-comment"># --- Data Loading ---
try:
    df_raw = pd.read_csv(input_filename)
except FileNotFoundError:
    print(fclass="hl-string">"Error: The file {input_filename} was not found. Please ensure it's in the same directory as the script.")
    exit()

class=class="hl-string">"hl-comment"># Rename columns based on the mapping
df = df_raw.rename(columns=column_mapping)

class=class="hl-string">"hl-comment"># Ensure all required timestamp columns exist, fill with NaT if not
for col in column_mapping.values():
    if class="hl-string">'Timestamp' in col and col not in df.columns:
        df[col] = pd.NaT

class=class="hl-string">"hl-comment"># Convert date columns to datetime objects, coercing errors to NaT (Not a Time)
date_cols = [col for col in df.columns if class="hl-string">'Timestamp' in col]
for col in date_cols:
    df[col] = pd.to_datetime(df[col], errors=class="hl-string">'coerce')

all_events = []
last_data_update = datetime.datetime.now()

class=class="hl-string">"hl-comment"># --- Activity Extraction ---

class=class="hl-string">"hl-comment"># 1. Journal Entry Created
event_created = df[df[class="hl-string">'CreationTimestamp'].notna()].copy()
event_created[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Created'
event_created[class="hl-string">'EventTime'] = event_created[class="hl-string">'CreationTimestamp']
event_created[class="hl-string">'UserName'] = event_created.get(class="hl-string">'PreparerUserName')
all_events.append(event_created)

class=class="hl-string">"hl-comment"># 2. Supporting Documentation Attached
if class="hl-string">'AttachmentTimestamp' in df.columns:
    event_attached = df[df[class="hl-string">'AttachmentTimestamp'].notna()].copy()
    event_attached[class="hl-string">'ActivityName'] = class="hl-string">'Supporting Documentation Attached'
    event_attached[class="hl-string">'EventTime'] = event_attached[class="hl-string">'AttachmentTimestamp']
    class=class="hl-string">"hl-comment"># Assuming the submitter or preparer attached the document
    event_attached[class="hl-string">'UserName'] = event_attached.get(class="hl-string">'SubmitterUserName', event_attached.get(class="hl-string">'PreparerUserName'))
    all_events.append(event_attached)

class=class="hl-string">"hl-comment"># 3. Journal Entry Submitted
event_submitted = df[df[class="hl-string">'SubmissionTimestamp'].notna()].copy()
event_submitted[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Submitted'
event_submitted[class="hl-string">'EventTime'] = event_submitted[class="hl-string">'SubmissionTimestamp']
event_submitted[class="hl-string">'UserName'] = event_submitted.get(class="hl-string">'SubmitterUserName')
all_events.append(event_submitted)

class=class="hl-string">"hl-comment"># 4. Journal Entry Reviewed
if class="hl-string">'ReviewTimestamp' in df.columns:
    event_reviewed = df[df[class="hl-string">'ReviewTimestamp'].notna()].copy()
    event_reviewed[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Reviewed'
    event_reviewed[class="hl-string">'EventTime'] = event_reviewed[class="hl-string">'ReviewTimestamp']
    event_reviewed[class="hl-string">'UserName'] = event_reviewed.get(class="hl-string">'ReviewerUserName')
    all_events.append(event_reviewed)

class=class="hl-string">"hl-comment"># 5. Journal Entry Rejected
if class="hl-string">'RejectionTimestamp' in df.columns:
    event_rejected = df[df[class="hl-string">'RejectionTimestamp'].notna()].copy()
    event_rejected[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Rejected'
    event_rejected[class="hl-string">'EventTime'] = event_rejected[class="hl-string">'RejectionTimestamp']
    event_rejected[class="hl-string">'UserName'] = event_rejected.get(class="hl-string">'ReviewerUserName', event_rejected.get(class="hl-string">'ApproverUserName'))
    all_events.append(event_rejected)

class=class="hl-string">"hl-comment"># 6. Entry Corrected and Resubmitted
if class="hl-string">'ResubmissionTimestamp' in df.columns:
    event_resubmitted = df[df[class="hl-string">'ResubmissionTimestamp'].notna()].copy()
    event_resubmitted = event_resubmitted[event_resubmitted[class="hl-string">'ResubmissionTimestamp'] > event_resubmitted.get(class="hl-string">'RejectionTimestamp', pd.NaT)]
    event_resubmitted[class="hl-string">'ActivityName'] = class="hl-string">'Entry Corrected and Resubmitted'
    event_resubmitted[class="hl-string">'EventTime'] = event_resubmitted[class="hl-string">'ResubmissionTimestamp']
    event_resubmitted[class="hl-string">'UserName'] = event_resubmitted.get(class="hl-string">'SubmitterUserName')
    all_events.append(event_resubmitted)

class=class="hl-string">"hl-comment"># 7. Journal Entry Approved
event_approved = df[df[class="hl-string">'ApprovalTimestamp'].notna()].copy()
event_approved[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Approved'
event_approved[class="hl-string">'EventTime'] = event_approved[class="hl-string">'ApprovalTimestamp']
event_approved[class="hl-string">'UserName'] = event_approved.get(class="hl-string">'ApproverUserName')
all_events.append(event_approved)

class=class="hl-string">"hl-comment"># 8. Approval Rescinded
if class="hl-string">'RescindTimestamp' in df.columns:
    event_rescinded = df[df[class="hl-string">'RescindTimestamp'].notna()].copy()
    event_rescinded[class="hl-string">'ActivityName'] = class="hl-string">'Approval Rescinded'
    event_rescinded[class="hl-string">'EventTime'] = event_rescinded[class="hl-string">'RescindTimestamp']
    event_rescinded[class="hl-string">'UserName'] = event_rescinded.get(class="hl-string">'ApproverUserName')
    all_events.append(event_rescinded)

class=class="hl-string">"hl-comment"># 9. Journal Entry Posted
event_posted = df[df[class="hl-string">'PostingTimestamp'].notna()].copy()
event_posted[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Posted'
event_posted[class="hl-string">'EventTime'] = event_posted[class="hl-string">'PostingTimestamp']
event_posted[class="hl-string">'UserName'] = event_posted.get(class="hl-string">'PosterUserName')
all_events.append(event_posted)

class=class="hl-string">"hl-comment"># 10. Posting Verified
if class="hl-string">'VerificationTimestamp' in df.columns:
    event_verified = df[df[class="hl-string">'VerificationTimestamp'].notna()].copy()
    event_verified[class="hl-string">'ActivityName'] = class="hl-string">'Posting Verified'
    event_verified[class="hl-string">'EventTime'] = event_verified[class="hl-string">'VerificationTimestamp']
    event_verified[class="hl-string">'UserName'] = event_verified.get(class="hl-string">'VerifierUserName')
    all_events.append(event_verified)

class=class="hl-string">"hl-comment"># 11. Journal Entry Reversal Processed
if class="hl-string">'ReversalTimestamp' in df.columns:
    event_reversal = df[df[class="hl-string">'ReversalTimestamp'].notna()].copy()
    event_reversal[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Reversal Processed'
    event_reversal[class="hl-string">'EventTime'] = event_reversal[class="hl-string">'ReversalTimestamp']
    event_reversal[class="hl-string">'UserName'] = event_reversal.get(class="hl-string">'ReverserUserName')
    all_events.append(event_reversal)

class=class="hl-string">"hl-comment"># 12. Journal Entry Reconciled
if class="hl-string">'ReconciliationTimestamp' in df.columns:
    event_reconciled = df[df[class="hl-string">'ReconciliationTimestamp'].notna()].copy()
    event_reconciled[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Reconciled'
    event_reconciled[class="hl-string">'EventTime'] = event_reconciled[class="hl-string">'ReconciliationTimestamp']
    event_reconciled[class="hl-string">'UserName'] = event_reconciled.get(class="hl-string">'ReconcilerUserName')
    all_events.append(event_reconciled)


class=class="hl-string">"hl-comment"># --- Final Assembly ---
if all_events:
    event_log = pd.concat(all_events, ignore_index=True)

    class=class="hl-string">"hl-comment"># Add required constant value attributes
    event_log[class="hl-string">'SourceSystem'] = class="hl-string">'BlackLine'
    event_log[class="hl-string">'LastDataUpdate'] = last_data_update

    class=class="hl-string">"hl-comment"># Select and order columns for the final output
    final_columns = [
        class="hl-string">'JournalEntryId',
        class="hl-string">'ActivityName',
        class="hl-string">'EventTime',
        class="hl-string">'SourceSystem',
        class="hl-string">'LastDataUpdate',
        class="hl-string">'UserName',
        class="hl-string">'JournalEntryType',
        class="hl-string">'CompanyCode',
        class="hl-string">'JournalEntryAmount',
        class="hl-string">'JournalEntryStatus',
        class="hl-string">'RejectionReason'
    ]

    class=class="hl-string">"hl-comment"># Filter for only the columns that exist in the dataframe to avoid errors
    existing_columns = [col for col in final_columns if col in event_log.columns]
    event_log = event_log[existing_columns]

    class=class="hl-string">"hl-comment"># Sort the event log
    event_log = event_log.sort_values(by=[class="hl-string">'JournalEntryId', class="hl-string">'EventTime'])

    class=class="hl-string">"hl-comment"># Save to CSV
    event_log.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%d %H:%M:%S')
    print(fclass="hl-string">"Successfully created event log: {output_filename}")
else:
    print(class="hl-string">"No events were generated. Please check your input file and column mappings.")

Schritte

Voraussetzungen und Einrichtung: Stellen Sie sicher, dass Python 3.6 oder höher installiert ist. Installieren Sie die erforderlichen Bibliotheken mit pip: pip install requests pandas. Besorgen Sie sich bei Ihrer BlackLine-Administration die API-Zugangsdaten (Client-ID, Client Secret und Refresh Token) sowie die BlackLine-Basis-URL Ihrer Organisation.
Skriptvariablen konfigurieren: Öffnen Sie das Python-Skript und suchen Sie den Konfigurationsabschnitt. Tragen Sie Ihre Client-ID, Ihr Client Secret, Ihren Refresh Token und die Basis-URL ein. Legen Sie den Extraktionszeitraum fest, indem Sie die Variablen START_DATE und END_DATE im Format „YYYY-MM-DD“ angeben.
Authentifizierung: Das Skript ruft zunächst die Funktion get_access_token auf. Diese übermittelt Ihre Zugangsdaten an den BlackLine-Authentifizierungsendpunkt (/api/oauth/token) und ruft ein temporäres Zugriffstoken ab, das für alle weiteren API-Anfragen erforderlich ist.
Erste Buchungsbelegliste abrufen: Das Skript sendet eine paginierte Anfrage an den Endpunkt /api/v2/journals und filtert nach dem angegebenen Erstellungszeitraum. Es ruft die Seiten nacheinander ab und erfasst die wichtigsten Angaben zu allen Buchungsbelegen im festgelegten Zeitraum.
Detaillierten Ereignisverlauf abrufen: Für jede im vorherigen Schritt erfasste Buchungsbeleg-ID führt das Skript zwei weitere API-Aufrufe aus. Zunächst fragt es den Verlauf des Buchungsbelegs ab, zum Beispiel über /api/v2/journals/{id}/history, um den detaillierten Prüfpfad mit Statusänderungen, Genehmigungen und Ablehnungen abzurufen. Anschließend fragt es den Anhang-Endpunkt ab, zum Beispiel /api/v2/journals/{id}/attachments, um festzustellen, wann Belege hinzugefügt wurden.
Daten in ein Event Log umwandeln: Das Skript verarbeitet die JSON-Antworten der API. Es durchläuft jeden Buchungsbeleg sowie die zugehörigen Verlaufs- und Anhangsdatensätze. Die Rohdaten werden in ein strukturiertes Event-Log-Format überführt, wobei für jede der 12 erforderlichen Aktivitäten eine eigene Zeile entsteht, etwa „Buchungsbeleg erstellt“, „Buchungsbeleg eingereicht“ und „Buchungsbeleg genehmigt“.
Statusänderungen Aktivitäten zuordnen: Das Skript leitet wichtige Aktivitäten aus den Daten des Verlaufsendpunkts ab. Ein Verlaufseintrag, der beispielsweise eine Statusänderung zu „Eingereicht“ enthält, wird zur Aktivität „Buchungsbeleg eingereicht“. Die Skriptlogik ordnet verschiedene Ereignistypen im Verlauf den standardisierten Aktivitätsnamen zu, die ProcessMind benötigt.
DataFrames erstellen: Das Skript verwendet die pandas-Bibliothek, um DataFrames zu erstellen. Zunächst wird aus der Buchungsbelegliste ein DataFrame für das Ereignis „Erstellt“ erzeugt. Ein weiterer DataFrame enthält alle übrigen Aktivitäten aus den Verlaufs- und Anhangsprotokollen. Anschließend werden beide zu einem vollständigen Event Log zusammengeführt.
Metadaten ergänzen und Spalten vereinheitlichen: Nach dem Zusammenführen der Daten ergänzt das Skript die erforderlichen Metadatenspalten, darunter SourceSystem (fest auf „BlackLine“ gesetzt) und LastDataUpdate (auf den Ausführungszeitpunkt des Skripts gesetzt). Außerdem benennt es Spalten passend zum erforderlichen Schema um, beispielsweise das API-Feld id in JournalEntryId.
Als CSV exportieren: Abschließend exportiert das Skript den fertigen Event-Log-DataFrame in eine CSV-Datei namens blackline_journal_entry_event_log.csv. Die Datei ist formatiert und kann direkt in ProcessMind hochgeladen werden.

Konfiguration

API-Zugangsdaten: Für die BlackLine-REST-API benötigen Sie eine gültige Client-ID, ein Client Secret und einen Refresh Token. Bewahren Sie diese sicher auf und hinterlegen Sie sie nicht direkt in produktiven Skripten.
Basis-URL: Das Skript benötigt die spezifische BlackLine-API-Basis-URL Ihrer Organisation, zum Beispiel https://api.blackline.com.
Datumsbereich: Im Skript sind die Variablen START_DATE und END_DATE festgelegt. Für eine erste Analyse empfiehlt sich ein Zeitraum, der die letzten 3 bis 6 Monate abdeckt. So erhalten Sie ausreichend Daten, ohne den Umfang unnötig zu vergrößern.
Seitengröße: Die Variable LIMIT legt fest, wie viele Datensätze pro API-Aufruf abgerufen werden. Der Standardwert beträgt üblicherweise 100. Eine Änderung kann sich auf die Leistung auswirken. Behalten Sie daher am besten den empfohlenen Wert bei, sofern der BlackLine-Support nichts anderes empfiehlt.
Erforderliche Berechtigungen: Der API-Benutzer, zu dem die Zugangsdaten gehören, muss über ausreichende Berechtigungen verfügen, um Buchungsbelege, deren Verlauf und Anhänge für die zu analysierenden Buchungskreise auszulesen.
Python-Umgebung: Voraussetzung für die Ausführung des Skripts ist eine funktionsfähige Python-Umgebung ab Version 3.6 mit den installierten Bibliotheken requests und pandas.

a Beispielabfrage python

import requests
import pandas as pd
from datetime import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your BlackLine API credentials and base URL
CLIENT_ID = class="hl-string">'[Your Client ID]'
CLIENT_SECRET = class="hl-string">'[Your Client Secret]'
REFRESH_TOKEN = class="hl-string">'[Your Refresh Token]'
BASE_URL = class="hl-string">'[Your BlackLine API Base URL, e.g., https://api.blackline.com]'

class=class="hl-string">"hl-comment"># --- Extraction Parameters ---
START_DATE = class="hl-string">'2023-01-01' class=class="hl-string">"hl-comment"># Format: YYYY-MM-DD
END_DATE = class="hl-string">'2023-12-31'   class=class="hl-string">"hl-comment"># Format: YYYY-MM-DD
LIMIT = 100 class=class="hl-string">"hl-comment"># Records per page

def get_access_token():
    class="hl-string">"""Authenticates with BlackLine to get an access token."""
    auth_url = fclass="hl-string">"{BASE_URL}/api/oauth/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'refresh_token',
        class="hl-string">'client_id': CLIENT_ID,
        class="hl-string">'client_secret': CLIENT_SECRET,
        class="hl-string">'refresh_token': REFRESH_TOKEN
    }
    response = requests.post(auth_url, data=payload)
    response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes
    return response.json()[class="hl-string">'access_token']

def main():
    class="hl-string">"""Main function to extract, transform, and save journal entry event data."""
    print(class="hl-string">"Starting BlackLine Journal Entry extraction...")
    
    try:
        access_token = get_access_token()
        headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}'}
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Authentication failed: {e}")
        return

    events = []
    last_data_update = datetime.utcnow().isoformat() + class="hl-string">'Z'

    class=class="hl-string">"hl-comment"># 1. Fetch all journals within the date range
    print(fclass="hl-string">"Fetching journals created between {START_DATE} and {END_DATE}...")
    journals = []
    offset = 0
    while True:
        journals_url = fclass="hl-string">"{BASE_URL}/api/v2/journals"
        params = {
            class="hl-string">'createdStartDate': START_DATE,
            class="hl-string">'createdEndDate': END_DATE,
            class="hl-string">'limit': LIMIT,
            class="hl-string">'offset': offset
        }
        try:
            response = requests.get(journals_url, headers=headers, params=params)
            response.raise_for_status()
            data = response.json()
            journals.extend(data.get(class="hl-string">'data', []))
            if class="hl-string">'nextLink' not in data or not data.get(class="hl-string">'data'):
                break
            offset += LIMIT
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching journals: {e}")
            break

    print(fclass="hl-string">"Found {len(journals)} journals. Now fetching detailed events for each...")

    class=class="hl-string">"hl-comment"># 2. For each journal, fetch history and attachments
    for journal in journals:
        journal_id = journal.get(class="hl-string">'id')
        if not journal_id:
            continue

        class=class="hl-string">"hl-comment"># --- Activity: Journal Entry Created ---
        events.append({
            class="hl-string">'JournalEntryId': journal_id,
            class="hl-string">'ActivityName': class="hl-string">'Journal Entry Created',
            class="hl-string">'EventTime': journal.get(class="hl-string">'createdDate'),
            class="hl-string">'UserName': journal.get(class="hl-string">'createdBy', {}).get(class="hl-string">'username'),
            class="hl-string">'JournalEntryType': journal.get(class="hl-string">'type'),
            class="hl-string">'CompanyCode': journal.get(class="hl-string">'companyCode'),
            class="hl-string">'JournalEntryAmount': journal.get(class="hl-string">'totalDebit'),
            class="hl-string">'JournalEntryStatus': journal.get(class="hl-string">'status'),
            class="hl-string">'RejectionReason': None
        })

        class=class="hl-string">"hl-comment"># Fetch history for other activities
        try:
            history_url = fclass="hl-string">"{BASE_URL}/api/v2/journals/{journal_id}/history"
            history_response = requests.get(history_url, headers=headers)
            history_response.raise_for_status()
            history_items = history_response.json().get(class="hl-string">'data', [])
            
            for item in history_items:
                activity_name = None
                rejection_reason = None
                
                class=class="hl-string">"hl-comment"># This mapping requires knowledge of your specific BlackLine history event descriptions
                class=class="hl-string">"hl-comment"># The following are common examples. Adjust them based on your BlackLine configuration.
                event_description = item.get(class="hl-string">'description', class="hl-string">'').lower()
                if class="hl-string">'submitted' in event_description:
                    activity_name = class="hl-string">'Journal Entry Submitted'
                elif class="hl-string">'reviewed' in event_description:
                    activity_name = class="hl-string">'Journal Entry Reviewed'
                elif class="hl-string">'rejected' in event_description:
                    activity_name = class="hl-string">'Journal Entry Rejected'
                    rejection_reason = item.get(class="hl-string">'comment') class=class="hl-string">"hl-comment"># Assuming comment contains the reason
                elif class="hl-string">'resubmitted' in event_description:
                    activity_name = class="hl-string">'Entry Corrected and Resubmitted'
                elif class="hl-string">'approved' in event_description and class="hl-string">'final' in event_description: class=class="hl-string">"hl-comment"># Example for final approval
                    activity_name = class="hl-string">'Journal Entry Approved'
                elif class="hl-string">'approval rescinded' in event_description:
                    activity_name = class="hl-string">'Approval Rescinded'
                elif class="hl-string">'posted' in event_description:
                    activity_name = class="hl-string">'Journal Entry Posted'
                elif class="hl-string">'posting verified' in event_description:
                     activity_name = class="hl-string">'Posting Verified'
                
                if activity_name:
                    events.append({
                        class="hl-string">'JournalEntryId': journal_id,
                        class="hl-string">'ActivityName': activity_name,
                        class="hl-string">'EventTime': item.get(class="hl-string">'eventDate'),
                        class="hl-string">'UserName': item.get(class="hl-string">'user', {}).get(class="hl-string">'username'),
                        class="hl-string">'JournalEntryType': journal.get(class="hl-string">'type'),
                        class="hl-string">'CompanyCode': journal.get(class="hl-string">'companyCode'),
                        class="hl-string">'JournalEntryAmount': journal.get(class="hl-string">'totalDebit'),
                        class="hl-string">'JournalEntryStatus': journal.get(class="hl-string">'status'),
                        class="hl-string">'RejectionReason': rejection_reason
                    })
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Could not fetch history for Journal ID {journal_id}: {e}")

        class=class="hl-string">"hl-comment"># Fetch attachments
        try:
            attachments_url = fclass="hl-string">"{BASE_URL}/api/v2/journals/{journal_id}/attachments"
            attachments_response = requests.get(attachments_url, headers=headers)
            attachments_response.raise_for_status()
            attachments = attachments_response.json().get(class="hl-string">'data', [])
            for attachment in attachments:
                events.append({
                    class="hl-string">'JournalEntryId': journal_id,
                    class="hl-string">'ActivityName': class="hl-string">'Supporting Documentation Attached',
                    class="hl-string">'EventTime': attachment.get(class="hl-string">'uploadedDate'),
                    class="hl-string">'UserName': attachment.get(class="hl-string">'uploadedBy', {}).get(class="hl-string">'username'),
                    class="hl-string">'JournalEntryType': journal.get(class="hl-string">'type'),
                    class="hl-string">'CompanyCode': journal.get(class="hl-string">'companyCode'),
                    class="hl-string">'JournalEntryAmount': journal.get(class="hl-string">'totalDebit'),
                    class="hl-string">'JournalEntryStatus': journal.get(class="hl-string">'status'),
                    class="hl-string">'RejectionReason': None
                })
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Could not fetch attachments for Journal ID {journal_id}: {e}")

        class=class="hl-string">"hl-comment"># --- Activities based on journal fields (may need customization) ---
        if journal.get(class="hl-string">'isReversed'):
            events.append({
                class="hl-string">'JournalEntryId': journal_id,
                class="hl-string">'ActivityName': class="hl-string">'Journal Entry Reversal Processed',
                class="hl-string">'EventTime': journal.get(class="hl-string">'[reversalDate]'), class=class="hl-string">"hl-comment"># Placeholder for reversal date field
                class="hl-string">'UserName': journal.get(class="hl-string">'[reversalUser]'), class=class="hl-string">"hl-comment"># Placeholder for user field
                class="hl-string">'JournalEntryType': journal.get(class="hl-string">'type'),
                class="hl-string">'CompanyCode': journal.get(class="hl-string">'companyCode'),
                class="hl-string">'JournalEntryAmount': journal.get(class="hl-string">'totalDebit'),
                class="hl-string">'JournalEntryStatus': class="hl-string">'Reversed',
                class="hl-string">'RejectionReason': None
            })

        if journal.get(class="hl-string">'reconciliationId'): class=class="hl-string">"hl-comment"># Assuming this indicates reconciliation
            events.append({
                class="hl-string">'JournalEntryId': journal_id,
                class="hl-string">'ActivityName': class="hl-string">'Journal Entry Reconciled',
                class="hl-string">'EventTime': journal.get(class="hl-string">'[reconciliationCertifiedDate]'), class=class="hl-string">"hl-comment"># Placeholder for certified date
                class="hl-string">'UserName': journal.get(class="hl-string">'[reconciliationCertifier]'), class=class="hl-string">"hl-comment"># Placeholder for certifier user
                class="hl-string">'JournalEntryType': journal.get(class="hl-string">'type'),
                class="hl-string">'CompanyCode': journal.get(class="hl-string">'companyCode'),
                class="hl-string">'JournalEntryAmount': journal.get(class="hl-string">'totalDebit'),
                class="hl-string">'JournalEntryStatus': journal.get(class="hl-string">'status'),
                class="hl-string">'RejectionReason': None
            })
        class=class="hl-string">"hl-comment"># Introduce a small delay to respect API rate limits
        time.sleep(0.1)

    if not events:
        print(class="hl-string">"No events were generated. Please check your date range and API access.")
        return

    class=class="hl-string">"hl-comment"># 3. Create DataFrame and save to CSV
    print(class="hl-string">"Transforming data and saving to CSV...")
    df = pd.DataFrame(events)

    class=class="hl-string">"hl-comment"># Add metadata columns
    df[class="hl-string">'SourceSystem'] = class="hl-string">'BlackLine'
    df[class="hl-string">'LastDataUpdate'] = last_data_update
    
    class=class="hl-string">"hl-comment"># Ensure required columns are present
    final_columns = [
        class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'UserName', class="hl-string">'JournalEntryType', class="hl-string">'CompanyCode', class="hl-string">'JournalEntryAmount', class="hl-string">'JournalEntryStatus', class="hl-string">'RejectionReason'
    ]
    for col in final_columns:
        if col not in df.columns:
            df[col] = None
            
    df = df[final_columns] class=class="hl-string">"hl-comment"># Order columns

    output_filename = class="hl-string">'blackline_journal_entry_event_log.csv'
    df.to_csv(output_filename, index=False)
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

if __name__ == class="hl-string">"__main__":
    main()

Bereit für die ersten Schritte?

Verwenden Sie dieses Template, um Ihre Daten effizient vorzubereiten und aussagekräftige Erkenntnisse zu Ihrem Record-to-Report-Prozess mit Buchungsbelegen zu gewinnen. Beginnen Sie noch heute damit, Effizienz und Compliance zu verbessern.

Zurück zum Leitfaden zur Prozessverbesserung Template herunterladen

Verbessern Sie noch heute die Effizienz Ihres Record-to-Report-Prozesses mit Buchungsbelegen

Verkürzen Sie die Durchlaufzeit von Buchungsbelegen um 30 % und schließen Sie schneller und präziser ab.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich • In wenigen Minuten eingerichtet

Ihr Daten-Template für den Record-to-Report-Prozess mit Buchungsbelegen

Ihr Daten-Template für den Record-to-Report-Prozess mit Buchungsbelegen

Attribute für den Record-to-Report-Prozess mit Buchungsbelegen

Aktivitäten im Record-to-Report-Prozess mit Buchungsbelegen

Anleitungen zur Datenextraktion

Export des BlackLine-Berichts zu Buchungsbelegen und Services

Schritte

Konfiguration

a Beispielabfrage python

Datenextraktion mit einem Python-Skript über die BlackLine-REST-API

Schritte

Konfiguration

a Beispielabfrage python

Bereit für die ersten Schritte?

Verbessern Sie noch heute die Effizienz Ihres Record-to-Report-Prozesses mit Buchungsbelegen

Ihr Daten-Template für den Record-to-Report-Prozess mit Buchungsbelegen

Ihr Daten-Template für den Record-to-Report-Prozess mit Buchungsbelegen

Attribute für den Record-to-Report-Prozess mit Buchungsbelegen

Aktivitäten im Record-to-Report-Prozess mit Buchungsbelegen

Anleitungen zur Datenextraktion

Export des BlackLine-Berichts zu Buchungsbelegen und Services

Schritte

Konfiguration

a Beispielabfrage python

Datenextraktion mit einem Python-Skript über die BlackLine-REST-API

Schritte

Konfiguration

a Beispielabfrage python

Bereit für die ersten Schritte?

Verbessern Sie noch heute die Effizienz Ihres Record-to-Report-Prozesses mit Buchungsbelegen

Der Schutz Ihrer Daten ist uns wichtig