The close is not the problem

A group financial controller asks for a faster close. Twelve working days, and the board wants eight. So the brief arrives as a consolidation brief: replace the tool, tighten the calendar, automate the eliminations.

Then you sit with the team through an actual close, and the twelve days break down like this. Two days waiting for one subsidiary to submit. Three days of intercompany matching that fails because two entities book the same transaction under different accounts. One day rebuilding a schedule that lives in a spreadsheet on somebody’s laptop. A day and a half of review comments that arrive after the numbers were already circulated. The consolidation engine itself runs in about forty minutes.

None of that is a consolidation problem. It is a submission problem, a mapping problem, an ownership problem and a review problem, wearing a consolidation costume.

Why the wrong brief survives contact

The close is the only part of the finance calendar with a visible number attached to it. Nobody counts the hours lost to intercompany disputes across the quarter, but everybody can count days to close. So the pain gets named after the thing that is measurable rather than the thing that is causing it.

New software is also easier to buy than new behaviour. A platform can be approved in a single capital request. Telling four business units that they will submit on day two, in an agreed format, with a named owner, requires someone senior to hold a position for a year.

What we do about it

Before we design anything in OneStream, we ask a finance team to instrument the close they already have. Not a maturity assessment. A timestamp on every submission, every rejection, every reopened period, for two cycles. It takes a controller about an hour per close to record, and it ends the argument about where the days go, because the days are on the page.

The instrumented close usually shows three things. First, that the critical path runs through two or three entities, not all of them, so a group wide programme is the wrong shape. Second, that a large share of the rework traces to a handful of accounts that different parts of the business use differently. Third, that review is sequential when it could be parallel, because nobody trusts a partial number.

Then the platform does help

Once you know that, an EPM implementation earns its keep. Submission windows and validation at the point of entry stop the bad data at the door instead of at the group. Intercompany matching against an agreed rule set removes the negotiation. A single, versioned set of reports removes the day and a half of comments on stale numbers.

But the sequence matters. A team that moves an unexamined close onto a new platform gets the same twelve days with better logging. We have been called in to fix that outcome more than once, and the second implementation is always harder than the first, because by then the business has learned that the system is the problem.

The number that actually moves

The teams that get to eight days rarely get there by speeding anything up. They get there by removing three waits and two arguments. The software is what makes the removal stick.