Finanzautomatisierung muss die letzten zwei Tage des Monats bestehen

Wir hatten eine Verbesserung am Rechnungsabgleich eines Kunden für den zweiten Arbeitstag des Monats eingeplant. Alle Tests waren grün. Die Controllerin stoppte das Release mit einem Satz: Solange der Abschluss läuft, wird nichts geändert. Sie hatte recht, und der Fehler lag bei uns. Wir hätten den Termin nie in diese Woche legen dürfen.

Im Kleinen war das der häufigste Designfehler in der Finanzautomatisierung. Systeme werden für einen durchschnittlichen Monat dimensioniert, getestet und ausgerollt. Beurteilt werden sie an seinen letzten beiden Tagen und den ersten Tagen des Folgemonats, wenn das Volumen am höchsten ist, die Fristen feststehen und jede Zahl kurz vor der Freigabe steht. Ein System, das am Fünfzehnten glänzt und am Dreißigsten nicht fertig wird, versagt genau dann, wenn das Finanzteam es sich merkt.

Lasttests spielen den stärksten Abschluss nach

Im Finanzbereich verteilt sich das Volumen nicht gleichmäßig. Lieferanten stellen zu ihrem eigenen Monatsende Rechnungen. Kunden zahlen gesammelt. Abgrenzungen, konzerninterne Verrechnungen und Korrekturbuchungen fallen in die letzten Tage. Die Spitze kommt also genau dann, wenn das Team am wenigsten Zeit für die Prüf-Queue hat.

Deshalb rechnen wir im Lasttest nicht mit einem Vielfachen des Tagesdurchschnitts. Wir spielen den stärksten Abschluss des Vorjahres aus den Daten des Kunden in voller Geschwindigkeit nach, hochgerechnet um das Wachstum, das das Unternehmen für das kommende Jahr plant. Ob die Ergebnisse stimmen, prüfen wir an anderer Stelle. Dieser Test beantwortet zwei Fragen: Wird die gesamte Spitze in den Stunden verarbeitet, die der Abschlusskalender vorsieht? Und kann das Team die verbleibende Prüf-Queue am selben Tag abarbeiten? Wenn eine geplante Expansion den Abschluss sprengen würde, soll ein Test das zeigen und nicht der erste Monat danach.

Das Zeitbudget läuft rückwärts vom Stichtag

Jeder Abschluss hat einen festen Endtermin. Von dort planen wir rückwärts. Jede Stufe des Workflows erhält einen spätesten Beginn und ein spätestes Ende: Einlesen, Abgleich, Weiterleitung der Ausnahmen, Prüfung, Buchung. Während des Abschlusses vergleicht das System jede Stufe mit ihrem Zeitbudget. Gerät eine in Verzug, wird der Prozessverantwortliche gewarnt, solange noch Zeit bleibt, Kollegen hinzuzuziehen oder früher mit der Prüfung zu beginnen.

So erfährt die Controllerin nicht erst am letzten Nachmittag, dass die Prüf-Queue dreimal so lang ist wie üblich. Sie weiß es am Morgen, einschließlich der Stufe, die hängt, und der Fälle, die warten.

Erst läuft die Automatisierung, dann hat das Team die Zeit

In vielen Abschlussplänen laufen die automatisierten Schritte parallel zu den Aufgaben des Teams, und beide streiten sich um dieselben letzten Stunden. Wir kehren das um. Die automatisierten Schritte sind erledigt, bevor die manuelle Arbeit beginnt. So steht früh fest, welche Fälle beim Team landen, und sie sind verteilt, solange noch der größte Teil des Zeitfensters übrig ist. Ist der Abgleichslauf zu Beginn des letzten Tages durch, hat das Team den ganzen Tag für seine Ausnahmen. Ist er erst am Nachmittag durch, bleiben ein paar Stunden und ein langer Abend.

Nach demselben Prinzip verlagern wir Arbeit ganz aus der Spitze heraus. Frühe Wareneingänge werden schon im Laufe des Monats abgeglichen, wiederkehrende Abgrenzungen vorab geprüft und bekannte Ausnahmen gebündelt. In die Spitze fällt dann nur noch, was sich tatsächlich nicht vorziehen lässt.

Zum Stichtag ist die Queue leer

Ein Team arbeitet auf den Stichtag hin. Ein System muss von vornherein darauf ausgelegt sein. Zum Stichtag ist jeder Fall entweder erledigt oder sichtbar zurückgestellt, mit Grund und Verantwortlichem. Nichts bleibt unbemerkt in Bearbeitung hängen.

