The Close That Depends on One Person

Every month the books close, and every month they close because one person does something nobody else can explain. What looks like a staffing risk is a process that was never written down, and its cost grows quietly every month.

Ask a finance team how the month closes and you'll get a tidy answer: the sub-ledgers roll up, the reconciliation runs, someone reviews it, and the numbers go out, which sounds like a process because it's described like one.

Ask something narrower, like who reconciles billing against the general ledger, and what exactly they do.

Now you get a name, usually after a small pause, because everyone knows the honest version. That person does it in a workbook, makes a series of adjustments, and the adjustments are right, and nobody else could reproduce them. The person is usually doing it extremely well, and the trouble is that the only complete description of the process lives in one human being.

Doing it by hand is fine

It's worth being precise, because the careless version of this argument does real harm.

Plenty of manual processes are perfectly sound. A spreadsheet with a named owner, a written method, version control, and a quarterly review is a sensible tool, cheap and easy to follow, and replacing it with software would often cost more than it saves. Nobody should feel bad about one.

A manual process becomes risky when the manual step carries judgment nobody wrote down. "This step is done by hand" is a cost. "This step is done by hand, following rules no one has ever stated" is a dependency, and dependencies behave differently: they never appear on a report, they never prompt a review, and they get worse precisely because things are going well.

How it forms

Nobody designs it this way, and every step along the way makes sense.

A system doesn't quite produce what finance needs, so somebody bridges the gap by hand, which is sensible, and since the bridge works, it stays. A month later an unusual case turns up and the same person handles it correctly, using judgment. The judgment doesn't get written down, because writing it down was never the job, and closing the month was.

Repeat that thirty or forty times over three years and the workbook has become a system of its own, with rules, exceptions, an escalation path, and a maintainer, and no documentation, no tests, no version history, and no second person.

The arrangement survives because it never fails. The person is good, the close happens, and from the outside everything looks healthy right up until the day that person isn't available.

What it already costs

The natural move is to file this under risk, something that would hurt if the person left. That framing lets it stay unfixed, because it turns a cost you're paying now into a hypothetical one.

The close takes longer than it should, and a little longer each year. Every new exception adds a manual step, and manual steps pile up. It's worth asking how long the close took two years ago.

Nothing can be improved. You can't improve a process you can't see, and every improvement conversation ends at the workbook, because changing it means changing something only one person understands, and breaking the close would cost more than the gain.

It can't be reviewed properly. A reviewer can check whether the numbers look right, and can't check whether the method was right, because the method isn't available to them. That's a gap in your controls whether or not anyone has written it up as one.

It holds the person back. The most capable person on the team can't take on anything bigger, take a vacation without careful planning, or be promoted without creating a succession problem, so their competence ends up keeping them in place.

Succession is a real cost too. When the work eventually changes hands, it changes hands badly. The successor learns the normal path in a week and discovers the exceptions over a year, one difficult month at a time.

The fix is smaller than it looks

Because this gets filed as risk, the proposed cure is usually huge: a new finance system, a transformation program, a big purchase. That rarely helps, and starting there usually fails, because you'd be automating a process nobody has defined yet and spending the whole implementation arguing about what the rules are. The sequence that works is plainer and much cheaper.

Write the rules down before touching any technology. Sit with the person through one real close, the actual one, and every time they make a decision, pause and ask why. Most of these sessions surface twenty to forty rules nobody has ever said out loud, and that written record is worth more than any tool you could buy this quarter.

Sort the rules into three groups. Some always produce the same answer, and a system can carry those. Some are genuine judgment calls that should stay with a person, with a stated basis and an owner. And some turn out to be workarounds for a flawed input upstream, which should be fixed where they start instead of being built into a new system.

That third group is usually bigger than anyone expects, and it's where most of the value sits. A lot of month-end adjustment exists only because something upstream gets entered inconsistently, so encoding the adjustment makes the problem permanent, while fixing the input makes the adjustment disappear.

Then automate the rule-following group, and only that. You're now building against a written specification instead of one person's memory, so it can be tested, reviewed, and handed over.

Give each judgment call an owner and a stated basis, so the reasoning outlives any one person and the judgment itself stays where it belongs.

What it looks like when it works

The close may not be faster on the first day. What changes is that a second person can run it, the method can be reviewed instead of taken on trust, new exceptions get added on purpose instead of quietly absorbed, and the person who used to be the process becomes the one who owns and improves it.

That last change matters more than the efficiency. The business stops depending on something it doesn't control, and gets back the full capacity of its best operator.

The same pattern elsewhere

The close is the clearest example because it runs on a schedule and a miss is obvious, and the pattern shows up well beyond finance: the engineer who's the only one who can ship a release, the operations lead who knows which customers get the exception, the admissions officer who knows how the unusual case really gets handled, and the account manager whose renewal forecast is right because of information that lives nowhere else.

Underneath each of those is the same thing: real expertise, applied well, with no copy of it that the business owns, which looks like excellence because it is excellence, and is a dependency at the same time. The work is to make sure the business keeps a copy of that expertise while the expert keeps doing what they're great at.

Back to articles