Best Practices für Finanzmodellierung im KI-Zeitalter (nicht nur Excel-Hygiene)

Fragen Sie zehn Finanzleute nach Best Practices für Finanzmodellierung, und Sie bekommen dieselbe Liste: Eingaben blau einfärben, niemals eine Zahl in eine Formel hardcoden, pro Zeile eine einheitliche Rechenlogik, ein Änderungsprotokoll führen. Alles gute Ratschläge. Auch dreißig Jahre alt und für ein Publikum geschrieben, das es in dieser Form nicht mehr gibt: einen menschlichen Prüfer, der eine Zelle mit dem Auge erfasst, merkt, dass etwas nicht stimmt, und den Analysten fragt, der das Modell gebaut hat.

Dieses Publikum hat sich verändert. Immer häufiger liest eine KI-Assistenz das Modell, nicht ein Mensch mit institutionellem Gedächtnis dafür, welcher Tab veraltet ist. Die alten Regeln waren nie falsch. Sie sind nur unvollständig für ein Modell, das von etwas abgefragt, zusammengefasst und mitunter neu berechnet wird, das keine Ahnung hat, welche Zelle es besser in Ruhe lässt.

Warum Tabellen-Hygiene allein nicht mehr reicht

Die klassische Best-Practice-Liste optimiert für genau ein Fehlerbild: den Menschen, der das Modell falsch liest. Blaue Eingabezellen verhindern, dass jemand versehentlich eine Formel überschreibt. Eine einheitliche Rechenlogik pro Zeile verhindert, dass ein Analyst über uneinheitliche Logik zwischen Spalten stolpert. Diese Konventionen funktionieren, weil ein Mensch zusätzlich sein Urteilsvermögen einsetzt: er bemerkt, dass die Umsatzformel für Q3 anders aussieht als die für Q2, und fragt nach, bevor er dem Ergebnis vertraut.

Eine KI-Assistenz bringt dieses Urteilsvermögen nicht von sich aus mit. Sie liest, was dasteht, mit ungefähr derselben Zuversicht, egal ob die Zelle sauber ist oder still überschrieben wurde. Sie weiß nicht, dass das Finanzteam den “alten” Tab seit März nicht mehr benutzt. Hygienekonventionen, die für das Auge eines menschlichen Prüfers gebaut wurden, übertragen ihren Schutz nicht automatisch auf ein System ohne Auge, ohne Gedächtnis für die Teamgeschichte und ohne Bauchgefühl dafür, dass etwas nicht stimmt.

Das ist kein Plädoyer gegen Hygiene, machen Sie damit weiter. Es ist ein Hinweis darauf, dass Hygiene ein engeres Problem gelöst hat als das, vor dem Sie jetzt stehen. Ein Modell kann makellos farbcodiert sein und trotzdem unsicher für eine unbeaufsichtigt lesende KI, weil die Risiken, die jetzt zählen, strukturell sind, nicht kosmetisch.

Regel eins: keine Plug-Zellen, die eine KI still “reparieren” kann

Jeder erfahrene Modellierer hat schon einmal einen Plug verwendet: eine Zelle, die die Bilanz zum Ausgleich zwingt, eine manuelle Anpassung, die eine Zahl an die Realität angleicht, ohne den Grund dafür zu erklären. Analysten lernen, solche Zellen zu erkennen und mit Misstrauen zu behandeln. Eine KI unterscheidet einen Plug in der Regel nicht von einer echten Formel. Schlimmer noch: Manche KI-gestützten Tools “reparieren”, was wie ein Fehler aussieht, indem sie die Zelle neu berechnen oder überschreiben, und entfernen damit still die bewusste Anpassung samt dem realen Grund, der zu ihr geführt hat.

Die Regel für das KI-Zeitalter: Wenn eine Zahl nicht über eine Formel bis zu den Quelldaten zurückverfolgbar ist, muss sie eine explizite, beschriftete Annahme sein, kein nackter Override, der in einer Formelzelle sitzt. “Plug zum Abgleich mit dem gemeldeten Cashbestand: -42.000 €, Prüfung läuft, verantwortlich: J. Osei, Stand 30.06.2026” ist eine Aussage, die eine KI respektieren und sichtbar machen kann. Ein unbeschrifteter Override in Zeile 47 ist eine Stolperfalle.

