Why closing an acquired company's books on open source accounting is different
After an acquisition, the group must decide whether to move the target's ledger onto its own self-hosted instance or keep the target running separately under transitional arrangements. The choice turns on three things: how much control the group needs over the target's books from day one, how much time remains before the first group close, and what audit evidence the target can produce for the period before and after the deal. Odoo and ERPNext can both host several companies, so the platform is rarely the limiting factor. Whether either fits depends on the edition and license terms the group already holds, the modules the target uses, and the footprint the group already runs.
An acquisition changes three areas at once. The accounting changes because the target's chart of accounts, tax settings, currencies and opening balances must be mapped to the group's structure. The IT general controls change because user access, change management and database administration now span two organizations, and the SEC allows management to exclude a newly acquired business from its internal control assessment for a limited period only. The data handling changes because the target's customer and employee records may move into a new hosting arrangement, which can trigger GDPR processor obligations or, for an EU target accessed from outside the EEA, a transfer mechanism. Each of these areas needs a named owner before cutover, not after.
The first practical step is an inventory: confirm which edition, version and license the target runs, who administers its database and servers, and which contracts govern hosting and support. Ask whether the group's Odoo subscription or ERPNext deployment covers the number of companies and users involved, and whether the target's version is still within its support window, since Odoo and Frappe both publish end-of-support dates that affect the upgrade path. These answers decide whether migration or parallel running is realistic within the close calendar, and they become the first entries in the evidence file the auditors will request.
Which requirements shape the acquisition close
This table maps the regulatory and audit requirements that can apply when an acquired company's ledger moves onto or runs beside a group's open source accounting system. Each row states when the requirement applies, so you can skip rows that do not fit your target, and what it means for the build. Applicability depends on the target's listing status, sector, location and data, so confirm each condition with your legal and audit advisers before design starts.
| Requirement | Applies when | What it means for the build |
|---|---|---|
| SEC ICFR exclusion for acquired businesses | The group is an SEC registrant and the target is newly acquired | Management may exclude the target from its ICFR assessment for up to one year and no more than one annual report, but must disclose the exclusion and its significance. Plan the target's controls to be running within that window. |
| SEC Release 33-8810 IT general controls | The target's ledger supports controls that address financial reporting risk | Assess program development, program changes, computer operations and access to programs and data only where they support those controls. Scope the IT general controls to the reporting-relevant ledger, not the whole instance. |
| DORA Article 28(3) ICT register | The target is a financial entity in scope of DORA | Record the self-hosted accounting platform and its hosting and support arrangements in the entity's register of ICT services. Update the register when the target moves onto the group's instance. |
| DORA Article 28(8) exit and transition plans | The accounting system supports a critical or important function of a financial entity | Document and test an exit strategy and transition plan for the platform. A post-close migration or decommissioning of the target's legacy ledger should follow the same tested plan. |
| NIS2 Article 3(4) change notification | The target is an essential or important entity under NIS2 in an EU Member State | Notify the competent authority of changes to name, contact details, IP ranges, sector or service locations without delay and within two weeks. Include the new hosting addresses and IP ranges once the target's systems are re-homed. |
| EU Data Act switching provisions | The target moves off a third-party data processing service to the group's own instance or another provider | Switching rights include support for a move to another provider or on-premises infrastructure, a maximum two-month notice period, a 30-day transitional period, porting of exportable data and no switching charges from 12 January 2027. Confirm the exit terms in the target's current contracts. |
| GDPR Article 28(3)(a) documented instructions | The group's entity or hosting partner processes the target's EU personal data as a processor | Processing must follow the controller's documented instructions, including for transfers. Document the instructions and the processing roles before the target's data is loaded into the group's instance. |
| GDPR Article 30 records of processing | The target's EU personal data, such as customer, vendor or employee records in finance data, is processed | Update the records of processing for the combined activity and describe Article 32 security measures where possible. Records should reflect the post-close data flows, not the target's pre-close ones. |
| EDPB 05/2021 remote access as transfer | Non-EEA acquirer staff log in to an EU target's accounting data for support or administration | Such remote access is treated as a transfer requiring a Chapter V transfer tool. Limit access by role and location, or keep administration within the EEA, before granting cross-border access. |
| SEC Rule 17a-4(b) record retention | The target is a broker-dealer or its ledger holds broker-dealer records | Preserve listed records, such as bills receivable or payable, bank statements and original business communications, for at least three years, the first two in an easily accessible place. Confirm the retention setting and restore testing survive the migration. |
What moves in the ledger: opening balances, mapping and cutover
The first decision is what actually crosses over at cutover. The trial balance at the closing date is the anchor, but it only works if it sits alongside open receivables and payables with their aging, fixed asset registers with cost, accumulated depreciation and in-service dates, bank account balances with the last reconciled statement, tax codes and rates in force on the cutover date, and every currency the target still holds balances in. The target's chart of accounts is the source for all of these. Before anything is loaded, confirm with the target's finance lead which of these items are open, which are closed by the final period, and which will be settled by the seller rather than carried across.
Chart of accounts mapping is a finance decision, not an IT task. Each target account needs one destination in the group chart, with a note on any split or merge, and the mapping table should be signed off by the group controller before any data is loaded, because every later balance inherits its errors. Keep the table versioned and attach it to the close evidence. Opening balances are then loaded as a single balanced entry dated the day after the target's last closed period, and the group's reconciliation should show the target's final trial balance, the mapped balances and the opening entry agreeing account by account, with differences explained. For ERPNext, the Data Import tool accepts CSV or Excel files with child table rows, but its documentation advises importing only a few thousand records at a time, so multi-year transaction histories should be staged in batches with a load log per batch. Confirm the import limits, the handling of child tables and the permissions needed to run imports with the platform owner before the rehearsal.
Move the target onto the group instance or keep it separate
Migrating the target onto the group's existing Odoo or ERPNext instance puts both companies on one chart of accounts, one close calendar and one access model. The group gains a single set of controls to test, a single place to produce consolidated reporting, and one set of administrators to review. The cost is that the change lands on the group's control environment immediately, so every new company, user and mapping becomes part of the scope that auditors test.
- Single chart and close: The target's accounts are mapped to the group chart once, and the first group close runs on the same calendar and templates as the rest of the group.
- Edition and multi-company limits: Odoo lists multi-company support in the Custom plan on its pricing page, and ERPNext's company model must be checked against the group's entity and currency needs. Confirm the edition and license terms in writing before design starts.
- Wider IT general control scope: New users, roles, customizations and data loads fall inside the group's access reviews and change management. Under the SEC's guidance on IT general controls, these controls matter where they address financial reporting risk.
- Access and data model changes: Target staff gain access to group records, and any non-EEA acquirer staff accessing EU personal data may trigger transfer requirements.
- Conditions that favor it: The group already runs a stable, supported version, the target's process is similar to the group's, and the target's ledger can be cut over inside the acquirer's reporting window.
Before committing, confirm the edition, the company and currency limits, the migration approach and the access model with the implementation partner.
Running the target on its own instance for a defined transition period keeps its ledger, users and controls isolated while the group prepares the integration. This protects the group's production controls from a rushed cutover and gives the target's team time to close its own books. The trade-off is a second environment to secure, back up, upgrade and evidence, and a consolidation step that must be run manually until the cutover.
- Isolated risk: A failed data load or misconfigured mapping affects only the target's instance, not the group's close.
- Second control environment: Access reviews, backups, patching and change logs must be produced for both instances until the cutover date.
- Timing constraints: SEC staff allow management to exclude a newly acquired business from its internal control assessment, but not beyond one year from the acquisition date or from more than one annual report, and the excluded business and its significance must be disclosed. DORA Article 28 and NIS2 notification duties may also set deadlines for changes in ICT services and entity details.
- Transition agreements: Where the seller still runs services, a transitional service agreement should define who operates the target's instance, its access and its data return.
- Conditions that favor it: The target's systems are materially different, the exclusion window gives room to remediate, or regulatory timelines require a separate record for a defined period.
Check the exclusion window, the regulatory notification dates and the planned cutover date together, since they often decide which tab applies.
Which open source platforms fit an acquisition close and why
An acquisition close puts pressure on the platform decision: the target's books must land on a system the group can audit, upgrade and support. The cards below cover the three self-hosted paths and the option of leaving the target where it is, with the licensing, support windows and upgrade access each one carries.
Odoo Community
Odoo Community is the LGPL-3.0 open source core of Odoo, so the group can run it without a license fee. The catch for an acquisition is support: the community edition has no access to the upgrade service, and a group that absorbs a target onto Community must own every upgrade, test and security patch itself. Confirm who will carry upgrades and patching before the target's ledger is migrated.
Odoo Enterprise and Custom plan
Odoo Enterprise adds the upgrade service, and on-premise use requires an Enterprise subscription. According to Odoo's pricing page, only the Custom plan can be hosted on Odoo.sh or on-premise, and only Custom includes multi-company and custom modules, which matter when the target keeps its own entity structure. Standard support runs to September 2029 for Odoo 20.0 and to September 2028 for Odoo 19.0, so check which version the group runs before the close date.
ERPNext on the Frappe Framework
ERPNext is GPL-3.0 and self-hosting it carries no license fee, but the Frappe Framework is MIT-licensed and support depends on version. Version 15 is supported to the end of 2027 and version 16 to the end of 2029, and Frappe warranty coverage requires a listed version and a matching Frappe Cloud support plan. Implementation is available through certified partners, so confirm the version the group will run and who holds the support contract for the post-close period.
Target stays on its existing system
Keeping the target's ledger on its own system during the transitional period avoids a migration inside the first close, and the group reports the target through a separate reporting layer until the books move. The risk is that the group has two charts, two close calendars and two sets of access controls to evidence. Confirm the target system's support and update status and write its access reviews into the group's control scope before signing the transitional service agreement.
Rollout phases for the first group close
This sequence moves the target's books from its legacy records into the group's chosen instance in controlled stages, with a signed output at each phase so that finance and audit can rely on the first group close.
Agree discovery scope in writing
The implementation partner, the group controller, the target's finance lead and the internal audit or external auditor agree in writing on which entities, periods, ledgers, bank accounts, integrations and user groups are in scope, and which are excluded for the transition. The output is a signed scope statement with named owners and the decision on whether the target joins the group instance or runs as a separate instance. Scope is closed only when every excluded item has a stated reason and a named owner for any transitional arrangement.
Inventory entities, charts and balances
The team lists every legal entity, currency, bank account, tax setting, open invoice population and fixed asset register belonging to the target, then builds the chart of accounts mapping workbook that links each source account to a target account and records the rule applied. Finance signs the workbook, and each unmapped or many-to-one account is resolved with a written rationale. The output is the approved mapping workbook and an inventory of open items that must carry over.
Build the test environment
The partner creates a test copy of the target's configuration in the group's instance or a separate test environment. For Odoo, a database duplication with neutralization produces a test copy that does not send live emails or connect to live payment or bank interfaces. For ERPNext, production-grade Docker images and Compose files from the frappe_docker repository are used for the later environments, and the single-file demo setup is not used beyond evaluation. The output is a documented environment inventory and a test sign-off that confirms the copy is isolated from production data flows.
Load and reconcile opening balances
The opening trial balance, open receivables and payables, and bank balances are loaded into the test environment from the mapping workbook, with imports done in batches because large files are slower to validate and easier to correct in parts. Each load is reconciled back to the target's signed closing trial balance, and every difference is logged with an owner and a resolution. The output is a reconciliation pack with zero unexplained variances, signed by the controller of the target and the group.
Configure access and change control
The team sets up user roles, approval workflows and segregation of duties for the new scope, connects authentication to the group identity source where the platform supports it, and records every customization or configuration change in a change log with approver and date. Admin rights are restricted and reviewed before go-live. The output is an access matrix and a change log that the IT general controls owner can test, with the first baseline user access review completed and signed.
Run a parallel close
For one full close cycle, the target's transactions are posted in both the legacy ledger and the new instance, and the two outputs are compared line by line for the trial balance, subledgers and key reports. Differences are classified as mapping, timing or defect issues and fixed before cutover. The output is a parallel close variance log with each item resolved or accepted by the controller, which becomes evidence that the new configuration produces the same results.
Execute cutover
The team freezes the legacy ledger for the agreed cutoff, runs the final balance load and migrates open transactions, switches users and integrations to the new instance, and confirms that bank feeds and invoice delivery work as intended. The cutover runbook records each step, its executor and its check, and rollback criteria are agreed in advance. The output is a signed cutover record with the final opening balances and a list of any transitional service arrangements still in force, each with an owner and an end date.
Deliver the first group close with evidence
The first close is performed in the new instance under the group's close calendar, with the evidence package assembled as the close proceeds: reconciliations, journal approvals, access reviews, change records, backup confirmations and the cutover record. The auditor or internal audit reviews the package against the scope statement agreed at the start. The output is a closed period, a signed evidence index and a list of open findings with owners, which is the basis for the group's ICFR assessment of the acquired business.
How transitional service agreements shape access and evidence
A transitional service agreement often leaves the seller running the target's systems for a period after closing, so the first question is who holds each credential. Decide, in writing, which party owns the database administrator role, the Odoo or ERPNext administrator account, the server root access and the backup encryption keys. The agreement should name the seller's support staff by role, require individual named accounts instead of shared logins, and state that the buyer receives the access logs. Confirm with the seller's IT team that their support tooling can export per-user activity from the ledger, since a generic server log will not show which accountant posted or reversed an entry.
Data location and processing instructions need the same precision. If the target holds personal data of EU residents, GDPR Article 28(3)(a) requires the seller, acting as processor, to act only on the controller's documented instructions, including for any transfer. The agreement should list hosting regions, sub-processors and any remote access from outside the EEA, because remote support from a third country is itself a transfer under EDPB Guidelines 05/2021. Where the target is an EU financial entity in scope of DORA, Article 28(8) expects tested exit strategies and transition plans for services supporting critical or important functions, so the agreement should set out how the ledger moves to the buyer's instance, who runs the test migration and what evidence proves it worked.
Exit terms decide whether the buyer can close its books without the seller. Specify the format and timing for returning the seller's records, including the full general ledger export, the open subledger items, attachments, the audit trail and the user list with role assignments, and fix a checksum-based acceptance test on opening balances before the seller's access is removed. Revoke seller accounts in a documented step, not by default at contract end. Fix the duration and any extension in the agreement, and confirm the exit mechanics with counsel and the auditors who will test the first group close, because they will ask for this evidence.
Audit evidence for the first group close
This table maps the evidence an auditor or regulator is likely to ask for during the first group close after an acquisition, what each item proves, and which part of the platform or project record produces it. Read it as a checklist to agree with your auditors early, because the scope of ICFR, IT general controls and regulatory logging depends on whether the target is a covered entity. The main takeaway is that most of the evidence is produced by the migration project itself, so it must be captured while the work happens.
| Evidence | What the auditor or regulator asks for | Which component produces it |
|---|---|---|
| Signed chart of accounts mapping | Approved mapping from each target account to a group account, with the approver, date and any accounts that were merged, split or retired | Project mapping workbook, approved in a change record, then loaded configuration in the group Odoo or ERPNext instance |
| Opening balance reconciliation | Proof that opening balances tie to the target's final closed trial balance, by account and by entity, with reconciling items explained | Trial balance exports from the target system, import logs and a reconciliation report from the group ledger |
| Record of excluded business and significance | Disclosure of any acquired business excluded from management's ICFR assessment, its significance, and the date it falls within the one-year window | Board or audit committee memo maintained by finance and reviewed with the external auditor |
| IT general control records for migration scope | Change records for load scripts, configuration and mapping changes, with testing and approval before production | Ticketing system, version control history for scripts, and signed test results from the migration environment |
| Access reviews for migrated users | Evidence that users carried over from the target were reviewed, that their roles match duties, and that segregation of duties conflicts were resolved | Role assignment export from the platform, reviewed and signed by the controller, with the access review log |
| Platform audit log and retention settings | Proof that changes to posted entries, master data and user permissions are logged, and that logs are kept for the required period | Platform audit trail configuration, log export, and documented retention settings confirmed with the auditor |
| Transitional service agreement access logs | Records of which staff at the seller or a service provider accessed the target's ledger during the transition, and for what purpose | Access logs from the hosting environment and the platform, plus the agreement's list of approved support accounts |
| Data processing records | Records of processing and transfer mechanisms for personal data in finance records, including any access by a non-EEA acquirer where EU data is involved | Processing register entries, data transfer assessments and the documented instructions issued to the hosting or support provider |
How long does closing an acquired company's books take and what does it cost?
How much effort does the first close of an acquired company need?
No supplied fact gives a duration for this work, so the effort depends on the scope you set. The main drivers are the number of legal entities and currencies being brought in, how complex the target's chart of accounts is compared with the group's, how many years of history must be loaded, how clean the source data is, and which edition is in use. A target that falls under SEC internal control rules or EU rules such as NIS2 or DORA adds evidence work on top of the bookkeeping. Ask for the effort estimate in the written scope, broken down by mapping, opening balances, reconciliation, controls and evidence, so you can see which drivers are behind each line.
Can the buyer's finance team run the first close alone?
It can, but only if it already knows the group's chart, close calendar and system well enough to review the target's mapping and opening balances. Many teams find the first close harder than later ones because the target's staff, records and conventions are unfamiliar and the approvals must be documented for auditors. Consider three checks before deciding: whether someone on the team has administered the platform before, whether the team can reconcile the target's bank and subledger balances independently, and whether there is capacity during the close window. If any answer is no, agree on an outside partner for the mapping, migration and control evidence in writing.
Which fees are one-time and which recur for open source accounting?
Self-hosted Odoo Community and ERPNext carry no license fee for the software itself. Odoo Enterprise requires a subscription and is available on the Custom plan for on-premise or Odoo.sh hosting, according to Odoo's pricing page. ERPNext self-hosting is free, while Frappe Cloud hosting starts at 5 US dollars per month for shared sites and 20 US dollars per month for shared servers, according to the ERPNext pricing page. Recurring costs include hosting, the support plan, upgrades every two years on Odoo Online and Odoo.sh, and internal administration time. One-time costs cover mapping, data migration, testing and evidence preparation. Ask the quote to split these lines and state the support window for each version.
What does the target and seller need to provide for the close?
The target and seller need to provide the trial balance and subledgers as of the cut-over date, bank statements, open invoices and payables, fixed asset registers, tax filings and the chart of accounts with its history of changes. They also need to grant read access to the source system and to name people who can answer mapping questions quickly. Mapping decisions, such as which accounts roll into which group accounts and how intercompany balances are eliminated, must be made by the buyer, not left to the seller's staff. If the seller will support the target during a transitional service agreement, its scope, service levels and data access rules should be written down before the cut-over.
Should the acquired books migrate into the group system or run separately first?
Running separately first is often used when the target has a different chart, currency or tax setup, or when the group has not yet agreed on its close process. Migrating directly reduces duplicate effort but puts the target's history into the group's controls sooner. Consider whether the group's edition supports multi-company use, since Odoo states that multi-company is available only on the Custom plan, according to its pricing page. Also consider how long the separate instance must be supported. Odoo standard support runs for three years after a major release, so a separate instance on an older version needs a dated upgrade plan.
What should a quote for closing an acquired company's books include?
A quote should follow from a written scope and list each deliverable with its acceptance criteria. Ask for the following items to be stated separately:
- Assumptions about the number of entities, currencies, history years and chart size
- Chart of accounts mapping and the sign-off process for each mapping decision
- Opening balance load, reconciliation to the seller's trial balance and sign-off
- Testing in a copy before production, and a rollback plan
- Control and evidence deliverables, including access lists and change records for the first close
- Support and upgrade terms, the named support hours, and which platform version is covered
- Hosting responsibilities and who holds administrator access
DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and DeployOpen does not publish a price list.
Which compliance rules change the time and cost of the first close?
If the acquired company is in scope for SEC internal control reporting, management may exclude it from its first assessment, but not beyond one year from the acquisition date and not from more than one annual report, and the exclusion and its significance must be disclosed, according to SEC staff guidance. For EU entities, DORA requires a register of ICT service arrangements and tested exit strategies for critical services, while NIS2 requires notifying the competent authority of changes within two weeks. Ask the partner to confirm which of these apply to the target before setting the scope, because each one adds evidence work that the quote should show separately.
What to ask an implementation partner before the acquisition close
Ask every partner to answer the following in writing before the signing of the scope: have you closed acquired entities on Odoo or ERPNext specifically, and which of those closes ran on the same major version the group uses? Ask for the number of such engagements and for a description of the target's entity structure, chart of accounts and currencies in each one, rather than a general statement about ERP experience. Ask which Odoo edition or ERPNext deployment model they would recommend for each entity and who holds the Odoo Enterprise subscription or the Frappe Cloud support plan, since that determines warranty coverage and upgrade access. Confirm in writing that the answers apply to your scope, not to a reference project you cannot inspect.
Ask how the account mapping and the opening balance reconciliation are documented. A credible answer names a mapping workbook that lists each source account, its target account, the rule applied, the approver and the date, plus a reconciliation that ties opening balances, open receivables and payables, and bank balances back to the target's last closed trial balance. Ask how migration scripts are version controlled, who reviewed each change, and where the approval record sits, because auditors will ask for the same change trail they expect under general IT controls. For test copies, ask how personal data in customer, supplier and employee records is neutralized before anyone outside the target's team sees them, and how the partner proves that the neutralization ran.
Ask who holds administrator and database access during the transitional service period, how that access is granted, reviewed and removed, and whether the target's staff, the buyer's staff and the partner each have separate named accounts. Ask for the upgrade path for both entities, including the target version, the test database step and the date by which each instance must move, and for the support hours and version coverage that apply after go-live. Finally, ask how the evidence pack for the first group close will be produced: which reports, extracts, change logs, access reviews and reconciliation sign-offs it contains, who prepares each item, and how the partner will hand over the pack so that your external auditor can rely on it. Confirm that the partner prepares evidence for your auditor and does not issue any audit opinion itself.
How DeployOpen delivers this work
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For an acquired company's ledger, that means agreeing in writing what moves onto the group's instance, how the chart of accounts is mapped and what evidence the first group close will need.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names the target's entities, currencies, chart of accounts mapping and opening balance approach.
- Scope also records whether the target stays on a separate instance or moves onto the group's Odoo or ERPNext system.
How we build
- We map the target chart of accounts to the group structure and test opening balances against source trial balances.
- We set up the target's access, approval and posting roles and test segregation of duties before go-live.
- We document configuration, customizations and data migration steps so each mapping can be reviewed by auditors.
How we hand over
- Handover covers configuration records, mapping tables, reconciliation workpapers and the audit evidence list for the first close.
- We provide runbooks for the target's cutover, transitional access and any service agreement exit steps.
- Administrators are trained on the controls, backups and upgrade process the client will own after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the first group close.
- Support can cover version upgrades, which the client should confirm against the vendor's current support dates.
- Clients should confirm with us who holds administrator access and how change records are kept after the engagement ends.
