Design for the Last Two Days of the Month

We had scheduled an improvement to a client's invoice matching for the second working day of the month. It had passed every test. The controller vetoed it in one sentence: nothing changes while the numbers are being closed. She was right, and putting it on that calendar was our mistake.

It was a small version of the most common design error in finance automation. Systems are sized, tested and released against an average month. They are judged in its last two days and the first days of the next, when volume peaks, deadlines are fixed 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 only moment the finance team will remember.

Load tests replay the busiest close

Finance volume is not evenly spread. Suppliers send invoices at their own month-end. Customers pay in clusters. Accruals, intercompany charges and adjustments land in the final days. The peak arrives exactly when the team has the least time to review 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 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. 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. Early receipts are matched, recurring accruals pre-validated and known exceptions grouped during the month, so the peak holds only what genuinely cannot arrive earlier.

The queue is empty at cut-off

A human team works to the cut-off. A system has to be designed to it. By the cut-off time, every case is completed or visibly held with a reason and an owner. Nothing is silently in progress.

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 arrive months later, the record of how the automated part of each close ran is already there, period by period.

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, often a different one per entity and 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.

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 answer is more review capacity, not a lower bar. Year-end gets a longer freeze, because the audit follows it.

Trust comes from one parallel close

A new system never carries a close alone the first time. For at least one full close, the team closes the month the old way while the system processes the same period, and the results are compared line by line. 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 the most convincing evidence a controller can get, because it tests the system against the only standard she cares about: 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 said no.