Blog

It is day four of the close, and finance is the only floor with the lights still on. The controller has a spreadsheet open that does not agree with the ledger, an email out to a cost centre that has gone quiet, and the same number in two reports that somehow changed between this morning and now. Ask her how it is going and she uses one word, the word every controller uses. Chasing.

A five-day close feels like a failure of finance, and finance is where the blame lands. But finance did not make this mess. It only inherited it, on a deadline, at the worst possible moment.

IFS Cloud can turn the close from a scramble into a controlled, repeatable sequence. But only if you treat it as the last mile of a clean pipeline, not as a finance sprint bolted onto the end of every month. Here is what a good close actually rests on, and why nearly all of it lives upstream of the people doing the chasing.

The ledger only reflects the sub-ledgers

In a suite like IFS Cloud, the general ledger sits downstream of everything (inventory movements, manufacturing cost, project transactions, purchasing accruals, sales invoices), each posting in through defined accounting rules. So the ledger is never cleaner than the transactions feeding it. That number the controller cannot explain? Manufacturing or the warehouse created it three weeks ago, and she is doing forensic accounting to account for their open work order.

The lever is not a faster finance team. It is sub-ledger discipline during the month: costed transactions, closed work orders, cleared accruals, reconciled inventory, done continuously, so that at period-end there is nothing left to chase because nothing was left open. The close gets fast when the month was clean, never when finance works the weekend harder.

Period control is a sequence, or it is theatre

IFS gives you real control over accounting periods: what can still post where, and in what order things close, so sub-ledgers settle before the ledger locks behind them. Used deliberately, it is a gate: late transactions land somewhere controlled instead of quietly reopening a number you already signed off. Used as an afterthought, it is a button someone clicks at the end, and then spends next month explaining why last month moved after it was closed. Decide the order on purpose. Which sub-ledgers close first, when the ledger locks, who may reopen a period and on whose authority. A close with no sequence is not a close. It is a snapshot that is still moving.

Two truths the system can carry, or two you carry by hand

Organisations of any size owe more than one accounting truth: a local statutory view and a group standard, different valuations, different calendars. IFS can carry them in parallel, natively, falling out of the same postings. The trap is treating that as something finance reconciles at the end with spreadsheets. Do that, and every close becomes a manual bridge between two views the system could have maintained all along, rebuilt from scratch, twelve times a year. Designed properly up front, both truths just appear. Bolted on afterwards, you have signed finance up to reconcile two realities by hand forever. It is an implementation decision, and it quietly sets the ceiling on how fast every future close can ever be.

You cannot speed up a close you cannot see

Part of why the close feels like chaos is that no one can see it. Twelve tasks across six people, and the only status report is walking over and asking. So the controller spends the week chasing status instead of clearing work, the priciest kind of busy there is.

IFS Cloud’s Lobbies make the close a live picture (reconciliations outstanding, sub-ledgers still open, exceptions, the cost centres that have not reported), on one screen everybody shares, with no external BI stack to stand up. When the whole team can see the same close in real time, the controller stops being a human switchboard and the bottleneck stops hiding. The thing actually holding up day four becomes visible to everyone at once.

The first close after go-live is the one that tells the truth

Every implementation has a moment of truth, and it is not go-live weekend. It is the first month-end on the new system, where migrated opening balances, fresh accounting rules, new cost structures and people still learning the screens all meet real numbers against a statutory deadline. Teams who prepare for it as an event (opening balances reconciled to a trusted number, the close steps dry-run, the first period-end staffed like a second go-live) sail through. Teams who treat it as “just another month” discover, live and on the clock, that an opening-balance assumption was wrong. If you are implementing now, put that first close on the plan as a named milestone with its own rehearsal. It is the exam the entire finance workstream was really studying for.

Day one, the other version

Picture the same controller, a few months later. The sub-ledgers reconciled themselves through the month, because nothing was left open to chase. The sequence ran in order. Both accounting truths were already there. And the whole close sat on one Lobby the team could see, so nobody had to walk over and ask. The lights in finance are off by a reasonable hour, because the close finished on day one, not because anyone worked harder, but because the month was clean before it ever reached her desk.

That is the difference between a scramble and a sequence. It was never really a finance problem. It was a pipeline, and the close was just where you finally saw it.