Wie KI komplexe Forecasts verlässlich macht

Im rollierenden Cashflow-Forecast eines Kundenprojekts stand monatelang eine Formel, die eine Umsatzzeile doppelt zählte. Die Zeile ging dadurch Monat für Monat mit dem Doppelten ihres Werts in die geplanten Einzahlungen ein. Das Modell lief in Excel auf den Daten des ERP-Systems, wurde regelmäßig gepflegt und lieferte stets plausible Summen. Der Fall stammt aus unserer eigenen Projektarbeit. Zur Anonymisierung nennt dieser Text finanzielle Größen nur als gerundete Prozentwerte.

Bis zur unabhängigen Gegenrechnung blieb der Fehler unbemerkt.

Ein KI-Agent leitete die Planungskette daraufhin außerhalb von Excel noch einmal aus den Rohdaten her und verglich sie mit dem Bericht. Dieselbe Prüfung fand zwei weitere Fehler im Bestandsmodell. Sie fing auch einen Fehler in der neuen Rechnung des Agenten ab, bevor diese in den Bericht gelangte. Dieser Fall zeigt, warum auch plausible Forecasts eine Prüfung ihrer Rechenwege brauchen.

Warum stille Fehler in Forecasts überleben

Ein Forecast beschreibt die Zukunft; seine Annahmen lassen sich deshalb noch nicht mit dem endgültigen Ergebnis vergleichen. Seine Rechenwege, allerdings, lassen sich schon heute prüfen. In diesem Projekt hatte die regelmäßige Nutzung eine doppelt gezählte Umsatzzeile nicht aufgedeckt. Wer den Bericht las, sah Ergebnisse statt Rechenwege. Der Autor des Modells wusste wiederum, was jede Formel tun sollte. Diese Vertrautheit ließ die Zahlen glaubwürdig aussehen. Der wiederholte Monatslauf belegte deshalb noch nicht, dass die Rechnung stimmte.

Eine Zelle aus dem Modell zeigt das Problem. Ist-Daten, fortgeschriebene Durchschnitte und die Einzelplanung lagen auf getrennten Blättern. Eine IFERROR/INDEX-MATCH-Formel wählte je Konto und Monat den Wert aus. War der Einzelplanwert größer als null, nahm sie ihn; andernfalls griff sie auf den Durchschnitt zurück. Die vollständige Formel und ein illustrativer SQL-Vergleich stehen im Artikel dazu, ab wann eine Excel-Tabelle Software ist.

Diese Unterscheidung ist wichtig: Ein Planwert von null oder ein negativer Wert übersteuerte den Durchschnitt in dieser Formel nicht. Geprüft werden muss deshalb auch die geschäftliche Regel hinter der Rechnung.

Neben der doppelt gezählten Umsatzzeile enthielt der Forecast zwei weitere Bestandsfehler. Drei Produktlinien standen mit ihrem vollen Umsatz im Plan, aber ohne direkte Kosten. Neun Kontonummern waren in einem Planungsblatt als Text gespeichert, während der Abgleich Zahlen suchte. MATCH fand sie nicht, und IFERROR wählte still den Ausweichwert. Die Einzelplanung wurde übersprungen, während Durchschnittswerte im Forecast standen.

Beim Aufbau eines rollierenden 12-Monats-Durchschnitts aus der Finanzbuchhaltung hätte der Agent beinahe einen weiteren Fehler eingebaut. Sein erster Versuch lieferte nur rund 2,5 % des tatsächlichen Werts. Jahresabschlussbuchungen zur Nullstellung der GuV-Konten im Kontenrahmen hatten rechnerisch ein Jahr aus dem Durchschnitt gelöscht. Die unabhängige Gegenrechnung zeigte die Abweichung sofort. Dieselbe Prüfdoktrin galt für die Arbeit des Agenten selbst.

Keiner dieser Fehler erzeugte eine Excel-Fehlermeldung.

Was die unabhängige Rechnung veränderte

Der nützliche Beitrag in diesem Projekt war die zweite Rechnung aus den Rohdaten. Formeln zu erzeugen gehörte zur Arbeit, doch der erste neu erzeugte Durchschnitt war selbst falsch. Vertrauen entstand dadurch, dass wir den Widerspruch zwischen zwei Rechenwegen aufklärten.

