De laatste twee dagen van de maand bepalen het ontwerp

We hadden een verbetering in de factuurmatching van een klant gepland voor de tweede werkdag van de maand. Alle tests waren groen. De controller hield de release met één zin tegen: tijdens de afsluiting verandert er niets. Ze had gelijk, en het was onze fout dat die datum in de planning stond.

Het was een kleine variant van de meest gemaakte ontwerpfout bij automatisering in finance. Systemen worden ingericht, getest en uitgerold voor een gemiddelde maand. Beoordeeld worden ze in de laatste twee dagen daarvan en de eerste dagen van de volgende, als het volume piekt, de deadlines vastliggen en elk cijfer bijna wordt afgetekend. Een systeem dat op de vijftiende prima werkt en op de dertigste te laat is, faalt op het enige moment dat het financeteam onthoudt.

Loadtests spelen de drukste afsluiting opnieuw af

Het volume in finance is niet gelijkmatig verdeeld. Leveranciers sturen facturen aan het eind van hun eigen maand. Klanten betalen in golven. Transitorische posten, intercompanydoorbelastingen en correcties volgen in de laatste dagen. De piek valt precies op het moment dat 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.

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. 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. Vroege ontvangsten worden al in de loop van de maand gematcht, terugkerende transitorische posten vooraf gecontroleerd en bekende uitzonderingen gebundeld. In de piek zit dan alleen nog wat echt niet eerder binnen kan komen.

De wachtrij is leeg bij de cut-off

Een team van mensen werkt vanzelf naar de cut-off toe. Een systeem moet daar expliciet op worden ingericht. Op het moment van de cut-off is elke post afgehandeld of zichtbaar aangehouden, met een reden en een eigenaar. Er is niets meer ongemerkt onderweg.

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. Komt de accountant maanden later, dan ligt per periode al vast hoe het geautomatiseerde deel van de afsluiting is verlopen.

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, vaak verschillend per entiteit en per bedrag.

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.

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 het antwoord meer mensen voor de beoordeling, geen lagere lat. Rond de jaarafsluiting duurt de freeze langer, omdat daarna de controle van de jaarrekening volgt.

Vertrouwen komt uit één parallelle afsluiting

Een nieuw systeem draait zijn eerste afsluiting nooit alleen. Minstens één volledige maand sluit het team op de oude manier af terwijl het systeem dezelfde periode verwerkt, en de uitkomsten worden regel voor regel vergeleken. 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 het sterkste bewijs dat een controller kan krijgen, want het systeem wordt getoetst aan de enige maatstaf die voor haar telt: 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 nee zei.