Close acceleration without heroics

When a finance team's close cycle has drifted past the second working week, the first proposal on the table is usually a tooling one. A new consolidation system, a new reconciliation tool, an automation layer over the ledger. We have walked into half a dozen engagements where the business case for that purchase was already half-written by the time we arrived. In almost every case, the tooling investment would have shortened the cycle by perhaps a day or two and would have done absolutely nothing about the reasons the cycle had slipped in the first place.

Close acceleration is rarely a technology problem. It is a dependency problem, an ownership problem, and an evidence problem, and those three problems have to be solved in that specific order before any tooling investment can pay back. This piece is about how to do that work without theatrics, without consultants in shirtsleeves with whiteboards, and without telling the team they have been doing it wrong.

Start with visibility, not change

The single most useful artefact we produce in the first fortnight of a close engagement is a one-page map. The trial balance lists every account; the map lists, for each material account, three things. The upstream dependency — what data, from where, has to land before this account can be closed. The named owner — a single human who is accountable, not a team. And the evidence required to sign it off — what does 'finished' look like, in a form a reviewer can confirm in under five minutes.

Producing that map is uncomfortable. It surfaces every line where the answer is 'we are not sure'. It surfaces every reconciliation where the upstream data arrives by goodwill rather than by schedule. It surfaces every account that has multiple half-owners, none of whom feel personally accountable for it being wrong. We have never run this exercise without finding at least four such lines, and on a stretched function it is closer to a dozen.

Critically, do not change anything during this phase. The temptation to fix as you discover is enormous. Resist it. The map is more valuable while it is incomplete and embarrassing than after it has been tidied up. The team needs to see, collectively, why the close keeps slipping. They will then volunteer fixes faster than any external party could impose them.

Rebuild around dependencies, not the org chart

Most close calendars are organised by team. Accounts payable goes first, accounts receivable goes second, payroll goes third, revenue recognition goes fourth, and so on. That structure feels intuitive because it matches the way the function is organised, but it is exactly wrong. It forces tasks into the critical path that could happily run in parallel, and it hides dependencies that cross team boundaries.

Once the dependency map exists, redesign the calendar around the chain. Tasks that share no upstream data should run in parallel. Tasks that genuinely have to be sequential should have hard cut-off times, and a named escalation route if the upstream data is late. The escalation route is the bit people skip. Without it, the calendar is a wish-list rather than a plan.

On a recent engagement we saved three working days of close time without changing a single accounting treatment, simply by lifting two reconciliations out of the critical path and parallelising them with payroll. The work itself had not changed. Only the order in which it was done had changed.

One owner per line, not per team

When a line item has a team owner rather than a personal owner, it has no owner. This is not a slogan. It is what we have observed every time we have walked into a slow close. 'Finance owns the bank reconciliations' means nobody in particular is responsible for the bank reconciliations being finished by the agreed cut-off. As soon as you name a single human against each material line, two things happen. The work gets finished on time, because somebody's name is against it. And the cover plan becomes obvious — when that named human is on holiday, the deputy is named in advance rather than improvised on the day.

The objection we get is that named ownership is unfair to the individual, because it makes them visible when something slips. The opposite is true. Named ownership is what allows the individual to push back on upstream causes — when their reconciliation is late because operations did not produce the data feed, the named owner has the standing to say so. Without naming, slips are diffuse and the individual carries the consequence anyway, just less visibly.

Move the bar from accuracy to predictability first

Finance teams in trouble often optimise for accuracy at the expense of predictability. The close runs long because nobody is willing to publish until every estimate has been polished. The board would rather have a number on day six that is within materiality than a number on day twelve that is theoretically perfect.

The first cycle after we redesign the calendar, we deliberately move the bar to predictability. Publish on the agreed date, with caveats clearly stated. Track the variance between the published number and the final-final number for the next three closes. If the variance is within materiality, the practice sticks and the close has effectively shortened. If it is not, the variance points directly to the accounts where deeper work is needed.

This re-prioritisation requires explicit air cover from the CFO. Without it, the controller will quietly slip the date the first time an estimate looks wobbly. Make the priority order public, document it in writing, and refer back to it the first time the team is tempted to chase perfection at the cost of the cadence.

Standardise evidence before automating it

Once the calendar is rebuilt and the bar is set, evidence standardisation becomes useful. The form we like is a single page per material journal: source of the entry, calculation method, materiality threshold, reviewer name, date. Anything below the threshold needs no senior review. Anything above does. The threshold is set explicitly and signed off, not implied.

This is the point at which automation begins to pay back. Reconciliation tools that import standardised evidence cut review time meaningfully. Workflow tools that route journals to the named reviewer with the standardised evidence cut review time meaningfully. Without the standardisation underneath, the same tools just speed up the production of inconsistent evidence — which is to say, they make the problem worse.

Reviews stop being meetings

The last lever is the review cadence. The legacy pattern is two long review meetings per close — one mid-close and one immediately before publish. Both run over and both end with action items that drift into the next cycle. Replace them with a daily fifteen-minute stand-up during close week. Three questions per attendee: what closed yesterday, what is closing today, what is blocked. Treatment questions go offline with a defined SLA. Status theatre is not allowed.

Stand-ups feel insufficient when you first introduce them. Senior team members will lobby for the long meetings to come back, on the grounds that complex issues need discussion. They do — but they need it offline, with the right two or three people, not in a forum of fifteen. Hold the line. Within two cycles the team will not want to go back.

What you have when you finish

A close that runs to a published cadence, with predictable timing and standardised evidence, is the foundation everything else in finance depends on. Forecasting becomes credible because the actuals it sits on are credible. Audit becomes shorter because the evidence is already in the form the auditor wants. Tooling investments become rational because the underlying process is stable enough to automate.

It is unglamorous work. There is no consultant slide deck at the end of it that captures the change. The evidence is in the cadence — three consecutive months of closing on the agreed day, with the controller leaving the office at six on close day rather than ten. That is the test. If you have it, you have done the work. If you do not have it, no amount of new software will give it to you.