An einem Tag rechnete der Agent 236 Pivot-Zellen in Python direkt aus der ERP-Schnittstelle nach und verglich auf den Cent. An einem anderen prüfte er jede Monatsspalte entlang der Planungskette, vom Kontenplan über die Durchschnitte und Einzelplanung bis in den fertigen Bericht. Dieser zweite Abgleich entlarvte die als Text gespeicherten Kontonummern. Ein geprüfter Monat wich um rund 8 % ab, und diese Abweichung musste erklärt werden. Beim bloßen Lesen der neun Zellen war sie nicht sichtbar geworden.

Seit diesem Forecast gilt bei uns eine Zahl erst dann als geprüft, wenn zwei unabhängige Rechnungen übereinstimmen und die geschäftliche Regel dahinter bestätigt ist. Der Abgleich von 236 Zellen zeigt, wie ein Agent die wiederkehrende Prüfarbeit übernehmen kann. Eine Übereinstimmung wäre weniger aussagekräftig, wenn beide Rechnungen dieselbe falsche Formel kopierten. Deshalb leiteten wir das zweite Ergebnis außerhalb der Mappe aus Rohdaten her. Das Vorgehen lässt sich nach einer Änderung wiederholen. Ob die Annahmen über künftige Einzahlungen sinnvoll sind, bleibt eine eigene geschäftliche Beurteilung.

Der Agent steuerte außerdem Excel per COM-Automatisierung und legte Abfragen und DAX-Measures skriptgesteuert an. Auf der Seite des ERP-Systems gehörten eigene Abfrageschnittstellen und serverseitige Filter dazu. Die Filter entfernten 20.000 irrelevante Zeilen, bevor die Daten die Mappe erreichten, und die Datei wurde rund 40 % kleiner. Jede Änderung auf der ERP-Seite wurde zuerst in einer Testumgebung geprüft, sodass eine fehlerhafte Abfrage dort aufgefallen wäre und nicht im laufenden System. Alle Änderungen wurden außerdem gegen die Quelldaten geprüft, bevor sie in die geprüfte Arbeitsmappe übernommen wurden.

Wo die Automatik endet

Der Kunde plant weiterhin selbst. Durchschnitte liefern Vorschlagswerte; die Regeln je Konto legen fest, wann die Einzelplanung Vorrang hat. Diese Aufteilung würden wir beibehalten: Ein Agent kann das Modell berechnen und prüfen, während der Verantwortliche die geschäftlichen Annahmen setzt. Die Bedingung eines positiven Planwerts in der Formel ist ein Beispiel für eine Regel, die dessen Urteil braucht.

Die ausgelieferte Arbeitsmappe lässt sich mit dem eigenen ERP-Zugang des Kunden aktualisieren. Ihre Rechenwege sind dokumentiert und wiederholbar. Unser Lieferprotokoll unterscheidet die geprüften Dateien vom laufenden Budget in der gemeinsamen Ablage: Die Übernahme der Korrekturen dort war beim letzten dokumentierten Stand noch unbestätigt. Eine geprüfte Datei belegt nicht, dass jede im Alltag verwendete Kopie ersetzt wurde.

Fünf Fragen an Ihren eigenen Forecast

Diese Fragen lassen sich besprechen, bevor Sie ein neues Werkzeug auswählen:

1. Wurde eine Berichtszahl jemals unabhängig, außerhalb des Modells, aus Rohdaten nachgerechnet?
2. Kann jemand eine beliebige Berichtszelle bis in ihre Quelldaten zurückverfolgen?
3. Wie wirken sich Jahresabschlussbuchungen auf Durchschnitte und Vergleiche aus?
4. Würde ein gescheiterter Abgleich, etwa Text statt Zahl, sichtbar?
5. Lässt sich eine Modelländerung wiederholen und die verwendete Dateiversion bestimmen?

Beginnen Sie mit einer wichtigen Berichtszahl. Rechnen Sie diese auf einem zweiten Weg nach und klären Sie jede Abweichung, bevor Sie die Prüfung ausweiten. In diesem Projekt führte die Abweichung von rund 8 % zu neun Kontonummern, deren Einzelplanung übersprungen wurde. Das ist ein konkreter Grund, den Rechenweg auch dann zu prüfen, wenn die Summe plausibel aussieht. Erstgespräch vereinbaren.