Finance

Was wir bauen

Wir setzen LLM-Technologie in den strukturierten, bedeutsamen Teilen des Finanzbetriebs ein, wo Genauigkeit nicht verhandelbar ist: Berichtsgenerierung, Abweichungskommentare, Budget-Ist-Analysen und Risikoübersichten. Jeder Output ist an Quelldaten verankert und mit einem vollständigen Audit-Trail signiert.

Kernkompetenzen

Finanzbericht-Generierung Automatisiertes Narrativ-Drafting aus ERP- oder Warehouse-Daten — Lageberichts-Kommentare, Abweichungserklärungen und Periodenübersichten. Output-Schemata werden gegen Eingabedaten validiert, bevor Text die Pipeline verlässt.

Zahlen-Validierung Jede in einem generierten Narrativ referenzierte Zahl wird mit dem Input-Payload abgeglichen. Abweichungen lösen strukturierte Retries aus — keine stillen Fehler. Keine Inferenz, keine Schätzung.

Regulatorische Leitplanken Prompt-Templates werden gegen anwendbare Offenlegungskonventionen (IFRS, lokale Rechnungslegungsstandards) geprüft. Zukunftsgerichtete Sprache ist hinter einer expliziten Datenorisierung gesperrt. Versionsgepinnte Modelle verhindern Stil-Drift zwischen Berichtsperioden.

Abweichungs- und Attributionsanalyse Strukturierte Zerlegung von Budget-Ist-Abweichungen, Segmentattribution und Kohortenvergleiche — als validiertes JSON oder formatiertes Narrativ, je nach nachgelagerten Anforderungen.

Finance-spezifische Standards

• Alle generierten Zahlen sind auf einen validierten Quell-Payload zurückführbar — keine modellinferenten Werte
• Prompt-Templates sind Compliance-geprüft und änderungskontrolliert
• Modell-Version ist in der Produktion gepinnt; Updates erfordern explizite Neu-Freigabe
• Audit-Log umfasst Input-Hash, Prompt-Version, Modell-Version und Output-Hash
• Zukunftsgerichtete Aussagen erfordern explizite Autorisierung im Input-Schema

Wann diese Arbeit sinnvoll ist

Der richtige Einstieg ist ein Berichts-Workflow mit stabilen Quelltabellen, wiederkehrendem Aufwand für Narrative und einem expliziten Prüfschritt. Typische Auslöser sind Periodenkommentare, wiederholte Abweichungserklärungen oder die Anforderung, den Weg einer Zahl bis in einen Absatz rekonstruieren zu können. Das ersetzt weder Bilanzierungsentscheidungen noch die Freigabe, sondern schafft eine kontrollierte Entwurfs- und Prüfschicht.

Delivery-Modell und Deliverables

Zuerst werden Quelldaten profiliert: Einheiten, Perioden, Dimensionen, Nullverhalten und Abstimmungsregeln. Danach definieren wir ein enges Output-Schema und ein Vokabular für zulässige Erklärungen. Die Generierung erhält validierte Daten statt eines unstrukturierten Datenbankauszugs. Ein Verifier extrahiert jede referenzierte Zahl und vergleicht sie mit dem Payload, bevor ein Reviewer den Entwurf sieht.

Deliverables können ein Source-to-Field-Mapping, Regeln für Zahlen-Grounding, versionierte Templates, eine Review-Queue, eine Audit-Log-Spezifikation, Testfälle für Grenzfälle und ein Übergabe-Runbook umfassen. Der Use Case zur Berichtsgenerierung und das Insight zu Audit-Trails zeigen verwandte Muster.

Abhängigkeiten, Risiken und Abnahme

Quellverantwortung, Rechnungslegungsdefinitionen, Disclosure-Policy und ein benannter Reviewer sind Voraussetzungen. Unklare Mappings, nachträgliche Korrekturen und Einheitenumrechnungen bleiben Risiken; die sichere Reaktion ist Stop oder Review, nicht Raten. Die Abnahme sollte Abstimmung, verbotene Sprache, Rückverfolgbarkeit und Reviewbarkeit an repräsentativen Perioden prüfen. Einen begrenzten Finance-Workflow besprechen.

Integrationshinweise

Die Integration sollte das Quellsystem als Autorität erhalten. Ein Berichtsentwurf kann Referenzen auf Payload und Validierungsergebnis in den bestehenden Review-Prozess übernehmen; der generierte Text bleibt bis zur Freigabe klar als Entwurf erkennbar. So kann die Einführung begrenzt starten: mit einem Berichtsabschnitt, geprüften Kontrollen und einer Erweiterung erst dann, wenn Reviewer Fehlerbilder verstehen.