Regel zwei: jede Eingabe führt entweder zu einem Ist-Wert oder zu einer benannten, datierten Annahme

Das Problem zweiter Ordnung bei Tabellenmodellen ist, dass “Eingabe” eine einzige, undifferenzierte Kategorie ist. Eine Umsatzwachstumsrate kann aus dem letzten Monatsabschluss stammen oder eine Zahl sein, die jemand vor acht Monaten in einem Planungsmeeting eingetippt und nie wieder angefasst hat. Optisch, in der Tabelle, sehen beide identisch aus: blauer Text, gleiche Schrift, gleiche Zeilenhöhe.

Für den Menschen, der das Modell baut, ist diese Unschärfe zu verkraften, weil er sich erinnert, was was ist. Für eine KI, die über das Modell nachdenkt (oder für jeden, der es befragt, nachdem der ursprüngliche Ersteller das Unternehmen verlassen hat), ist sie es nicht. Die Lösung besteht darin, Herkunft zu einer Eigenschaft der Eingabe zu machen, nicht zu etwas, das nur konventionell mitgedacht wird:

Eingabetyp	Was gebraucht wird	Beispiel
Ist-Wert	Verknüpfung zur abgestimmten Buchhaltungszahl und Periode	”Umsatz, Juni 2026, abgeglichen mit Hauptbuch”
Benannte Annahme	Verantwortlicher, Datum der Festlegung, Begründung	”8 % MoM-Wachstum, festgelegt vom CFO, 14.05.2026, basierend auf Pipeline-Review”
Abgeleitet	Formel und ihre vorgelagerten Abhängigkeiten, sichtbar statt verborgen	”= Ist-Wert Vormonat × Wachstumsannahme”
Plug	Explizite Beschriftung, Grund und Ablaufbedingung	siehe Regel eins

Nichts davon verlangt neue Disziplin, die gute Modellierer nicht ohnehin schon halb praktizieren. Es verlangt, sie strukturell statt optional zu machen, denn die Kosten, sie zu überspringen, waren früher “jemand ist im Review-Meeting verwirrt” und sind heute “eine KI nennt eine falsche Zahl mit voller Überzeugung, und niemand bemerkt es, bevor der Vorstand sie sieht.” Mehr dazu, warum genau dieses Fehlerbild so gefährlich ist, lesen Sie unter warum KI bei Finanzmathematik danebenliegt.

Regel drei: Versionskontrolle, die die Bearbeitungen eines KI-Agenten übersteht

Versionskontrolle in Tabellenkalkulationen war schon immer informell: ein Dateiname mit “_v3_FINAL_wirklichfinal” darin, bestenfalls die Revisionshistorie eines gemeinsamen Laufwerks. Das war tragbar, solange nur Menschen die Datei bearbeitet haben, denn ein Mensch, der etwas kaputt macht, erinnert sich meist ungefähr, was er geändert hat, und kann es rückgängig machen oder es zumindest im nächsten Standup erklären.

Eine KI-Agentin, die ein Modell bearbeitet, trägt diese Rechenschaftspflicht nicht automatisch mit sich. Wenn eine Assistenz in eine Live-Tabelle zurückschreiben darf (einen Treiber anpassen, eine Formel erweitern, “aufräumen”, was sie als Fehler interpretiert), müssen Sie genau wissen, was sich geändert hat, wann, auf wessen Anweisung und gegenüber welchem vorherigen Zustand. Sonst driftet Ihr Modell ohne Prüfpfad. Aus demselben Grund ist eine Tabellenkalkulation das falsche Fundament für KI-gestützte Finanzfunktionen: Ein Raster wurde nie dafür gebaut, seine eigene Historie in der Granularität zu protokollieren, die ein autonomer Editor verlangt.

Die praktische Regel ist enger gefasst als das Schlagwort “Versionskontrolle einführen”. Sie lautet: Jeder Schreibzugriff auf das Modell, ob von Mensch oder KI, muss zuordenbar, zeitgestempelt und rückgängig machbar sein, und der vorherige Zustand muss abfragbar bleiben. Wenn Ihr Modell die Frage “Wie sah das vor dem Eingriff der KI aus?” nicht beantworten kann, sollte keine KI daran rühren.

