The close that could not be signed
A finance director called me in February because the auditors wanted standalone accounts for one of the group's legal entities and nobody could produce them. The system had been configured eighteen months earlier with one subsidiary per sales region, because that was how the business described itself in the Monday meeting. Two of the group's legal entities sat inside the same region, and one of them traded across two.
Every posting for those companies landed in the same subsidiary, separated only by a department value that order entry staff chose from habit. The statutory accounts had to be assembled in a spreadsheet from a saved search plus a list of manual adjustments, and that spreadsheet became permanent. Three years later, two people still rebuilt it every quarter.
Nobody chose badly on purpose. The subsidiary list was filled in during week two by a consultant asked to get the structure in so configuration could start. The controller who signs the statutory accounts was not in that conversation, and by the time anyone looked closely there were tens of thousands of transactions posted against the arrangement.
The subsidiary hierarchy is among the hardest things in NetSuite to restructure once transactions exist against it. Decisions taken in the first few weeks of an implementation constrain the group for years, and they are usually taken by whoever happens to be configuring rather than by anyone who understands how the group is owned and reported.
Make a subsidiary mean one legal entity
The rule that holds up over time is the plain one. A subsidiary should represent a legal entity, something that files its own accounts, holds its own tax registration, and could be sold or wound up on its own. Any candidate on your list that fails that test belongs somewhere else in the design.
Legal entity structure changes rarely, and a new country or an acquisition arrives with lawyers and dates attached, so you hear about it well in advance. Operating structure changes constantly. Divisions merge, a product line moves under a different leader, two regions become three, and none of that comes with notice or a filing deadline.
Using subsidiaries to model divisions is the mistake that causes the most pain later. The divisional view the business wants can be produced from segments, and segments can be renamed, retired and reassigned at will. A subsidiary carrying two years of posted transactions cannot. When the division goes away you are left with a node in the hierarchy that represents nothing, and every new joiner has to be told why it is there.
The hierarchy decides what you can consolidate
The parent and child arrangement is what the system rolls figures up through, so it decides which consolidated views you can produce without hand assembly. A subgroup the board asks about every quarter needs to exist as a node in that hierarchy, with the right entities beneath it. If it does not, someone rebuilds it in a spreadsheet each quarter, and that person becomes the reporting system.
Elimination follows the same shape. Intercompany balances net off at a level with both trading entities beneath it, so flattening everything under the top parent leaves elimination clean only at group level. Two entities that trade heavily and get reported on together want a common parent matching the way you intend to report them.
How much of this the system does for you depends on your edition and which features are switched on, and subsidiary functionality in particular varies by both. Confirm the behaviour in your own account before designing around it, rather than trusting a diagram from someone else's project. If the group also runs a second ledger elsewhere, the dual ledger question deserves settling in the same conversation.
Base currency is the decision with no second chance
Three currencies get confused in these discussions. A subsidiary has its own base currency, the one its books are kept in and its statutory accounts filed in. The group has a consolidation currency, what the parent reports in. Transactions carry their own currencies, whatever the customer or supplier document was raised in.
The base currency of a subsidiary is the one you cannot walk back. Every posted amount, every revaluation and every balance in that entity's history is denominated in it. Changing it once transactions exist stops being a configuration change and becomes a new subsidiary plus a migration of history that your auditors will want explained.
So ask the person who files the accounts, not the person who sells into the country. A sales team quoting in a currency tells you nothing about which currency the entity keeps its books in. Write the base currency beside each entity on the list and have the controller initial it before anyone posts.
The chart of accounts and the segments underneath it
Whether the chart of accounts is shared across subsidiaries usually gets decided quietly, and it deserves an argument. A shared chart makes consolidation straightforward and forces local finance teams to give up codes they have used for a decade. Restricting accounts per entity is possible in many configurations, and every restriction turns into a question at the next reconciliation.
The segments are where the management views live. Department, class, location and any custom segmentation you add carry division, product line, channel and cost centre. Design them in the same week as the subsidiary list, because the case for a division subsidiary wins by default when nobody has shown where else the divisional profit and loss comes from. That work sits next to master data governance and to reporting two departments can agree on.
Access and intercompany follow the same structure
A user's subsidiary access decides what they can see and where they can post, which makes it part of the entity design rather than a task for the week before go-live. A shared services clerk processing payables for six entities needs something different from a country controller who should see one entity, and both need writing down before anyone assigns roles.
The broad grant is the tempting answer, and the one that shows up in the audit. Somebody gets access to every subsidiary because they needed two, and the review three years later cannot tell whether that was ever right. Where one person genuinely works across entities, record which entities and why, beside your notes on segregation of duties.
Intercompany arrangements are far easier when the entity structure was designed with them in mind. Before the structure is locked, name the pairs of entities that will trade, decide whether both sides post or one side drives, and agree who reconciles the result each month. Retrofitting that onto a hierarchy built for sales regions buys you manual journals at every close. What the system automates here depends on edition, enabled features and sometimes licensing, so check your own account.
Get it signed off before anything posts
Find the person who owns statutory reporting for the group and make them review the structure before a single transaction is recorded. Not the project sponsor and not the finance systems lead. The person whose name goes on the filings, who will spot the entity dissolved last year and the branch that should never have been a subsidiary.
Then close a period across the whole structure in a test account before go-live. Post intercompany transactions in both directions, run the consolidation, and have someone who reads the real reports look at the output. A structural problem found in rehearsal costs a conversation. The same problem at the first live close costs a month. An ERP migration rehearsal is where this belongs.
Adding a subsidiary later is routine work. Restructuring one that already carries posted history is a project with a budget, a timeline and an auditor asking why. So walk the subsidiary list line by line with your controller this week and confirm each of these before the first live transaction.
- The legal entity each subsidiary represents, and who files its accounts.
- The base currency of each entity, initialled by the person who files them.
- The parent of each entity, and every subgroup the board reports on.
- Which entity pairs will trade intercompany, and who reconciles them monthly.
- Whether the chart of accounts is shared, and which segments carry the division view.
- The subsidiary access each finance role gets, and every exception with its reason.
- The date the structure was reviewed, and the name of the person who approved it.
