Ontworpen voor de afsluitweek

We hadden een verbetering in de intercompany-matching van een groep gepland voor de tweede werkdag van de maand. Alle tests waren groen. De controller vroeg ons de release te verplaatsen, met één regel: tijdens de afsluiting verandert er niets. Ze had gelijk. Onze releasekalender bevatte geen afsluitdatums, dus niets hield die datum tegen.

Het was een kleine variant van een veelgemaakte ontwerpfout bij automatisering in finance, en we hadden hem net zelf gemaakt. Het systeem wordt ingericht, getest en uitgerold voor een gemiddelde maand, en daarna beoordeeld in de laatste twee dagen van die maand en de eerste dagen van de volgende, als de matchwachtrij het langst is, de cut-off niet kan schuiven en elk cijfer bijna wordt afgetekend. Een systeem dat op de vijftiende prima werkt en op de dertigste te laat is, faalt op het moment dat het financeteam onthoudt.

Engineers die besturingssystemen voor machines bouwen, noemen dit een harde deadline: een resultaat dat te laat komt, is weinig meer waard, dus wordt het ontwerp beoordeeld op zijn slechtste geval. Een maandafsluiting werkt net zo, met accountants in plaats van actuatoren, en het slechtste geval komt elke maand terug.

Loadtests spelen de drukste afsluiting opnieuw af

Het volume in finance klontert. Leveranciers factureren op hun eigen maandeinde, dus hun facturen stapelen zich op in dezelfde paar dagen. Klantbetalingen komen in golven binnen rond de gangbare betaaltermijnen. Transitorische posten, intercompanydoorbelastingen en de correcties uit de beoordeling landen in de laatste dagen, precies wanneer het team de minste tijd heeft om een wachtrij af te werken.

De loadtest is daarom geen veelvoud van het daggemiddelde. We spelen de drukste afsluiting van het afgelopen jaar opnieuw af, met de eigen historische data van de klant, op volle snelheid en opgehoogd met de groei die het bedrijf voor volgend jaar verwacht. Of de uitkomsten kloppen, testen we elders. Deze test beantwoordt twee vragen: wordt de hele piek verwerkt binnen de uren die de afsluitkalender toestaat, en kan het team de wachtrij die overblijft dezelfde dag afhandelen? Als een geplande uitbreiding de afsluiting in gevaar brengt, willen we dat uit een test weten en niet uit de eerste maand na de uitbreiding.

De herhaling draait tegen de echte afhankelijkheden, omdat die op dezelfde dagen pieken. De interface van het ERP heeft limieten op het aantal aanroepen. De dienst die documenten leest, heeft een maandquotum. De responstijden van een gehost model zijn op de laatste werkdag van de maand anders dan op een rustige dinsdag. Elk krijgt in de test een gemeten plafond, en elk krijgt een schriftelijke terugvaloptie: wat de workflow doet, en wie wordt ingelicht, als die afhankelijkheid op de eerste dag van de afsluiting vertraagt of stopt.

Het tijdsbudget wordt teruggerekend vanaf de cut-off

Elke afsluiting heeft een vast eindpunt, en daar rekenen we vanaf terug. Elke fase van de workflow krijgt een uiterste starttijd en een uiterste eindtijd: inlezen, matchen, uitzonderingen doorzetten, beoordelen, boeken. Bij een afsluiting met een cut-off om zes uur 's avonds op de tweede werkdag kan een budget er zo uitzien:

• Matching klaar om 08:00 op dag 2, zodat beoordelaars de dag beginnen met een bekende wachtrij.
• Uitzonderingen doorgezet naar benoemde eigenaren om 09:00.
• Beoordelingen klaar om 15:00, met tijd voor wat de beoordelingen opleveren.
• Boekingen voltooid en teruggelezen om 16:30.
• Cut-offrapport bij de controller om 17:00, een uur voordat ze tekent.

De tijden zijn die van de controller, niet de onze. Waar het om gaat, is dat elk tijdstip een eigenaar en een waarschuwing heeft. Tijdens de afsluiting bewaakt het systeem elke fase tegen haar budget. Loopt een fase uit, dan krijgt de proceseigenaar een signaal op een moment dat er nog tijd is om extra mensen in te zetten of eerder met beoordelen te beginnen.

De controller ontdekt dus niet op de laatste middag dat de wachtrij drie keer zo groot is als normaal. Ze hoort het 's ochtends, samen met welke fase achterloopt en welke posten nog wachten.

Automatisering is als eerste klaar, zodat mensen de tijd krijgen

In een gangbare planning draaien de geautomatiseerde stappen tegelijk met de eigen afsluittaken van het team, zodat beide om dezelfde laatste uren strijden. Wij doen het andersom. De geautomatiseerde fasen zijn klaar voordat het handwerk begint. Wat voor mensen overblijft, is dan bekend en toegewezen terwijl zij nog het grootste deel van de beschikbare tijd hebben. Een matchingrun die aan het begin van de laatste dag klaar is, geeft het team de hele dag voor de uitzonderingen. Een run die 's middags klaar is, geeft een paar uur en een late avond.

