A single-entity NetSuite implementation is a well-understood project. A multi-entity OneWorld implementation looks similar from the outside and is a different animal underneath. Every design decision multiplies. Intercompany becomes a core process rather than an afterthought. Consolidation, currency, tax, and reporting all take on dimensions that don’t exist in a single-entity account.
Companies that approach OneWorld as “the regular implementation, but with more subsidiaries” tend to discover the difference around the first consolidated close. This article walks through what actually changes, the decisions that matter most, and the mistakes that cost the most to undo.
What OneWorld Is
OneWorld is the NetSuite edition that supports multiple legal entities (subsidiaries) in one account, with each subsidiary carrying its own base currency, tax nexus, chart of accounts mapping, and books, and the parent able to consolidate everything into unified financial statements. It handles multi-currency transactions, intercompany transactions and eliminations, and consolidated reporting across the hierarchy.
If your company has more than one legal entity that needs separate books (a US parent with a UK subsidiary, a holding company with operating companies, an acquired business kept as its own entity), you need OneWorld. If you have one legal entity with multiple locations or divisions, you usually don’t; departments, classes, and locations handle that within a single subsidiary.
The Design Decisions That Define the Project
Subsidiary hierarchy
The structure of parent and child subsidiaries determines how consolidation rolls up, how intercompany eliminations work, and what reporting is possible. It should mirror your legal structure, but there are choices within that: whether to create elimination subsidiaries, how to handle holding companies with no operations, and whether to model regional sub-consolidations.
Changing the hierarchy after go-live is painful. This decision deserves the most careful attention of anything in the project.
Chart of accounts strategy
OneWorld supports a single global chart of accounts shared across subsidiaries, with accounts restricted to specific subsidiaries where needed. The usual mistake is letting each subsidiary bring its own legacy chart, which creates a sprawling account list and makes consolidation mapping a nightmare. The better approach is a unified chart designed for the group, with subsidiary-specific accounts only where local requirements genuinely demand them.
Currency
Each subsidiary has a base currency. Transactions can occur in other currencies. Consolidation happens in the parent’s currency using exchange rate types (current, average, historical) applied by account type. Getting the consolidated exchange rate configuration right, and understanding how NetSuite handles cumulative translation adjustment, is specialized knowledge. Get it wrong and your consolidated balance sheet won’t balance in ways that take weeks to diagnose.
Intercompany framework
Which subsidiaries transact with each other, for what (goods, services, management fees, loans, shared costs), and how those transactions should be recorded and eliminated. NetSuite’s intercompany framework can automate much of this: paired intercompany transactions, automated elimination journals, intercompany netting. But it has to be designed, with intercompany customers and vendors set up, intercompany accounts defined, and elimination rules configured.
Tax
Each subsidiary carries its own tax nexus and tax rules. VAT, GST, sales tax, withholding: the configuration differs by jurisdiction and NetSuite’s tax engine (or a third-party tax SuiteApp) needs to be set up per subsidiary.
Segments and classifications
Departments, classes, and locations can be shared across subsidiaries or restricted. Deciding on a consistent segment design across the group, rather than letting each entity define its own, is what makes cross-subsidiary reporting meaningful.
Roles and access
Users may need access to one subsidiary, several, or all. Role design must account for subsidiary restrictions, and the administrator population needs even more care than in a single-entity account.
Data Migration Across Entities
Every subsidiary’s data has to be migrated, mapped to the unified chart and segment design, tagged to the right subsidiary, and reconciled. Opening balances must tie per subsidiary and in consolidation. Intercompany balances must agree between the entities involved on day one, or the first elimination will fail.
Historical data decisions are harder here too: if the subsidiaries ran on different legacy systems with different structures, bringing detailed history into a unified model may not be realistic, and the project needs to decide what comparative reporting will look like across the transition.
Where OneWorld Projects Go Wrong
Hierarchy decided too fast. A structure chosen in week two that doesn’t reflect how the business actually consolidates, discovered at the first close.
Subsidiary-by-subsidiary thinking. Each entity implemented as its own mini project with its own design, leaving the group with inconsistent charts, segments, and processes that can’t be reported across.
Intercompany treated as a finance detail. Left until the end, under-designed, and then manually handled every month because the automation was never built.
Currency configuration misunderstood. Consolidated exchange rates misapplied, translation adjustments landing in the wrong place, and a consolidated balance sheet that doesn’t balance.
Underestimated testing. A full consolidated mock close, including intercompany eliminations and currency translation, is the single most important test in a OneWorld project. Projects that skip it find out at the real close.
Local requirements discovered late. A statutory reporting requirement in one country, a tax rule in another, a local invoice format somewhere else. Each one found after design is a change order.
What a Good OneWorld Implementation Looks Like
The projects that go well share a pattern. Discovery is done at the group level first, establishing the hierarchy, the unified chart, the segment design, and the intercompany framework before any individual subsidiary is configured. Then each subsidiary is implemented within that framework, with local requirements handled as exceptions to a shared design rather than as independent builds.
Finance leadership at the group level is engaged throughout, because the consolidation and intercompany decisions belong to them, not to any single entity’s controller. Testing includes a full consolidated close in sandbox, with real migrated data, before go-live is approved.
That’s a more demanding version of a standard NetSuite implementation, and it benefits from a partner who has delivered multi-entity projects before, because the pitfalls above are specific to OneWorld and are learned mostly by experience.
Phased or Big Bang
One strategic choice worth considering: whether to bring all subsidiaries live at once or phase them. A phased approach (parent and largest entity first, then others over subsequent months) reduces risk and lets the team learn before scaling. It also creates a period where some entities are in NetSuite and others aren’t, which complicates consolidation during the transition.
Big bang is cleaner once live but concentrates all the risk on one cutover. The right answer depends on the number of entities, their complexity, and the organization’s appetite for a longer project versus a riskier one. An experienced NetSuite consultant can usually recommend which approach fits after understanding the entity structure and the team’s capacity.
The Payoff
A well-implemented OneWorld account is a genuine transformation for a multi-entity business. Consolidated financials that close in days instead of weeks. Intercompany that eliminates automatically. Group-wide reporting on consistent segments. One system of record across every entity, with local compliance handled per subsidiary. That outcome is entirely achievable. It requires treating OneWorld as the group-level design exercise it is, investing in the decisions that are hard to reverse, and testing the consolidated close before trusting it. Companies that do those things end up with the system they were promised. Companies that treat it as a bigger single-e
