This article is written for NetSuite finance leaders, controllers, and solution architects who operate multi-entity environments and are beginning to press against the practical limits of the traditional Subsidiary model. A working familiarity with NetSuite subsidiaries, intercompany accounting, and period-close consolidation will help, though I have kept the concepts approachable throughout.
TL;DR Summary
NetSuite’s OneWorld and Subsidiary architecture is the right foundation for the vast majority of multi-entity businesses. But when a company must maintain fully segregated financials for hundreds or thousands of legal entities, the subsidiary model becomes impractical to administer at that volume. This article describes how we represented legal entities as lightweight custom records (which we will call “Business Units” for simplicity), and then rebuilt the controls that subsidiaries provide natively: general ledger balancing, A/R and A/P integrity, intercompany transactions, and intercompany elimination. The result is stand-alone financials at scale, without giving up the accounting rigor that NetSuite enforces out of the box.
Introduction
Some businesses grow into a shape that NetSuite’s standard multi-entity tools were never sized for. Consider a company whose business model requires a separate legal entity, and a separate bank account for each customer it serves, with a firm expectation that every entity can produce its own clean, stand-alone financial statements. Now imagine that company is on a trajectory to scale into the thousands of such entities. The requirement for multi-entity is relatively advanced accounting but approachable: segregated books that each balance and report on their own. The scale is what makes it interesting.
In this article, I walk through a real client engagement in which none of the traditional options fit, and we instead modeled legal entities as custom records. The harder and more interesting work came next: rebuilding the guardrails that subsidiaries provide, from keeping every transaction in balance and preventing A/R and A/P from crossing entity lines, to handling intercompany activity and automating elimination at period close. The same pattern can apply to more conventional environments as well.
Where OneWorld and Subsidiaries Excel
To be clear, NetSuite’s OneWorld architecture for multi-entity accounting is solid. Its subsidiary boundaries are immutable, so each entity operates, records financial activity, and reports independently, while still consolidating up through one or more levels of parent entities. The Intercompany Framework and Elimination features are strong. The good news is that nearly all of the client situational problems I have encountered over the years in multi-entity environments traced back to setup decisions or weak practices, not gaps in NetSuite functionality.
That said, some situations call for an approach beyond traditional Subsidiaries. One is simple volume: out of the box, NetSuite supports up to 250 subsidiaries, and more can be added with special provisioning, though it is somewhat uncharted territory. Once you reach into the high hundreds or thousands, though, a subsidiary-based structure likely becomes difficult to administer and maintain.
Prolecto Thought Leadership and NetSuite Subsidiary Alternatives
Our thinking on alternatives to the standard subsidiary model has evolved over the years. The articles below offer useful background:
- 2020: Streamlined Transaction Alternative to NetSuite OneWorld Multi-Entity Accounting: A period-end clearing model that uses custom transactions and balancing segments to consolidate intercompany activity monthly, cutting record volume while preserving separate financials for each entity.
- 2017: How To: NetSuite Subsidiary Alternative to OneWorld: How to produce entity-level financial statements without licensing OneWorld, by using a custom GL segment to stamp every transaction with its legal entity.
- 2025: Learn the Hidden Mechanics Behind NetSuite’s Consolidated Financial Reports: A look under the hood at how NetSuite consolidates multi-entity financials through report-time currency translation, and the reconciliation challenges that create.
- 2020: Learn How to Import NetSuite Subsidiaries: A practical guide to bulk-loading subsidiaries, useful background for anyone weighing the administrative weight of a large subsidiary structure.
When Balancing Segments Are the Better Fit
NetSuite offers a feature called “Custom Balancing Segments” that can serve as an alternative to Subsidiaries, and it comes with its own set of trade-offs. I don’t recommend reaching for Balancing Segments simply because they appear less complex than subsidiaries. In some respects, they are more lightweight and flexible; in others, they introduce complexity of their own. I plan to dedicate a future article to the differences and to best practices for working with them.
I do recommend Balancing Segments over Subsidiaries in scenarios where the segments represent operating units or business divisions that are not distinct legal entities but are genuinely part of one company, while each still needs a full, stand-alone set of financials. This is common in non-profit “Fund Accounting,” where compliance and donor fiduciary duties require that assets be firmly segregated. They can also be appealing when a company plans to restructure its legal entities into a single entity in the near future and needs only a short-term mechanism to produce separate financial statements. NetSuite does not allow subsidiaries to be merged, so the difficulty of later collapsing to a single entity is a strong argument for using segments, which can simply be deactivated when the time comes.
When subsidiaries are impractical, native or custom segments are often the next best way to represent legal entities, and the Balancing Segment feature does a good job of preserving general ledger fidelity. Even so, performance can become a concern once the environment requires thousands or tens of thousands of records.
Modeling Legal Entities as Custom Records
We have a client whose industry requires them to set up a separate legal entity to track the business activity, assets, and liabilities tied to each of their customers. Every customer has a corresponding legal entity and bank account, and each must be able to produce clearly segregated financial statements. The client is on a growth trajectory that will likely scale into the thousands of legal entities. After weighing the options among Subsidiaries, native segments, and custom segments, we concluded that none of the traditional approaches would fit well, and that each risked performance problems down the road.
Instead, we designed a system built on a custom record to represent each legal entity. Custom records are lightweight and highly malleable, so they model the structures the company needed without the performance overhead the other options carried.
That decision shifted the challenge away from the record itself and toward building a control structure that would enforce all of the required boundaries and enable consolidation.
(Note: For the rest of this article, I use the term “Business Unit” to refer to a legal entity that requires independent financial reporting.)
Rebuilding Subsidiary Controls from Scratch
To make custom records viable, we needed to reproduce the controls that NetSuite enforces natively for subsidiary accounting. We began by cataloging that built-in functionality, so we could then work through how to deliver each piece against a custom record.
The areas we needed to solve were:
- General ledger balancing
- A/R and A/P integrity
- A broad controls framework
- Custom reporting
- Intercompany transactions
- Intercompany elimination
Enforcing General Ledger Balance
The most fundamental control, ensuring debits equal credits for any Business Unit, comes from placing the field that points to the custom record at the transaction header level only. NetSuite enforces an ironclad constraint that every transaction must balance to zero, debits equal to credits. Any field with a 1:1 relationship to the transaction inherits that guarantee: report against it, and debits and credits will always balance. The challenge is making sure the field appears on every transaction type, is always populated, and is always populated with the correct value.
That calls for controls on three fronts: making the field mandatory in the UI, adding stopgap measures for the CSV-imported and integrated transactions that bypass the UI, and putting detection reporting in place to catch any transaction where the Business Unit field comes through NULL.
Keeping A/R and A/P Within Business Unit Lines
While the header-level control keeps each transaction’s debits and credits in balance, some scenarios require controls that span multiple transactions. Accounts Receivable and Accounts Payable are the clearest examples. A Customer Payment should not be applied against an Invoice in a different Business Unit, and the same holds for Vendor Payments against Vendor Bills. NetSuite has no native control that blocks this, so a scripted control is required. Incidentally, one of the nice features of Custom Balancing Segments is that while it allows cross-segment payments, it has options for automatically creating inter-segment balancing entries for cross-segment Accounts Receivable and Accounts Payable applications.
Designing the Intercompany Landscape
Here’s where things get interesting. Companies with high intercompany volume tend to run into a handful of recurring scenarios. Two applied to this client:
- Arm’s-length intercompany transactions: one Business Unit sells to another, with the selling unit recognizing revenue and the buying unit recognizing an expense (or an asset, such as inventory).
- Shared services: one Business Unit incurs overhead or expense on behalf of others and needs to pass it along.
A related situation is centralized treasury, where cash is received or disbursed through one Business Unit’s bank on behalf of another. Rather than build a separate treasury mechanism, we found it cleaner to assign ownership of the underlying payable or receivable to the Business Unit that ultimately pays or receives. That choice reframes the activity as an intercompany flow and brings it into the same shared-services pattern, so it is handled by the same tooling rather than as a special case.
Two needs run through all of this. First, whatever the scenario, intercompany activity must stay in balance across Business Units: an amount booked on one unit needs its mirror on the counterparty. Second, the shared-services cases need tooling to allocate the cost and generate the intercompany entries in the first place. We built for both, starting with the balancing control that underpins everything else.
Keeping Both Sides of Intercompany in Balance
Both sides of an intercompany transaction should tell parallel versions of the same story: a payable on one Business Unit, an equal and offsetting receivable on the other. This holds for every intercompany transaction, whatever produced it. Yet it is not something NetSuite guarantees on its own, even with native subsidiaries. Each transaction must balance internally, but nothing matches the payable on one entity to a receivable on its counterparty, and in a high-volume environment the two sides can easily drift apart. (When intercompany accounts fall out of balance across entities, the gap surfaces in the “CTA-Elim” account during month-end elimination; see my previous article on the topic: Intercompany Account Balance Troubleshooting)
To close that gap, we created a parent record that links the two sides of each intercompany transaction, along with controls ensuring that any amount booked on one Business Unit carries a corresponding amount on the counterparty. The visualization and screenshot below shows how this works in practice.
We also required that any posting to an intercompany account be tagged with its counterparty Business Unit, so that every intercompany balance is traceable to the specific unit it offsets. That tagging makes the balancing check possible and feeds directly into the elimination process later.
Handling Shared Services and Centralized Treasury
With cross-entity balancing guaranteed, the shared-services scenario still needs tooling of its own. Here, one Business Unit incurs expenses that belong to others. Centralized rent or payroll is a common example: a management Business Unit pays the cost, but the units that benefit need to record their share and reimburse it.
The centralized-treasury case fits here as well. As noted earlier, where cash is received or disbursed through one Business Unit’s bank on behalf of another, we assign ownership of the underlying payable or receivable to the unit that bears it, which turns the activity into the same shared-services pattern.
Either way, the system needs to do two things: allocate the shared expense to the correct Business Unit, and record the corresponding intercompany impacts.
In a traditional OneWorld environment, or one using dimensions or custom segments, there are established options for automating this. NetSuite offers a SuiteApp called “Transaction Line Distribution“, and NetGain has a solution “Shared Transactions“. Both of those options act on the source transactions themselves to generate the proper intercompany routing. NetSuite also provides a periodic-allocation tool for businesses that prefer to assess the total impact of shared transactions across a period and then allocate to the appropriate entities.
To replicate the shared services model in NetSuite for our Business Unit custom record, we built a workbench that was driven by the shape of upstream transactions. It lets the client net out and generate the equivalent intercompany payables and receivables across Business Units in a few clicks (see the screenshot below).
Netting of intercompany receivables and payables takes place in the background, where all matching amounts within the same subsidiary pair are netted into a single net payable or receivable. The source transactions are linked to the resulting intercompany entries using a record that sits in the background, allowing a 360-degree view of source-to-target entries.
The end result is a tightly controlled, transparent intercompany allocation process flow. It’s easy to envision the same approach adapted to more traditional environments where legal entities are represented by Subsidiaries or Custom Balancing Segments.
Elimination Workbench: Transparent Automation for Period Close
The final capability we needed was a way to eliminate intercompany balances at consolidation. We mirrored NetSuite’s consolidation structures by creating a dedicated “elimination” Business Unit and by creating a flag on the account record to indicate which accounts are subject to elimination. Because our client’s requirements were more contained than a full intercompany framework, we could drive elimination with straightforward, account-driven logic rather than tagging individual transactions.
We then built a workbench that lets the user see the amounts eligible for elimination and enforces cross-Business Unit balancing, so lopsided eliminations cannot occur. Expandable summary rows reveal the detail within each Business Unit, so the user can see exactly what they are posting before they post the eliminating entries.
Custom AI-Driven Workbenches
It is worth noting how these workbenches came to be. Both the shared-services and elimination tools were built through AI-augmented development (in this case, we used Claude Code), pairing our NetSuite and accounting expertise with AI to design, generate, and refine the underlying logic and interfaces faster than conventional development would allow. That shift matters beyond this one engagement. Custom tooling that was once too costly to justify against off-the-shelf features is becoming practical to build, and we see this pattern emerging across our work: the balance is tipping toward designing systems around what the business actually needs, rather than around what the platform makes easy. Consider reading Marty Zigman’s recent article, NetSuite, AI, and the Discipline of Building Serious Business Systems. The Business Unit architecture described here is an early example of what that makes possible.
Conclusion: Designing Around the Business
NetSuite’s subsidiary architecture remains the right choice for most multi-entity businesses. But when scale or structure pushes past what subsidiaries were designed for, the platform is appropriately malleable to model legal entities another way, and disciplined enough to let you rebuild the controls that keep the books honest. This is one of the reasons we highly value the NetSuite Platform. It allows us to listen carefully to our clients’ ambitions, model their challenge well, and bring to life the experience and logic they always wanted in NetSuite. As AI-augmented development lowers the cost of building purpose-fit tooling, we expect to see more solutions shaped around the business rather than around the platform.
If this article resonates, consider subscribing to receive notifications for new posts. And if you are facing multi-entity challenges that stretch beyond what subsidiaries can handle, let’s have a conversation.
