Most NetSuite decisions are reversible. You can add a field, rewrite a workflow, rebuild a report, change a form. A handful are not, or are reversible only at a cost so high that nobody ever does it.
Those are worth arguing about before go-live, at a stage when arguing is cheap. Here are the four that come back to bite hardest in a multi-subsidiary account.
The instinct when migrating is to bring the old chart across, because it is known and it reconciles. It is usually the wrong instinct, because most legacy charts encode in the account number what NetSuite handles with segments: department, class, location, and custom segments of your own.
An account called "Marketing salaries / UK / Digital" is three dimensions welded into one string. In NetSuite that is one salaries account plus three segment values, and the difference is that segments can be combined and filtered freely while account strings can only be listed.
This is hard to undo. Once a year of transactions is posted against a fine-grained chart, restructuring means either remapping history or accepting a discontinuity in every comparative report. The usual outcome is that nobody does it and the account lives with the wrong structure permanently.
The rule that has served well: an account should answer "what kind of money is this", and nothing else. Everything answering "whose", "where" or "which activity" belongs in a segment.
The hierarchy is not only a legal structure; it determines how consolidation rolls up, where eliminations happen, and what any given user can see. Getting it wrong is not fatal on day one, because with three subsidiaries everything is visible to everyone anyway. It becomes expensive at the first acquisition, when the natural place for the new entity is somewhere the current shape does not allow.
Two questions to settle before anything is created. First: is the hierarchy modelled on the legal entity structure, or on how you manage the business? They are frequently not the same, and the hierarchy can only be one of them, the other has to be a segment. Second: where do intercompany eliminations sit, and is there an explicit elimination subsidiary at each level that needs one? Retrofitting that later means reprocessing intercompany history.
If you need statutory and management reporting on different bases, different depreciation, different revenue timing, local GAAP against group IFRS, that is what multi-book is for, and it is far cleaner than the alternative of parallel spreadsheets that drift apart within two quarters.
The catch is that a secondary book added later does not populate itself with history. It starts from the point it was created. So the decision is effectively: do we want a second book with history, or a second book starting from a date. If the answer is the first, it has to be decided before the data loads, not after somebody asks for a comparative.
A subsidiary base currency cannot be changed once transactions exist. This one is genuinely permanent and it is the shortest item on this list because there is nothing to discuss beyond getting it right.
The trap is a subsidiary that is legally in one country but transacts almost entirely in another currency. The base currency should be the functional currency, the one the entity actually operates in, not necessarily the one of the country it is registered in. Getting this wrong produces translation noise on every consolidated report for the life of the account.
These four are not IT decisions and they are not finance decisions. They need the controller who will file the statutory accounts, whoever is responsible for management reporting, and someone who knows what the group might buy or sell in the next three years, in the same room for one afternoon. That meeting is far cheaper than any of the remediation projects it prevents, and in our experience it is the single highest-return hour of an implementation.
For balance, it is worth knowing what you can relax about. Forms, fields, workflows, saved searches, approval routing, roles and permissions, dashboards, PDF templates, and almost every customization are all changeable later at reasonable cost. Do not spend discovery agonising over an approval threshold; spend it on the four above.
The general test: if getting it wrong means changing a configuration, it is reversible. If getting it wrong means restating posted history, it is not. Sort your open questions by that test and the priority order writes itself.
Six questions about your business, and an indicative phase plan with the arithmetic shown.
Years of building on NetSuite: SuiteScript, SuiteFlow, SuiteQL, SuiteTalk, Advanced PDF templates and Celigo integrations. We write these up when a problem comes round for the third time.
Tell us what you are running today and where it is breaking down. Most calls run 20 to 30 minutes and end with a clear next step. We reply within one business day.