Protecting the Month-End Close During an ERP Implementation: A Portfolio Company Case

A case: a portfolio company replaces its ERP while growing fast, and the close cannot slip

The month-end close during ERP implementation is where most system projects quietly damage the finance function. Testing, data migration and training all compete for the same few finance people who close the books. This case follows a common situation in private equity portfolios: a growing company replacing its ERP, with a lean finance team and no room for a late or inaccurate close. It sets out how the risks were assessed, how accounting and consolidation testing was organised, how the close was protected, and how the business was stabilised and handed back. The case is representative, not a named company, and it is the type of situation NEO Expertise supports finance teams through.

The Situation

The company has doubled its revenue in three years, partly through acquisitions, and now runs four legal entities on a system designed for one. The private equity owner has approved an ERP replacement to support the next stage of growth.

The ERP project plan assumes finance staff will spend around 40% of their time on design workshops, testing and data validation for six months. The finance team is eight people, already closing on working day 7 with little slack. At the same time, HR is implementing a new HR information system, which competes for the same payroll data and some of the same people. HR systems support is its own specialism and is handled separately; this case follows the finance side.

Something has to give. The question the owner asked was how to make sure it is not the close, and not the accuracy of the numbers.

Step 1: Assess Capacity and Transformation Risk

The assessment covered internal team capacity against the combined calendar: the ERP project milestones laid over the monthly close, quarter ends, the audit and lender reporting. It showed three months where the demand on finance was more than 150% of available hours. Those three months were the system integration testing phase, the user acceptance testing phase and the month of go-live, and one of them was also a quarter end with lender reporting due.

It also identified the capability gaps. Nobody on the team had tested a consolidation in a new system before, and the project’s testing plan covered transactions in detail but consolidation only as a single line item. That was the transformation risk that mattered most: a go-live where individual entities work and the group numbers do not.

The finance gaps, the urgent resource needs and the risks were written up together, so the owner and management approved one response rather than a series of separate requests.

Step 2: Test Accounting and Consolidation

Experienced finance specialists joined the team for the duration of the project, with two roles: carry part of the recurring close workload, and lead finance testing on the ERP project.

Accounting process testing ran scenario by scenario: order to cash, purchase to pay, payroll journals, fixed assets, accruals, intercompany charging and the period-end close. Each scenario was tested with real transactions from a prior month, and the results were compared with what the old system had produced.

Consolidation testing was built as a full trial consolidation, not a checklist. Illustrative results from the first trial on a prior quarter’s data:

Test	Result	Cause
Entity trial balances agree to old system	3 of 4 agreed	One entity’s opening balances migrated at the wrong date
Intercompany eliminations net to zero	€214,000 residual	Two intercompany accounts mapped to external revenue
Group profit agrees to prior reported figure	€38,000 difference	Foreign currency translation rate table not loaded for one month
Reporting pack populates automatically	11 of 14 schedules	Three schedules still pulling from spreadsheets

Every issue was logged, resolved and retested, and the trial was repeated until the group figures reproduced the prior reported numbers exactly. The intercompany mapping error alone would have overstated group revenue in the first live month. The matching discipline in reconciling intercompany balances was what found it.

Step 3: Protect the Month-End Close

Close timelines were treated as fixed. The specialists took over defined parts of the recurring close (reconciliations, accruals, intercompany matching) so the permanent team could attend design workshops and testing without the close slipping.

Financial accuracy was protected by keeping controls unchanged during the project: the same reviews, the same sign-offs, the same reconciliation deadlines. The first live close on the new system was run in parallel with the old one for the balance sheet, so any migration difference would show up in the reconciliations rather than in the published figures.

Maintaining financial accuracy through a system change is also a legal duty, not only good practice. Under the EU Accounting Directive 2013/34/EU, annual financial statements must give a true and fair view, and in the UK section 386 of the Companies Act 2006 requires adequate accounting records at all times, including the day a system is switched over.

Step 4: Manage Risk and Keep Momentum

Critical milestones were monitored weekly, and issues were escalated quickly to the project sponsor and the owner’s operating partner. The finance and ERP teams worked from one shared issue log, so a testing defect and its effect on the close were visible in the same place.

Two decisions kept the project moving without increasing risk. First, the go-live was timed for the start of a quarter, not a year end, so the first live close was not also an audit close. Second, the acquired entities’ data was cleaned before migration, using the approach in our post-acquisition data check, instead of migrating their open issues into the new system.

Step 5: Stabilise, Document and Hand Back

After go-live, the specialists stayed through two full closes on the new system. They documented every close procedure as it now worked, trained the permanent team on the new processes, and transferred responsibilities back task by task. Temporary gaps were closed, and the processes left behind were designed to scale with the next acquisitions.

The result the owner cared about: the close stayed on working day 7 through the entire project, and the first two live closes were delivered on time with no restatement. The sequence for integrating the next acquisition onto the new system is covered in the first 100 days finance integration roadmap.

Where ERP Projects Hurt the Close

• Planning project time without backfilling the close. The project plan assumes finance hours that the close is already using.
• Testing transactions, not consolidation. Every entity works and the group numbers do not.
• Going live at year end. The first live close becomes the audit close, with no room for teething problems.
• Relaxing controls during the project. Skipped reviews in a busy quarter are where migration errors reach the published figures.

This approach assumes the ERP replaces the existing system in one go. Where entities move in waves, the group runs two systems for months, and consolidation testing has to be repeated for every wave, with a mapping between the old and new charts maintained until the last entity has moved.

The ERP and Close Protection Checklist

Use this as a working checklist. Each item is a check to complete, not a topic to consider.

Plan the capacity

• ☐ Overlay project milestones on the close, quarter ends, audit and lender reporting
• ☐ Identify the months where demand exceeds available finance hours
• ☐ Backfill recurring close tasks before the project starts

Test properly

• ☐ Test each accounting process with real transactions from a prior month
• ☐ Run a full trial consolidation, not a checklist review
• ☐ Agree entity trial balances to the old system
• ☐ Confirm intercompany eliminations net to zero
• ☐ Check currency translation rates are loaded for every period
• ☐ Reproduce the prior reported group profit exactly

Protect the close

• ☐ Keep all controls, reviews and sign-offs unchanged during the project
• ☐ Allow no change to systems feeding the ledger around month end
• ☐ Time go-live away from the year end
• ☐ Run the first live close in parallel with the old system for the balance sheet

Stabilise

• ☐ Keep support in place through two full closes after go-live
• ☐ Document close procedures as they now work
• ☐ Train the permanent team and transfer each task back

Frequently Asked Questions

How do you protect the month-end close during an ERP implementation?

Treat close deadlines as fixed, backfill the recurring close work so the permanent team can join the project, keep all controls unchanged, time go-live away from year end, and run the first live close in parallel with the old system for balance sheet reconciliations.

What should consolidation testing cover in a new ERP?

A full trial consolidation on real prior-period data: entity trial balances agreed to the old system, intercompany eliminations netting to zero, currency translation, and group profit reproducing the reported figure. Repeat the trial until every difference is explained and resolved before go-live.

Why do ERP projects need extra finance capacity?

Because design workshops, testing and data validation need the same finance people who close the books. Without extra capacity, either the project gets less finance input than it needs or the close slips. Temporary specialists can carry recurring close tasks or lead testing so neither happens.