Consolidating ERPs after a merger

The core evidence is a signed opening balance reconciliation for each legal entity, showing the trial balance in the legacy system, the mapped balances loaded into the ERP, and any differences with their explanations. The finance controller of the acquired entity and the acquirer's group controller should both sign it before the first live period is posted. Keep the batch load logs, the mapping table from the old chart of accounts to the new one, and the reconciliation of open receivables and payables to subledger detail. The ERP produces the balances and load logs, while the people responsible for the close produce the sign-off. DeployOpen prepares the reconciliation workpapers and the evidence folder, but the external auditor decides whether the opening position is reliable. Ask your auditor which reconciliations and sample sizes they expect before the first batch runs.

Auditors expect every change that affects financial data to have a request, an approver, a test record and a deployment record. This covers chart of accounts changes, tax and currency settings, company configuration, custom modules, and any server script or import script used to move data. In Odoo, custom modules and configuration changes should be tracked in version control and promoted from a test database through a controlled release. In ERPNext, Server Scripts are disabled by default from version 15 and must be enabled with the server_script_enabled setting, so the enablement itself should be a recorded change. The version control history, ticket references and environment promotion logs are produced by your engineering and ERP teams. This maps to the change management area that the FTC Safeguards Rule requires for covered financial institutions. DeployOpen can set up the change workflow and assemble the records, while your IT general controls owner signs off on their operation.

Access reviews must include every account carried over from the acquired company, including accounts that were never formally onboarded to the acquirer's identity system. Export the user list and role assignments from both the legacy ERP and the new environment, then match each user to an active employee or contractor. Remove or disable accounts for leavers, and document the business owner's approval for each retained role. In Odoo, the Community edition has no built-in multi-company role matrix on the lowest plans, so confirm which edition and plan your design requires. For directory-based login, the LDAP options for Odoo and ERPNext are documented, and they can reduce manual account handling. Your identity team produces the review and approvals, and the ERP produces the user and role exports. DeployOpen can script the comparison and prepare the review pack, but the reviewers must be your managers.

You need a matrix showing which roles can create, approve and post journal entries, vendor payments and bank transactions, and proof that no single user holds conflicting combinations for the same entity. Include the roles that exist in the acquired company's legacy system and how each was mapped. Also record any temporary exceptions, such as a shared controller covering both entities during the first close, with the compensating review that applies. Export the role assignments at the cutover date and again after the first close. The segregation matrix is designed by your finance and risk owners, and the ERP produces the role exports and posting logs. DeployOpen can help model the roles in the target platform and test the conflicts, but the approval of the matrix belongs to management.

Keep audit logs of user activity, configuration changes and posting changes for the full retention period your regulator or auditor requires. For SEC broker-dealers, Rule 17a-4(b) requires preservation of records such as bills receivable or payable and bank statements for not less than three years, the first two in an easily accessible place. Confirm which records fall under your own rule set and whether any apply to the acquired entity. Logs should be protected from edits by administrators, and their location should be documented. Your security team owns the log retention and storage design, and the ERP produces the logs. DeployOpen can configure log export to your central store and test that retention works, but the retention period itself must come from your legal and compliance owners.

DORA Article 28(3) requires financial entities to keep a register of information on all ICT service arrangements, at entity, sub-consolidated and consolidated levels. After an acquisition, the acquired entity's ERP hosting, support contracts, data processing providers and any group-level service must be entered into the register, and the register must be updated when the merged system changes. Article 28(8) also requires tested exit strategies and transition plans for services that support critical or important functions, which applies to the ERP cutover if it supports those functions. The register is maintained by your third-party risk and compliance team, and the ERP project supplies the list of providers, hosting locations and data flows. DeployOpen can document the platform components and hosting arrangements for that list, while your compliance team decides which arrangements are critical or important.

For SEC registrants, SEC staff allow management to exclude a newly acquired business from its assessment of internal control over financial reporting, but the exclusion cannot extend beyond one year from the acquisition date or cover more than one annual report. The excluded business and its significance must be disclosed. Your financial reporting team documents the acquisition date, the excluded entity, its share of assets and revenue, and the date it enters the assessment scope. Keep the ERP cutover date in the same record, because it marks when the controls in the new system become part of the assessment. The disclosure is drafted by management and reviewed by the external auditor, and DeployOpen prepares the system-level dates and scope inputs. Confirm the exact disclosure wording with your auditor and securities counsel.

