Design for Close Week

We had scheduled an improvement to a group's intercompany matching for the second working day of the month. It had passed every test. The controller asked us to move it, with one rule: nothing changes while the numbers are being closed. She was right. Our release calendar had no close dates in it, so nothing had stopped the date being chosen.

It was a small version of a design error that is common in finance automation, and we had just made it ourselves. The system is sized, tested and released against an average month, then judged in that month's last two days and the first days of the next, when the matching queue is longest, the cut-off cannot move and every number is about to be signed. A system that is excellent on the fifteenth and late on the thirtieth has failed at the moment the finance team remembers.

Engineers who build control systems for machines call this a hard deadline: a result that arrives late is worth little, so the design is judged on its worst case. A month-end close works the same way, with accountants instead of actuators, 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, so their invoices pile into the same few days. Customer payments come in clusters around common payment terms. Accruals, intercompany charges and the adjustments that come out of review land in the final days, which is when the team has the least time to work a queue.

So the load test is not a multiple of the daily average. It is a replay of the busiest close of the past year, from the client's own history, at full speed, scaled by the growth the business plans for next year. Correctness is covered elsewhere. This test asks whether the whole peak clears in the hours the close calendar allows, and whether the review queue it leaves is one the team can finish that day. If a planned expansion would break the close, we want a test to say so, not the first month after the expansion.

The replay runs against the real dependencies, because they peak on the same days. The ERP's interface has rate limits. The document-reading service has a monthly quota. A hosted model provider's response times are not the same on the last working day of the month as on a quiet Tuesday. Each gets a measured ceiling in the test, and each gets a written fallback: what the workflow does, and who is told, if that dependency slows down or stops on day one of the close.

The time budget runs back from the cut-off

Every close has a fixed end. We work backwards from it. Each stage of the workflow gets a latest start and a latest finish: ingested, matched, exceptions routed, reviews done, postings complete. For a close that cuts off 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 the day with a known queue.
• Exceptions routed to named owners by 09:00.
• Reviews done by 15:00, leaving time for what the reviews turn up.
• Postings complete and read back by 16:30.
• Cut-off report with the controller by 17:00, an hour before they sign.

The times are the controller's, not ours. What matters is that each has an owner and a warning attached. During the close the system tracks each stage against its budget and warns the process owner when one runs late, while there is still time to add people or start review early.

The controller does not find out on the last afternoon that the review queue is three times its normal size. She is told in the morning, with the stage that is late and the cases that are waiting.

Automation finishes first so people get the window

A common schedule runs the automated steps alongside the team's own close tasks, so both compete for the same final hours. We invert it. Automated stages finish early, before the human stages begin, so that everything left for people is known and routed while they still have most of the window. A matching run that finishes at the start of the last day gives the team the whole day for its exceptions. One that finishes in the afternoon gives them a few hours and a late night.

The same logic moves work out of the peak altogether. A goods receipt that arrives on the tenth is matched on the tenth, the accruals that recur every month are validated in the third week, and known exceptions are grouped as they appear, so the peak holds only what cannot arrive earlier. Close software vendors call this the continuous close, and it is the right direction. It shrinks the peak without removing it: accruals, intercompany charges and the adjustments that come out of review still land in the window, so the system is still sized for the window.

The queue is empty at cut-off

People work to a cut-off without being told. An accountant does not leave a half-posted journal overnight on the second working day. A system will, unless it is built not to. So at the cut-off time every case is either completed or held where someone can see it, with a reason and an owner.

In practice, background retries, cases waiting for a document and review items nobody picked up can leave work suspended across the line, and it surfaces as an unexplained difference after the books are closed. So the workflow produces a cut-off report automatically: completed, held and why, arrived too late for this period. The controller reads it before signing.

At the end of each close the workflow also files its own evidence: the cut-off report, held items with owners, every reversal it was involved in, and stage timings against budget. When the auditors ask months later how the automated matching ran in one particular close, the answer is already filed under that period, and nobody has to rebuild it from system logs.

Cut-off rules belong to finance

Documents keep arriving after the cut-off: an invoice dated in the old month, received two days into the new one. Which period does it belong in, and should it be accrued? Every finance team has an answer. In a group it is often a different answer for the Dutch entity than for the German one, and different again above a certain amount.

The system does not invent one. Cut-off rules are written with the controller before go-live, per entity, and applied deterministically: which document and receipt dates go to which period, above what amount a late document is escalated, which become accrual proposals rather than postings. Anything outside the rules goes to a person with the facts.

In a group, the close is a sequence of closes: subsidiaries, then intercompany matching, then consolidation, often across time zones. An automated posting in one entity after its cut-off, against a counterpart already closed in another, creates a difference that takes days to trace. Intercompany steps therefore run inside the tighter of the two entities' windows.

Nothing changes during the close

Around each close there is a freeze window, agreed with finance and written into the release calendar. No new rules, no threshold changes, no prompt edits, no model version changes, 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.

A freeze has another side. When it lifts, every change that waited is ready to land at once. So the first days after the close get a release plan of their own, with changes going out one at a time, each with its acceptance run, not as one bundle on day three.

The freeze covers the configuration people do not think of as code. A threshold lowered on the twenty-ninth to clear a backlog is a change to the close process, made at the worst possible time. When volume spikes, the safer answer is usually more review capacity, not a lower bar. Year-end gets a longer freeze, because the audit follows it.

Trust comes from one parallel close

The first close a new system sees, it does not see alone. 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 entity, 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 is also strong evidence for a controller, because it tests the system against the standard she already works to: her own closed numbers. For the same reason, go-live never lands in the last week of a month or quarter.

Peak clearance is the measure

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