Volgens dezelfde logica halen we werk helemaal uit de piek. Een goederenontvangst van de tiende wordt op de tiende gematcht, de transitorische posten die elke maand terugkomen worden in de derde week gecontroleerd, en bekende uitzonderingen worden gebundeld zodra ze opduiken. In de piek zit dan alleen nog wat niet eerder binnen kan komen. Leveranciers van afsluitsoftware noemen dit de continuous close, en het is de goede richting. Het maakt de piek kleiner zonder hem weg te halen: transitorische posten, intercompanydoorbelastingen en de correcties die uit de beoordeling komen, landen nog steeds in dat venster, dus het systeem wordt nog steeds op dat venster gedimensioneerd.

De wachtrij is leeg bij de cut-off

Mensen werken vanzelf naar een cut-off toe. Een boekhouder laat op de tweede werkdag geen half geboekte memoriaalpost een nacht liggen. Een systeem wel, tenzij het zo is gebouwd dat het dat niet doet. Op het moment van de cut-off is daarom elke post afgehandeld of zichtbaar aangehouden, met een reden en een eigenaar.

In de praktijk blijft er werk over de grens hangen: herhaalpogingen op de achtergrond, posten die op een document wachten, beoordelingen die niemand heeft opgepakt. Na het afsluiten van de boeken duikt dat op als een onverklaard verschil. De workflow maakt daarom automatisch een cut-offrapport: wat is afgehandeld, wat is aangehouden en waarom, en wat te laat binnenkwam voor deze periode. De controller leest het voordat ze aftekent.

Aan het eind van elke afsluiting legt de workflow ook zijn eigen verantwoording vast: het cut-offrapport, de aangehouden posten met hun eigenaren, elke storno waarbij hij betrokken was en de doorlooptijden per fase tegen het budget. Vraagt de accountant maanden later hoe de geautomatiseerde matching in één bepaalde afsluiting is verlopen, dan ligt het antwoord al onder die periode klaar en hoeft niemand het uit systeemlogs te reconstrueren.

Cut-offregels zijn van finance

Na de cut-off blijven er documenten binnenkomen, zoals een factuur met een datum in de oude maand die twee dagen na de maandwissel binnenkomt. In welke periode hoort die, en is er een transitorische post nodig? Elk financeteam heeft daar een antwoord op. In een groep is dat voor de Nederlandse entiteit vaak een ander antwoord dan voor de Duitse, en boven een bepaald bedrag weer een ander.

Het systeem bedenkt dat antwoord niet zelf. De cut-offregels stellen we voor de livegang per entiteit op met de controller, en het systeem past ze deterministisch toe: welke document- en ontvangstdatums bij welke periode horen, boven welk bedrag een laat document wordt geëscaleerd en welke documenten een voorstel voor een transitorische post worden in plaats van een boeking. Alles wat buiten de regels valt, gaat met de feiten naar een medewerker.

In een concern is de afsluiting een reeks afsluitingen: eerst de dochterondernemingen, dan de intercompanyafstemming, dan de consolidatie, vaak verspreid over tijdzones. Een geautomatiseerde boeking in de ene entiteit na haar cut-off, terwijl de tegenpost in een andere entiteit al is afgesloten, levert een verschil op dat dagen uitzoekwerk kost. Intercompanystappen draaien daarom binnen de krapste deadline van de twee entiteiten.

Tijdens de afsluiting verandert er niets

Rond elke afsluiting geldt een change freeze, afgesproken met finance en vastgelegd in de releasekalender. Geen nieuwe regels, geen andere drempels, geen gewijzigde prompts, geen nieuwe versie van het model en geen wijzigingen in de exports waarop de workflow draait. Echte storingen lopen via een noodprocedure, met goedkeuring van de controller, en elk gebruik daarvan wordt achteraf beschreven zoals een incident.

Een freeze heeft ook een keerzijde. Als hij wordt opgeheven, staat elke wijziging die moest wachten tegelijk klaar. De eerste dagen na de afsluiting krijgen daarom een eigen releaseplan, waarin wijzigingen één voor één live gaan, elk met een eigen acceptatierun, en niet als één bundel op dag drie.

De freeze geldt ook voor configuratie die mensen niet als code zien. Een drempel die op de negenentwintigste wordt verlaagd om een achterstand weg te werken, is een wijziging in het afsluitproces op het slechtst denkbare moment. Piekt het volume, dan is meer capaciteit voor de beoordeling meestal het veiligere antwoord, geen lagere lat. Rond de jaarafsluiting duurt de freeze langer, omdat daarna de controle van de jaarrekening volgt.

Vertrouwen komt uit één parallelle afsluiting

Zijn eerste afsluiting maakt een nieuw systeem niet alleen mee. Minstens één volledige maand sluit het team op de oude manier af terwijl het systeem dezelfde periode verwerkt, en de twee worden regel voor regel vergeleken: dezelfde entiteit, dezelfde rekening, dezelfde periode. Elk verschil eindigt als een gecorrigeerde regel, een gedocumenteerde uitzondering of een bekende beperking.

Dat kost het team extra werk in een drukke week, en dat zeggen we vooraf. Het is ook sterk bewijs voor een controller, want het systeem wordt getoetst aan de maatstaf waarmee zij al werkt: haar eigen afgesloten cijfers. Om dezelfde reden plannen we een livegang nooit in de laatste week van een maand of kwartaal.

De maatstaf is of de piek op tijd is verwerkt

Voor een financeworkflow rapporteren we geen gemiddelde verwerkingstijd. We rapporteren of de wachtrij bij elke afsluiting voor de cut-off leeg was, en met hoeveel marge. Dat is het cijfer dat de controller beschermde toen ze ons vroeg de release te verplaatsen.