Splitting a NetSuite instance is the process of moving an acquired company off a shared, consolidated NetSuite environment and onto its own instance. It becomes necessary to split a NetSuite instance because the original consolidation was configured around the acquiring company’s processes rather than taking both businesses into account. While NetSuite supports multiple subsidiaries with different currencies, tax setups, approval workflows, and transaction forms in a single instance, it works best when configured for that structure from the very beginning of the M&A consolidation process.
There’s a pattern that happens before most instance splits. It’s rarely one dramatic failure. Instead, it’s often a year of small workarounds—manual payment checks, spreadsheets standing in for reports, configuration everyone already expects to rebuild—that eventually cost an organization more than finally taking on a proper split of NetSuite instances.
Why shared NetSuite instances can break down after M&A
When one company acquires another, the standard move is to consolidate both businesses onto the same NetSuite instance, and that’s a reasonable standard decision for a reason. NetSuite’s multi-subsidiary architecture is built for exactly this scenario.
The problem shows up when NetSuite gets configured around the parent company’s business rather than both businesses. One of our Charted Services clients lived this exact situation for about a year after being acquired. The setup they were forced on to didn’t reflect how their business actually ran:
- Accounts payable followed the parent company’s process, not theirs
- Billing worked differently than what their team was used to
- Their chart of accounts carried a long list of accounts they never used
- Saved reports that used to return results under a specific title stopped returning anything, even on an exact-title search
Separately, the merger itself introduced data problems unrelated to either company’s processes. This led to a handful of vendors ending up with duplicate records once the two companies’ data was combined.
The real cost: Workarounds that compound
None of these issues were severe enough on their own to justify a rebuild of a separate NetSuite setup. But stacked over a year, they added up to a team spending real time on manual checks and patchwork fixes, including:
- Manually confirming whether a bill had actually been paid, because the system’s records weren’t reliable
- Pulling data into spreadsheets because NetSuite’s reports didn’t reflect how the team tracked the business
- Building configurations they already suspected they’d have to rebuild once they got their own instance
That last point is often the biggest tell—when a team is investing time and effort into fixes they expect to throw away, the shared instance has stopped being a logical decision.
What triggers the decision to split
There’s usually no single event that forces the split. It’s more that every improvement made on the shared instance is effort that gets lost the moment the company splits off, and the team is worn down from working around a system never built with them in mind.
At some point, patching the current instance stops being worth it.
What changes in a proper NetSuite split, and what doesn’t
A well-run NetSuite split isn’t a copy-paste of the old setup onto new infrastructure. It’s a chance to replace inherited customization with what NetSuite already does natively. In the case of our client, that meant:
- Standard approval workflows instead of the custom ones built for the parent company
- A simpler, in-house invoicing method instead of the specialized third-party billing tool that came bundled with the parent’s instance
The goal isn’t to recreate what existed before; it’s to build the instance the acquired business needs to get back to an efficient process.
How to avoid needing a NetSuite split altogether
NetSuite can support two businesses with different processes on a single instance. But doing so efficiently requires someone to configures it that way from the start, factoring in the second business’s chart of accounts, workflows, and reporting built out on their own terms, rather than dropped into the parent company’s existing setup.
Skip that work during the initial consolidation, and the acquired business ends up having to work around someone else’s configuration instead of its own. Eventually, teams are forced back to manual fixes until the workaround cost eventually forces the conversation and a NetSuite separation becomes the only way forward for financial clarity and efficiency.
The Charted Services team is here to help you with all your M&A concerns around NetSuite, whether consolidating NetSuite instances (properly, from the start) or splitting a NetSuite instance to better serve all sides of the business. Speak to one of our NetSuite-certified experts today by contacting us here.
Frequently asked questions
When should you split a shared NetSuite instance after an acquisition? Consider a split when workarounds—manual reconciliation, spreadsheets replacing broken reports, configuration you already plan to rebuild—become routine rather than occasional. The trigger is usually cumulative cost, not a single failure.
Can NetSuite support two businesses with different processes in one instance? Yes. NetSuite’s multi-subsidiary architecture supports different currencies, tax setups, approval workflows, and transaction forms in a single instance. It works when the second business’s setup is configured intentionally from the start, not inherited from the parent company’s configuration.
What causes duplicate vendor records after a NetSuite consolidation? Merging two companies’ vendor data into one instance commonly creates duplicate vendor records, since each company’s data existed independently before consolidation. This is a data migration issue distinct from process or configuration mismatches.
Should a new NetSuite instance replicate the old configuration exactly? No. A split is an opportunity to replace custom-built workarounds with NetSuite’s native functionality, such as standard approval workflows and built-in invoicing, rather than recreating specialized customization that no longer fits the business.