The main cost drivers are the number of legal entities and currencies, the volume of history to migrate, how much the target's processes differ from yours, the number of custom modules and integrations, and the quality of the acquired data. Each entity adds chart of accounts mapping, intercompany rules and reconciliation work. Each extra currency adds rate handling and translation testing. Heavy customization raises build, test and upgrade effort for the life of the system. Poor source data is often the largest hidden cost, because cleansing and reconciliation take longer than the load itself. Ask any partner to price these items separately so you can see which decision moves the total.

Costs usually fall into four groups. Software is paid to the vendor, either as Odoo Enterprise or Custom plan subscriptions or as zero-license ERPNext, where the software itself is free under GPL-3.0. Hosting is paid to your cloud provider, data center or, for ERPNext, Frappe Cloud if you choose it. Implementation is paid to a partner for fit-gap, configuration, migration and testing. Internal staff time from finance, IT and the business is a cost even when it is not invoiced. Ask each bidder to separate these lines, and to state which items are fixed-price and which are time-and-materials.

One-time costs include fit-gap analysis, chart of accounts design, data mapping, migration scripts, trial loads, testing, training and cutover support. Recurring costs include software subscriptions, which for Odoo are priced per user under the plan chosen, hosting, backups, monitoring, security patching and vendor or partner support. Upgrades are also recurring. On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years according to Odoo's upgrade documentation, and standard support for Odoo 20.0 runs until September 2029. For ERPNext, Frappe's supported versions policy requires a listed version and a matching Frappe Cloud support plan to receive warranty coverage. Request a five-year cost view that includes at least two upgrade cycles.

An internal team can do it if it has people who have implemented the chosen ERP before, a finance lead who can own the chart of accounts and opening balances, and enough capacity to run a cutover without disrupting the close. Most acquirers lack that capacity during the first year after a deal, when integration staff are also handling reporting, controls and systems inventories. A partner is usually most useful for multi-company configuration, batch migration tooling, reconciliation scripts and the cutover rehearsals. Whichever route you choose, the written scope should name who signs off each reconciliation and who owns post-go-live support. Ask a partner to show which items they configure and which they customize, since that decides how upgradable the result will be.

Finance must provide decisions and sign-off: the target chart of accounts, currency and intercompany rules, the opening balance and open item reconciliation, and the period-end cutover calendar. IT must provide the hosting environment, identity integration, user provisioning, backup and restore tests, and the integration points with banks, payroll and the acquirer's reporting tools. Both teams must agree on access controls and change management before any production load. Under the SEC's ICFR guidance, IT general controls over program changes and access to data are examples of areas to evaluate, so IT should document these from the start. Ask each partner to list the decisions it expects from your finance and IT leads, with dates.

SEC staff allow management to exclude a newly acquired business from its assessment of internal control over financial reporting, but the exclusion cannot extend beyond one year from the acquisition date or cover more than one annual report. The excluded business and its significance must be disclosed. This creates a planning deadline: if the target stays on its legacy ledger, the acquirer must still bring it into scope before the window closes. Working back from that date, many teams schedule the design, migration rehearsal and cutover to finish in time for the next period-end review. Confirm the exact dates with your external auditor, because the rules depend on your filing status and the acquisition facts.

The duration depends on the number of entities, the volume and quality of history, how many systems feed the ledger, and how many migration rehearsals the finance team needs before sign-off. No supplied source gives a fixed duration for this type of project, so treat any single figure with caution. Ask each partner for a phased plan with milestones for design, build, migration trial loads, parallel close and cutover, and ask which dependencies sit outside their control, such as the acquirer's auditor review or the target's data extracts. Compare the plan against the ICFR exclusion deadline and the period-end calendar, not against a generic project length.

A useful quote lists the scope in writing: entities, currencies, modules, number of users, integrations, custom modules and data sets, with history years stated. It should separate migration tooling, trial loads and reconciliation sign-off from configuration and training, and state what is fixed-price and what is time-based. Ask for the assumptions about source data quality, what happens if the target's extracts are incomplete, and how change requests are priced. Include hosting and support as separate recurring lines, and ask who pays for upgrades. DeployOpen plans and implements self-hosted open-source platforms inside the client's own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A quote follows from that written scope.