Narrative Finanzberichterstattung automatisieren

Sie automatisieren narrative Finanzberichterstattung, indem Sie die Arbeit in zwei Teile aufspalten. Die Reporting-Pipeline erzeugt abgestimmte Zahlen mit Herkunftsnachweis, und das Modell schreibt Prosa, die genau diese Zahlen belegt und nichts anderes. Es berechnet niemals eine Summe neu und leitet keine Abweichung ab. Eine Prüfung nach der Generierung liest jede belegte Zelle aus dem Berichtsschema zurück und lässt jeden Entwurf durchfallen, dessen Zahlen abgedriftet sind.

Ein Board-Pack ist Monat für Monat weitgehend dasselbe Dokument, nur mit anderen Zahlen darin. Die Abweichungsanalyse, der Run-Rate-Kommentar, der Absatz “Warum haben sich die Personalkosten bewegt”: Die Struktur steht fest, die Zahlen ändern sich, und eine Analystin verbringt einen Nachmittag damit, Kontext um Zahlen herum abzutippen, die am selben Morgen finalisiert wurden. Die Prosa von der Arithmetik zu trennen, ist genau das, was diesen Nachmittag verschwinden lässt.

Diese Trennung ist der springende Punkt. Ein Modell, das aus einem Prompt heraus Management-Kommentare zu Ihrem Geschäft generieren soll, schreibt flüssige, plausible Sätze mit Zahlen, die es sich ausgedacht hat. Genau die Flüssigkeit ist das Gefährliche. Ein selbstsicherer Satz behauptet, die Bruttomarge habe sich um 180 Basispunkte verbessert, während das Berichtsschema 130 ausweist, und ein Aufsichtsgremium liest das als Tatsache.

Verankern Sie die Prosa in einer aufgelösten Kennzahlentabelle

Bevor auch nur ein Text generiert wird, muss die Reporting-Pipeline dem Modell eine Tabelle übergeben, mit der es nicht diskutieren kann. Jede Zahl, die im Kommentar auftauchen könnte, wird einmal berechnet, gegen das Hauptbuch abgestimmt und mit einem Bezeichner versehen. Umsatz nach Segment, der Vorjahres- bzw. Vorperiodenvergleich, die Budgetzeile, die daraus resultierende Abweichung, all das lebt in einer einzigen aufgelösten Struktur mit einer Referenz auf jeder Zelle.

Das Modell sieht Ihr Hauptbuch nicht. Es sieht diese Tabelle. Wenn es schreibt “der EMEA-Umsatz lag 12 % über Budget”, dann ist diese 12 % emea.revenue.var_vs_budget_pct, ein Wert, den die Pipeline bereits berechnet und auf die Quelle zurückgeführt hat. Die Prosa rendert die Tabelle, sie erhebt keinerlei eigenständige Behauptung über das Geschäft.

• Point-in-Time-Korrektheit zählt hier genauso wie in einem Feature Store für ein Modell. Die Zahlen müssen das Hauptbuch zum Berichtsstichtag widerspiegeln, nicht zum Zeitpunkt der Generierung, sonst verändert eine spät gebuchte Position stillschweigend eine Zahl, die der Kommentar bereits beschrieben hat.
• Die Abstimmung passiert vor der Generierung, niemals darin. Wenn sich die Segmentumsätze nicht zur konsolidierten Summe addieren, stoppt die Pipeline. Sie wollen nicht, dass das Modell eine Differenz mit einem geschliffenen Satz übertüncht.
• Entity Resolution zahlt sich aus, wenn dieselbe Kostenstelle in einem System “Sales - EMEA” heißt und in einem anderen “EMEA Commercial”. Der Kommentar verweist auf eine einzige kanonische Entität, weil die Kennzahlentabelle die beiden bereits zusammengeführt hat.

Legen Sie hier dieselbe Disziplin an wie bei einem Trainingsdatensatz. Leakage bedeutet in diesem Kontext, dass das Modell nach einer Zahl greift, die nicht in der abgestimmten Tabelle stand: ein Wert, an den es sich vage aus dem Prompt erinnert, oder eine Summe, die es selbst neu berechnet hat. Beides sind Defekte, und die Kennzahlentabelle existiert, damit das Modell niemals greifen muss.

Sorgen Sie dafür, dass jede Aussage ihre Zahl belegt

Den Input zu verankern, ist die halbe Miete. Die andere Hälfte zwingt den Output dazu, seine Referenzen mitzuführen, damit Sie ihn prüfen können. Wir lassen das Modell einen Kommentar ausgeben, bei dem jede numerische Aussage mit der Zellreferenz getaggt ist, aus der sie stammt. Intern sieht der Satz so aus: “die Bruttomarge verbesserte sich um [gross_margin.var_bps] Basispunkte”, und der Renderer setzt am Ende den aufgelösten Wert ein.

