LLM-gestützte Finanzberichte: Von Rohdaten zu revisionsfähigen Zusammenfassungen

Finanzberichterstattung ist repetitiv, strukturiert und bedeutsam – eine Kombination, die sie zu einem idealen Kandidaten für LLM-Automatisierung macht, die jedoch mehr Sorgfalt erfordert als die meisten anderen LLM-Anwendungsfälle.

Was automatisierbar ist

Am besten geeignet für LLM-gestützte Finanzberichte sind Narrativ-Abschnitte: Kommentare zur Lage des Unternehmens, Abweichungsanalysen, Budget-Ist-Vergleiche. Diese teilen eine gemeinsame Struktur: einen Daten-Input (Zahlen aus ERP oder Data Warehouse), ein Template (regulatorisches oder internes Format) und ein Narrativ (in kontrollierter Geschäftssprache).

Was ohne menschliche Prüfung nicht automatisiert werden sollte: die abschließende Freigabe von Zahlen, zukunftsgerichtete Aussagen, die regulatorischen Offenlegungsregeln unterliegen, sowie alles, was in eine externe Revisionskette einfließt.

Eine praxistaugliche Architektur

Eine produktionsreife Berichts-Pipeline besteht aus vier Stufen:

Stufe 1 — Datenextraktion: Strukturierte Daten aus ERP oder Warehouse in ein validiertes JSON-Payload überführen. Schema-Validierung ist hier nicht verhandelbar; ein nachgelagertes LLM kann einen vorgelagerten Datenfehler nicht korrigieren.

Stufe 2 — Prompt-Konstruktion: Validierte Daten in ein versioniertes Prompt-Template einfügen. Das Template kodiert das Berichtsformat (z. B. IFRS-Kommentarkonventionen), Tonvorgaben (neutral, keine Spekulation) und das Output-Schema.

Stufe 3 — Generierung und Validierung: Das LLM erstellt das Narrativ. Ein nachgelagerter Schritt prüft, ob alle referenzierten Zahlen exakt mit den Eingabedaten übereinstimmen – Zahl für Zahl. Bei jeder Abweichung: Ablehnung und strukturiertes Retry.

Stufe 4 — Audit-Logging: Jeder generierte Bericht protokolliert den Input-Payload-Hash, die Prompt-Version, die Modell-Version und den Output-Hash. So entsteht eine revisionsfähige Kette vom Quell-Datensatz bis zum fertigen Narrativ.

Messbare Ergebnisse

In der Praxis berichten Teams, die diese Architektur nutzen, über:

• Deutliche Reduktion der Analysten-Zeit für routinemäßige Abweichungskommentare
• Nahezu keine Formatierungsfehler in Vorlagen-Abschnitten
• Konsistente Anwendung von Offenlegungssprache über Berichtsperioden hinweg

Der Schlüssel liegt darin, das LLM als präzises Entwurfswerkzeug zu behandeln, nicht als autonomen Autor. Der menschliche Prüfer wechselt vom Schreiben zur Verifizierung – ein schnellerer und skalierbarerer Ablauf.

Risikokontrollen

Drei Kontrollen sind vor dem Einsatz von Finanz-LLMs unverzichtbar:

1. Zahlen-Verankerung: Alle Zahlen im Output müssen auf die Eingabedaten zurückführbar sein. Keine Inferenz oder Schätzung.
2. Ton-Leitplanken: Prompts müssen zukunftsgerichtete Sprache explizit untersagen, sofern die Eingabedaten keine freigegebenen Prognosen enthalten.
3. Versions-Pinning: In der Produktion eine feste Modell-Version verwenden. Modell-Updates können den Output-Stil so verschieben, dass compliance-geprüfte Templates beschädigt werden.

Wo die Grenze liegt

Die wichtigste Designentscheidung ist, wo das LLM arbeiten darf. Es kann eine Erklärung aus einem freigegebenen Payload entwerfen; es sollte nicht entscheiden, welche Ledger-Einträge maßgeblich sind, eine fehlerhafte Abstimmung reparieren oder eine Prognose erfinden. Diese Entscheidungen gehören in bestehende Verantwortlichkeiten und Review-Prozesse. Die Pipeline macht die Grenze im Input-Schema sichtbar und weist Requests ohne erforderlichen Freigabestatus zurück.

Perioden, Einheiten und Ausnahmen

Finanzdaten enthalten Details, die im Prompt klein wirken, aber die Bedeutung ändern: Geschäfts- versus Kalenderperiode, absolute versus prozentuale Abweichung, Währungsumrechnung, Vorzeichenlogik, Restatements und fehlende Vergleichswerte. Solche Eigenschaften werden als typisierte Felder mit Einheiten und Perioden-IDs kodiert. Ein negativer Aufwandswert darf nicht nur über eine Prose-Anweisung von einem negativen Umsatzwert unterschieden werden.

Ausnahmen sind Teil des Output-Vertrags. Ein fehlender Quellwert, eine nicht abgestimmte Summe oder ein Wert außerhalb erwarteter Grenzen erzeugt eine benannte Ausnahme mit genug Kontext für die menschliche Klärung. Ein Retry darf Formatierung reparieren, aber keine fehlende Tatsache erzeugen. Hier ist strukturierte Validierung wertvoller als ein längerer Prompt.

Review und Change Control

Der Reviewer braucht Quell-Payload oder kontrollierte Referenz, Narrativ, Liste extrahierter Zahlen und Validierungsergebnis. Ein allgemeines „Freigeben“ ist schwächer als explizite Entscheidungen wie freigeben, bearbeiten, ablehnen oder eskalieren – mit Grund und Zeitstempel. Der Review-Datensatz identifiziert Prompt- und Modellversion, unter Beachtung von Aufbewahrung und Zugriff.

Change Control umfasst Templates, Schemata, Source-Mappings, Modellversionen, Terminologie und Disclosure-Regeln. Jede Änderung läuft durch ein repräsentatives Eval-Set; Qualität, Grounding, Ton und Latenz werden dokumentiert. Ein Modell-Upgrade ist nicht automatisch besser, sondern eine neue Abhängigkeit mit Evidenzbedarf.

Praktische Abnahme-Checkliste

Vor dem Einsatz eines Berichts-Workflows wird geprüft, ob Quellen abstimmen, Einheiten und Perioden eindeutig sind, jede Output-Zahl zurückverfolgbar ist, verbotene oder nicht freigegebene Sprache blockiert wird, der Reviewer Ausnahmen sieht und der Audit-Trail abfragbar ist. Teste leere Daten, Restatements, widersprüchliche Inputs, ungewöhnlich große Abweichungen und Provider-Ausfall. Für Perioden ohne erfüllte Voraussetzungen bleibt ein manueller Fallback.

So bleibt das LLM eine nützliche Komponente in einem Finance-geführten Prozess: Es kann wiederkehrenden Schreibaufwand reduzieren, aber das angemessene Erfolgskriterium ist vertrauenswürdige Reviewbarkeit – kein Versprechen autonomer Berichterstattung. Der Finance-Service beschreibt das umgebende Muster.