Für die Abschlusswoche gebaut

Wir hatten eine Verbesserung am Intercompany-Abgleich einer Unternehmensgruppe für den zweiten Arbeitstag des Monats eingeplant. Alle Tests waren grün. Die Controllerin bat uns, den Termin zu verschieben, mit einer Regel: Solange der Abschluss läuft, wird nichts geändert. Sie hatte recht. In unserem Release-Kalender standen keine Abschlusstermine, also hatte nichts verhindert, dass dieser Tag gewählt wurde.

Im Kleinen war das ein verbreiteter Designfehler in der Finanzautomatisierung, und wir hatten ihn gerade selbst gemacht. Das System wird für einen durchschnittlichen Monat dimensioniert, getestet und ausgerollt und dann an dessen letzten beiden Tagen und den ersten Tagen des Folgemonats beurteilt, wenn die Abgleich-Queue am längsten ist, der Stichtag sich nicht verschieben lässt und jede Zahl kurz vor der Freigabe steht. Ein System, das am Fünfzehnten glänzt und am Dreißigsten nicht fertig wird, versagt in dem Moment, den sich das Finanzteam merkt.

Ingenieure, die Steuerungen für Maschinen bauen, nennen das eine harte Frist: Ein Ergebnis, das zu spät kommt, ist nur noch wenig wert, also wird das Design an seinem schlechtesten Fall gemessen. Ein Monatsabschluss funktioniert genauso, mit Buchhaltern statt Aktoren, und sein schlechtester Fall kommt jeden Monat wieder.

Lasttests spielen den stärksten Abschluss nach

Im Finanzbereich ballt sich das Volumen. Lieferanten stellen zu ihrem eigenen Monatsende Rechnungen, also stapeln sich deren Rechnungen in denselben wenigen Tagen. Kundenzahlungen gehen gebündelt rund um übliche Zahlungsziele ein. Abgrenzungen, konzerninterne Verrechnungen und die Korrekturen aus der Prüfung fallen in die letzten Tage, also genau dann, wenn das Team am wenigsten Zeit für eine 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.

Der Nachlauf läuft gegen die echten Abhängigkeiten, denn auch sie haben ihre Spitze an denselben Tagen. Die Schnittstelle des ERP hat Ratenlimits. Der Dienst, der Belege ausliest, hat ein Monatskontingent. Die Antwortzeiten eines gehosteten Modellanbieters sind am letzten Arbeitstag des Monats andere als an einem ruhigen Dienstag. Jede dieser Abhängigkeiten bekommt im Test eine gemessene Obergrenze und eine schriftliche Rückfallebene: was der Workflow tut und wer informiert wird, wenn sie am ersten Tag des Abschlusses langsamer wird oder ausfällt.

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. Bei einem Abschluss mit Stichtag um 18 Uhr am zweiten Arbeitstag könnte ein Budget so aussehen:

• Abgleich fertig um 08:00 an Tag 2, damit die Prüfer den Tag mit einer bekannten Queue beginnen.
• Ausnahmen verteilt an namentlich zuständige Personen bis 09:00.
• Prüfungen erledigt bis 15:00, mit Zeit für das, was die Prüfungen zutage fördern.
• Buchungen abgeschlossen und zurückgelesen bis 16:30.
• Stichtagsbericht bei der Controllerin um 17:00, eine Stunde bevor sie unterschreibt.

Die Uhrzeiten legt die Controllerin fest, nicht wir. Entscheidend ist, dass zu jeder eine zuständige Person und eine Warnung gehören. 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. Ein Wareneingang vom Zehnten wird am Zehnten abgeglichen, die monatlich wiederkehrenden Abgrenzungen werden in der dritten Woche geprüft, und bekannte Ausnahmen werden gebündelt, sobald sie auftreten. In die Spitze fällt dann nur noch, was sich nicht vorziehen lässt. Anbieter von Abschlusssoftware nennen das Continuous Close, und die Richtung stimmt. Es verkleinert die Spitze, ohne sie zu beseitigen: Abgrenzungen, konzerninterne Verrechnungen und die Korrekturen, die aus der Prüfung entstehen, fallen weiterhin ins Zeitfenster, also wird das System weiterhin für dieses Zeitfenster ausgelegt.

Zum Stichtag ist die Queue leer

Menschen arbeiten auf einen Stichtag hin, ohne dass man es ihnen sagen muss. Eine Buchhalterin lässt am zweiten Arbeitstag keine halb gebuchte Buchung über Nacht liegen. Ein System schon, wenn es nicht ausdrücklich anders gebaut ist. Zum Stichtag ist deshalb jeder Fall entweder erledigt oder sichtbar zurückgestellt, mit Grund und Verantwortlichem.

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. Fragen die Wirtschaftsprüfer Monate später, wie der automatisierte Abgleich in einem bestimmten Abschluss gelaufen ist, liegt die Antwort bereits unter dieser Periode ab, und niemand muss sie aus Systemprotokollen rekonstruieren.

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. In einer Gruppe ist es für die niederländische Gesellschaft oft eine andere als für die deutsche, und oberhalb eines bestimmten Betrags noch einmal 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, und jede Nutzung wird danach aufgearbeitet wie ein Vorfall.

Eine Sperre hat noch eine zweite Seite. Wird sie aufgehoben, steht jede Änderung, die gewartet hat, gleichzeitig bereit. Die ersten Tage nach dem Abschluss bekommen deshalb einen eigenen Release-Plan, in dem die Änderungen einzeln live gehen, jede mit ihrem Abnahmelauf, nicht als ein Paket an Tag drei.

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, ist mehr Prüfkapazität meist die sicherere Antwort, nicht eine niedrigere Hürde. Für den Jahresabschluss gilt eine längere Sperre, weil die Jahresabschlussprüfung folgt.

Vertrauen entsteht aus einem Parallelabschluss

Seinen ersten Abschluss erlebt ein neues System nicht 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 beides Zeile für Zeile: gleiche Gesellschaft, gleiches Konto, gleiche Periode. 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 ein starker Nachweis für eine Controllerin, denn das System wird an dem Maßstab gemessen, nach dem sie ohnehin arbeitet: 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 uns bat, das Release zu verschieben.