Closing faster is mostly a reconciliation problem

Teams trying to shorten the close usually attack the last three days. The time is almost never there. It is in the accounts that are only reconciled once a month, and the reason that is hard is not effort.

By The erp.io team — Research and engineering

When a finance team asks us to help shorten the close, the plan they arrive with is nearly always a plan to compress the final few days: more people, longer hours, a checklist with owners. It works once, by about a day, and then stops working. Our close benchmarks across 38 teams, with the method and the spread, are on the close benchmarks page.

Where the days actually are

The close is long because a set of accounts are only looked at once a month, and looking at them involves reconstructing a month of activity from memory and evidence. The bank might be reconciled weekly. Intercompany, accruals, prepayments, inventory in transit, the clearing accounts that things land in when nothing else fits — those wait.

By the time anyone opens them, the reconciliation is not arithmetic. It is an investigation, in which someone tries to work out what a transaction from the 8th was, from a description entered by a person who has since had three hundred other things happen to them.

A discrepancy is cheap on the day it appears and expensive on the last day of the month. Nothing about it changed except who still remembers.

The lever, and its actual cost

Continuous reconciliation is the answer, and it is not free — which is the part usually left out when it is recommended. Moving the work into the month means:

  • Daily or weekly matching on the high-volume accounts, which is either a person’s recurring time or an automated match with a documented exception path. If it is a person and they are busy, it will be the first thing dropped in a bad week, and the close will quietly go back to what it was.
  • Someone owning the clearing accounts by name. An account everyone can post to and nobody owns is where the close hides. Its balance should be reviewed on a schedule, not at month end.
  • A rule for what happens to an unexplained item after a week. Escalated, written off within a threshold, or attached to a named person. Any of the three is fine. None of the three is what usually happens, which is that it waits for the close.

Where the automation argument gets oversold

Automated matching genuinely removes most of the volume, and it is the single biggest lever we see. It does not remove the exceptions, and the exceptions are where the days are. A tool that matches 90% of transactions has not shortened your close by 90% — it has left you the 10% that were always the hard part, and it will have shortened the close by rather less than the brochure implies.

It also creates a failure mode worth naming: a high auto-match rate makes the remaining queue feel small, so it gets triaged less rigorously, and items sit in it longer than they did when someone was looking at everything. We have seen a team’s exception queue age get worse after automation while their headline match rate looked excellent.

What to measure instead of days

Days-to-close is a lagging indicator and a poor diagnostic, because it moves for reasons that have nothing to do with the underlying problem. Two better ones, both available before the close:

  • The age of the oldest unreconciled item, by account. This predicts the close length better than anything else we look at, and it is visible on day three.
  • The number of accounts whose last reconciliation was the last close. That count is the size of the investigation you have scheduled for yourself.

Neither requires new software. Both are uncomfortable to publish internally, which is roughly the test of whether a metric is doing anything.

What we build for this is on the platform pages, and what it does not do — including the workflows we score ourselves worst on — is on the benchmarks page.

The erp.io team

We publish under one byline because no individual owns a finding here. Who you actually work with is on the team page, including the parts of a small team that are a disadvantage.

Keep reading

Other posts.

The reference call question that cannot be rehearsed

Vendor-supplied references are selected, prepared and generally honest, which is what makes them nearly useless. Four questions that produce information anyway, and one that does not work.

19 August 2026 · Read →

What an agent structurally cannot do inside a ledger

Our agents run at 94% accuracy on the workflow they are best at and 66% on the one they are worst at, measured across 23 customers. The gap is not a training problem. It is a description of which tasks have a checkable answer and which do not.

12 August 2026 · Read →

"Nobody can decide" is a schedule item, not a personality problem

Requirements that never settled (31%) and no internal owner with authority (19%) are the two largest primary causes across the 41 stalled implementations in our sample. Together they are half of it, and both are usually described afterwards as a people problem. They are a design problem.

29 July 2026 · Read →

Everything else we publish.

Primary research with stated sample sizes, buyer guides, and comparisons scored on published weights.