As highlighted by Oracle NetSuite, modifying the subsidiary hierarchy is a highly complex and sensitive operation. Oracle itself has stated that:
“The consequences of implemented modifications are outside the scope of any support made available to your organization by Oracle, and your organization is solely responsible for the effect of such modifications on your organization’s use of the product and for any costs or expenses arising from or related to such modifications, including but not limited to the cost of any required data fixes.”
Potential risks and impacts as outlined by Oracle include:
- Existing financial statements may be lost with no possibility of recovery
- Subsidiaries may be inactivated unintentionally
- Consolidated/Budget exchange rates may be irreversibly recalculated
- Elimination subsidiaries may be assigned incorrect parent subsidiaries
- Auto-elimination journals may post incorrectly
- “Include Children” filter may yield different subsidiary sets
- Role-based access restrictions may change unexpectedly
- Reports may provide inaccurate results across the hierarchy change date
- Custom scripts and workflows referencing subsidiaries may begin to fail
Due to the above, any changes to the subsidiary hierarchy should be approached with extreme caution. It is strongly recommended to:
- Conduct a thorough impact assessment across all modules (Financials, Reporting, Access Control, Customizations).
- Engage Oracle Support or a certified NetSuite partner for guidance and validation.
- Test all changes in a sandbox environment before any production deployment.
- Document all dependencies, including scripts, workflows, saved searches, and reports.
- Communicate with stakeholders to ensure awareness of potential reporting and access changes.
- Plan for post-change validation, including reconciliation of financials and testing of key processes.
Impact on Posting Periods
- Will changing the parent affect posted transactions if posting periods are open?
- Changing the parent subsidiary does not retroactively alter posted transactions, but it can affect how those transactions are reported, consolidated, or interpreted in the new hierarchy. For example:Consolidated financials may shift due to the new parent-child relationship.
- Historical data may appear under a different hierarchy in reports, depending on how the report handles subsidiary relationships.
- Do we need to close all posting periods before making the change?
- While not mandatory, it is strongly recommended to close all posting periods for the affected subsidiary before making the change. This helps:Prevent new transactions from being posted during the transition.
- Ensure data consistency and easier reconciliation post-change.
- Avoid complications with consolidated reporting and eliminations.
Impact on Reports
- Which reports are likely to be affected?
- Any report that references the subsidiary hierarchy or uses consolidation logic may be impacted. This includes:Financial Statements (Income Statement, Balance Sheet, Cash Flow)
- Consolidated Reports
- Budget vs. Actuals
- Elimination Reports
- Saved Searches with subsidiary filters
- Custom Reports or Workbooks using “Include Children” or hierarchical filters
- Should any reports be run or saved prior to the change?
- Yes, it is highly advisable to:Run and export key financial and operational reports before the change for audit and comparison purposes.
- Save snapshots of consolidated reports, elimination journals, and any custom reports that rely on the current hierarchy.
- Document saved search criteria that use subsidiary filters, especially those using “Include Children.”