Das verschafft Ihnen eine mechanische Prüfung, die bei jedem Entwurf läuft, bevor ein Mensch ihn liest:

• Nehmen Sie jede getaggte Aussage, lesen Sie die referenzierte Zelle aus der Kennzahlentabelle erneut ein und bestätigen Sie, dass die gerenderte Zahl übereinstimmt. Schon eine Abweichung von einem einzigen Basispunkt lässt den Entwurf durchfallen.
• Markieren Sie jedes Zahlenliteral in der Prosa, das überhaupt kein Referenz-Tag hat. Eine ungetaggte Zahl ist eine Zahl, die das Modell aus dem Nichts produziert hat, und sie geht nicht raus.
• Prüfen Sie Richtungswörter gegen das Vorzeichen der zugrunde liegenden Abweichung. Wenn die Zahl gesunken ist und der Satz “wuchs” sagt, ist das ein aufgedeckter Fehler, keine Stilanmerkung.

Nichts davon beurteilt, ob der Kommentar aufschlussreich ist. Es beurteilt, ob der Kommentar den Zahlen treu ist, und das ist die eine Eigenschaft, bei der ein Board-Pack nicht falsch liegen darf. Ob die Analystin mit der Story einverstanden ist, die der Entwurf erzählt, ist genau das, womit ein Mensch den Nachmittag verbringen soll, statt Zahlen abzutippen.

Halten Sie einen zurückgehaltenen Satz vergangener Berichtsperioden mit ihren freigezeichneten Kommentaren bereit. Wenn Sie den Prompt, das Kennzahlenschema oder das Modell ändern, lassen Sie die Generierung gegen diese Perioden laufen und vergleichen Sie den Output per Diff. Das ist Ihr Eval-Set, und es ist die einzige ehrliche Methode, um herauszufinden, ob eine Änderung, die im Pack dieses Monats besser aussieht, klammheimlich das letzte Quartal kaputtgemacht hat.

Bewahren Sie den Audit Trail und einen Menschen im Loop

Board- und Management-Reporting wird geprüft, und manchmal wird es im Nachhinein untersucht. Das bestimmt, was Sie aufbewahren müssen. Bewahren Sie zu jedem veröffentlichten Narrativ die Kennzahlentabelle, aus der es generiert wurde, die Modellversion, den Prompt und das Ergebnis der Referenzprüfung auf. Wenn in neun Monaten jemand fragt, warum der März-Kommentar eine Margenbewegung auf eine bestimmte Weise beschrieben hat, können Sie exakt rekonstruieren, was das Modell gesehen hat und was ihm vorgegeben wurde.

Straight-through Processing ist für dieses Dokument das falsche Ziel. Die Pipeline sollte verändern, was die Analystin tut, statt die Analystin zu entfernen. Sie liefert einen belegten Entwurf, der die numerische Prüfung bereits bestanden hat, und die Analystin liest ihn auf Urteilskraft hin. Braucht diese Abweichung operativen Kontext, den die Zahlen nicht zeigen können? Vergräbt das Modell eine Bewegung, die einen eigenen Absatz verdient? Ihre Änderungen sind die Prüfung, auf die es ankommt, denn jemand, der das Geschäft versteht, zeichnet die Story ab, statt Arithmetik Korrektur zu lesen.

• Steuern Sie Entwürfe nach Wesentlichkeit. Ein Routinemonat mit kleinen Abweichungen braucht eine leichte Lektüre; eine Periode mit einer Restrukturierungsrückstellung oder einer Akquisition bekommt eine vollständige, und die Pipeline sollte sichtbar machen, was worum es sich handelt, statt jedes Pack gleich zu behandeln.
• Verfolgen Sie, wo Analystinnen konsequent umschreiben. Wenn das Modell immer wieder denselben wiederkehrenden Posten falsch charakterisiert, ist das ein Drift, den Sie im Prompt oder im Kennzahlenschema beheben können, und das Änderungsprotokoll ist der Ort, an dem Sie ihn sehen.
• Versionieren Sie das Template gemeinsam mit dem Code. Wenn der CFO möchte, dass der Kommentar mit Cash statt mit Umsatz aufmacht, ist das eine Änderung, die Sie einmal vornehmen, gegen die zurückgehaltenen Perioden testen und ausliefern, kein Umformatieren, das jede Analystin von Hand macht.

Aus dem Kommentar, der früher einen Nachmittag gekostet hat, wird eine Prüfung, die zwanzig Minuten dauert, und die Zahl im dritten Absatz stimmt, weil die Pipeline sie gegen das Berichtsschema bewiesen hat, nicht weil jemand daran gedacht hat, noch einmal nachzurechnen.