Connected business operations. Flexible deployment.
A practical guide for finance and IT leaders to ensure data integrity, validate trial balances, and resolve discrepancies when migrating to a new ERP system.
Reconciling financial statements after a major ERP platform change is a critical validation process that ensures the General Ledger (GL) in the new system matches the source of truth from the legacy system. The recommended approach involves a multi-layered reconciliation strategy that compares trial balances, subledger details, and open items at the account level, not just the total level. This process is essential because financial data is the backbone of business decision-making, and any discrepancy can lead to inaccurate reporting, audit failures, or cash flow mismanagement. The primary risks to control include data loss during extraction, mapping errors in the Chart of Accounts (COA), currency conversion mismatches, and the loss of historical audit trails. By establishing a rigorous reconciliation protocol before cutover, finance and IT teams can identify and resolve discrepancies while the legacy system is still accessible, significantly reducing the risk of post-go-live financial chaos.
Before any data is moved, the finance team must define the scope of the migration. This includes determining which historical periods will be migrated. Typically, companies migrate the current open period and the previous closed period for year-over-year comparisons, while archiving older data in a read-only repository. The Chart of Accounts mapping is the most critical technical task. Every account in the legacy system must be mapped to a corresponding account in the new ERP. This is not a one-to-one process; it often involves consolidating multiple legacy accounts into a single new account or splitting one legacy account into several new ones. The mapping logic must be documented and approved by the Controller or CFO to ensure that the financial structure aligns with the new business processes.
Legacy systems often contain data anomalies such as duplicate vendor records, inactive customers with open balances, or transactions posted to incorrect accounts. Data profiling involves scanning the source database to identify these issues. Cleansing must occur before migration to prevent 'garbage in, garbage out.' For example, if a legacy system has 500 variations of 'Office Supplies' in the vendor master, these should be consolidated into a single standardized vendor record in the new ERP. This step reduces the volume of data to be migrated and improves the accuracy of subledger reconciliations.
The technical execution phase involves extracting data from the legacy ERP, transforming it to match the new system's schema, and loading it into the target environment. This process is typically automated using ETL (Extract, Transform, Load) tools. The transformation layer applies the COA mapping, currency conversion rules, and tax jurisdiction updates. It is crucial to maintain an audit trail during this phase. Every record should be tagged with its source ID and transformation timestamp. This allows for traceability if a discrepancy is found later. The loading process should be performed in a staging environment first, allowing the finance team to run preliminary reconciliations without impacting the production system.
Open items, such as unpaid invoices and unapplied receipts, are the most complex data to migrate. Unlike closed transactions, open items have a status that must be preserved. The new ERP must recognize these items as 'open' so that they can be paid or applied in the future. If the status is lost, the system may treat them as closed, leading to duplicate payments or missing liabilities. Subledgers for Accounts Payable (AP) and Accounts Receivable (AR) must be reconciled against the GL. The sum of all open AP invoices must equal the AP control account in the GL. Similarly, the sum of all open AR invoices must equal the AR control account. Any variance indicates a mapping error or a data loss issue.
The reconciliation process is the core of the validation phase. It involves comparing the trial balance from the legacy system with the trial balance from the new ERP. This comparison should be performed at three levels: total level, account level, and line-item level. At the total level, the sum of debits must equal the sum of credits in both systems. At the account level, each individual account balance must match. At the line-item level, specific transactions, particularly large or unusual ones, should be spot-checked. The finance team should use a reconciliation workbook that lists every account, the legacy balance, the new balance, the variance, and the status of the variance (e.g., 'Resolved,' 'Under Investigation,' 'Accepted').
| Reconciliation Level | Description | Responsible Role | Frequency |
|---|---|---|---|
| Total Level | Sum of all debits and credits | ERP Project Manager | After every load |
| Account Level | Balance of each GL account | Finance Analyst | Daily during cutover |
| Subledger Level | Open items in AP/AR | AP/AR Manager | Weekly during testing |
| Line-Item Level | Specific transaction details | Internal Audit | Spot checks |
Discrepancies are inevitable during a major ERP change. The key is to have a structured process for resolving them. Each variance should be categorized into one of three types: data error, mapping error, or business decision. A data error occurs when the source data was incorrect. A mapping error occurs when the COA mapping logic was applied incorrectly. A business decision occurs when the company intentionally changes how a transaction is recorded in the new system. For example, the company may decide to reclassify certain expenses from 'Operating' to 'Capital' in the new ERP. These decisions must be documented and approved by the CFO. The reconciliation workbook should track the root cause of each variance and the corrective action taken.
Multi-currency and multi-tax environments add significant complexity to reconciliation. The new ERP must use the correct exchange rates for the period in which the transaction occurred. If the legacy system used a different rate, the balances will not match. The finance team must define the exchange rate policy for the migration. Typically, the rate used is the rate on the last day of the previous period. Tax calculations must also be verified. If the new ERP calculates tax differently than the legacy system, the tax liability accounts will show variances. These variances must be analyzed to ensure that the new tax logic is correct and compliant with local regulations.
The cutover phase is the final window for reconciliation. During this time, the legacy system is frozen, and no new transactions are posted. The final data load is performed, and the reconciliation is repeated. The go/no-go decision for go-live should be based on the results of this final reconciliation. If there are unresolved variances in critical accounts, such as Cash, Inventory, or Payroll, the go-live should be delayed. The cutover runbook should include specific financial checks, such as verifying that the bank account balances in the new ERP match the bank statements. This ensures that the company can process payments and receive payments immediately after go-live.
| Check Item | Criteria for Success | Owner | Timing |
|---|---|---|---|
| Trial Balance Match | Zero variance at account level | Controller | Final Load |
| Bank Reconciliation | Bank balances match statements | Treasury Manager | Final Load |
| Open Items Count | Count matches legacy system | AP/AR Manager | Final Load |
| Tax Liability | Tax accounts match expected values | Tax Manager | Final Load |
After go-live, the reconciliation process does not end. The first month-end close in the new ERP is a critical test. The finance team should perform a detailed reconciliation of all subledgers to the GL. They should also compare the financial statements generated by the new ERP with the expected statements based on the legacy data. Any discrepancies found during the first close should be investigated immediately. The IT team should monitor the system for performance issues that could affect financial reporting, such as slow batch jobs or failed integrations. The stabilization phase typically lasts for three to six months, during which the finance team refines their processes and the IT team resolves any remaining technical issues.
Auditors will scrutinize the financial data after an ERP migration. The company must be prepared to demonstrate that the data in the new ERP is accurate and complete. This requires maintaining detailed documentation of the reconciliation process, including the reconciliation workbooks, mapping documents, and approval records. The audit trail in the new ERP should be enabled to track who made changes to financial data and when. This transparency helps build trust with auditors and stakeholders. The company should also conduct a post-implementation review to identify lessons learned and improve future migration projects.
Several risks can derail the financial reconciliation process. Data loss is the most severe risk, where transactions are missing from the new ERP. This can be mitigated by performing multiple trial loads and reconciliations. Mapping errors are the most common risk, where transactions are posted to the wrong accounts. This can be mitigated by involving the finance team in the mapping process and testing the mapping logic thoroughly. Integration failures can also cause discrepancies, where data from external systems, such as payroll or banking, is not correctly loaded into the ERP. This can be mitigated by testing integrations in a staging environment and monitoring them closely during cutover.
Reconciling financial statements after a major ERP platform change is a complex but manageable process. It requires close collaboration between finance and IT teams, rigorous testing, and a structured approach to discrepancy resolution. By following the steps outlined in this guide, companies can ensure that their financial data is accurate, complete, and audit-ready in the new ERP system. The key to success is to start early, involve the right stakeholders, and maintain a high level of discipline throughout the migration process. A well-executed reconciliation process not only protects the integrity of the financial data but also builds confidence in the new ERP system, enabling the organization to realize the full benefits of the investment.
Common questions on this topic. Talk to our team for anything specific to your business.
The first step is to perform a total-level trial balance comparison between the legacy and new ERP systems to ensure that the sum of debits equals the sum of credits in both.
The initial reconciliation can take several days to weeks, depending on the complexity of the data. The first month-end close is the true test and may take longer to resolve any remaining discrepancies.
Common discrepancies include mapping errors in the Chart of Accounts, currency conversion mismatches, and loss of open item status in subledgers.
Open items that do not match should be investigated to determine if they were lost during migration or if there is a mapping error. They should be manually adjusted in the new system and documented.
No, it is not necessary to migrate all historical data. Typically, only the current open period and the previous closed period are migrated, while older data is archived.
The Controller or CFO is ultimately responsible, but the day-to-day reconciliation is typically performed by Finance Analysts and AP/AR Managers, with support from the IT team.
Learn how to design a Professional Services ERP architecture that aligns project delivery with financial controls, resource management, and scalable operations.
Learn a practical framework for prioritizing ERP modules in a staggered migration. Reduce risk, ensure data integrity, and maintain operational continuity by sequencing based on dependencies, business impact, and technical complexity.
Learn how to build a robust data validation framework to ensure accuracy, integrity, and business continuity during ERP migrations and upgrades.
Discuss your workflows, modules and deployment options with our team.
Back to resources