From the first blueprint to the next stage of growth.
Give your systems a shared picture of the business.
Give people the right NetSuite-connected experience for their work.
Focused applications for specific operational challenges.
Start with the workflows that make your industry different.
Useful answers for choosing, implementing and improving NetSuite.
What changed, why it matters, and what to review next.
Meet the people and approach behind CuriousRubik.
Adding a subsidiary to a live NetSuite account should be treated as a controlled extension of the operating model. Approve its legal identity, hierarchy, currency and reporting needs before creating the record. Then prove that transactions, integrations, roles and the first close work for the new entity without disrupting existing subsidiaries.
The subsidiary form is only the beginning. A new entity can expose assumptions in saved searches, approval rules, payment processes and integrations that were written when the account had a smaller perimeter.
Record the legal name, jurisdiction, parent relationship, base currency, operational start date and required reporting. Add tax registrations, accounting books, fiscal requirements and local document needs as applicable. Assign an accountable finance owner for each decision.
Distinguish a genuinely new legal entity from a new branch or analytical reporting requirement. Locations and other classifications may be appropriate for operational detail within an existing entity. The decision should follow the legal and accounting model rather than convenience on a report.
Retain the approved hierarchy diagram and the reason for the chosen parent. NetSuite creates subsidiaries in a parent-child structure, and some field choices are restricted after the first save. Hierarchy modifications can have serious reporting consequences, so do not rely on later cleanup as the design method.
Check the organization's OneWorld entitlement and the relevant subsidiary or country licensing with the account owner. Confirm the enabled tax model, accounting books, localization SuiteApps and features used by the new entity. Avoid assuming that the existing entity's setup covers a different jurisdiction.
Review the subsidiary settings and accounting preferences that require a deliberate choice. Compare the global template with the new entity's approved requirements and record justified differences. Keep unrelated account-wide changes out of the launch unless their effects have been assessed.
If Multi-Book Accounting is in scope, verify the supported process for associating the subsidiary with the required books and currencies. Treat book readiness as a separate acceptance item, rather than assuming it follows automatically from the subsidiary appearing in the list.
Identify accounts, departments, classes, locations, items, customers and vendors required for the new subsidiary. Check their subsidiary availability and transaction use. A correct subsidiary record is of little help if the first invoice cannot select the required customer or income account.
Review shared counterparties instead of automatically creating duplicates. Confirm which existing records can be used and which represent a different legal counterparty. Preserve approved local terms, tax information and document addresses.
Test default values. A shared customer or integration template may default to an older primary subsidiary. Make the intended transaction subsidiary explicit in the acceptance evidence, including what happens when a required mapping is absent.
Define who can enter, approve, report and administer the new entity's activity. Test local users, shared-service users and integration roles separately. Adding the entity to a business report should not automatically grant broad transaction access.
Check approval routing for purchase requests, vendor bills, journals and customer transactions used by the business. Include a case where the expected approver is unavailable. A rule that worked for existing entities can leave the new subsidiary's transactions without an owner.
Review external outputs such as invoice templates, payment instructions and customer-center visibility. The entity name, address and relevant registration details should come from the approved source, not a copied template belonging to another company.
Inventory every interface that filters, maps or defaults subsidiary. Include inbound order feeds, payroll summaries, expenses, bank files, reporting extracts and outbound invoices. Search for hard-coded identifiers and lists that exclude new entities.
Test rejected mappings and retry behavior. An unknown subsidiary should create an actionable exception rather than silently posting to the existing parent. Confirm that a corrected replay produces one intended transaction.
Record the cutover point for each source. If an acquired operation continues transacting in a legacy system temporarily, define which system owns each process and prevent duplicated opening transactions or payments.
Assume a fictional new subsidiary has opening cash of USD 100,000 and receivables of USD 40,000. Payables are USD 25,000, and approved opening equity is USD 115,000. In this simplified example, assets total USD 140,000 and liabilities plus equity also total USD 140,000.
The opening trial balance therefore balances, but that is not sufficient acceptance. The USD 40,000 receivable control must agree with the intended open customer items, and the USD 25,000 payable control must agree with the intended open vendor items. Confirm currency, due dates and customer or vendor references.
Next, enter a controlled test sale, supplier bill and receipt or payment through the actual process. Verify entity, classifications, approval, document output and ledger impact. Ensure the same transaction does not appear in an unrelated subsidiary's operational queue.
These values are hypothetical and omit other balances. The actual opening approach and any migration journals require approval by the accounting owner.
Identify the first reporting period, close tasks and reviewers. Test the new subsidiary's trial balance, receivables, payables, cash and relevant operational reconciliations. Include tax and statutory outputs where required by the approved scope.
For group reporting, verify consolidation context, currency treatment and any intercompany relationships. Elimination design should follow the actual group structure and transactions. A consolidated total can look reasonable while the new entity's local books remain incomplete.
Preserve expected results and actual evidence from the rehearsal. Resolve material differences before live transactions begin, and record any accepted limitation with an owner and a practical operating control.
The release pack should confirm design approval, master-data availability, access tests, integration tests, opening-balance reconciliation and first-close readiness. Identify outstanding issues by consequence rather than marking every checklist item green to meet a date.
After launch, review the first live transaction from each critical process and the first completed close. A CuriousRubik NetSuite implementation review can help turn subsidiary setup into a verified operating launch with clear evidence and ownership.
No. Master data, roles, approvals, integrations, documents and opening balances must support the entity. Test the first transactions and reporting outputs before releasing the new subsidiary for routine use.
Do not rely on that. Some subsidiary fields are restricted after creation, and hierarchy changes can have significant consequences. Approve the structure and applicable currencies before saving the initial setup.
Not automatically. Review shared-record capabilities and the legal counterparty identity. Reuse approved records where appropriate, while preserving entity-specific terms, tax information and transaction controls.
No. Reconcile supporting open items, due dates, currencies and operational records to the control accounts. A balanced total can still contain the wrong customers, vendors or duplicated documents.
Trace the first live transaction in each critical process and complete the first close reconciliation. This confirms that the approved design works with real users, source systems and reporting cutoffs.
