AI in the month-end close: exception queues, not automation

Most pitches for AI in the financial close promise automation: the system posts the adjustment, blocks the suspicious entry, files the pack. Each of those verbs moves accountability from a named person to a piece of software — which is exactly what a group financial controller cannot accept, because their name goes on the close either way.

There is a more useful shape, and it is deliberately less dramatic: the system reads, tests, and ranks; a human decides. Read-only by design, not as a limitation but as the point.

What deterministic tests find in a ledger

Run across a multi-entity general ledger in the pre-close window, deterministic checks surface the things reviewers know to worry about but rarely have time to sweep for: duplicate journals, round-number and just-below-threshold clustering, back-dated and post-period postings, sequence gaps, intercompany breaks, distributions that fail Benford's-law analysis.

None of that requires a model to guess. Every test is ordinary code over normalised data, which means every flag can show the exact rows it came from.

The exception queue is the product

The output that matters is a ranked queue the controller works through item by item — open the flag, drill to the source rows, disposition it, move on. The system never posts, never edits, never blocks, never files. What changes is not who decides. It is how much the decider can see before sign-off.

That framing also answers the adoption question. A tool that takes decisions away from the finance team gets resisted. A tool that hands them a better-prepared review gets used.

Accountability survives contact with the auditor

Because every figure traces to source rows and the important steps land in an inspectable log, the close does not acquire a new black box. It acquires a paper trail. The controller signs with more certainty, and the signature still belongs to a person — which is the only arrangement an auditor, or an owner, should accept.