Finanzanalyse und Finanzplanung auf Daten aus dem Hauptbuch

Eine Buchung ist die kleinste ehrliche Einheit, mit der ein Finanzmodell arbeiten kann. Sie trägt das Datum, das Konto, die Soll- oder Habenseite und den Betrag, und alles, was ein Bericht zusammenfasst, ist eine Summe über diese Zeilen. Maesn normalisiert dieses Objekt über die Systeme hinweg, der Code, der Buchungen zu einem Zeitraum, einem Konto oder einer Kostenstelle gruppiert, wird also einmal geschrieben und nicht einmal je Buchhaltungsplattform.

Die Normalisierung endet bei den Feldern, die ein System nicht veröffentlicht, und dieser Endpunkt hat dafür das schärfste Beispiel im Modell. Sichtbar wird es, wenn man die Feldlisten liest statt der Form der Antwort: auf einem Teil der dokumentierten Systeme hat die Antwort keine Positionen, eine Buchung kommt also beschrieben, aber nicht beziffert zurück. Wer lesbare Systeme zählt und auf die Summe baut, setzt diese Buchungen als wertlos in eine Planung.

Die Forderungsseite ist die erfreulichere, und dort findet die meiste Arbeit an der Liquidität tatsächlich statt. Rechnungen sind breit lesbar und tragen überall dort, wo sie dokumentiert sind, einen Status, und das reicht, um ein Hauptbuch nach Fälligkeit zu staffeln, ohne dass es einen Endpunkt dafür gibt. Eingangsrechnungen geben dasselbe Bild auf der Verbindlichkeitsseite. Zusammen beantworten sie, was offen ist und wann es fällig wird, und das ist die Eingabe, mit der ein Liquiditätsmodell die meiste Zeit verbringt.

Die Menge ist die andere Hälfte des Problems, denn ein Modell, das Historie will, will Jahre von Buchungen und nicht die von gestern. Lesezugriffe sind über die Systeme hinweg auf eine Weise paginiert und filterbar, ein inkrementeller Abruf hält eine Aktualisierung im Verhältnis zu dem, was sich geändert hat, und wo ein System einen großen Lesezugriff als Hintergrundaufgabe statt als Antwort beantwortet, kommt das als eine asynchrone Aufgabe, die Sie abfragen. Die Objektformen selbst kommen aus dem Common Data Model, und die Verbindung, die jeder Kunde einmal freigibt, ist in Unified Authentication beschrieben.

Die letzte Zeile ist die, um die herum man planen muss, denn sie ist nicht dünn, sondern leer. Bankaktivität kommt von überhaupt keinem angebundenen System zurück, während das Schreiben einer Transaktion für einige Systeme dokumentiert ist. Eine Fähigkeit, die es nur in eine Richtung gibt, liest man aus einer Funktionsliste leicht falsch, und diese hier lohnt zweimal gelesen zu werden: das Objekt, das hier Transaktion heißt, ist ein Sammelbecken für Datensätze, die zu keinem der anderen passen, und nicht die Zeile auf einem Kontoauszug.

Ereignisse lohnt es sich auf dieselbe Weise zu messen. Buchungen veröffentlichen auf manchen Systemen Änderungsereignisse und die Summen- und Saldenliste auf keinem, und ein Produkt, das auf eine Buchung reagieren will, statt sie beim nächsten Durchlauf zu finden, kann das für diese tun und den Rest abfragen. Wie dieser Mechanismus arbeitet und wo seine Kanten liegen, ist das Thema von Unified Webhooks. Die Unterschiede je System, die nach der Normalisierung bleiben und zu denen die Betragsbasis oben gehört, behandelt Customisation Handling, und wie eine teilweise Antwort aussieht, wenn ein System ein Feld auslässt, ist Unified Error Handling.

Die Systeme dieser Klasse, denen ein Finanzprodukt am häufigsten begegnet, sind die deutschen und niederländischen Hauptbücher, und ihr Verhalten auf diesem Endpunkt unterscheidet sich genug, um es vor dem Zuschnitt zu lesen: DATEV Rechnungswesen, das hier als einziges System einen Hauptbuch-Lesezugriff mit einer Aufgabe statt mit einer Antwort beantwortet, Exact Online, Xero und Microsoft Dynamics 365 Business Central.