Why your close takes 15 days when it should take 5

Why does month end close take so long?

Because a close is a queueing problem wearing the costume of a workload problem.

APQC's Open Standards Benchmarking work, drawn from roughly 2,300 organizations, puts the median monthly close at 6.4 calendar days, the top quartile at 4.8 days, and the bottom quartile at 10 days or more. The top quartile is not doing a quarter of the work. They are doing roughly the same work with far less waiting between the pieces.

I have run the close for a group of entities for about a decade, and every time I have measured it honestly the ratio has been the same: four or five days of effort spread across two or three weeks of elapsed time. The effort was never the problem. The gaps were.

So the useful question is not "how do we work faster" but "what are we waiting for, and why is that wait in front of the others instead of beside them".

Cause one: the dependency chain is serial when most of it could be parallel

A serial close runs one task at a time because each step was written down in the order somebody happened to learn it.

The familiar pattern: the bookkeeper reconciles Entity A, then B, then C, in the order the files sit in the browser tabs, then intercompany, then accruals, then review, then consolidation. Almost none of that ordering is real. Entity C's bank reconciliation does not depend on Entity A's, and depreciation does not depend on the bank at all.

The only hard dependencies are that you cannot reconcile against a statement you do not have, cannot agree an intercompany balance until both sides exist, and cannot consolidate until every entity is done. Everything else is convention. When I mapped my own close and drew the real dependencies rather than the habitual order, most tasks had no upstream blocker at all. That is the first place to look, and it costs nothing but attention.

Cause two: you are waiting on bank feeds and statements

Nothing in the close can be verified before the underlying source arrives, and bank data does not arrive on a uniform schedule.

Some feeds land overnight, some with a two or three day lag, and some push transactions that later change amount when they clear. Card statements often cut on a date unrelated to the month end, so the card closing on the 24th leaves seven days of charges that need accruing rather than reconciling.

For nine entities with two banks each, that is eighteen bank arrival times before the cards, and the close waits for the last one. Inventory every source, record its actual arrival lag, and stop assuming everything is available on day one. One broken feed forcing a manual download is often worth two days.

Cause three: intercompany never reconciles on the first pass

Intercompany balances are the most reliable source of delay in a multi-entity close because they require two sets of books to agree about the same transaction.

Entity A books a management fee to Entity B. Entity B books it a month later, or to a different account, or not at all because nobody sent an invoice. The two books now disagree, and the disagreement has to be explained before the group numbers mean anything.

The failure modes are all preventable. One side accrues and the other waits for the invoice. The amounts differ because the allocation was recalculated. A recharge is booked as a reduction of expense on one side and revenue on the other. And most often the intercompany accounts are never reconciled against each other at all, so they accumulate a difference that grows quietly for years.

If your close has one structural weak point, this is usually it. Agree intercompany every month and the balances stay small enough to fix in an hour. Let it run for a year and you have a project.

Cause four: manual journal entry prep is rebuilt from scratch every month

A journal entry recalculated by hand each month is a journal entry waiting for a person, and people are the scarcest resource in a lean finance function.

Think about what gets prepared by hand in a small group: depreciation, prepaid amortisation, the payroll accrual for days straddling the month, the interco management fee, revenue cut-off adjustments, shared costs allocated on headcount. Each lives in a spreadsheet somebody opens, updates, checks, and types into the ledger.

Two problems follow. First, elapsed time: each entry is a small task with a human queue in front of it. Second, reliability. Panko's spreadsheet-error research, synthesising audits of 88 operational spreadsheets, found 94% contained at least one error, with an average cell error rate of 5.2%. Those are the workbooks feeding your journal entries.

Errors cost days as well as accuracy, because a number that looks wrong in review sends the entry back to the start of the queue. Gartner's 2024 survey of 497 controllers and chief accounting officers found 18% of accountants make financial errors at least daily and 59% make several errors per month.

Anything calculated the same way every month can be prepared automatically and reviewed rather than rebuilt, which takes preparation off the critical path.

Cause five: review is a bottleneck with one person in it

If one person reviews everything, the close cannot be faster than that person's calendar.

This is the cause owners look at last, because the bottleneck is usually them. The bookkeeper finishes on day six. The owner is travelling until day ten. Review happens on day eleven, generates four questions, and the answers come back on day thirteen.

Three problems are tangled together: the reviewer is a single point, the review has no defined scope so it expands to whatever the reviewer feels like asking about, and it happens once, at the end, on everything.

