ERP Migration Audit Risk: What Finance Leaders Should Evidence Before Audit
If your ERP changed recently, auditors will want comfort over data completeness, accuracy and access controls. Here is what to prepare and why it matters.
Migrating to a new ERP system is one of the most significant events in the lifecycle of a finance function. It is also one of the highest-risk events from an audit perspective.
When the system that produces your financial data changes during the audit period, auditors cannot simply rely on prior year procedures. They need to establish — from scratch — that the new system is properly controlled, that data was migrated accurately and completely, and that the financial information produced after go-live can be relied upon.
For PE-backed and growth-stage businesses, where system changes often accompany rapid growth or post-investment transformation, this is a recurring challenge. Finance leaders who understand the audit risk can mitigate it. Those who do not tend to find out about it during fieldwork.
Why Auditors Treat ERP Migrations as High Risk
The concern is not that something necessarily went wrong. It is that something could have gone wrong in a way that affects financial reporting — and that, without appropriate evidence, auditors cannot rule it out.
Specific risks that auditors consider during an ERP migration:
Data completeness. Were all transactions, balances and master data records migrated from the old system to the new one? Or were some records lost, duplicated or truncated in the process?
Data accuracy. Were figures migrated correctly? Are opening balances in the new system consistent with closing balances in the old one? Were any transformations or mappings applied during migration that could have altered values?
Cut-off. Were transactions correctly attributed to the right period before and after go-live? Is there a risk that some transactions were recorded twice — once in each system — or not at all?
Access and configuration. Was the new system configured with appropriate access controls from go-live? Or was it deployed with permissive settings that were tightened later?
Change management. Was the go-live approved through a formal sign-off process? Was user acceptance testing performed and documented? Were rollback procedures in place?
Audit trail. Does the new system maintain an adequate audit trail of transactions? If the old system's audit trail is no longer accessible, how will auditors test transactions that occurred before migration?
What Finance Leaders Should Have on File
1. A migration plan and sign-off document
A formal document describing the migration scope, approach, key milestones, and the sign-off authority. This confirms that the migration was a managed process rather than an improvised one.
2. Pre and post migration reconciliation
A reconciliation of opening balances in the new system to closing balances in the old system, across all material balance sheet lines. This is the single most important piece of evidence for auditors testing data accuracy and completeness.
The reconciliation should be:
- Prepared at the point of migration, not retrospectively
- Reviewed and signed off by an appropriate authority (typically the FD or Financial Controller)
- Supported by trial balance extracts from both systems at the migration date
If this reconciliation does not exist, recreating it retrospectively from system extracts is possible but more difficult — and auditors will want to understand why it was not produced at the time.
3. Data mapping documentation
Where data was transformed, mapped or restructured during migration — for example, where chart of accounts codes changed, or where multiple legacy systems were consolidated — a documented mapping showing how old data translates to new data.
4. User acceptance testing (UAT) records
Evidence that the new system was tested by finance users before go-live, covering key processes: order-to-cash, procure-to-pay, payroll, period-end close, reporting. UAT records should show what was tested, what the expected result was, what the actual result was and who signed off.
5. Go-live approval
A formal sign-off confirming that UAT was completed satisfactorily and the system was approved for live use. This might be a board paper, a project steering committee minute or a signed completion certificate.
6. Initial access configuration
Documentation showing who was granted access to the new system at go-live, at what permission level, and who authorised that access. This is the baseline for ongoing access reviews.
7. Parallel run or parallel reconciliation (where applicable)
Where both the old and new systems ran simultaneously for a period, a reconciliation of outputs from both systems over the parallel period confirms that the new system is producing accurate results. Even where a parallel run was not performed, a retrospective comparison of outputs for a sample of transactions provides useful comfort.
8. Ongoing audit trail availability
Confirmation that the old system's data remains accessible — either in the live system, in an archived database or through exported data files — for the period covered by the audit. Auditors will need to test pre-migration transactions.
Common Gaps That Create Audit Risk
No migration reconciliation. This is the most frequently cited gap. In the pressure of go-live, the formal balance reconciliation was not prepared. Auditors then need to construct it from available data, which takes time and may not be conclusive.
UAT not documented. Testing was performed informally and the results were not retained. There is no evidence that the system was validated before live use.
Access not configured from go-live. The system went live with permissive or default access settings, which were tightened over the following weeks. There is no documentation of who had access to what during the period immediately after go-live.
Change management bypassed for speed. Changes were made to the system in the first weeks after go-live without the normal approval process, because the business was in stabilisation mode. These undocumented changes are difficult for auditors to evaluate.
No plan for legacy system data. The old system was decommissioned or access was removed before auditors could test it. Transactions from the pre-migration period cannot be readily accessed.
The Conversation to Have Before Fieldwork
If your ERP migrated in the last 12 to 24 months, have a specific conversation with your audit partner before fieldwork begins. Cover:
- The timing of the migration relative to the audit period
- What migration documentation exists
- Whether a pre and post reconciliation was prepared, and what it showed
- How legacy system data will be made available for testing
- Any issues or anomalies identified during or after migration
This conversation allows the auditor to plan their approach with full information — and allows you to identify any gaps in your evidence with enough time to address them.