Skip to main content
Finaisse
All articles

Month-End Close

Why is month-end close so slow?

The last few days get the attention. Most of what slows them down was created weeks earlier — in reconciliations, journals, cut-off and the dependencies between them.

By Kris Subramanian·August 2026·6 min read

Day four is when problems become visible, not when they happen

It's day four of close.

The team is waiting on an intercompany reconciliation. A journal has arrived without support. An accrual needs revisiting because an invoice landed on the 29th that nobody expected. A receipt was applied to the wrong account on the 12th, which has just changed a balance, which means a reconciliation someone signed off last week has to be opened again.

Everyone is working. Nothing is moving.

The instinct is to push harder: more follow-ups, another status call, longer evenings. It works, in the sense that the close finishes. It also guarantees the same four days next month, because none of those problems were created on day four.

Day four is only when they became visible.

A close is a dependency structure, not a task list

A checklist assumes the work is a set of items that can be done in any order by whoever is free. A close is nothing like that. It's the point where several independent streams of work have to arrive at the right state simultaneously, and each one can invalidate the others.

An unapplied receipt changes the receivables position, which changes a reconciliation, which reopens a review. A late invoice changes an accrual, which changes a journal, which changes a schedule someone has already tied out.

The dependency existed on the 12th. The close team meets it on day four.

That's the gap. The close team can see the dependency. The operation that created it moved on three weeks ago.

Completion is not readiness

Every finance team has a close checklist, and checklists earn their place. They make ownership visible and give everyone one way to see progress.

What a checklist shows you is that bank reconciliation is outstanding, the accrual journal is pending, and the account review hasn't started.

What it can't show you is why any of them is outstanding, what each is waiting on, what else it affects, and whether it matters.

On day one an outstanding task is a task. On day four the same task is either a dependency holding up two other people or it's nothing. The checklist looks identical either way.

That's why close status measured in percentage complete is a number that feels informative and isn't.

Nobody can keep four hundred tasks true

A multi-entity close can run to several hundred tasks: reconciliations, journals, schedules, reviews, intercompany matches, tax provisions — one per entity, per account, per period.

Every one of them has a status, and today that status is maintained by hand.

Someone observes what has actually happened and transcribes it into a tracker. That transcription is where the truth leaks out, because a checklist is a manual model of reality that is stale by exactly as long as it's been since somebody updated it.

On day one, nobody minds. On day four, it's the thing decisions are being made from.

At three hundred tasks, keeping the tracker honest is itself a job — and it's the job that gets dropped first when the close gets tight.

Automating every task isn't the answer. Many close activities require judgement and shouldn't be delegated to software. What can go is the status update by hand.

The reconciliation task shouldn't move because a person ticked it. It should move because the reconciliation balanced. The accrual task should reopen on its own when an invoice arrives after cut-off. The intercompany task should flag when the counterparty balance moves, not when someone gets round to comparing them.

The event should update the task. The person should be deciding what to do about it.

The same exception, four weeks apart

Take a reconciliation difference of $410K on an intercompany account.

Found on the 8th, it's a question for whoever owns that account, and there are three weeks to answer it.

Found on the 22nd, it's competing for attention with the month's other work, and the person who knows what happened may be on leave.

Found at close, it's a close risk. It's blocking elimination, which is blocking consolidation, and the options have narrowed to explaining it, booking it, or delaying sign-off.

Nothing about the difference changed. What changed is how much time was left to deal with it.

And time is the only variable in that list that the finance team can't manufacture.

A checklist can't tell $500 from $500K

Completion status hides something else: materiality.

Two open items, two unticked boxes, and one of them can move the financial statements while the other cannot.

Prioritising by age, by owner or by whatever is at the top of the list is how teams end up spending close week on things that were never going to matter.

A controller doesn't need to know how much of the checklist is done. They need to know what could still change the numbers.

What changes when the work underneath is connected

The goal is fewer things arriving on day four in the first place, and that only happens if the close can see the operation feeding it.

When reconciliation runs against transactions as they move rather than against a month-end extract, exceptions surface on the 8th instead of being discovered at close.

When cut-off is visible during the month, the question stops being *what hasn't arrived?* and becomes *what could still change the numbers?*

When a change upstream automatically updates the work it affects downstream, the dependency lives in the system rather than in the memory of whoever has been doing this longest.

None of that requires anyone to work faster. It requires the events that are already happening to reach the tasks that depend on them — the one thing a tracker maintained by hand can never do, and what a connected finance operation is built to make possible.

Close readiness becomes something the work produces rather than something a person asserts.

A close shouldn't be ready because someone ticked a box. It should be ready because what's underneath it is.

What this doesn't fix

It's worth being honest about the limit.

A connected close still has bad months. An acquisition closes, a system migration lands mid-cycle, a customer disputes something large on the 30th — and none of that is a visibility problem.

What changes is the proportion.

The recurring, structural part of the delay — the part that happens every single month for the same reasons — is largely a consequence of finding out late. That part is addressable.

The genuinely unusual month is not, and any vendor promising otherwise hasn't closed many books.

The fastest close

The fastest close isn't the one where everyone works harder at month-end. It's the one where fewer problems are waiting when month-end arrives.

The close is only the deadline. The real work happens in the days before it.

See the work feeding the close — reconciliations, journals and cut-off — in one connected view.