In der Praxis bleibt sonst Arbeit über den Stichtag hinaus liegen: automatische Wiederholungsversuche, Fälle, die auf einen Beleg warten, Prüfposten, um die sich niemand gekümmert hat. Nach dem Periodenabschluss tauchen sie als ungeklärte Differenzen wieder auf. Der Workflow erstellt deshalb automatisch einen Stichtagsbericht: erledigt, zurückgestellt mit Grund, zu spät für diese Periode eingegangen. Die Controllerin liest ihn, bevor sie den Abschluss freigibt.

Außerdem legt der Workflow nach jedem Abschluss seine Nachweise ab: den Stichtagsbericht, die zurückgestellten Posten mit ihren Verantwortlichen, jede Stornobuchung, an der er beteiligt war, und die tatsächlichen Laufzeiten der Stufen im Vergleich zum Budget. Wenn die Wirtschaftsprüfer Monate später kommen, ist für jede Periode bereits dokumentiert, wie der automatisierte Teil des Abschlusses gelaufen ist.

Stichtagsregeln gehören dem Finanzbereich

Belege kommen auch nach dem Stichtag: eine Rechnung mit Datum im alten Monat, eingegangen zwei Tage nach Monatsbeginn. In welche Periode gehört sie, und muss sie abgegrenzt werden? Jedes Finanzteam hat darauf eine Antwort, oft je Gesellschaft und Betrag eine andere.

Das System erfindet keine eigene. Die Stichtagsregeln legen wir vor dem Go-live gemeinsam mit der Controllerin fest, je Gesellschaft, und das System wendet sie deterministisch an: welche Beleg- und Eingangsdaten in welche Periode fallen, ab welchem Betrag ein verspäteter Beleg eskaliert wird und welche Belege als Abgrenzungsvorschlag statt als Buchung behandelt werden. Was die Regeln nicht abdecken, geht mit allen Fakten an einen Menschen.

Im Konzern besteht der Abschluss aus mehreren Abschlüssen nacheinander: erst die Tochtergesellschaften, dann die Abstimmung der konzerninternen Posten, dann die Konsolidierung, oft über mehrere Zeitzonen. Bucht die Automatisierung in einer Gesellschaft nach deren Stichtag gegen einen Posten, der in der anderen Gesellschaft schon abgeschlossen ist, entsteht eine Differenz, deren Klärung Tage dauert. Konzerninterne Schritte laufen deshalb im engeren der beiden Zeitfenster.

Während des Abschlusses ändert sich nichts

Rund um jeden Abschluss gilt eine Änderungssperre, mit dem Finanzbereich vereinbart und im Release-Kalender eingetragen. Keine neuen Regeln, keine geänderten Schwellenwerte, keine Prompt-Änderungen, keine neuen Modellversionen, keine Änderungen an den Exporten, aus denen der Workflow seine Daten bezieht. Echte Störungen laufen über einen Notfallprozess, den die Controllerin freigibt.

Die Sperre gilt auch für Konfiguration, die niemand als Code wahrnimmt. Wer am Neunundzwanzigsten einen Schwellenwert senkt, um einen Rückstau abzubauen, ändert den Abschlussprozess zum ungünstigsten Zeitpunkt. Steigt das Volumen sprunghaft, braucht es mehr Prüfkapazität, keine niedrigere Hürde. Für den Jahresabschluss gilt eine längere Sperre, weil die Jahresabschlussprüfung folgt.

Vertrauen entsteht aus einem Parallelabschluss

Ein neues System verantwortet seinen ersten Abschluss nie allein. Mindestens einen vollständigen Abschluss lang schließt das Team den Monat wie bisher ab, während das System dieselbe Periode verarbeitet. Danach vergleichen wir die Ergebnisse Zeile für Zeile. Jede Differenz wird zu einer korrigierten Regel, einer dokumentierten Ausnahme oder einer bekannten Einschränkung.

Das bedeutet für das Team Mehrarbeit in einer ohnehin vollen Woche, und das sagen wir vorher offen. Es ist aber der stärkste Nachweis, den eine Controllerin bekommen kann, denn das System wird an dem einzigen Maßstab gemessen, der für sie zählt: an ihren eigenen abgeschlossenen Zahlen. Aus demselben Grund legen wir den Go-live nie in die letzte Woche eines Monats oder Quartals.

Maßstab ist, ob die Spitze abgearbeitet wird

Für einen Finanz-Workflow berichten wir keine durchschnittliche Bearbeitungszeit. Wir berichten, ob bei jedem Abschluss die Queue vor dem Stichtag leer war, und mit wie viel Puffer. Genau diese Zahl hat die Controllerin geschützt, als sie Nein sagte.