- OneWorld subsidiary hierarchy cannot be merged or restructured once in production - design it as if it is for the next ten years
- 1:1 alignment between legal entity and subsidiary is the safest default; statistical subsidiaries cover internal reporting without legal implications
- Share items and customers with subsidiary restriction; split vendors only where legal separation or payment bank accounts demand it
- An elimination subsidiary is mandatory for consolidated intercompany reconciliation, not optional
- Functional, reporting and transaction currency are three separate concepts; configure each deliberately at subsidiary creation
- Transfer pricing documentation must exist before intercompany transactions flow, not after
- Spend six weeks on subsidiary architecture before any configuration begins; the cost of rework scales with the square of the number of subsidiaries
There is a small number of decisions in a NetSuite implementation that cannot be undone. Subsidiary design is the largest of them. Once transactions flow, accounts are posted and historical comparisons are established, the subsidiary hierarchy locks in. NetSuite does not support subsidiary merges. It does not support reassigning transactions between subsidiaries. It does not support changing a subsidiary's base currency.
The consequence: the decisions you make in the first six weeks of a OneWorld implementation are the decisions you live with for the life of the platform.
This article walks through the four architectural decisions that define a OneWorld implementation, and the patterns we use to get each one right at day one.
Decision one: legal alignment
The first question is what each subsidiary represents. The two options are:
- Legal-entity alignment: one subsidiary per legal company. This is the audit-clean default.
- Operational alignment: subsidiaries represent operating divisions within legal entities, or groupings across legal entities.
Legal-entity alignment is correct for almost every organisation. It matches how external auditors think, how tax authorities think, and how banks and counterparties think. A consolidated set of books built on legal subsidiaries is defensible by design.
Operational alignment is tempting when the business speaks in terms of divisions, brands or regions that do not match legal boundaries. It is almost always a mistake. The reporting view the business wants can be produced by other means - custom segments, classes, departments - without compromising the legal structure.
A useful adjunct is the "statistical subsidiary". This is a subsidiary not used for transactions but configured to receive data copies via custom logic, for internal reporting purposes. It is rare and specialist. Most organisations do not need one.
The practical test: can an external auditor reconcile the subsidiary's trial balance back to a legal company's books without transformation? If yes, the alignment is correct. If no, reconsider.
Decision two: shared versus isolated master data
Master data is the records shared across subsidiaries: customers, vendors, items, projects, employees. For each of these, NetSuite offers two models.
- Shared with subsidiary restriction: one record exists, and a multi-select subsidiary field controls where it can be used. This yields one source of truth and cleaner master data.
- Isolated per subsidiary: separate records for each subsidiary, with custom logic to keep them in sync if needed. This yields stronger legal isolation but master data drift becomes near-certain.
Our default positions:
| Record type | Default | Exceptions |
|---|---|---|
| Items | Shared with subsidiary restriction | Regulated-goods customers may require isolation |
| Customers | Shared with subsidiary restriction | Some regulated industries require per-entity KYC separation |
| Vendors | Split when payment bank accounts differ by entity | Shared is fine if payments flow from a common bank relationship |
| Employees | Shared with primary subsidiary | HR systems usually dictate this |
| Projects | Per-subsidiary | Project accounting rarely spans entities |
The critical rule: once you pick isolated for a record type, the operational overhead compounds. Every change to a shared master has to be replicated manually or via script. We have seen organisations with 40% of vendor master time spent reconciling duplicates that should never have been created separately.
If you pick shared with restriction, the governance discipline is different but manageable. A change request process for the master record, with the restriction decision as part of approval, prevents most drift.
Decision three: intercompany pattern
Intercompany transactions are the traffic between subsidiaries. A sale from subsidiary A to subsidiary B that is really a transfer within the group. A management charge from headquarters to operating companies. An intercompany loan. A royalty payment.
Two patterns handle intercompany cleanly:
The automated intercompany journal pattern
When a transaction is entered on one subsidiary with a counterparty subsidiary designated, NetSuite's intercompany automation creates the mirror transaction on the counterparty subsidiary automatically. The two transactions are linked by an intercompany number, which makes them identifiable at consolidation.
This is the pattern to default to. It reduces manual reconciliation, ensures both sides post with correct VAT and withholding treatment, and provides the audit linkage consolidators need.
The elimination subsidiary
An elimination subsidiary is a dummy subsidiary that exists only to receive reversing entries at consolidation. Its function: when consolidated financials are produced, the eliminations subsidiary carries the opposite of the intercompany effect, netting the group position to zero.
This is not optional for a OneWorld implementation producing consolidated statements. Without it, the consolidated balance sheet carries both sides of every intercompany transaction, inflating figures and obscuring the true group position.
The configuration: create a subsidiary called "Elim" with a descriptive name, place it as a direct child of the parent at consolidation level, assign it a base currency matching the reporting currency, and run the elimination rules against it. No operational transactions should ever post directly to it. If one does, it is a sign that something upstream went wrong.
Transfer pricing
Any intercompany transaction must have a documented transfer pricing basis. Tax authorities enforce this across every jurisdiction a OneWorld instance operates in. The documentation is typically outside NetSuite - in a tax memorandum - but the rate at which intercompany transactions post should match the documented basis.
This cannot be an afterthought. Transfer pricing policies decided late create historical transactions at wrong rates and provoke tax adjustments. Put the policy in writing before any intercompany transaction flows.
Decision four: currency strategy
Currency in OneWorld is three separate concepts. Confusing them is the most common source of reporting misinterpretation.
- Functional currency (also called subsidiary base currency): the currency of the subsidiary's financial records. It is set at subsidiary creation and cannot be changed. Typically the statutory reporting currency of the legal entity.
- Reporting currency: the currency in which consolidated group financials are produced. Set at the OneWorld level, typically USD or GBP or EUR for global groups.
- Transaction currency: the currency in which a specific transaction was denominated. Can be any enabled currency. Revalued to functional at transaction date and again at consolidation date.
Every subsidiary you create permanently binds to a functional currency. Pick it based on the legal entity's statutory obligation, not the group's preferred reporting. A UK subsidiary's functional currency is GBP even if the group reports in USD. The reporting currency conversion happens at consolidation.
Exchange rate types matter:
| Rate Type | When used | Example |
|---|---|---|
| General | Standard transactional rate | Sales invoice on date X |
| Historic | Rate at original transaction | Revaluing long-standing intercompany balances |
| Spot | Single point-in-time rate | Period-end mark-to-market |
Configure the rate types at consolidation level with a loading strategy - daily feeds from a rate provider are standard practice. Manual rate entry should be an exception, not a routine.
The six-week architecture phase
OneWorld implementations without a dedicated architecture phase consistently over-run, deliver confused structures and require rework. Our standard for any OneWorld programme is a six-week architecture phase before any NetSuite configuration begins. The deliverables are:
- Subsidiary map: one diagram showing legal entities, their parents, and the consolidation path
- Currency strategy document: functional currency per subsidiary, reporting currency, rate types and rate load approach
- Master data matrix: which records are shared, which are isolated, with rationale
- Intercompany playbook: the types of intercompany transactions expected, the accounting treatment, the elimination pattern
- Transfer pricing memorandum: the policy basis for each intercompany relationship, approved by the tax function
- Chart of accounts alignment: shared versus subsidiary-specific accounts, segment strategy for management reporting
These are not theoretical documents. Each one is referenced repeatedly during configuration and troubleshooting. Each one has an owner who signs off. Changes after configuration begins are formal change requests with impact assessment.
The subsidiary creation checklist
When the architecture is ratified, the actual subsidiary creation follows a standard checklist per subsidiary:
- Name, short name, country, language, time zone
- Functional currency - verify twice, cannot be changed
- Parent subsidiary - places it in the hierarchy
- Elimination flag if this is the elimination subsidiary
- Default chart of accounts
- Fiscal calendar
- Tax nexus and tax agency configuration
- Address for statutory purposes
- Logo and header configuration for subsidiary-branded documents
Once saved, the subsidiary exists for the life of the platform. Changes beyond cosmetic detail are constrained.
The bottom line
OneWorld is not a feature. It is a structural decision about how the group will be represented in NetSuite for the next decade. The four decisions - legal alignment, master data pattern, intercompany treatment, currency strategy - compound. Getting them right at day one is a six-week investment. Getting them wrong is a rebuild.
If you are about to start a OneWorld programme, do not rush past architecture. The week you save at the start becomes six months of rework at the end.
Need a governance review, architecture assessment, or custom SuiteScript delivered to this standard?
Book a Free Consultation