The Close That Depends on One Person

Every month the books close. Every month they close because one person does something nobody else can explain. That is not a staffing risk. It is a process that was never written down, and it compounds quietly until the day it cannot.

Ask a finance team how the month closes and you will get a clean answer. Sub-ledgers roll up, the reconciliation runs, review happens, the numbers go out. It sounds like a process because it is described like one.

Then ask a narrower question. Who does the reconciliation between billing and the general ledger, and what do they actually do?

Now you get a name. And usually a small pause, because everyone knows the honest version: they do it in a workbook, they make a set of adjustments, and the adjustments are correct, and nobody else could reproduce them.

This is broken work. Not because it is manual, and not because the person is doing it badly. Usually they are doing it extremely well. It is broken because the definition of the process exists in exactly one place, and that place is a human being.

Manual is not the problem

It is worth being precise here, because the sloppy version of this argument does real damage.

Plenty of manual processes are fine. A spreadsheet with a named owner, a documented method, version control, and a quarterly review is a proportionate tool. It is cheap, it is legible, and replacing it with software would cost more than it saves. Nobody should feel bad about it.

The thing that makes a manual process dangerous is not the manual part. It is when the manual step carries undocumented judgment.

There is a real difference between "this step is done by hand" and "this step is done by hand according to rules that have never been written down." The first is a cost. The second is a dependency, and dependencies behave differently: they do not show up on any report, they never trigger a review, and they get worse specifically because things are going well.

How it forms

Nobody designs this. It accumulates, and each individual step is reasonable.

A system does not quite produce what finance needs, so somebody bridges the gap by hand. That is sensible. The bridge works, so it stays. A month later an edge case appears, and the same person handles it, correctly, using judgment. That judgment is not written down, because writing it down was not the job. The job was closing the month.

Repeat that thirty or forty times over three years and the workbook is now a system. It has rules, exceptions, an escalation path, and a maintainer. It just has no documentation, no tests, no version history, and no second person.

The reason this survives is that it never fails. The person is good. The close happens. From the outside, the process looks healthy right up until the moment it is not available.

What it actually costs

The instinct is to file this under risk, as a thing that would be bad if the person left. That framing lets it stay unfixed, because it turns a present cost into a hypothetical one.

The costs are already being paid.

The close is slower than it should be, and getting slower. Each new exception adds a manual step, and manual steps do not compound down. Ask what close took two years ago.

Nothing can be improved. You cannot optimise a process you cannot see. Every improvement conversation ends at the workbook, because changing it means changing something only one person understands, and the risk of breaking the close outweighs the gain.

It cannot be reviewed properly. A reviewer can check whether the numbers look right. They cannot check whether the method was right, because the method is not available to them. That is a control gap whether or not anyone has written it up as one.

It quietly limits the person. The most capable person in the team is structurally prevented from taking on anything larger, taking leave without planning around it, or being promoted without a succession problem. They are not being rewarded for their competence. They are being held in place by it.

And the succession cost is real, not hypothetical. When it does transfer, it transfers badly. The successor learns the happy path in a week and discovers the exceptions over a year, one painful month at a time.

The fix is smaller than people expect

Because this gets filed as risk, the proposed remedy is usually enormous: replace the finance system, run a transformation programme, buy something.

That is rarely what it needs, and starting there usually fails, because you are automating a process nobody has defined yet. You will spend the implementation arguing about what the rules are.

The actual sequence is duller and much cheaper.

Extract the rules before you touch any technology. Sit with the person through one real close, not a described one. Every time they make a decision, stop and ask why. Most of these sessions produce twenty to forty rules that have never been stated aloud. That transcript is the asset. It is worth more than any tool you could buy this quarter.

Sort the rules into three piles. Deterministic ones, which a system can execute. Genuine judgment calls, which should stay with a human but need a stated basis and an owner. And rules that turn out to be workarounds for a broken upstream input, which should be fixed at the source rather than encoded.

That third pile is usually bigger than anyone expects, and it is where most of the value is. A lot of month-end adjustment exists only because something upstream is entered inconsistently. Encoding that adjustment into a new system makes the problem permanent. Fixing the input makes the adjustment disappear.

Then automate the deterministic pile, and only that. Now you are building against a specification instead of a person's memory, so it can be tested, reviewed, and handed over.

Give the judgment calls an owner and a stated basis. Not to eliminate judgment, which is often the right answer, but so the reasoning survives the person.

What it looks like when it works

The close is not necessarily faster on day one. What changes is that a second person can run it, the method can be reviewed rather than trusted, an exception can be added deliberately instead of absorbed silently, and the person who used to be the process becomes the person who owns and improves it.

That last part matters more than the efficiency. The business stops depending on something it does not control, and gets back the capacity of its best operator.

Where this shows up beyond finance

The close is the clearest example because it happens on a schedule and the failure is visible. The pattern is not confined to finance.

It is the engineer who is the only one who can do the release. The operations lead who knows which customers get the exception. The admissions officer who knows how the edge case is really handled. The account manager whose renewal forecast is right because of information that lives nowhere.

Same structure every time: real expertise, correctly applied, and no version of it that the business itself owns. It looks like excellence, and it is. It is also a dependency, and the two are not mutually exclusive.

The work is not to remove the expertise. It is to make sure the business has a copy.

Back to articles