Change your reporting before you change your ledger.

Most ERP projects I’ve seen go something like this, from finance’s side.

The new system gets chosen, the project gets planned, and nice reporting goes in a box marked “phase two”. History comes across as opening balances and maybe a year of detail, because migrating more is slow and expensive. Go-live happens (usually a bit later than planned), and then someone has to rebuild the management accounts and the board pack on the new chart of accounts - at the exact moment everyone is already exhausted.

And the first month’s pack has historics nobody quite trusts.

It’s easy to see why this happens so often. The ledger is the big, risky bit, and shiny reporting feels like something to sort out once things calm down. But the board still wants its pack on working day five, go-live or not. And it’s expecting it to be better than before.

So flip the order. Before you change the ledger, give your reporting and your history a home of their own - a reporting model that’s fed by the ledger, rather than living inside it. Build the reports there, on top of the system you have now, while everyone still knows what the numbers should be.

Work out the structure you want for your reports going forward, before the chaos of an ERP move. Load all the history in, as far back as is useful for you.

Then, when the new ledger goes live, you map its chart of accounts to the structure you’ve already built, and switch the feed. The reports don’t change. Last year’s numbers - and earlier - are still sitting there to compare against. Most of the business won’t notice anything happened at all - which is exactly what you want from a go-live.

That cutover isn’t free, of course. Someone still has to do that mapping. But you do it once, in one place, and you can test it against months you’ve already closed before anyone relies on it.

There’s a couple of bonuses, too. Reporting comes off the ERP project’s list, so if the timeline slips (and it might!), finance isn’t stuck waiting. And designing the reporting first tells you a lot about what the new chart of accounts actually needs to look like - far better to find that out before it’s built than after.

The benefits of this setup also apply if you buy companies, by the way. Acquired ledgers feed into the same reporting quickly, mapped once, rather than being bolted on in a spreadsheet every month end for however long.

Your reports shouldn’t need to know which ledger they’re sitting on. Do them first!