The First Month End Decides Whether Your ERP Is Trusted

Every implementation plan has a go-live date, and almost every one treats it as the finish line. Training is signed off, the old system is switched to read-only, someone brings cake. Then the project team rolls off, and three weeks later the finance team tries to close the month.

That close is the real test. Not because anything dramatic goes wrong, but because it is the first time every number in the system has to agree with every other number, in front of people who will be held responsible for the answer. A system that survives its first month end gets used. One that does not gets worked around, and within two quarters the spreadsheets are back.

What actually breaks, and why

In our experience the failures at first close are rarely bugs. They are gaps between what was migrated and what the close needs. Five recur often enough to plan for:

1. Opening balances that were never proved

Masters migrate cleanly and everyone relaxes. Opening balances are harder: trial balance by account, ageing by party, stock by warehouse and batch, and each of those has to tie to the closing position of the old system on the cutover date. If the tie-out was done on totals only, the first close is where the detail disagrees — usually in party-wise ageing, where one supplier's opening is a single lump with no invoice references behind it.

2. Cutover documents in limbo

The goods received on Friday against a purchase order raised in the old system. The invoice a customer disputed the week before cutover. The advance paid in the old system against an order delivered in the new one. Every migration has a handful of these, and each needs an explicit decision — carry the document, or carry only its balance — recorded before cutover rather than argued about during the close.

3. Tax periods that straddle the switch

If you go live mid-period, the statutory return for that period has to be assembled from two systems. That is manageable when it is planned and painful when it is discovered. It is one of the few genuine arguments for timing go-live to a period boundary even when the project is ready earlier.

4. Nobody owns the close in the new system

In the old system the sequence lived in someone's head: post these accruals, run that revaluation, check this suspense account, then lock the period. None of that is in the project plan, because it was never written down. The first close becomes an act of rediscovery under deadline.

5. Reports that are right but unfamiliar

A correct balance sheet in an unfamiliar layout reads as a wrong balance sheet. We have watched a controller reject an accurate P&L because cost centres were grouped differently from the report they had used for nine years. This costs a day of trust for what is an afternoon of report configuration — done before the close, not after.

The close checklist we run

This is the list we work through with a client's finance team before cutover, so the first close is a rehearsal of something already agreed rather than a first attempt:

• Tie-out, three ways. Trial balance by account, ageing by party, and stock valuation by warehouse — each reconciled to the old system on the cutover date and signed off by whoever owns that number.
• An open-items register. Every straddling document listed with a decision beside it: carried as a document, carried as a balance, or deliberately left behind.
• A written close sequence. The steps, in order, with an owner and an expected duration for each — including the ones that used to live in someone's head.
• Reports configured to the old layout first. Match what the team reads today. Improve the format in the second or third close, once the numbers are trusted.
• A dry-run close on real data. Before go-live, close a copied period end to end in the new system. Every problem found here is found without a deadline attached.
• Named support for close week. Not a ticket queue — a person who knows the implementation, available on the days the close is actually happening.

Why this shapes how we staff a project

Our delivery runs in six stages, and the last one is Go-Live & Support rather than Go-Live. That is not a marketing flourish — it is where the budget and the calendar have to reflect that the close is part of the implementation. A plan that ends on cutover day has quietly moved the hardest week onto the client.

It also changes what we build during configuration. If the close sequence is written down early, some of its steps turn out to be automatable: the recurring accruals, the revaluation run, the suspense-account check that someone does by eye every month. Those become scheduled jobs and reports rather than tribal knowledge, which is the difference between a close that takes four days and one that takes four days only when the right person is not on leave.

If you are mid-project right now

You do not need to restructure anything to improve your odds. Two things help more than the rest: write the close sequence down this week while the old system is still running, and schedule a dry-run close on real data before go-live. Both can be done inside an existing plan, and both convert the first close from a discovery exercise into a repeat performance.

If you would rather have someone who has done it before in the room, that is the conversation to start — and the honest version of that conversation includes which month end we would aim for, and why.