Your First Year-End Close on a New ERP: A Practical Plan

You went live on the new ERP in spring or summer. Hypercare ended, the monthly closes got a little faster each time, and the project team moved on to other work. Now it is October, and your first year-end close on the new ERP is three months away. It will be the first time the system has to produce a full year of figures that an auditor signs, a tax return relies on, and a board compares with last year. Last year lives in a different system.

The first year-end close on a new ERP is where every shortcut taken during the migration comes back. Opening balances that were never fully reconciled, stock valuations that were “close enough” at cutover, fixed assets loaded as a single line. None of that stopped the monthly closes. All of it shows up at year-end. Below is what to check now, and how to run the close itself.

Why the first year-end close on a new ERP is different

A monthly close asks whether this month makes sense. A year-end close asks whether the whole year makes sense, including the part that happened before go-live. If you changed systems mid-year, your annual figures are stitched together from two systems, and the seam is the cutover date. Every number the auditor tests near that seam, the opening balances, open orders, stock and fixed assets, has to be explained from both sides.

There is also a set of processes that only run once a year: year-end stock counts and revaluation, depreciation true-ups, accruals for bonuses and holiday pay, closing the fiscal year and carrying balances forward, intercompany eliminations, and the statutory reports. In a new ERP, most of these have never been run for real. Some were tested once in a project environment with test data. Some were not tested at all, because go-live had priority.

Even the fiscal year close itself is more than one step. Microsoft’s own Business Central documentation, for example, lists nine separate areas of work, from restricting posting dates and adjusting exchange rates to running pre-closing reports and posting the year-end closing entry. Your ERP will have its own version of that list. The question is whether your team has ever worked through it.

October: find out what you do not know

Start with a short, honest review, ideally run by someone from finance and someone who knows the ERP configuration.

1. List every once-a-year process: stock count, revaluation, depreciation, accruals, fiscal year close, intercompany, VAT annual adjustments, statutory reports. For each, write down whether it has run in the new ERP, only in test, or never.
2. Reconcile the migration. Check the opening balances loaded at cutover against the old system’s closing balances, account by account. Any difference you cannot explain now will be the auditor’s first question.
3. Check stock and fixed assets in detail. These are the areas where migrations most often loaded summary figures instead of detail, and year-end is where the detail is needed.
4. Talk to your auditor. Tell them you changed systems, when, and how the data was migrated. Ask what they will want to see. Most auditors would much rather hear this in October than discover it in February.
5. Keep the old system readable. Make sure someone can still log in to the old ERP, or has a reliable export of it, until the audit is signed.

November: rehearse the close

Anything that has never run in production should run in a test copy of the live system before December. Take a recent copy of production, run the fiscal year close, the stock revaluation, the depreciation run and the key reports, and compare the result with what finance expects. This is the step most companies skip, and it is the one that finds the configuration gaps while there is still time to fix them.

Use the rehearsal to write the close plan: every step, in order, with an owner, a day and a check. Who runs the stock revaluation, on which day, and who confirms the result? Which report does the controller sign off before the fiscal year is closed? A plan on paper is also what lets someone else step in if a key person is ill in the first week of January.

December and January: run the close

• Count stock on the date you planned, with the process you rehearsed, and post the differences in the new ERP before the fiscal year is closed.
• Run the close in the order of the plan and tick off each check. Do not skip a check because the step “looked fine”.
• Keep a short log of every manual correction and why it was needed. It is useful for the auditor, and it is the list of things to fix before next year.
• Have someone who knows the configuration available on the close days. Not on call somewhere, available. If that person was part of the implementation team that has since left, arrange cover now.

After the close: fix the causes

Once the audit is signed, go through the log of manual corrections. Each one is a small configuration or process problem that will come back next year and, in most cases, every month. The first year-end close is the best moment you will get to see them all in one list. Treat it as the real end of the implementation, not as a finance event.

The bottom line

A company that went live in 2026 is not finished with its ERP project until the first year-end close is done and the audit is signed. Review what has never run in October, rehearse the close in November, freeze changes in December and run the close to a written plan in January. The work is not glamorous, and it is much cheaper than explaining a stock difference to the auditor in February.

What Happens After Go-Live

Should You Go Live With Your New ERP on January 1?

Why Post-Go-Live Support Fails and How to Tell If Yours Is Failing

Application Management service

Sources

Microsoft Dynamics 365 Business Central: close years and periods (documentation)