CFOs running NetSuite OneWorld across two or three legal entities usually rule out a netsuite oneworld to odoo migration before testing whether the assumption holds. The logic feels airtight: intercompany eliminations, consolidated reporting, multi-currency balances across subsidiaries. Surely that depth doesn't transfer to an open-source ERP.
Most of it does. The real gap list is three items long and structural, not a vague warning about complexity. del.ai sells NetSuite-to-Odoo migrations. So read the case below as an interested party's argument, not a neutral one. Then check the gap list against your own structure before you take our word for it.
The specific fear sounds like this: "We run three entities, multi-currency, consolidated reporting. Odoo can't touch that." It's stated as fact, not as a question, which is the tell. Nobody has actually tested it against their own structure.
NetSuite OneWorld earned its reputation honestly. It was built for consolidation depth: parallel statutory ledgers, multi-currency elimination engines, per-jurisdiction reporting. For companies actually using that depth, del.ai considers that reputation deserved.
The problem is that OneWorld gets treated as one undifferentiated thing. A company with three US entities and a single functional currency gets lumped in with a very different company. That one runs a dozen subsidiaries across several continents, with externally audited group financials. Both hear the same story: OneWorld means you're stuck.
They aren't the same structure, and they don't face the same migration math. The next two sections separate what actually requires OneWorld's depth from what a simpler multi-entity setup pays for and never uses. The CFOs holding this objection tightest often have the most to gain from testing it.
Before the transfer-versus-gap argument means anything, it helps to see what OneWorld actually bills for, separate from base NetSuite.
NetSuite upsells OneWorld at the second legal entity. Start with the honest caveat: Oracle does not publish OneWorld pricing. Every number in circulation, including ours, is either an industry estimate or somebody's negotiated contract. A third-party pricing guide that says so explicitly puts the OneWorld platform tier at $2,000–$5,000 a month against a standard NetSuite base commonly quoted near $999 a month, and notes that per-subsidiary fees vary by contract — some agreements charge incrementally above a baseline, others bundle them. We are not restating the widely quoted "$24,000–$30,000 module fee plus $1,200 per subsidiary per month" figures, because we could not find a source that stands behind them.
The practical consequence for a CFO is unchanged and easier to check: OneWorld is a separable tier on your own invoice. Pull the contract and find that line before comparing anything.
That's the netsuite oneworld license cost question most CFOs never separate from the rest of the stack. The rest of the stack, on del.ai's cost model:
| Cost line | Annual range |
|---|---|
| Base NetSuite license | $30,000–$50,000 |
| Alliance Partner support | $30,000–$100,000 |
| SuiteApps | $20,000–$50,000 |
| BI and ETL tooling | $30,000–$80,000 |
| Internal admin headcount | $100,000–$400,000 |
| Full stack | $210,000–$680,000 |
The OneWorld tier sits on top of the base license line in that table, at whatever your contract says. It is a specific, separable line, not a rounding error.
NetSuite prices that tier for consolidation depth: multi-book parallel ledgers, three-plus-currency elimination engines, statutory per-jurisdiction reporting. It is not a per-seat markup. It is a price for a specific set of capabilities.
The math only makes sense if the structure actually uses that depth. Most two- to three-entity US companies with a single functional currency do not. The next two sections answer that question directly. One covers what part of that depth transfers to Odoo. The other covers what part is real, structural, and worth paying for.
For a US-domestic company with two to three legal entities and a single functional currency, three things transfer cleanly. Subsidiaries map onto Odoo's multi-company structure, with each entity running as a separate company under one shared database instance. Intercompany document pairing comes from a free community add-on rather than stock Community. Multi-currency transaction balances at the entity level are handled natively. Group consolidated reporting is the exception: Odoo's Consolidation app is Enterprise-only, and a del.ai deployment runs Community, so that layer is covered by a module we build rather than by a per-seat licence. None of this is a workaround bolted on afterward. Odoo 19's multi-company and intercompany auto-document features are built for exactly this structure, running the current stable release. A single foreign sales-office subsidiary with no statutory consolidation requirement is covered too. Odoo publishes fiscal localization modules for dozens of countries, with documented pages for 59 of them. What doesn't transfer is a shorter, more specific list, covered next.
Source: Odoo 19 multi-company and intercompany documentation, ↗, 2026; Odoo 19 fiscal localizations, ↗, 2026.
In a netsuite oneworld multi-subsidiary migration, Odoo maps each legal entity to a company record inside a single instance. Each company sets its own chart of accounts, fiscal localization, and tax rules. Financial statements produce per-entity by default, the same starting point a controller already works from in NetSuite.
Controllers usually ask the netsuite intercompany transactions migration question first, and the answer is concrete. When one subsidiary invoices another, the matching bill on the receiving entity is raised by an add-on rather than by stock Community: OCA's account_invoice_inter_company, AGPL-3, maintained on the 18.0 branch. The same module covers a purchase order raising the matching sales order on another company. Stock moves between entities run through Community's normal inter-warehouse routes with nothing added.
Odoo's Consolidation app — account mapping between entities, translation rates applied automatically — ships in Enterprise, and Enterprise is a renewing per-seat subscription. A del.ai deployment does not use it, because we deploy Odoo Community under LGPLv3 and the point of the move is that you stop paying per seat to run your own books.
What Community gives you natively is the layer underneath, and for a two- to three-entity US structure on one functional currency it is most of the job: each entity as its own company in one database, with its own chart of accounts and tax rules, and multi-currency handled at entity level.
Group-level consolidated reporting is the piece that sits above that line. It is covered the same way every other Enterprise-only convenience is covered here — an existing connector, a module we build, or the agent layer — and which of the three applies to your structure is named on the first call, before you sign, not discovered afterwards. What does not happen is being moved back onto a per-seat licence to close the gap.
Three things, and each is structural rather than cosmetic. Multi-book accounting is the first: NetSuite Multi-Book keeps parallel GAAP and local-statutory ledgers per entity. Odoo is architecturally one ledger per company, a permanent gap with no roadmap fix. The second is group consolidation across three or more functional currencies. Odoo's Consolidation app is Enterprise-only, so a Community deployment covers this through a built module or the agent layer, and eliminations across three-plus currencies go semi-manual either way, without an audit-grade nightly tie-out. The third is statutory or externally audited group consolidation, which does not hold up under external audit without manual workpapers. That gap is the one most likely to break a fast timeline. Each is discoverable with one direct question. Do you keep parallel statutory books? How many functional currencies touch consolidation? Are your group financials externally audited? Active use of any one is a nameable disqualifier, not a hedge about complexity in general.
Source: Odoo Consolidation app documentation, ↗; NetSuite Multi-Book Accounting overview, ↗, 2026.
NetSuite Multi-Book runs GAAP and local-statutory ledgers in parallel per entity. Odoo's architecture is one ledger per company. That is not a configuration limit a future release closes; it's how the system is built. If your structure requires parallel statutory books today, that is one of the honest reasons to stay on OneWorld, and it should surface in the first discovery call, not mid-cutover.
A multi-entity erp migration risk shows up specifically when group consolidation touches three or more functional currencies. Consolidation on Community runs through a module we build rather than the Enterprise app, and elimination entries across three-plus currencies become a semi-manual process. There is no nightly, audit-grade tie-out the way NetSuite's consolidation engine produces one. For two entities in one functional currency, this gap never activates. For a group spanning three-plus currencies, it activates immediately.
When a netsuite subsidiary consolidation migration includes externally audited or statutorily filed group financials, it runs into the sharpest limit. Odoo's consolidated output does not hold up under external audit without manual workpapers layered on top. That gap is the one most likely to break a 90-day cutover if it's active. Ask directly whether group financials are externally audited or filed before assuming the timeline holds.
Frequently, yes — though the honest starting point is that Oracle does not publish OneWorld pricing, so no exact figure here is verifiable. A third-party pricing guide that says as much puts the OneWorld platform tier at $2,000 to $5,000 a month against a standard NetSuite base commonly quoted near $999 a month, with per-subsidiary fees varying by contract. NetSuite prices that tier for consolidation depth: multi-book ledgers, three-plus-currency eliminations, statutory reporting. A two- to three-entity company running a single functional currency never touches any of that depth. It has no parallel statutory books and no external audit on group financials. It pays consolidation-tier pricing for capability it structurally cannot use, and that gap compounds at every renewal on top of the base license, the partner retainer and the SuiteApp spend. Check the OneWorld line on your own invoice rather than any published estimate, including this one.
Source: Broken Rubik, "NetSuite OneWorld: Multi-Subsidiary & Multi-Currency," 2026, third-party estimate that states Oracle does not publish official OneWorld pricing. ↗
The pattern repeats across simple-structure OneWorld shops. The CFO certain OneWorld blocks migration is often the same CFO paying full consolidation-tier pricing for a two-entity, single-currency structure. That structure would clear a base multi-company setup elsewhere.
This runs on the same self-funded mechanic as any del.ai migration. The migration fee is offset by the SaaS spend it deletes, not by new budget. Migration starts ~$50k, and Odoo hosting runs from ~$2k/mo afterward. The OneWorld tier is an extra line on top of the base licence — what it costs you is on your contract, not on any published rate card. Whatever that number is, it is deleted alongside the rest of the stack, which is why the deletion side of the ledger moves faster for a OneWorld account than for a base-tier one.
That is the argument here: OneWorld's reputation as an impossible migration case is strongest exactly where it's least deserved. Simple-structure OneWorld shops are not the weakest migration candidates. On del.ai's read of the structure, they are among the strongest. The gap between what they pay for and what they use is larger than almost any other segment in the NetSuite install base.
Multi-entity migrations run sequenced, not simultaneous, for qualifying migrations within the signed scope document. Each subsidiary keeps operating on NetSuite until its own cutover weekend arrives. The first entity to cut over is typically the simplest one: cleanest data, fewest dependencies. Later entities cut over once the pattern from the first one is proven.
Intercompany transactions and consolidated reporting get reconciled to the penny before any single entity goes live on Odoo. That reconciliation runs against the same period in both systems: journal entries, intercompany eliminations, AR and AP aging, and the consolidated view across whichever entities have already moved. If the numbers don't match, that entity's cutover doesn't proceed.
Rollback exists at every step, per entity, not only at the end of the full program. An entity that fails reconciliation stays on NetSuite while the rest of the program continues around it. That is a meaningfully different risk profile than a single-entity migration. Instead of one all-or-nothing cutover weekend, a multi-entity structure gets several smaller, individually reversible cutover events.
The audit-trail and record-immutability mechanics that govern how history carries over during cutover apply the same way across a multi-entity structure — nothing about running several entities changes what SOX compliance requires of the record.
Yes for a narrow structure, and the boundary is the whole answer. Yes, if the structure is US-domestic, two to three legal entities, at most one foreign sales-office subsidiary with no statutory consolidation requirement, and a single functional currency. No, if the structure has four or more legal entities, a foreign operating subsidiary that requires statutory consolidation, multi-book parallel statutory ledgers, or group financials that are externally audited or filed. Those four conditions are a checklist a CFO or controller can apply to their own structure in under a minute, without waiting on a discovery call. Entity count alone is not the disqualifier; the four structural conditions above are. A company can run three legal entities and clear every check on this list, and a company can run two entities and fail on the audit condition alone. The structure, not the entity count, decides the answer either way.
Source: del.ai migration methodology, 2026
Fit: two to three legal entities, US-domestic, with at most one foreign sales-office subsidiary and a single functional currency. Not a fit today: four or more legal entities, a foreign operating subsidiary requiring statutory consolidation, multi-book parallel ledgers, or externally audited or filed group financials. That second list is an honest disqualification, not a hedge, and it's the reason the first list is credible.
The fastest way to know which side of that line your structure falls on is a scoping conversation, not more research. The checklist above takes a minute to run against your own entities.
Built for NetSuite OneWorld shops running two to three US legal entities with total NetSuite spend of $120,000 or more a year, sweet spot $200,000 or more. Not a fit if you run four or more entities, keep multi-book statutory ledgers, or your group financials are externally audited across three or more functional currencies.
30 minutes. We walk your specific entity structure against the three gap conditions above. Then we tell you whether OneWorld is actually blocking your migration or just feels like it is. No pitch. You'll know which side of the line your structure falls on before the call ends.
Sources
1. Broken Rubik, "NetSuite Pricing: Real Costs From $999/mo to $10K+," third-party ERP cost benchmark noting Oracle does not publish OneWorld/subsidiary fees, 2026. ↗
2. Broken Rubik, "NetSuite OneWorld: Multi-Subsidiary & Multi-Currency," third-party estimate, 2026. ↗
3. Odoo, "Licenses" (Community LGPLv3; Enterprise proprietary subscription), 2026. ↗
See how this works in the product