Designing NetSuite Intercompany Operations

The question is why intercompany accounting becomes hard even when the business logic is simple. One entity sells, funds, allocates, or recharges another. The accounting should follow. But in practice, every choice in the general ledger, subsidiary structure, item setup, and import process either reduces friction or compounds it.

What’s at stake is not only clean consolidation. It is the finance team’s ability to operate at month-end without rebuilding the same logic in spreadsheets. When intercompany flows are designed after the fact, close tasks become detective work: matching balances, explaining eliminations, tracing failed imports, and reconciling activity that should have been structured correctly upstream.

From first principles, the system needs to answer four questions consistently: who is transacting, what is being recorded, how it should eliminate, and how it enters NetSuite. A good setup does not make intercompany accounting effortless. It makes the work observable, repeatable, and auditable.

Start With the Operating Model

Before configuring NetSuite, the team needs to define the actual operating model. This is where many implementations move too quickly. They start with accounts and forms before agreeing on the flows.

A useful walkthrough begins by listing each intercompany activity:

• Management fees
• Shared services allocations
• Cost recharges
• Intercompany loans
• Inventory transfers
• Royalty or IP charges
• Centralized vendor payments
• Cash pooling or funding movements

For each flow, document the source entity, destination entity, frequency, currency, tax treatment, and whether the transaction should eliminate on consolidation. This becomes the control map for the rest of the design.

The key distinction is between commercial intercompany activity and funding or balance sheet activity. A recharge between subsidiaries may use intercompany revenue and expense accounts. A loan should use due to and due from accounts. A centralized payment may create a payable settlement pattern. Treating all of these as generic journal entries usually creates reconciliation issues later.

Design the Subsidiary and GL Structure Together

NetSuite’s OneWorld structure depends heavily on subsidiaries, currencies, and elimination relationships. The GL design should not be separate from that structure. It should reflect how the organization consolidates and how the accounting team works.

Subsidiary setup decisions

The subsidiary hierarchy should mirror legal ownership and reporting needs, not every management view. If management reporting requires regions, business units, or product lines, those are usually better handled through classifications such as departments, classes, locations, or custom segments.

Common decisions include:

• Whether dormant entities need full subsidiary setup
• Whether branches should be subsidiaries or locations
• Whether holding companies require their own transaction activity
• Which entities require base currency alignment
• Where elimination subsidiaries sit in the hierarchy

These decisions affect every intercompany transaction. A poor subsidiary hierarchy can force manual consolidations or unnecessary journals. A clean hierarchy makes eliminations and reporting easier to trust.

Chart of accounts decisions

The chart of accounts should give intercompany balances enough precision to reconcile without creating hundreds of accounts. A practical structure often separates:

• Intercompany receivables
• Intercompany payables
• Intercompany revenue
• Intercompany expense
• Intercompany interest income
• Intercompany interest expense
• Intercompany loan principal
• Intercompany clearing

The question is how much detail belongs in the account versus dimensions. If each counterparty receives its own account, the chart expands quickly. If all activity uses one account without entity-level tagging, reconciliation becomes harder.

In NetSuite, the entity, subsidiary, and intercompany partner fields can carry much of the counterparty logic. The GL account should describe the accounting nature of the balance. The partner field should describe who the other side is. This separation makes reporting more flexible and reduces account maintenance.

Use Intercompany Accounts Deliberately

Not every account should be marked as intercompany. Marking an account as intercompany should mean the balance is expected to eliminate or reconcile against another subsidiary.

For balance sheet accounts, the pairing logic matters. Due from Entity A should align with due to Entity B. If one side posts through an invoice and the other through a journal, the system can still support the accounting, but the reconciliation design must anticipate timing and source differences.

For income statement accounts, elimination behavior should be tested with realistic transactions. Revenue and expense eliminations can appear correct in simple tests but fail when departments, classes, currencies, or partial periods are involved.

A good design principle is this: only automate what the team can explain manually. If the finance team cannot describe why an intercompany revenue account eliminates in a given consolidation path, automation will not fix the ambiguity.

Build the Process Across Sessions, Not in One Meeting

A deep NetSuite intercompany setup usually benefits from multiple working sessions. Each session should have a clear output. This keeps the work operational rather than theoretical.

Session 1: Map flows and accounting outcomes

The first session is not about configuration. It is about accounting intent. The team should walk through each flow and define:

• Triggering event
• Source system or owner
• Debit and credit logic
• Counterparty entity
• Required approvals
• Timing at month-end
• Elimination expectation
• Reconciliation owner

The output is a transaction matrix. This matrix becomes the reference point for configuration and testing.

Session 2: Confirm GL and dimension design

The second session converts accounting intent into structure. This includes account choices, segment usage, naming conventions, and required fields.

A common example is shared services. The parent entity pays payroll, software, and professional fees, then allocates costs to operating subsidiaries. The team must decide whether the recharge is recorded as intercompany revenue and expense, a contra-expense, or a balance sheet clearing entry. Each option has different reporting consequences.

The right answer depends on policy, audit expectations, and management reporting. The important part is consistency. If one region uses revenue and expense while another uses clearing accounts, consolidation reporting becomes difficult to explain.

Session 3: Design import automation

The third session focuses on how transactions enter NetSuite. This is where operational discipline matters.

Import automation should specify:

• Source file format
• Required columns
• Validation rules
• Default values
• Error handling
• Posting period controls
• Approval routing
• Rollback or reversal process
• Audit trail requirements

For many teams, CSV import is the first step. More mature processes may use SuiteScript, middleware, or a data warehouse feed. The tool matters less than the control design.

An import should not simply load debits and credits. It should validate subsidiary, account, currency, department, class, counterparty, and period before posting. Failed rows should produce actionable errors, not vague import logs.

Design the Import Template Like a Product

The import template is part of the accounting system. It should be treated with the same care as a form or workflow.

A reliable template usually includes:

• External transaction ID
• Source system reference
• Posting date
• Posting period
• Subsidiary
• Counterparty subsidiary
• Currency
• Exchange rate handling
• Account
• Debit amount
• Credit amount
• Department, class, location, or custom segment
• Memo standard
• Intercompany partner
• Elimination flag or account logic

The external ID is especially important. Without it, duplicate prevention becomes manual. With it, the system can reject repeated loads or support controlled updates.

Memo standards also matter. A useful memo might include allocation month, source cost pool, and counterparty. A vague memo such as “IC entry” forces the reviewer to leave NetSuite and search elsewhere.