Design for Close Week

We had scheduled an improvement to a group's intercompany matching, which pairs up charges between companies in the same group, for the second working day of the month. The controller asked us to move it: nothing changes while the numbers are being closed. She was right. Our release calendar had no close dates in it.

The close is the few days in which finance finishes the month's books by a fixed deadline, the cut-off, and we had made a common design error. Finance automation is sized, tested and released against an average month, then judged in the last two days and the first days of the next, when the queue is longest, the cut-off can't move and every number is about to be signed.

Engineers who build control systems for machines call this a hard deadline: a late result is worth little, so the design is judged on its worst case. A close works the same way, and its worst case comes round every month.

Load tests replay the busiest close

Finance volume bunches up. Suppliers invoice at their own month-end; payments cluster around common terms; accruals (estimates for costs not yet invoiced), intercompany charges and the adjustments that come out of review land in the final days, when the team has least time.

So the load test isn't a multiple of the daily average. It replays the busiest close of the past year, from the client's own history, at full speed, scaled by next year's planned growth. Correctness is tested elsewhere. This one asks whether the peak clears in the hours allowed, leaving a review queue the team can finish that day. If a planned expansion would break the close, a test should say so before the expansion does.

It runs against the real dependencies, which peak on the same days: the ERP's request limits, the document service's monthly quota, a hosted model that is slower on the last working day than on a quiet Tuesday. Each gets a measured ceiling and a written fallback: what happens, and who is told, if it slows or stops on day one.

The time budget runs back from the cut-off

Each stage gets a latest start and finish, counted back from the cut-off. For a close that ends at six in the evening of the second working day, a budget might read:

• Matching finished by 08:00 on day 2, so reviewers start with a known queue.
• Exceptions routed to named owners by 09:00.
• Reviews done by 15:00, leaving time for what they turn up.
• Entries in the books complete and read back by 16:30.
• Cut-off report with the controller by 17:00, an hour before she signs.

The times are the controller's, not ours. What matters is that each has an owner and a warning: the process owner hears when a stage runs late, while there's time to add people or start review early. So the controller learns in the morning, not on the last afternoon, that the review queue has tripled.

Automation finishes first so people get the window

Often automated steps run alongside the team's own close tasks, competing for the same final hours. We invert that. Automated stages finish before human ones begin, so everything left for people is known while they still have most of the window: a whole day for exceptions, not a few hours and a late night.

The same logic moves work out of the peak. A goods receipt that arrives on the tenth is matched on the tenth, recurring accruals are checked in the third week, and known exceptions are grouped as they appear. Close software vendors call this the continuous close. It shrinks the peak without removing it: accruals, intercompany charges and review adjustments still land in the window, so the system is still sized for the window.

The queue is empty at cut-off

An accountant doesn't leave a half-entered journal overnight at cut-off. A system will, unless built not to: background retries, cases waiting for a document and review items nobody picked up can leave work hanging across the line, to surface as an unexplained difference after the books are closed. So at cut-off every case is completed or visibly held, with a reason and an owner, and a cut-off report lists completed, held and why, and arrived too late. The controller reads it before signing.

After each close the workflow files its own evidence under that period: the cut-off report, held items with owners, every reversal it was involved in, and stage timings against budget. When auditors ask months later, nobody rebuilds it from system logs.

Cut-off rules belong to finance

Documents keep arriving after cut-off, like an invoice dated in the old month and received in the new one. Which period, and should it be accrued? Every finance team has an answer, and in a group it often differs between the Dutch and German companies, and again above a certain amount.

The system doesn't invent one. Cut-off rules are written with the controller before go-live, per company, and applied exactly: which document and receipt dates go to which period, above what amount a late document goes to a person, which become accrual proposals rather than entries. Anything outside the rules goes to a person with the facts.

In a group, the close is a sequence (subsidiaries, intercompany matching, then consolidation into group accounts) often across time zones. An entry in one company after its cut-off, against a counterpart already closed in another, takes days to trace. So intercompany steps run inside the tighter of the two companies' windows.

Nothing changes during the close

Around each close there's a freeze window, agreed with finance and written into the release calendar: no new rules, no changed thresholds, no edited AI instructions, no new model versions, no changes to the exports that feed the workflow. Real failures go through an emergency path with the controller's approval, and every use of it is written up afterwards like an incident.

The freeze also covers settings people don't think of as code: a threshold lowered on the twenty-ninth to clear a backlog changes the close at the worst time. When volume spikes, the safer answer is more review capacity, not a lower bar. Year-end gets a longer freeze, because the audit follows. When a freeze lifts, the changes that waited go out one at a time, each tested, not as one bundle on day three.

Trust comes from one parallel close

For at least one full close, the team closes the month the old way while the system processes the same period, and the two are compared line by line: same company, same account, same period. Every difference ends as a fixed rule, a documented exception or a known limitation.

It costs the team extra work in a busy week, and we say so upfront. It's also strong evidence, because it tests the system against the controller's own closed numbers. For the same reason, go-live never lands in the last week of a month or quarter.

We don't report average processing time for a finance workflow. We report whether every close cleared its queue before cut-off, and by how much. That's the number the controller was protecting when she asked us to move the release.