Das Modell um einen Treiberbaum bauen, nicht um eine Wand aus Formeln

Best-Practice-Ratschläge aus dem letzten Jahrzehnt drängten Modellierer zu flacheren, besser prüfbaren Formelketten: eine Berechnung pro Zeile, minimale Verschachtelung. Das gilt weiterhin, aber das KI-Zeitalter liefert einen zusätzlichen Grund dafür, der über reine Prüfbarkeit hinausgeht: Eine KI, die über “Was passiert mit dem EBITDA, wenn das Hiring verlangsamt wird” nachdenkt, braucht eine lesbare kausale Struktur im Modell, nicht nur lesbare Arithmetik.

Ein Treiberbaum macht die kausale Kette explizit: Headcount treibt die Personalkosten, Personalkosten plus Gemeinkosten treiben den Opex, Umsatz minus Opex treibt das EBITDA. Eine Frage zu einem einzelnen Hebel lässt sich dann bis zu ihren nachgelagerten Effekten zurückverfolgen, ohne dass die KI (oder ein Mensch) hundert verknüpfte Zellen zurückentwickeln muss. Dabei geht es weniger um Eleganz als um Beantwortbarkeit: Ein als Treiberbaum organisiertes Modell kann eine echte Was-wäre-wenn-Frage mit einer verteidigbaren Antwort stützen, statt eine Näherung als solche auszugeben. Die Mechanik dahinter beschreibt der Treiberbaum-Erklärartikel ausführlicher.

Wie sich das zusammengesetzt anfühlt

Keine dieser vier Regeln (keine stillen Plugs, nachvollziehbare Eingaben, rechenschaftspflichtige Versionierung, treiberbasierte Struktur) ersetzt die klassische Hygiene-Checkliste. Sie setzen darauf auf. Ein Modell, das beide Regelwerke befolgt, ist eines, bei dem ein menschlicher Prüfer und eine KI-Assistenz unabhängig voneinander dem vertrauen können, was sie sehen, und dieses Vertrauen wird durch Struktur verdient, nicht durch Konvention vorausgesetzt.

Die unbequeme Konsequenz: Die meisten bestehenden Modelle, gebaut nach dem alten Standard, sind nicht KI-tauglich, auch wenn sie nach dem Maßstab des alten Standards gut gebaut wurden. Das ist kein Grund, jedem Modell im Haus zu misstrauen. Es ist ein Grund, “kann eine KI das gefahrlos lesen” als eigene Frage zu behandeln, getrennt von “würde ein guter Analyst das durchwinken”, und sie explizit zu stellen, statt anzunehmen, dass die erste Frage automatisch aus der zweiten folgt.

Fazit

Tabellen-Hygiene war für einen Prüfer konzipiert, der ein Urteilsvermögen mitbringt, das eine Maschine nicht hat. Die Regeln für das KI-Zeitalter verwerfen diese Disziplin nicht, sie erweitern sie: jeden Plug beschriften, jede Eingabe bis zu einem Ist-Wert oder einer benannten Annahme zurückverfolgen, jede KI-Bearbeitung rechenschaftspflichtig und rückgängig machbar gestalten und das Modell um Treiber herum strukturieren, über die eine KI nachdenken kann, statt um eine Wand aus undurchsichtigen Formeln. Ein Modell, das beide Standards erfüllt, können Sie einem Menschen oder einer KI in die Hand geben und der Antwort in beiden Fällen vertrauen.

Die Modellierungsschicht von Rexfin ist genau dafür gebaut: abgestimmte Eingaben, nachvollziehbare Annahmen, keine stillen Plugs und eine deterministische Engine unter allem, was die KI sagt. Wenn Sie sehen möchten, wie ein nach diesen Regeln gebautes Modell mit Ihren eigenen Daten aussieht, vereinbaren Sie eine Demo.

Für die zugrunde liegende Architektur beginnen Sie am besten beim Pillar-Artikel zur verlässlichen Finanzmodellierungsschicht für KI. Von dort aus zeigt die Drei-Statement-Projektions-Engine, wie die Berechnungen strukturiert sind, und die Modellvorlagen-Bibliothek bietet Startpunkte, die bereits nach diesen Regeln gebaut sind.