The fixes are structural, not motivational. Define what review covers, with materiality thresholds. Let low-risk work be reviewed by someone other than the owner. And review in tranches as entities complete. A reviewer looking at three entities on day three is not a bottleneck; the same reviewer looking at nine on day ten is.

Cause six: nobody owns the task, so everyone waits

An unowned task is not a slow task. It is a task that does not start.

Who chases the supplier invoice that has not arrived? Who updates the headcount file the allocation depends on? These sit in the space between people, and each can absorb days of nothing happening.

Write down every close task with exactly one name against it. Not a team, a name. The discomfort you feel doing that is the problem becoming visible.

When is a 15-day close the right answer?

Sometimes it is, and pretending otherwise is how advisers lose credibility.

If your finance function is one part-time bookkeeper covering nine entities, a five-day close is not a process improvement, it is a hiring decision. If revenue cannot be measured until a distributor reports on the tenth, no workflow design moves that date. If the close competes with payroll, collections, and a compliance deadline in the same week, something has to give, and the close may be the right thing to give.

What matters is whether your 15 days are chosen or inherited. A group that has decided the close lands on day 12 because that is when the last real input arrives, and hits day 12 every month, is running a good process. A group landing anywhere between day 11 and day 19 depending on the month does not have a slow close. It has no close at all, and the variability is the symptom.

Intuit's Enterprise Technology Benchmark found that 76% of multi-entity firms say their technology struggled when they added entities and 64% say the close takes too long. Most of those firms are not badly run. They are running a single-entity process at multi-entity scale, and the process broke, not the people.

A worked example: taking a twelve-entity group from 15 days to six

A group of twelve entities: five service businesses, three property companies letting space to them, two trading in a second currency, one part-owned business and one dormant company. Final numbers arrive somewhere around day 15.

Mapping it produces a clear picture. Days one to four: nothing happens, because two card statements and one foreign bank statement have not arrived and the bookkeeper is waiting for a complete set. Days five to nine: sequential bank reconciliation, one entity at a time. Days nine to eleven: intercompany, which throws up six differences, four because the rent recharge was accrued on one side and invoiced on the other. Day twelve: manual entries from seven spreadsheets. Days thirteen to fifteen: review by the owner, who is not available on the thirteenth.

Now redistribute. Bank reconciliation for the nine entities whose feeds arrive overnight starts on day one and runs in parallel, so three late statements hold up three entities rather than twelve. Intercompany is agreed weekly, so month end has one or two differences instead of six. The rent recharge posts on both sides on the same day, eliminating the largest recurring difference. Depreciation, prepaid, and allocations are prepared before month end. Review happens in three tranches with a materiality threshold, so the owner spends 40 minutes three times instead of two days once.

Nothing there is heroic. The work is still the same four or five days. It now finishes by day six, because the waiting was removed rather than the work.

Can QuickBooks or Xero fix this?

Partly, and the boundary is worth stating precisely.

Both do the single-entity mechanics well: bank feeds, reconciliation screens, recurring journal templates, period locking, and a decent audit trail of who posted what. If your slow close is caused by manual bank reconciliation in a spreadsheet, either one solves that outright.

What neither does is the group layer. They will not agree Entity A's intercompany receivable to Entity B's payable, will not eliminate on consolidation, and will not show which of twelve entities is holding up the group. That layer becomes a spreadsheet, which reintroduces the manual preparation and error exposure described above, and it is where most of the residual days live.

Where to start

Measure before you change anything. For one close, log every task with a start time, a finish time, and the name of the thing it was waiting for. One month of that data will tell you more than any framework.

Then fix the waits in order of size. Broken feeds first, intercompany discipline second, prepared-in-advance entries third, review structure fourth. If the books are behind before the close even begins, you have a catch-up problem rather than a close problem, and that comes first.

This queue is what cruisr was built for: routine categorisation and reconciliation run nightly on your existing QuickBooks Online or Xero files, so the books are current when the month ends, exceptions go to a human team rather than piling up for one reviewer, and the close package lands by business day 3. When the queue is gone, what remains is judgement, and judgement was never the slow part.

If you would rather see where your own days are going first, get in touch. cruisr runs a free close diagnostic on your existing files and comes back within 48 hours with a 30-minute readout. And if the mechanics are unfamiliar, what a close actually is is the place to start.