Connected business operations. Flexible deployment.
A practical guide for CIOs and finance leaders to migrate intercompany data without double-counting or balance mismatches, covering profiling, mapping, elimination logic, and reconciliation.
To avoid double-counting and balance mismatches when migrating intercompany transactions, you must implement a strict one-to-one transaction mapping, validate entity relationships before data load, and perform multi-layered reconciliation between subledgers and the general ledger. The primary risk is that intercompany transactions exist in two ledgers (the seller and the buyer), and if the migration logic does not correctly identify and link these pairs, the system may treat them as external transactions or duplicate them during the load. This leads to inflated revenue, expenses, and asset balances, breaking the consolidation process. The recommended approach involves profiling source data to identify all intercompany pairs, mapping legacy entity codes to the new ERP structure, applying transformation rules that preserve the link between the two sides of the transaction, and executing trial migrations with full reconciliation before cutover. Success depends on treating intercompany data as a single logical unit rather than two separate records, ensuring that elimination entries are correctly generated or preserved in the target system.
Intercompany transactions are inherently complex because they involve multiple legal entities, currencies, and accounting periods. In a legacy system, these transactions might be stored in separate tables or even separate databases for each entity. When migrating to a new ERP, the data model often changes, requiring a re-mapping of entity IDs, account codes, and transaction types. If the migration script simply copies records without validating the relationship between the debit and credit sides, the new system may not recognize them as intercompany. This results in the transactions being treated as external, which prevents the automatic elimination of revenue and cost of goods sold during consolidation. Furthermore, if the migration process runs multiple times or if the data is loaded into both the subledger and the general ledger without proper deduplication, double-counting occurs. This not only distorts financial reports but also creates significant audit risks, as the audit trail becomes broken or inconsistent.
The first step is to profile the source data to understand the volume, structure, and quality of intercompany transactions. Identify all entities involved in intercompany trade and map their legacy codes to the new ERP entity structure. This mapping must be validated by finance stakeholders to ensure that the legal entity hierarchy is correctly represented in the target system. Check for orphaned transactions where one side of the intercompany pair exists in the source but the other side is missing or incomplete. These orphans must be resolved before migration, as they will cause balance mismatches in the new system. Additionally, profile the currency conversion rates used in the legacy system and ensure that the target system can replicate these rates for historical data. If the target system uses different rate tables, you must decide whether to migrate the original rates or recalculate them, and document this decision clearly.
Use data profiling tools to identify unique transaction IDs that link the seller and buyer sides of an intercompany transaction. In many legacy systems, this link is implicit or stored in a separate reference table. You must extract this link and ensure it is preserved in the migration script. If the legacy system does not have a direct link, you may need to reconstruct it based on matching criteria such as date, amount, currency, and counterparty code. This reconstruction must be validated by finance teams to ensure accuracy. Once the pairs are identified, create a master list of all intercompany transactions to be migrated. This list will serve as the baseline for reconciliation after the migration.
Develop detailed mapping rules that translate legacy data fields into the target ERP structure. For intercompany transactions, this includes mapping entity codes, account codes, transaction types, and currency codes. Ensure that the mapping preserves the intercompany flag or indicator in the target system. If the target ERP uses a specific field to identify intercompany transactions, populate this field correctly during the transformation. Additionally, define rules for handling open items. Decide whether to migrate open intercompany payables and receivables or to close them out before migration. Migrating open items requires careful handling to ensure that the aging and due dates are correctly transferred. If you choose to close out open items, you must perform a final reconciliation in the legacy system to ensure that all balances are zero before cutover.
Discover how professional services ERP systems stabilize operations during growth by standardizing project accounting, resource allocation, and financial controls to prevent operational breakdowns.
Learn how to align IT and finance teams for a successful ERP data cutover. This guide covers planning, data validation, runbooks, and risk mitigation strategies to ensure operational continuity.
Learn how professional services firms use ERP analytics to align resource capacity with project demand, improve margin visibility, and standardize financial controls for scalable growth.
Discuss your workflows, modules and deployment options with our team.
Back to resources