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. That instinct treats days-to-close like a staffing problem, when it is really an account reconciliation problem hiding behind the calendar.
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. None of that is a limitation of the ledger — it is what happens when month-end close is treated as a single event instead of a continuous accounting process.
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. That gap is exactly why financial close automation vendors quote match rate instead of days saved.
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. If your close management software cannot show you those two numbers today, it is measuring the wrong thing.
A close that never gets faster is often the last symptom of problems that started much earlier: data nobody looked at properly before go-live, decisions that stalled the schedule, or an agent that was allowed to post before it should have been trusted to. If you are still evaluating vendors, the reference-call questions worth asking will tell you which of these a given system actually has under control.
Close speed runs into the same discipline problem in a few other places: a group close that was never designed before the first entity was migrated, a two-way integration where nobody decided which side is authoritative, a chart of accounts that was copied rather than redesigned, and a cutover plan that never defined what would have stopped it.