Finance & Accounting Transformation
ERP Migration Finance Lead — what actually goes wrong.
System integrators build software. Accountants close books. The gap between them is where ERP migrations fail. Here's what that gap actually looks like — and what a finance lead does about it.
The problem you're looking at
You're 90 days into a NetSuite implementation. Or Dynamics 365. Or a SAP S/4HANA cutover. The system integrator's project plan has 400 line items and a green status. The CFO is nervous. The controller hasn't slept in three weeks. The first parallel close is two months away and nobody can answer basic questions:
- —Is the new chart of accounts actually going to produce the reports we need, or is it just a remapping of the old mess?
- —What does the opening balance sheet look like, and who's reconciling it?
- —Why are the intercompany accounts not netting?
- —How are we handling cutoff — last month's accruals in the old system, this month's in the new?
- —What happens to the recurring journal entries, the depreciation schedules, the deferred revenue waterfalls?
- —Who owns the trial balance reconciliation between old and new for the first three closes?
The system integrator's answer to all of these is some version of "that's a client-side decision." Which is correct. And which is exactly why ERP migrations fail when there's no senior finance person sitting on the client side making those decisions in real time.
The structural problem
ERP implementations have three roles:
The system integrator — typically a consulting firm certified on the platform (NetSuite Alliance Partner, Microsoft Dynamics Partner, SAP gold partner, etc.). They configure the software, write the integrations, and run the project plan. Their billable hours are the budget. They are not accountants.
The internal finance team — the controller, the AP/AR clerks, the staff accountants. They know the current process. They are buried with the day job. They do not have the bandwidth to redesign the chart of accounts, write the cutover plan, and run parallel closes on top of the regular monthly close.
The finance lead on the migration — the person who sits between the integrator and the internal team, makes the accounting decisions, owns the COA design, owns the opening balance sheet, owns the cutover plan, and owns the parallel close reconciliations.
Most failed migrations are failed because the third role doesn't exist. The CFO doesn't have time. The controller doesn't have the seniority or the bandwidth. The system integrator can't do it because they're not accountants. So the decisions get made by whoever happens to be in the room when the question comes up — and the decisions are wrong more often than they're right.
What actually goes wrong
Five failure patterns that show up across NetSuite, Dynamics, SAP, and Oracle implementations:
Failure 01
The chart of accounts gets remapped instead of redesigned.
The migration is treated as a system swap, not a finance transformation. The old COA — built over 15 years by three different controllers, full of dead accounts, no consistent department structure, intercompany running through equity — gets mapped one-for-one into the new system. You now have the same broken COA in a more expensive system. Reporting gets no better. The board pack still requires Excel gymnastics.
The fix
Redesign the COA before the system goes live. Department dimensions, clean intercompany loan accounts, GAAP-compliant categorization, account ranges that support the reports the business actually needs. This is a finance decision, not a system decision, and it has to happen before the integrator starts building.
Failure 02
The opening balance sheet doesn't tie.
Day one of the new system, the trial balance is off. By $4,200, or $42,000, or $420,000. Nobody knows why. The integrator says the data load was successful. The controller says the source data was right. Three months later, the cumulative variance is large enough that the audit firm wants to know what happened, and nobody has a clean reconciliation.
The fix
A formal opening balance sheet reconciliation, account by account, signed off by the finance lead before go-live. Every variance investigated. Every adjustment documented. Every subsidiary ledger tied to the GL. This is hours of work that the integrator will not do and the internal team cannot fit in.
Failure 03
Cutover bridges accruals incorrectly.
The old system has a month of accrued expenses sitting on the balance sheet. The new system goes live on the first of the next month. What happens to those accruals? Who reverses them? In which system? Against which expense accounts?
In the most common failure mode, the accruals get loaded into the new system as opening balances but never get reversed against expense — so the next month's P&L double-counts those expenses. Or the accruals get reversed in the old system but the load to the new system uses the post-reversal balance, leaving the new system understated. Either way, the first three months of reporting in the new system are wrong, and nobody figures it out until the audit.
The fix
A documented cutover plan that specifies, for each balance sheet account, what gets loaded, what gets reversed, where, and when. Run by someone who has actually closed books in both systems.
Failure 04
Recurring journal entries get rebuilt from scratch — badly.
Depreciation, amortization, prepaid expense waterfalls, deferred revenue recognition, intercompany allocations, accrual templates. In the old system, these were running automatically (or were set up as templates by someone who left two years ago). In the new system, they all need to be rebuilt.
The integrator can configure the templates if you give them the inputs. The internal team doesn't have the time to write the inputs. So the templates get rebuilt approximately, with rounding errors, with missing accruals, with depreciation schedules that don't tie to the fixed asset register. Six months later, someone notices that monthly depreciation is off by $8,000 a month and has been since go-live.
The fix
A senior finance resource extracts the actual logic from the old system, documents it, designs the new templates correctly, and tests them before go-live. Not glamorous. Critical.
Failure 05
Parallel close gets skipped or shortened.
The project plan says two months of parallel close. By month one, the team is exhausted, the project is behind schedule, and the integrator suggests cutting parallel down to one month — or skipping it entirely if the data validation looks clean. The CFO, under pressure to finish on budget, agrees.
Parallel close is not a formality. It's the only mechanism for catching the configuration errors, the COA mapping problems, the recurring JE rebuilds that are wrong, and the cutover bridges that didn't bridge. Skipping it means catching those problems in production, with the auditors watching.
The fix
Two full parallel closes, minimum, with a documented reconciliation between old and new for every P&L line and every balance sheet account. Variances investigated. Adjustments made before go-live, not after.
A worked example
A specialty manufacturer, $80M revenue, migrating from a legacy ERP to NetSuite. System integrator was a mid-tier NetSuite Alliance Partner with a strong technical team. Internal finance team: a CFO, a controller, two staff accountants, an AP clerk. Project budget: $400K for the integrator, 9-month timeline.
At the 90-day check-in, the project was green per the integrator. The controller was three weeks behind on the current month's close. The CFO was nervous but couldn't articulate why. They brought in a finance lead — not to manage the project (the integrator was doing that) but to own the accounting side.
First two weeks of the engagement:
- —Audited the proposed new COA against the actual reporting needs of the business. Found 47 accounts being remapped that shouldn't exist in the new system, and 12 accounts the business needed that weren't in the new design. Rebuilt the COA. Two-week delay on the integrator's configuration schedule. Worth every day.
- —Built the opening balance sheet reconciliation template. Identified three subsidiary ledgers (fixed assets, prepaid expenses, accrued liabilities) where the source data was not going to tie to the GL on day one. Started cleanup before go-live, not after.
- —Mapped the existing recurring journal entries — 23 of them — against the new system's template capability. Identified five that the integrator's standard approach would have built incorrectly.
Next two months:
- —Cutover plan written, reviewed with the integrator, signed off by the CFO. Every accrual, every prepaid, every intercompany balance had a documented disposition.
- —First parallel close: 14 reconciling items between old and new, all investigated, all resolved. Most were configuration issues in the new system that would have produced wrong reporting for months if go-live had happened on the original schedule.
- —Second parallel close: 3 reconciling items, all minor, all resolved.
Go-live:
- —Trial balance tied to the penny on day one.
- —First post-go-live month-end close: 9 business days, slightly longer than the pre-migration baseline but with the new reporting structure in place.
- —Second month-end: back to 7 days.
- —First audit cycle after go-live: zero adjustments related to the migration.
Total cost of the finance lead over the engagement: roughly 8% of the integrator's fee. The math on what a failed go-live would have cost — restatement risk, audit findings, six months of bad reporting, lost board credibility — was not close.
What a finance lead on an ERP migration actually does
Not project management. Not change management. Not training delivery. Those belong with the integrator and the internal team.
The finance lead owns five things:
- COA design. Building the new chart of accounts to support the reporting the business actually needs, not just remapping the old one.
- Opening balance sheet. Account-by-account reconciliation between old and new, every variance documented and resolved before go-live.
- Cutover accounting. Documented disposition for every balance sheet account at the transition date — what loads, what reverses, where, when.
- Recurring entry rebuild. Extracting the actual logic from the old system, designing the new templates correctly, testing them in parallel before go-live.
- Parallel close reconciliation. Running the reconciliations between old and new closes, investigating variances, escalating configuration issues to the integrator while there's still time to fix them.
This is senior work. It cannot be done by a junior consultant or a junior internal accountant. It cannot be done by the system integrator because they are not accountants. It cannot be done by the existing controller because they are running the current month's close.
How we work
Jiesen Li Advisory takes ERP migration engagements on a project basis with a defined scope and a fixed or capped fee. The buyer is typically a CFO, a controller, or a PE operating partner whose portco is mid-migration and getting nervous. The engagement runs in parallel with the system integrator — we don't replace them. We sit on the client side and own the accounting decisions they can't make.
Twenty-five years of operational finance across semiconductors (NASDAQ-100, on the PeopleSoft and Oracle ERP teams), media (Fortune-50 entertainment, payment processing stack across three POS systems), specialty chemicals, hospitality, and multi-unit retail. Systems range: Oracle (inventory, COGS, standard cost), SAP FI/CO/MM/PP/SD, PeopleSoft, NetSuite, Microsoft Dynamics, Restaurant365, QuickBooks.
Next step
If you're in the middle of an ERP migration — or staring down the start of one — the first conversation is free.
Read next
Offer
The Finance Diagnostic — two weeks, fixed fee.
What we look at, what you get, and how the engagement actually runs.
ReadPractice
Operator credentials, not a consultancy pitch.
Where we've closed books — semis, SaaS, payments, hospitality — and why it matters.
ReadTool
Ask jiesen — practitioner-grade answers.
Test the assistant with the hardest accounting question on your desk today.
Readjiesen Li · Finance & accounting transformation · ERP migration finance lead · post-acquisition integration