At a glance
- Treat converting an add-on's ERP as a separate project, not a default: keep its existing system unless its operations are similar enough to the rest of the portfolio to share one outright, or the hold period justifies the migration.
- A keep-vs-convert decision table and a consolidation exception matrix — exception type, auto-resolve or route, and approver — turn a multi-ERP close into a repeatable monthly routine instead of a one-off scramble.
- Chart-of-accounts mapping is a table built once per entity and re-run every close, not a remap from scratch each month.
- Currency translation and per-account rate overrides can auto-resolve inside one ERP's own consolidation tools; intercompany eliminations, unmapped accounts, and timing gaps between different ERPs need a person.
- Consolidation policy — what counts as a proper elimination, what needs disclosure — stays the controller's and auditor's call; this page maps the workflow, not the standard.
Should each add-on keep its ERP?
A roll-up's third or fourth add-on can easily sit on a different ERP than the platform itself. That's where multi-ERP consolidation automation for private equity roll-ups stops being a one-time integration project and becomes a monthly operating problem. Keep the add-on's ERP as the default move: converting it is a separate project with its own timeline, cost, and risk.
That project is worth it only when the operations are already alike. EstesGroup's guidance on ERP decisions for add-on acquisitions puts the fit test directly: consolidation fits when the companies sell similar products, serve similar customers, operate comparable warehouses, and follow related purchasing, pricing, fulfillment, and accounting processes[1]. Otherwise — a specialized market, a different fulfillment model, separate regulatory requirements — the guidance says the acquired company should stay on its existing ERP for a period of time[1].
The reporting side doesn't have to wait on a migration. RSM's guidance for private-equity-backed companies recommends companies standardize the chart of accounts, entity hierarchy and key dimensions to create a consistent structure that supports accurate management reporting and meets buyer requirements[2], whether or not the ledgers are later converted.
The multi-ERP close pattern map
Treat the table below as a working rule, not a one-time check: revisit it whenever an add-on's operations change or the remaining hold period shortens.
| Decision factor | Favors keeping the add-on's ERP | Favors converting to the platform ERP |
|---|---|---|
| Remaining hold period vs. conversion timeline | Less runway than a realistic migration needs | Enough runway to absorb a multi-month conversion |
| Operating similarity to the rest of the portfolio | Specialized market, different fulfillment model, or separate regulatory requirements | Sells similar products, serves similar customers, operates comparable warehouses, and follows related purchasing, pricing, fulfillment, and accounting processes |
| Native multi-entity consolidation on the platform ERP | The platform ERP can't consolidate the add-on either way, so converting doesn't remove the mapping step | The platform ERP already has native multi-subsidiary consolidation the add-on would gain by moving onto it |
| Mapping effort vs. ledger-migration effort | Chart of accounts and entity hierarchy can be standardized without moving the ledger | Mapping drift keeps reappearing faster than a monthly process can track it |
| Diligence and exit timeline | Exit is too near for full consolidation — a data warehouse or reporting layer can aggregate the numbers instead | Exit is distant enough to complete a full conversion and present one system of record before diligence starts |
Row 3 hinges on a limit of native consolidation: NetSuite OneWorld can display consolidated data for multiple related subsidiaries directly[3], but only for subsidiaries actually configured inside that account — not for an add-on still on a separate system.
The consolidation exception matrix
In Sage Intacct, a global consolidation converts entities with different operating currencies into a single reporting currency[4]. The decision above is made once, or rarely; the matrix below is what a controller, or an agent working under the controller's thresholds, applies every close: what counts as an exception, whether it resolves itself, and who signs off.
| Exception type | Typical cause | Auto-resolve or route to a person | Approver |
|---|---|---|---|
| Currency translation difference | Subsidiaries consolidate in different operating currencies | Auto-resolve when the ERP calculates it natively — the way NetSuite OneWorld calculates its CTA line [5] | Controller reviews the calculated translation line; no action needed unless it's unexpectedly large |
| Rate override for a specific account | One GL account (for example, equity) needs a non-default rate method: ending spot, weighted average, or historical | Auto-resolve once configured as an override account, letting a preparer set a different rate method per account [6] | Controller approves the override configuration when it's set up, not every month |
| Intercompany elimination | Balances between related entities must net out before the numbers roll up | Auto-resolve within one ERP's elimination accounts when both entities share it — Sage Intacct posts eliminations to a named account [7]; otherwise route to a person | Controller or consolidation preparer confirms the elimination ties out |
| Unmapped chart-of-accounts line | A new or add-on account has no destination on the standardized reporting chart | Route to a person — an unmapped account should never post into a default bucket on its own | Controller, or whoever owns the mapping table |
| Timing or period misalignment | One entity's close calendar doesn't line up with the platform's reporting period | Route to a person to confirm which period the entry belongs to | Preparer, with the controller if it crosses a quarter or year-end |
| Duplicate or missing subsidiary entry | An add-on's ledger export loaded twice, or didn't load completely | Route to a person; verify against the source ledger before reloading anything | Preparer, escalate to controller if the source system can't confirm it |
Rows 1 through 3 describe what a single ERP's own consolidation tooling already does when related entities share it: NetSuite OneWorld calculates its cumulative translation adjustment dynamically, applying a current, average, or historical rate by account type[5].
Sage Intacct's per-account rate override and elimination account each work only within one ERP[6][7], which is why elimination in the matrix splits between auto-resolve and route.
How do you map different charts of accounts every month?
Build the mapping once per entity, then re-run it every close — don't remap from scratch each month. One row per account, pointing to its destination on the standardized reporting chart, is the whole mechanism; the work is keeping it current.
- Map once per entity
One row per account, pointing to its destination on the standardized reporting chart, before the entity's first close.
- Route what's unmapped
Any account with no destination goes to the preparer or controller — never into a default bucket.
- Re-run and diff
Re-apply the mapping every close and flag any row whose destination changed without a documented reason.
- Refresh on every new add-on
Extend the table before a new entity's first close, not during it.
This is the same standardization RSM recommends ahead of a sale[2]: one chart, one entity hierarchy, one set of dimensions, applied consistently whether the underlying ledgers sit on one ERP or four.
The mapping table's job ends once every account has a destination; whether the numbers actually close — accruals, flux review, sign-off — is a separate workflow. See Financial close automation for that side of the calendar.
Which consolidation exceptions need a human?
Anything the matrix above marks route needs a human: any exception where resolving it wrong would misstate a subsidiary's numbers, not just slow the close down. That covers unmapped accounts, cross-ERP eliminations, timing misalignments, and duplicate or missing entries.
Routing a cross-ERP exception to the right person still leaves it open until someone confirms what it actually ties out against. Financial reconciliation automation covers the account-level matching this matrix's eliminations and overrides ultimately depend on.
How quickly can a new add-on report in the platform format?
There's no single timeline to quote, and we wouldn't estimate one: it depends on how much of the add-on's chart of accounts differs from the standardized one, how many accounts are genuinely new, and how complete its data is at close.
Connecting the add-on's export to the mapping table is mechanical and quick. Running one full exception cycle before the output counts as reportable takes a full close, and confirming with the controller comes before the numbers reach board or lender reporting.
When does an ERP conversion make sense?
Convert when every factor in the table above points the same direction: similar operations, enough runway left in the hold period to absorb the migration, and enough distance from exit to finish a conversion rather than bridge a near-term close with a reporting layer.
RSM's exit-readiness guidance asks companies to choose either a single-instance ERP or a federated model with a shared data framework and reporting layer[2]. When full consolidation isn't feasible before the exit, it points instead to a data warehouse or analytics layer to aggregate data from multiple ERP systems[2].
EstesGroup's framing holds regardless of the ultimate choice: the decision should begin with the operating model, not the software brand[1]. If multiple ERPs stay in place instead, leadership still has to define which system owns each customer, supplier, product, price, and financial record[1].
When this doesn't apply
- A single, low-volume add-on: a manual month-end tie-out can cost less than building and maintaining a mapping table and exception routine.
- The add-on's data is still being untangled post-close — see Legacy finance workflow automation before mapping or routing runs against unstable data.
- The close depends on a judgment call — an estimate, a disputed balance, a write-off — that a matrix can't make.
Where to start: a first scoped workflow
Start with one add-on and one close cycle, not the whole portfolio at once: build its mapping table, run the exception matrix against a period already closed, and compare what it would have flagged against what your team actually did.
- Pick one add-on
The one with the most mapping drift or manual month-end hours, not necessarily the newest one.
- Map and replay
Build its mapping table, then replay the matrix against an already-closed, reviewed period without changing the recorded result.
- Compare and adjust
Check what the matrix would have auto-resolved or routed against what your team actually flagged, and tighten disagreeing rules.
- Go live on one cycle, then scale
Run it live for one close before extending the same mapping table and matrix to the next add-on.
Frequently asked questions
Should each add-on keep its ERP?
Keep it, as the default move. Converting an add-on's ERP is a separate project with its own timeline, cost, and risk — we recommend justifying it against the remaining hold period, and only converting when its operations are similar enough to the rest of the portfolio to share one system outright.
How do you map different charts of accounts every month?
Build a mapping table once per entity, one row per account pointing to its destination on the standardized chart, then re-run the same mapping every close. Route any unmapped account to a person instead of a default bucket, and treat an unexplained mapping change as an exception itself.
Which consolidation exceptions need a human?
Anything where resolving it wrong would misstate a subsidiary's numbers, not just slow the close: unmapped chart-of-accounts lines, intercompany eliminations between entities on different ERPs, timing misalignments, and duplicate or missing ledger entries. Currency translation and per-account rate overrides can often auto-resolve inside one ERP's own consolidation tools.
How quickly can a new add-on report in the platform format?
There's no standard timeline; it depends on how much the add-on's chart of accounts differs from the standardized one, how many accounts are genuinely new, and how complete its data is at close. Connecting its export to the mapping table is quick, but running one full exception cycle before the output counts as reportable takes a full close.
When does an ERP conversion make sense?
When the add-on's operations are similar enough to the rest of the portfolio, enough hold period remains to absorb a multi-month migration, and the exit is distant enough to finish that conversion rather than needing a data warehouse or reporting layer to bridge a near-term close across separate ERPs.
Related reading
- Financial close automation covers the calendar, accruals, and sign-off workflow this matrix feeds into.
- Financial reconciliation automation covers the account-level matching the eliminations and overrides depend on.
- Legacy finance workflow automation covers getting an add-on's exports into a usable feed before mapping runs.
- AI agents for private equity portfolio companies maps automation across a portfolio company's back office beyond the close.
- AI financial close automation goes deeper on reconciliation and sign-off inside the close itself.
Sources
- EstesGroup, "The ERP Decisions Behind Successful Private Equity Acquisitions" (2026) (accessed 2026-09-30)
- RSM US LLP, "ERP readiness for private equity exits" (2026) (accessed 2026-09-30)
- Oracle NetSuite, "OneWorld Financial Statements" (accessed 2026-09-30)
- Sage Intacct, "Run Global or Domestic Consolidation" (accessed 2026-09-30)
- Oracle NetSuite, "Cumulative Translation Adjustment (CTA) Overview" (accessed 2026-09-30)
- Sage Intacct, "Consolidation Override Accounts" (accessed 2026-09-30)
- Sage Intacct, "Consolidation Elimination Accounts" (accessed 2026-09-30)
- Intuit, "QuickBooks Desktop Enterprise features" (accessed 2026-09-30)
More in Finance operations
Deal Jacket and Title/Registration Automation for Multi-Rooftop Dealer Groups
Deal jacket and title/registration automation for multi-rooftop dealer groups: a completeness checklist table, audit-gap handling and cross-store standards.
Auto DealershipsFranchise Brand-Standards Audit Documentation: Automating the Paper Trail Behind the Inspection
Franchise brand-standards audit documentation: how an agent turns photos, PDFs, forms and emailed fixes into one packet per location, ready when asked.
Multi-Unit Franchise OperatorsGroup and Folio Billing Audit: Catching the Leak Types a Normal Error Check Misses
A group and folio billing audit for hotel management companies: a leak-type table of rate code mismatches, missing closes, adjustments, orphaned charges.
Hotel Management Companies