NetSuite Intercompany Transactions and Eliminations

The Accounting Foundation: What Must Be Eliminated and Why

Before diving into NetSuite configuration, it's essential to understand what consolidation accounting requires at the theoretical level. The elimination requirement isn't arbitrary. It flows directly from the definition of consolidated financial statements.

Consolidated financial statements present the parent company and all its subsidiaries as if they were a single economic entity. From this definition flows a fundamental rule: transactions between members of the consolidated group must be removed entirely, because they represent internal transfers within a single entity, not transactions with external parties.

Types of Intercompany Transactions

Intercompany Sales and Purchases (Goods and Services)

When one subsidiary sells goods or services to another, the seller records revenue and the buyer records an expense (or inventory/asset). At the consolidated level, both the revenue and the corresponding expense must be eliminated, because no transaction with an external party occurred.

For example: US Parent manufactures goods and sells them to UK Subsidiary at a transfer price of $100,000. US Parent records $100,000 revenue. UK Subsidiary records $100,000 cost of inventory. At consolidation, both are eliminated.

Intercompany Profit in Inventory

When intercompany-transferred goods remain in the buyer's inventory at period-end, the seller's profit embedded in the transfer price has not yet been realized through an external sale. That unrealized intercompany profit must be eliminated.

Continuing the example above: if UK Subsidiary has $30,000 of the transferred goods remaining in inventory (valued at transfer price), and the US Parent's cost was $70,000 on the full $100,000 (30% margin), the unrealized profit in ending inventory is $30,000 x 30% = $9,000. This must be eliminated by reducing inventory and increasing COGS.

Intercompany Loans and Advances

When one subsidiary lends funds to another, the lender records a receivable (asset) and the borrower records a payable (liability). At consolidation, both the intercompany receivable and the intercompany payable must be eliminated. An entity cannot owe money to itself. Interest income on the lender's side and interest expense on the borrower's side are also eliminated.

Intercompany Dividends

When a subsidiary pays a dividend to its parent, the parent records dividend income and the subsidiary records a reduction in retained earnings. At consolidation, the dividend income in the parent is eliminated against the retained earnings reduction in the subsidiary.

Intercompany Management Fees, Royalties, and Allocations

Management fees, IP royalties, shared service charges, and cost allocations flowing between entities create revenue/income in the charging entity and expense in the receiving entity. Both sides must be eliminated at consolidation.

Intercompany Fixed Asset Transfers

When a subsidiary transfers a fixed asset to another subsidiary, the selling entity may record a gain or loss. At the consolidated level, no external transaction occurred. The asset is still within the group. Any intercompany gain or loss must be eliminated, and the asset must be carried at its original consolidated cost basis.

The Consolidation Elimination Requirement

At consolidation, the following eliminations are always required:

• Intercompany sales: Eliminate revenue (seller) and COGS (buyer) from the P&L.
• Intercompany profit in inventory: Reduce inventory on the balance sheet and increase COGS.
• Intercompany loans: Remove IC receivable (asset) and IC payable (liability) from the balance sheet.
• Intercompany interest: Eliminate interest income (lender) and interest expense (borrower) from the P&L.
• Intercompany management fees: Eliminate management fee income (charger) and management fee expense (receiver) from the P&L.
• Intercompany dividends: Eliminate dividend income (parent) from the P&L. Reduce retained earnings (subsidiary) on the balance sheet.
• Intercompany fixed asset transfers: Eliminate gain/loss on transfer from the P&L. Adjust the asset to original cost basis on the balance sheet.
• Intercompany investment: Eliminate the parent's investment in subsidiary against the subsidiary's equity on the balance sheet.

The investment elimination (eliminating the parent's investment in the subsidiary against the subsidiary's equity) is handled at the consolidation level and is a separate process from operational intercompany transaction management. This is the foundational consolidation entry and is discussed further in the consolidated reporting section below.

Common GAAP and IFRS Considerations

US GAAP (ASC 810): Full consolidation of majority-owned subsidiaries. Proportionate consolidation is generally not permitted. Non-controlling interests (minority interests) are presented as a component of equity, not as a liability.

IFRS (IFRS 10): Control-based consolidation model. Similar in most practical respects to US GAAP consolidation for most corporate structures. Non-controlling interests are presented as equity.

Transfer Pricing (Both GAAP and IFRS): Intercompany transactions must be conducted at arm's-length prices for tax purposes (OECD Transfer Pricing Guidelines, country-specific regulations). The accounting consolidation elimination does not replace transfer pricing compliance. Both are required independently.

Downstream vs. Upstream Transfers: The direction of an intercompany transfer (parent-to-sub vs. sub-to-parent) can affect how unrealized profit eliminations are allocated between controlling and non-controlling interests. For simplicity, this guide assumes wholly-owned subsidiaries (100% ownership) unless noted otherwise.

NetSuite OneWorld: Architecture and Prerequisites

Intercompany functionality in NetSuite is a OneWorld-exclusive feature set. OneWorld must be licensed and configured before any intercompany processing can occur.

Subsidiary Hierarchy Design

The subsidiary hierarchy is the structural foundation of all OneWorld functionality. Every intercompany transaction, elimination, and consolidation report depends on the subsidiary hierarchy being correctly designed.

Navigate to Setup > Company > Subsidiaries > New.

Key Hierarchy Design Principles:

Legal Entity Alignment. Each subsidiary record in NetSuite should correspond to a distinct legal entity. Don't create subsidiaries for business units, cost centers, or reporting segments that are not separate legal entities. Use Departments, Classes, or Locations for those.

Ownership Hierarchy Reflects Legal Ownership. The parent-child relationships in the subsidiary hierarchy should mirror the legal ownership structure. If US Parent owns 100% of UK Subsidiary and 60% of German JV, the hierarchy should reflect this.

Elimination Subsidiary Placement. Elimination subsidiaries (discussed later in this guide) are created as children of the consolidating parent. Their placement determines at which level eliminations are performed in a multi-tier hierarchy.

Currency Assignment. Each subsidiary has a functional currency. This determines how transactions in other currencies are translated for that entity's standalone financial statements. Currency assignment cannot be changed after transactions are posted.

Here's an example of a typical subsidiary hierarchy:

Global Holdings Inc. (USD) -- Top-Level Consolidation Entity
├── US Operations LLC (USD)
│   ├── US Sales Corp (USD)
│   └── US Manufacturing LLC (USD)
├── UK Holdings Ltd (GBP)
│   ├── UK Trading Ltd (GBP)
│   └── Ireland Services Ltd (EUR)
├── APAC Holdings Pte Ltd (SGD)
│   ├── Singapore Operations (SGD)
│   └── Australia Pty Ltd (AUD)
└── [Elimination] Global Eliminations (USD)
    ├── [Elimination] Americas Eliminations (USD)
    └── [Elimination] EMEA Eliminations (GBP)

A critical warning: Subsidiary hierarchy changes after go-live are extremely disruptive. They affect historical reporting, consolidation, and intercompany configurations. Design the hierarchy carefully before going live and involve both Finance and Tax in the design review. A tax advisor should review the hierarchy to ensure it does not create unintended permanent establishment or transfer pricing complications.

Intercompany Accounts in the Chart of Accounts

A well-designed Chart of Accounts for a OneWorld implementation includes dedicated intercompany accounts that clearly identify balances as intercompany, are excluded from external financial statement presentation (consolidated out), and enable efficient reconciliation and matching between entities.

Balance Sheet Accounts:

• Intercompany Receivable (by Subsidiary): Other Current Asset. Amounts owed by a specific related entity.
• Intercompany Loan Receivable (by Subsidiary): Non-Current Asset. Long-term intercompany loans.
• Intercompany Payable (by Subsidiary): Other Current Liability. Amounts owed to a specific related entity.
• Intercompany Loan Payable (by Subsidiary): Non-Current Liability. Long-term intercompany loan obligations.

Income Statement Accounts:

• Intercompany Revenue (by Type): Revenue from intercompany sales.
• Intercompany Management Fee Income: Management fees charged to subsidiaries.
• Intercompany Royalty Income: IP royalties received from subsidiaries.
• Intercompany Management Fee Expense: Management fees paid to parent.
• Intercompany Royalty Expense: IP royalties paid to IP-holding entity.
• Intercompany Interest Income: Interest on intercompany loans.
• Intercompany Interest Expense: Interest on intercompany loans.

I'd recommend creating separate accounts for each intercompany relationship where the volume warrants it. For large groups, maintaining separate "IC Receivable -- US Parent" and "IC Receivable -- UK Subsidiary" accounts (rather than a single "IC Receivable") dramatically simplifies reconciliation and elimination.

In NetSuite, intercompany accounts should be configured so they're included in elimination rules. This is managed through the Elimination configuration rather than a field on the account record itself.

Intercompany System Accounts

NetSuite OneWorld uses two system-level accounts for automated intercompany balancing:

• Intercompany Payables Account (System): Used by NetSuite to record the automatic offsetting credit when a multi-subsidiary journal entry creates a due-to/due-from balance between entities.
• Intercompany Receivables Account (System): The corresponding debit account on the receiving entity's side.

These system accounts are configured at Setup > Accounting > Accounting Preferences > Intercompany tab. They must be set before any intercompany transactions are posted.

A best practice here: map the system intercompany accounts to dedicated "Intercompany Clearing" accounts in your COA, separate from the manually managed intercompany payable/receivable accounts. This makes it clear which intercompany balances were system-generated (from journal entries) vs. which arose from billing transactions.

Enabling Intercompany Features

Step 1: Confirm OneWorld License. OneWorld must be licensed. Single-subsidiary NetSuite accounts do not have intercompany functionality.

Step 2: Enable Intercompany Features. Navigate to Setup > Company > Enable Features > Accounting tab. The key features to enable:

• Intercompany: Enables basic intercompany journal entries and subsidiary-to-subsidiary transactions.
• Intercompany Netting: Enables the netting settlement process.
• Intercompany Auto-Balancing: Enables automatic due-to/due-from generation on multi-subsidiary journal entries.

Step 3: Configure Intercompany Preferences. Navigate to Setup > Accounting > Accounting Preferences > Intercompany tab. Key settings include:

• Intercompany Payables Account (system account for auto-balancing)
• Intercompany Receivables Account (system account for auto-balancing)
• Default Intercompany Exchange Rate Type

Step 4: Configure Elimination Subsidiaries (covered in the eliminations section below).

Intercompany Customer and Vendor Setup

For intercompany billing transactions (sales orders, invoices, purchase orders, vendor bills), each subsidiary that transacts with another must have corresponding customer and vendor records representing the counterparty entity.

Intercompany Customer Record: When Subsidiary A sells to Subsidiary B, Subsidiary B must exist as a Customer record in Subsidiary A's books.

Navigate to Lists > Relationships > Customers > New. Key fields:

• Name: Use a clear naming convention (e.g., "UK Trading Ltd [IC]"). The [IC] suffix prevents confusion with external customers of the same name.
• Subsidiary: The subsidiary that owns this customer record (Subsidiary A in this example).
• Currency: The transacting currency between the two entities.
• Intercompany: Check this flag. It marks the customer as an intercompany relationship and enables intercompany transaction matching.

Intercompany Vendor Record: When Subsidiary B receives the invoice from Subsidiary A, Subsidiary A must exist as a Vendor record in Subsidiary B's books.

Navigate to Lists > Relationships > Vendors > New. Key fields:

• Name: Consistent naming with the customer record (e.g., "US Operations LLC [IC]").
• Subsidiary: Subsidiary B.
• Intercompany: Check this flag.

Intercompany Relationships Configuration

NetSuite's Intercompany Relationships feature formally links Customer and Vendor records as intercompany counterparts. This linkage enables automated matching and elimination processing.

Navigate to Setup > Accounting > Intercompany Preferences > Intercompany Relationships. For each intercompany trading pair, you'll configure:

• Selling Subsidiary: The entity that invoices.
• Buying Subsidiary: The entity that receives the invoice.
• Intercompany Customer (on Selling Sub): The customer record representing the buying entity.
• Intercompany Vendor (on Buying Sub): The vendor record representing the selling entity.
• Elimination Subsidiary: Which elimination entity processes the elimination entries for this pair.

Properly configured Intercompany Relationships are required for NetSuite's automated elimination process to function correctly. In practice, incomplete or incorrect relationship configuration is the most common cause of elimination failures.

Intercompany Journal Entries

Intercompany journal entries are used for transactions that can't be processed as billing documents: intercompany cost allocations, management fee accruals, equity transactions, and corrections.

A standard journal entry in NetSuite is posted to a single subsidiary. An intercompany journal entry spans multiple subsidiaries. It creates entries on the books of two or more entities simultaneously.

Navigate to Transactions > Financial > Make Intercompany Journal Entries.

The intercompany journal entry form differs from a standard journal entry in two key ways. First, each line has a Subsidiary field, allowing different lines to be assigned to different entities. Second, NetSuite enforces balance at the subsidiary level, automatically creating offsetting due-to/due-from entries between entities.

Example: Management Fee Charge from US Parent to UK Subsidiary

The user-entered lines:

• Line 1: Management Fee Income [IC], US Parent, Credit $10,000
• Line 2: Management Fee Expense [IC], UK Subsidiary, Debit $10,000

NetSuite automatically creates the balancing entries:

• Auto Line 3: IC Receivable (System), US Parent, Debit $10,000
• Auto Line 4: IC Payable (System), UK Subsidiary, Credit $10,000

The result: US Parent has income of $10,000 and a receivable of $10,000 from UK Subsidiary. UK Subsidiary has an expense of $10,000 and a payable of $10,000 to US Parent. At consolidation, all four lines are eliminated.

Due To / Due From Accounts

The "Due To" and "Due From" accounts are the intercompany balance sheet accounts that accumulate outstanding intercompany obligations between entities. They're the intercompany equivalent of accounts payable and receivable.

• Due From (Asset): Amounts owed to the recording entity from a related entity. A receivable from an intercompany counterpart.
• Due To (Liability): Amounts owed by the recording entity to a related entity. A payable to an intercompany counterpart.

You have several design options for these accounts:

• Option A: Single Due To / Due From Accounts. One "Due From -- Intercompany" asset account and one "Due To -- Intercompany" liability account. Simpler COA, but requires sub-entity-level reporting via saved searches to reconcile individual intercompany relationships.
• Option B: Entity-Specific Due To / Due From Accounts. "Due From -- US Parent," "Due From -- UK Subsidiary," etc. More COA accounts, but intercompany reconciliation is straightforward. Each account's balance should be zero at consolidation.
• Option C: Single Clearing Account with Segment Tagging. A single "Intercompany Clearing" account with Class or Custom Segment tagging to identify the counterparty. Allows flexible reporting without account proliferation.

My recommendation: for groups with 5 or fewer intercompany relationships, entity-specific accounts are preferred for simplicity. For groups with 10+ intercompany relationships, a single clearing account with Class tagging is more maintainable.

Multi-Subsidiary Journal Entries

NetSuite allows journal entries that span more than two subsidiaries simultaneously. This is useful for cost allocations that must be distributed across multiple entities in a single journal entry.

For example, a shared infrastructure cost of $60,000 allocated across three subsidiaries:

• Line 1: Infrastructure Expense, US Sales Corp, Debit $20,000
• Line 2: Infrastructure Expense, UK Trading Ltd, Debit $25,000
• Line 3: Infrastructure Expense, Singapore Operations, Debit $15,000
• Line 4: IT Cost -- Intercompany Income, US Parent (shared services center), Credit $60,000

NetSuite creates three automatic balancing pairs (one for each subsidiary receiving a charge) against the US Parent's receivable position.

Automated Balancing Entries

NetSuite's automated balancing for intercompany journal entries is governed by the accounts configured at Setup > Accounting > Accounting Preferences > Intercompany tab.

Here's how it works:

• The user enters journal lines on multiple subsidiaries.
• Upon save, NetSuite calculates the net debit/credit imbalance for each subsidiary.
• For each subsidiary that is not in balance, NetSuite creates an offsetting entry to the configured Intercompany Receivables or Payables system account.
• The sum of all auto-balancing entries nets to zero at the group level.

An important distinction: the automated balancing entries use the system intercompany accounts (configured in Accounting Preferences), not the manually managed entity-specific IC accounts in your COA. This is intentional. It provides a clean separation between system-generated intercompany balances and those arising from billing transactions.

Intercompany Sales and Purchases (Billing Transactions)

For intercompany transactions that involve the sale and purchase of goods or services, billing transactions (sales orders, invoices, purchase orders, vendor bills) are preferred over journal entries. Billing transactions create a formal, document-controlled audit trail, support matching (the invoice from the seller can be matched to the vendor bill on the buyer's side), feed inventory and fulfillment workflows, and support three-way matching (PO to receipt to vendor bill).

Intercompany Sales Orders and Invoices

When Subsidiary A sells to Subsidiary B, the process on Subsidiary A's side mirrors a standard customer sale.

Step 1: Create the Intercompany Sales Order. Navigate to Transactions > Sales > Enter Sales Orders > New. Select the intercompany customer record representing Subsidiary B. Set the subsidiary to Subsidiary A (the selling entity). Add the items being transferred at the transfer price (at arm's length per your transfer pricing policy) in the agreed intercompany billing currency.

Step 2: Fulfill and Invoice. Process fulfillment (if inventory) and create the invoice per your standard workflow. The invoice posts to Subsidiary A's AR and Revenue accounts.

The GL impact on Subsidiary A (the seller):

• Debit: IC Accounts Receivable -- Sub B, $100,000
• Credit: Intercompany Revenue, $100,000

Intercompany Purchase Orders and Vendor Bills

On Subsidiary B's side, the receipt of the intercompany invoice is processed as a vendor bill.

Step 1: Create Intercompany Purchase Order (Optional). Navigate to Transactions > Purchases > Enter Purchase Orders > New. Select the intercompany vendor record representing Subsidiary A, with the subsidiary set to Subsidiary B.

Step 2: Create or Receive Vendor Bill. When the invoice from Subsidiary A is received, create a vendor bill in Subsidiary B referencing the intercompany vendor.

The GL impact on Subsidiary B (the buyer):

• Debit: Inventory / Expense, $100,000
• Credit: IC Accounts Payable -- Sub A, $100,000

At consolidation, the eliminations work like this: IC Revenue ($100,000 credit) goes to zero. COGS/Expense ($100,000 debit) goes to zero. IC AR ($100,000 debit) goes to zero. IC AP ($100,000 credit) goes to zero. Net consolidated impact: zero. Correct, because no external transaction occurred.

Intercompany Item Fulfillment and Receipts

For inventory transfers between subsidiaries, the fulfillment (from the seller's warehouse) and item receipt (into the buyer's warehouse) must both be processed to remove inventory from the selling subsidiary's balance sheet and add it to the buying subsidiary's balance sheet at the transfer price.

The typical inventory transfer workflow:

• Subsidiary A creates a Sales Order to Subsidiary B.
• Subsidiary A fulfills the order (Item Fulfillment transaction). Inventory leaves Subsidiary A's books.
• Subsidiary B creates a Purchase Order (or receives the vendor bill).
• Subsidiary B processes an Item Receipt. Inventory enters Subsidiary B's books at transfer price.

Intercompany Profit in Inventory: If the transfer price includes a profit margin and any transferred inventory remains unsold at period-end, an elimination entry is required to remove the intercompany profit embedded in the buyer's inventory balance:

• Debit: Intercompany Revenue (or COGS reduction), $9,000
• Credit: Inventory (reduce to original cost), $9,000

This elimination is typically calculated manually or via a saved search that identifies the ending inventory quantity from intercompany transfers and applies the seller's margin rate.

Drop-Ship Intercompany Transactions

Drop-ship scenarios, where a subsidiary takes a customer order but another subsidiary fulfills it directly, are common in multi-entity distribution businesses. The accounting involves three entities: the external customer, the "selling" subsidiary (the one with the customer relationship), and the "fulfilling" subsidiary (the one with the inventory).

The transaction flow:

• Customer orders from Subsidiary A (external customer to Subsidiary A).
• Subsidiary A places a purchase order on Subsidiary B for fulfillment.
• Subsidiary B ships directly to the customer.
• Subsidiary B invoices Subsidiary A at transfer price.
• Subsidiary A invoices the customer at external selling price.

On Subsidiary B's side (the fulfiller): it ships inventory (reduces inventory, records COGS) and issues an IC invoice to Sub A, debiting IC AR from Sub A and crediting IC Revenue.

On Subsidiary A's side (the selling entity): it records the IC purchase (Debit Inventory or COGS directly, Credit IC AP to Sub B) and issues an external customer invoice (Debit AR, Credit Revenue).

At consolidation, you eliminate IC Revenue (Sub B to Sub A) against IC COGS (Sub A), and eliminate IC AR / IC AP. The external customer revenue and COGS remain in the consolidated P&L.

GL Impact of Intercompany Billing

Here's a summary of the full GL impact of a complete intercompany billing cycle:

Subsidiary A (Seller), at Invoice:

• Debit: IC Accounts Receivable -- Sub B, $100,000
• Credit: Intercompany Revenue, $100,000

Subsidiary B (Buyer), at Vendor Bill:

• Debit: Inventory / COGS / Expense, $100,000
• Credit: IC Accounts Payable -- Sub A, $100,000

Consolidated Elimination Entries:

• Debit: Intercompany Revenue (Sub A), $100,000
• Credit: Inventory / COGS / Expense (Sub B), $100,000
• Debit: IC Accounts Payable -- Sub A (Sub B), $100,000
• Credit: IC Accounts Receivable -- Sub B (Sub A), $100,000

Net consolidated result: revenue, expense, AR, and AP all eliminated. The balance sheet and P&L show no trace of the internal transaction.

Transfer Pricing: The Business and Accounting Context

Transfer pricing, the prices at which related entities transact with each other, sits at the intersection of accounting and tax. The price set for intercompany transactions determines three things: the profitability of each subsidiary (which affects local tax liabilities), whether the arrangement complies with tax regulations (most jurisdictions require arm's-length pricing), and the financial statement presentation of each subsidiary's standalone results.

Tax authorities in virtually every major jurisdiction have rules requiring intercompany prices to reflect what unrelated parties would agree to in comparable circumstances (the "arm's length principle"). Failure to comply exposes the group to transfer pricing adjustments, penalties, and double taxation.

Common Transfer Pricing Methods

The OECD Transfer Pricing Guidelines (and most national implementations) recognize five primary methods:

• Comparable Uncontrolled Price (CUP): Compare the intercompany price to prices charged in comparable transactions between unrelated parties. The most direct method when reliable comparable transactions exist.
• Resale Price Method (RPM): Used for distribution entities. Start with the resale price to the external customer, subtract a gross margin appropriate for the distributor's functions, and the result is the arm's-length transfer price.
• Cost Plus Method (CPM): Used for manufacturers and service providers. Start with the cost of production/delivery, add an arm's-length markup for the functions performed and risks assumed.
• Transactional Net Margin Method (TNMM): The most commonly used method in practice. Compare the net profit margin earned by the tested party (the less complex entity) to that earned by comparable independent companies.
• Profit Split Method: For highly integrated operations where both parties make unique contributions. Split the combined profit from the transaction based on the relative contributions of each party.

Configuring Transfer Pricing in NetSuite

NetSuite does not have a native "transfer pricing" module. Transfer prices are implemented through the pricing configuration on items and the price levels assigned to intercompany customers.

Approach 1: Intercompany Price Level. Create a dedicated price level for intercompany transactions at Setup > Accounting > Price Levels > New, named something like "Intercompany Transfer Price." For each item, set the intercompany price level at the transfer price determined by your transfer pricing policy. On the intercompany customer record, set the default price level to "Intercompany Transfer Price." When a sales order is created for an intercompany customer, the system automatically defaults to the transfer price.

Approach 2: Intercompany Markup on Cost. For cost-plus arrangements, configure the intercompany price as a percentage markup over standard cost. Set item cost in NetSuite, create a price formula (Standard Cost x (1 + Markup%)), and apply this formula to the Intercompany Transfer Price level.

Approach 3: Manual Price Entry. For complex transfer pricing arrangements where prices vary by transaction, allow manual override of the transfer price on each transaction, with a required approval step for intercompany transactions above a threshold (enforced via SuiteFlow workflow).

Keep in mind that NetSuite itself is not a transfer pricing documentation tool. It applies the prices. The transfer pricing study, functional analysis, and contemporaneous documentation required for tax compliance must be maintained outside NetSuite (typically in a dedicated TP documentation system or a well-structured document management library).

Transfer Pricing and Tax Risk

Here's a critical operational consideration: the intercompany prices entered in NetSuite must be consistent with the prices in the transfer pricing documentation. Discrepancies between what the documentation says and what is actually charged create audit exposure.

I've found that the best practice here is to have the transfer pricing team review the pricing setup before it's finalized in NetSuite and provide written confirmation that the configured prices reflect the approved transfer pricing policy. Build an annual review of intercompany prices into the finance calendar.

Intercompany Cost Allocations and Charges

Beyond inventory transfers, intercompany accounting includes the allocation of costs incurred by one entity on behalf of others. This is the economics of a shared services model.

Management Fee Arrangements

Many groups charge management fees from the parent entity to subsidiaries for central services: finance, HR, IT, legal, executive oversight. The management fee creates income at the parent (or shared services entity) and expense at each subsidiary.

Common management fee methodologies include:

• Fixed fee: A set monthly or annual charge regardless of actual costs.
• Cost-based: Actual costs of central services allocated to subsidiaries, often with a markup.
• Revenue-based: Fee as a percentage of subsidiary revenue.
• Headcount-based: Fee based on the number of employees at each subsidiary.

For recurring management fees in NetSuite, you can create a monthly recurring intercompany journal entry template at Transactions > Financial > Make Intercompany Journal Entries. Save it as a memorized transaction with monthly recurrence. The revenue accountant reviews and posts each month.

Alternatively, you can use a Scheduled Script to generate the intercompany journal entries automatically based on a configured allocation percentage, eliminating the manual step entirely.

Shared Services Allocations

More granular than management fees, shared services allocations charge specific functional costs to the subsidiaries that benefit from them. Common shared services include:

• IT infrastructure (allocated by headcount or server usage)
• Finance and accounting (allocated by revenue or transaction volume)
• Legal (allocated by revenue or specifically by entity)
• Marketing (allocated by revenue or specifically to the benefiting entity)
• Real estate (allocated by square footage or headcount)

The typical allocation methodology in NetSuite follows three steps. First, identify the total cost pool for each shared service in the period (pull from the shared services entity's actuals via saved search). Second, apply the allocation key (headcount, revenue, etc.) to determine each subsidiary's share (this calculation typically occurs in Excel or a planning tool, then is entered into NetSuite). Third, post intercompany journal entries for each allocation, debiting the shared service expense account at each receiving subsidiary and crediting the intercompany income account at the shared services entity.

For a more advanced configuration, NetSuite's statistical accounts (non-monetary accounts that track operational metrics like headcount or square footage) can be used as the basis for allocation formulas in journal entry templates. This reduces manual calculation but requires statistical account maintenance. You'll find these at Lists > Accounting > Statistical Accounts.

IP Royalties and License Fees

For groups that hold intellectual property (patents, trademarks, software) in a dedicated IP entity and license it to operating entities, the IP entity records royalty income and the operating entities record royalty expense. Transfer pricing compliance requires the royalty rate to reflect arm's-length rates for comparable IP arrangements. Royalties are often the highest-scrutiny intercompany charge from a tax perspective, particularly in cross-border arrangements.

IP royalties are typically charged as a percentage of the operating entity's revenue. A monthly calculation script or memorized journal entry that reads the subsidiary's revenue for the period and calculates the royalty charge is the standard approach.

If you're building a scripted solution, the functional specification would look something like this: a scheduled script triggered on the last business day of the month that queries each operating subsidiary's Revenue GL account for the period, multiplies by a configured royalty rate (from a custom configuration record), and creates intercompany journal entries posting royalty income to the IP entity and royalty expense to each operating subsidiary. The auto-balance mechanism creates the IC payables/receivables.

Configuring Recurring Intercompany Allocations

For allocations that recur monthly at consistent amounts, memorized intercompany journal entries work well. Navigate to Transactions > Financial > Make Intercompany Journal Entries, then save as a Memorized Transaction. Configure monthly recurrence on a specified day and assign it to a specific Finance team member for review and posting. NetSuite sends a reminder when the memorized transaction is due.

One limitation to be aware of: memorized transactions don't update automatically for amount changes (e.g., if the allocation base changes period-to-period). Amounts must be manually updated each period. For allocations where amounts are fixed, this is fine. For variable allocations, a scripted approach is more reliable.

Intercompany Eliminations

When consolidated financial statements are produced in NetSuite, intercompany transactions must be eliminated. NetSuite's elimination process is the mechanism by which this occurs.

The eliminations required fall into three categories:

P&L Eliminations:

• Intercompany revenue (seller) eliminated against intercompany COGS/expense (buyer)
• Intercompany management fee income eliminated against management fee expense
• Intercompany interest income eliminated against interest expense
• Intercompany royalty income eliminated against royalty expense
• Intercompany dividend income eliminated against dividend payment

Balance Sheet Eliminations:

• Intercompany AR eliminated against intercompany AP
• Due From eliminated against Due To
• Intercompany loan receivable eliminated against intercompany loan payable
• Parent's investment in subsidiary eliminated against subsidiary's equity (investment elimination, typically handled as a manual journal entry at the top-level consolidation)

Unrealized Profit Eliminations:

• Profit in ending inventory from intercompany transfers
• Profit on intercompany fixed asset transfers (deferred gain)

NetSuite's Automated Elimination Process

NetSuite can automate the elimination of intercompany P&L and balance sheet items through its Intercompany Elimination feature. The automation applies to standard intercompany accounts, those that have been configured in elimination rules.

Here's how the automated process works:

• At period-end, Finance runs the elimination process for the consolidation level.
• NetSuite reviews transactions in the configured intercompany accounts across all subsidiaries within the elimination scope.
• NetSuite generates elimination journal entries in a dedicated Elimination Subsidiary, reversing the intercompany account balances at the consolidated level.
• Consolidated financial reports exclude elimination subsidiary balances from entity-level reporting but include them in consolidated totals.

Elimination Subsidiary

The Elimination Subsidiary is a special subsidiary type in NetSuite that exists solely to hold elimination journal entries. It doesn't represent a legal entity and never appears in standalone financial statements. It only shows up in consolidated reports.

To create one, navigate to Setup > Company > Subsidiaries > New:

• Name: "[Elimination] Group Consolidation" or similar.
• Type: Check the "Elimination" checkbox.
• Parent: The consolidating entity this elimination subsidiary serves.
• Currency: The consolidation currency.

Multi-Tier Eliminations: For groups with multi-tier structures (sub-groups with their own sub-consolidations), multiple elimination subsidiaries may be required, one at each consolidation level. For example:

• Americas Sub-Consolidation: "[Elimination] Americas"
• EMEA Sub-Consolidation: "[Elimination] EMEA"
• Global Top-Level: "[Elimination] Global"

Each elimination subsidiary eliminates intercompany transactions at its level. The global elimination subsidiary also eliminates transactions between the sub-groups.

Configuring Elimination Rules

Elimination rules define which accounts are eliminated and how the elimination entries are generated. Navigate to Setup > Accounting > Intercompany Preferences > Elimination Rules.

Each Elimination Rule specifies:

• Name: Descriptive rule name (e.g., "Eliminate IC Revenue and COGS").
• Elimination Subsidiary: Which elimination entity posts the entry.
• Source Account(s): The intercompany accounts to be eliminated.
• Offset Account: The account to which the elimination debit/credit is posted (typically the same intercompany account, netting to zero).
• Scope: Which subsidiary pairs this rule applies to.

Rule Type 1: Account-Based Elimination. Eliminate the full balance of a specified intercompany account across all subsidiaries within the elimination scope. For example, to eliminate IC Revenue Account (4900): the Source Account is 4900 -- Intercompany Revenue, the elimination action debits IC Revenue (reversing the credit balance), and the credit goes to the offset account. Net effect: IC Revenue balance equals zero at the consolidated level.

Rule Type 2: Transaction-Based Elimination. Match specific transactions between subsidiaries and eliminate matched pairs. This is more precise than account-based elimination and handles partial matches. Note that NetSuite's native elimination primarily operates at the account balance level. Transaction-level matching is more granular and typically requires custom saved searches or third-party tools for full automation.

Running Eliminations in NetSuite

Navigate to Transactions > Financial > Intercompany > Eliminate Intercompany Transactions.

The process is straightforward:

• Select the Elimination Subsidiary.
• Select the Accounting Period.
• Review the proposed elimination entries (preview mode).
• Verify that all expected intercompany accounts are included and balances appear correct.
• Post the elimination entries.

Elimination entries post to the Elimination Subsidiary as journal entries. They can be reviewed like any other journal entry at Reports > Financial > Journal Entries (filter by Subsidiary = Elimination Subsidiary).

Eliminations should be run at every period-end for which consolidated financial statements are produced. For monthly close environments, eliminations are run as part of the close checklist. For quarterly reporting companies, eliminations are run quarterly at minimum.

If intercompany transactions are modified after eliminations have been run, the elimination must be re-run for the period. NetSuite will typically reverse the prior elimination entries and create new ones. Verify this behavior in your account before relying on it.

GL Impact of Elimination Entries

All elimination entries are posted in the Elimination Subsidiary. They're zero-sum by design. Each elimination debit is offset by an elimination credit.

P&L Elimination Example (IC Revenue and Expense): Posted in the Elimination Subsidiary:

• Debit: Intercompany Revenue, Elimination Sub, $100,000
• Credit: Intercompany COGS/Expense, Elimination Sub, $100,000

At the consolidated level, the $100,000 IC Revenue from Subsidiary A and the $100,000 IC Expense from Subsidiary B are both reversed, netting to zero.

Balance Sheet Elimination Example (IC AR and AP):

• Debit: IC Accounts Payable -- Sub A (elimination), $100,000
• Credit: IC Accounts Receivable -- Sub B (elimination), $100,000

The consolidated balance sheet shows no IC AR or IC AP. Total assets and total liabilities are both reduced by $100,000.

Reviewing and Verifying Eliminations

After running eliminations, verify completeness with the following checks:

Check 1: Intercompany Account Balances at Consolidated Level. Run the Trial Balance for the consolidated entity (including the Elimination Subsidiary). Any intercompany account with a non-zero balance indicates an incomplete elimination. Navigate to Reports > Financial > Trial Balance (Consolidated).

Check 2: Intercompany Revenue vs. Intercompany Expense. Total intercompany revenue across all subsidiaries should equal total intercompany expense across all subsidiaries (within each revenue/expense pair). Differences indicate unmatched intercompany transactions. Build a saved search: Income Statement lines where Account type = Intercompany, grouped by Account, summed across all subsidiaries. The net balance for each intercompany account pair should be zero.

Check 3: IC AR vs. IC AP Balance. Total IC Accounts Receivable across all subsidiaries should equal total IC Accounts Payable across all subsidiaries. Any difference is an intercompany imbalance.

Check 4: Elimination Subsidiary Balance. The Elimination Subsidiary's total assets should equal its total liabilities at the consolidated level (elimination entries net to zero by design). Any imbalance indicates an error in the elimination rules or posting.

Intercompany Matching and Reconciliation

The most common intercompany accounting problem at period-end: the IC AR on one entity's books does not equal the IC AP on the counterpart's books. These imbalances come from several sources:

• Timing differences: Subsidiary A invoices in December. Subsidiary B processes the vendor bill in January. At December year-end, AR exists on Sub A's books but no AP on Sub B's books.
• Amount differences: Subsidiary A invoices $100,000. Subsidiary B's AP team enters $90,000 (data entry error). A $10,000 mismatch exists.
• Currency differences: The transaction is invoiced in USD from Sub A. Sub B records it in GBP at a different exchange rate. The balances don't agree in the settlement currency.
• Missing transactions: Subsidiary A charges a management fee. Subsidiary B never records the corresponding expense.
• Duplicate entries: A transaction is posted twice on one side.

Unreconciled intercompany imbalances prevent clean eliminations, distort consolidated financial statements, and create audit findings.

Intercompany Matching Tools

NetSuite's Intercompany Netting feature provides a settlement mechanism for confirmed IC balances, but it's not a matching/reconciliation tool per se. Native NetSuite does not have a purpose-built intercompany matching workflow.

You can build a custom saved search for IC matching that compares IC AR on one subsidiary to IC AP on the counterpart. The structure would use Transaction as the record type (Journal Entry, Invoice, Vendor Bill), filter by the intercompany accounts and relevant subsidiaries, and include columns for Transaction ID, Counterpart Reference, Amount, Subsidiary, and Date. Group by the counterpart transaction reference (e.g., the IC invoice number) and show groups where the net amount is not zero.

For large groups with high transaction volumes, dedicated intercompany reconciliation platforms like Trintech Cadency, BlackLine, or Circit provide automated matching, dispute management, and confirmation workflows between entities.

Building an Intercompany Reconciliation Process

A structured intercompany reconciliation process should be completed before elimination entries are run each period.

Step 1: Entity-Level Confirmation (Day -5). Each subsidiary's Finance team produces a schedule of all outstanding IC AR and IC AP balances, identifying the counterparty and the amount for each balance.

Step 2: Bilateral Comparison (Day -4). For each intercompany pair, both sides compare their schedules. A common approach: designate one entity as the "lead" (typically the seller or the parent) and have the "receiving" entity confirm or dispute the balance.

Step 3: Difference Investigation (Day -3). Investigate and resolve all differences identified in Step 2. For timing differences, agree on which period's books the transaction belongs to and post accordingly. For amount differences, identify the error and post a correcting entry on the appropriate side. For missing transactions, post the missing entry.

Step 4: Final Confirmation (Day -2). Both sides confirm that their IC balances agree. Document the confirmation (email or in-system confirmation via workflow).

Step 5: Run Eliminations (Day -1). Only after all IC balances are confirmed and reconciled, run the elimination process.

Automated Matching via Saved Searches

For high-volume intercompany transactions, a saved search-based automated matching approach can identify unmatched pairs daily, providing early warning of emerging imbalances rather than discovering them at period-end.

Build a daily IC matching saved search using Transaction as the record type, filtering by IC AR / IC AP accounts over a rolling 90-day window. Join and group transactions by a counterparty reference field (this requires a custom field on intercompany transactions storing the counterpart's transaction ID). Show groups where the net amount is not zero, meaning one side is present with no match on the other side, or amounts differ.

Set up a saved search email alert delivered to each entity's Finance team daily, listing any unmatched intercompany transactions. This shifts the reconciliation from a month-end scramble to an ongoing daily process.

Intercompany Netting

Intercompany netting is the process of offsetting intercompany balances between entities so that only the net amount is settled in cash. Instead of each entity making individual payments for every intercompany invoice, the netting process calculates the net position between all entities and settles only the net amount.

Here's a simple example. Without netting: US Parent owes UK Subsidiary $150,000 (management fee), and UK Subsidiary owes US Parent $200,000 (intercompany product purchase). That means two wire transfers: US Parent sends $150,000 and UK Subsidiary sends $200,000. Total cash movement: $350,000.

With netting: the net position is that UK Subsidiary owes US Parent $50,000 ($200K minus $150K). Only one wire transfer is needed. Total cash movement: $50,000.

The benefits are clear: reduced transaction costs (fewer wire fees), reduced FX conversion costs, simplified treasury management, and lower counterparty exposure.

Netting Configuration in NetSuite

Enable the feature at Setup > Company > Enable Features > Accounting > Intercompany Netting.

To set up a netting agreement, navigate to Setup > Accounting > Intercompany Netting Agreements > New. You'll configure:

• Name: Agreement name (e.g., "Global Monthly Netting").
• Subsidiaries: All subsidiaries participating in this netting agreement.
• Netting Currency: The settlement currency for net payments.
• Netting Period: How often netting occurs (monthly, weekly).
• Cutoff Date: The date through which transactions are included in each netting cycle.
• Settlement Account: The bank account used for net settlements.

You'll also need to specify which IC AR and IC AP accounts are included in the netting calculation. Typically all intercompany balance sheet accounts.

Netting Settlement and GL Impact

Step 1: Create Netting Statement. Navigate to Transactions > Financial > Intercompany > Create Netting Statement. NetSuite reviews all outstanding IC AR and IC AP balances for the participating subsidiaries through the cutoff date, calculates each entity's net position, and generates a netting statement showing each entity's gross receivables from other entities, each entity's gross payables to other entities, and each entity's net position (net payer or net receiver).

Step 2: Review and Confirm. Finance reviews the netting statement, confirms the amounts with each subsidiary's Finance team (or uses the automated confirmation workflow), and approves the statement for settlement.

Step 3: Settlement. The entity with a net payable position pays the entity with a net receivable position. In practice, settlements flow through a central treasury account (often the parent or a treasury center subsidiary).

The GL impact for the net payer (e.g., UK Subsidiary owes $50,000 net):

• Debit: IC Accounts Payable -- US Parent, $50,000
• Credit: Cash / Bank, $50,000

The GL impact for the net receiver (e.g., US Parent receives $50,000 net):

• Debit: Cash / Bank, $50,000
• Credit: IC Accounts Receivable -- UK Sub, $50,000

After settlement, both entities' IC balances for the netting cycle are cleared to zero.

Multi-Currency Netting

When entities transact in multiple currencies, netting requires converting all positions to the settlement currency. The exchange rate used for this conversion must be documented and consistently applied.

Common approaches include:

• Period average rate: Use the average exchange rate for the netting period.
• Spot rate at cutoff date: Use the spot rate on the netting cutoff date.
• Contractual rate: A pre-agreed rate specified in the netting agreement.

FX differences arising from currency conversion during netting settlement create realized FX gains and losses on each entity's books. These gains and losses are real (not eliminated). They represent actual economics of the intercompany settlement.

Multi-Currency Intercompany Transactions

Every intercompany transaction has a transaction currency (the currency in which the invoice is denominated, agreed between the two entities) and a functional currency (the primary currency of each participating subsidiary's financial statements). When these differ, translation is required on each entity's books.

For example: US Parent (functional currency: USD) invoices Germany Sub (functional currency: EUR) in USD. Germany Sub must translate the USD invoice into EUR for its books.

NetSuite uses the exchange rate configured for the relevant rate type (e.g., "Average Rate" or "Spot Rate") on the transaction date for the transaction currency to functional currency conversion. You can configure exchange rates at Lists > Accounting > Currency Exchange Rates.

Exchange Rate Determination

For intercompany transactions, the exchange rate question has both accounting and transfer pricing dimensions.

The accounting rate is the rate used to translate the transaction into each entity's functional currency for GAAP financial statement purposes (typically the exchange rate on the transaction date, or the period average rate if using average rate accounting).

The transfer pricing settlement rate is the rate used to determine the actual amount of cash that will settle between the entities. This may differ from the accounting rate.

I'd recommend defining the exchange rate basis for all intercompany transactions in your intercompany agreement documentation. Configure NetSuite's rate type consistently with this documentation. Auditors will ask how intercompany exchange rates are determined.

Unrealized and Realized Intercompany FX Gains and Losses

Unrealized FX on IC Balances: An IC receivable denominated in a foreign currency is remeasured at each period-end using the current exchange rate. The difference between the original rate and the current rate generates an unrealized FX gain or loss.

For example: US Parent has a EUR 100,000 IC receivable from Germany Sub, recorded when the EUR/USD rate was 1.10 (USD equivalent: $110,000). At period-end, the rate is 1.05 (USD equivalent: $105,000). US Parent records an unrealized FX loss of $5,000.

NetSuite's currency revaluation process (run at period-end) remeasures all foreign-currency denominated IC balances and posts unrealized FX gains/losses. Navigate to Transactions > Financial > Revalue Open Currency Balances.

Realized FX on IC Settlement: When the IC balance is actually settled (payment received or netting completed), the difference between the settlement rate and the carrying rate creates a realized FX gain or loss.

Intercompany FX Elimination Issue: Here's a critical consolidation complexity. Unrealized FX gains and losses on intercompany balances appear on both entities' books but are not always mirror images of each other (because each entity translates from its own functional currency perspective). These intercompany FX amounts must be carefully analyzed at consolidation:

• If the IC balance will be settled: The FX gain/loss is real and should NOT be eliminated. It represents genuine economic exposure that will be settled in cash.
• If the IC balance is considered quasi-permanent (long-term intercompany loan with no settlement intent): Under ASC 830 (and IAS 21), FX gains/losses on permanent intercompany monetary items are recorded in Other Comprehensive Income (OCI), not P&L. NetSuite does not natively manage this OCI treatment. It requires a manual adjustment or custom configuration.

This is one of the most technically complex areas of consolidation accounting and frequently requires input from a technical accountant or external auditor.

Eliminating Intercompany FX

For intercompany balances that will be settled, the FX gain on one entity's books and the FX loss on the other entity's books should net to zero in aggregate (they're mirror images). The elimination at consolidation removes both.

For permanent intercompany items (quasi-equity loans), the FX amounts belong in the CTA (Cumulative Translation Adjustment) component of OCI in the consolidated balance sheet, not in consolidated net income. Manual reclassification entries are required.

Consolidated Reporting

NetSuite's consolidated reporting aggregates the financial data of all subsidiaries within the consolidated group (per the subsidiary hierarchy) and presents combined financial statements net of elimination entries.

Consolidated reports in NetSuite work by summing the financial balances of all subsidiaries included in the consolidation scope, adding the balances of the Elimination Subsidiary (which are negative by design, reversing intercompany accounts), translating foreign-currency subsidiary balances to the consolidation currency using the appropriate exchange rates, and presenting the combined result as the consolidated financial statements.

Most financial reports in OneWorld have a "Consolidation" option in the Subsidiary filter. For example, go to Reports > Financial > Income Statement, then filter by Subsidiary = [Top-Level Consolidating Entity] and include Consolidated. This presents the consolidated view automatically, including all subsidiaries and elimination entries.

Consolidation Exchange Rates

When consolidating subsidiaries with different functional currencies, each subsidiary's financial statements must be translated to the consolidation currency. ASC 830 and IAS 21 prescribe specific rates:

• Income Statement items: Average rate for the period.
• Balance Sheet items (assets and liabilities): Closing rate (spot rate at period-end).
• Equity (historical transactions): Historical rate (rate at the time the equity transaction occurred).

Configure consolidation exchange rates at Lists > Accounting > Currency Exchange Rates. For each currency pair, set the Current Rate (closing/spot rate for balance sheet translation), Average Rate (period average for income statement translation), and Historical Rate (used for specific equity items). NetSuite applies these rates in consolidated reports automatically when the consolidation view is selected.

A critical operational step: exchange rates must be updated in NetSuite before consolidated reports are run. Many organizations pull rates from an external source (Bloomberg, ECB, etc.) and load them into NetSuite on the last business day of the month.

Cumulative Translation Adjustment (CTA)

The Cumulative Translation Adjustment is the difference that arises in the consolidated balance sheet due to translating a subsidiary's balance sheet items at the current rate while its equity is translated at historical rates. The CTA is not a profit or loss. It's an equity component that absorbs the translation difference.

The mechanics are straightforward: take the subsidiary's net assets (Assets minus Liabilities) translated at the current rate, compare it to the subsidiary's equity translated at historical rates, and the difference is CTA. It accumulates over the life of the subsidiary.

NetSuite calculates and reports CTA as part of its consolidated balance sheet. The CTA appears as a line in the Equity section.

After running consolidated reports, verify that the consolidated balance sheet balances. If it doesn't, the most common cause is an error in exchange rate configuration or an intercompany balance that hasn't been fully eliminated.

Minority Interest (Non-Controlling Interest)

When a subsidiary is not 100% owned by the parent, the non-controlling interest (NCI) represents the portion of the subsidiary's equity and net income attributable to the minority shareholders.

NetSuite OneWorld allows configuration of the ownership percentage on each subsidiary record. Consolidated reports can present NCI as a separate equity component. Set this at Setup > Company > Subsidiaries > [Subsidiary] > Ownership % field.

When eliminating the parent's investment in the subsidiary against the subsidiary's equity, only the parent's ownership percentage is eliminated. The NCI portion of the subsidiary's equity remains as a separate line in consolidated equity.

One limitation worth noting: NetSuite's native NCI handling is functional but limited for complex structures (step acquisitions, partial disposals, NCI measured at fair value). For these scenarios, manual adjustment entries outside NetSuite (or a dedicated consolidation tool) are typically required.

Building a Consolidated P&L and Balance Sheet

Using NetSuite's Financial Report Builder, you can construct a fully customized consolidated P&L and Balance Sheet that excludes intercompany accounts from presentation (they're eliminated and net to zero), separates revenue by subsidiary or region, presents minority interest separately in the equity section, and includes CTA as an OCI component.

Navigate to Reports > Financial > Financial Report Builder. Key configurations for consolidation:

• Subsidiary filter: Set to the top-level consolidating entity, with "Include Subsids" checked.
• Account filters: Exclude internal intercompany accounts from presentation rows (since they net to zero post-elimination, they add noise if displayed).
• Column structure: Can be configured to show each subsidiary in a separate column plus a consolidated total column, which is useful for management reporting.

Intercompany Fixed Asset Transfers

When a fixed asset is transferred between subsidiaries, specific accounting considerations apply.

The selling subsidiary records the disposal of the asset (removes asset cost and accumulated depreciation, recognizes any gain or loss). The buying subsidiary records the asset at the transfer price (or at the agreed value).

If the transfer price differs from the selling subsidiary's carrying value, a gain or loss is recorded. At the consolidated level, this gain or loss must be eliminated because no external transaction occurred.

The consolidation elimination entry:

• Debit: Gain on Intercompany Asset Transfer
• Credit: Fixed Asset (reduce to original consolidated cost)

The eliminated gain is not permanently eliminated. It's deferred and recognized in the consolidated statements over the remaining useful life of the asset (as additional depreciation is reversed to reflect the original consolidated cost basis). This creates a recurring consolidation adjustment for the life of the asset.

NetSuite's Fixed Asset Management (FAM) module does not natively support intercompany asset transfers with automatic elimination. The standard process involves:

• Disposal of the asset in the selling subsidiary (via FAM disposal function).
• Creation of a new asset record in the buying subsidiary at the transfer price.
• Manual consolidation elimination entries for the intercompany gain/loss.
• A recurring consolidation adjustment entry to recognize the deferred gain over the remaining useful life.

For organizations with frequent fixed asset transfers, a custom workflow that automates steps 1 and 2 and creates the consolidation elimination entry reduces error risk.

Intercompany Payroll and Cost Sharing

A frequently overlooked category of intercompany transactions: employees who are employed by one entity but work for another.

Common scenarios include:

• An employee is on the US Parent payroll but spends 60% of their time supporting the UK Subsidiary.
• A shared Finance team is employed by a shared services entity but supports all operating subsidiaries.
• An executive is on the holding company payroll but provides services to multiple operating entities.

The employing entity incurs the full payroll cost. An intercompany charge allocates the appropriate portion of that cost to the benefiting entities.

The payroll cost sharing process in NetSuite works like this. First, the employing entity processes payroll normally. The full payroll expense posts to the employing entity's books. Second, at month-end, an intercompany cost allocation is calculated based on agreed allocation keys (time reports, FTE percentages, revenue percentages). Third, intercompany journal entries are posted: the employing entity gets a credit to payroll expense (partial reversal) and a debit to IC Receivable, while the benefiting entity gets a debit to payroll/staff cost expense and a credit to IC Payable.

An important transfer pricing consideration: cross-border payroll cost sharing is subject to transfer pricing rules. The allocation methodology and markup (if any) must be documented in the transfer pricing study. Many jurisdictions require a markup on cost for intercompany services, even for payroll recharges, which means the receiving entity pays more than just the bare cost allocation.

When Native NetSuite Intercompany Falls Short

NetSuite's native intercompany functionality handles the majority of common scenarios well. The following situations require custom development or third-party tools:

• Transaction-Level Intercompany Matching. Native NetSuite can eliminate account balances in aggregate but doesn't provide a native transaction-level matching workflow that confirms each individual intercompany invoice to its corresponding vendor bill. For high-volume intercompany environments, a custom matching workflow (using SuiteFlow and saved searches) or a third-party tool is required.
• Automated Intercompany Profit in Inventory Calculation. The calculation and elimination of intercompany profit in ending inventory requires knowing how much inventory was transferred intercompany, how much of that inventory remains unsold at period-end, and the seller's margin rate. NetSuite doesn't natively calculate this. It requires custom scripts reading inventory movement data.
• Complex NCI Calculations. Non-controlling interest calculations for step acquisitions, partial disposals, or NCI measured at fair value exceed NetSuite's native capabilities. Manual calculations and adjustments are required.
• Quasi-Equity Intercompany Loan FX (OCI Treatment). Moving FX gains/losses on permanent intercompany monetary items from P&L to OCI (as required by ASC 830 / IAS 21) is not natively automated in NetSuite. A custom reclassification script or manual journal entry is required each period.
• High-Volume Automated Intercompany Billing. For groups that need to automatically generate hundreds of intercompany invoices per period based on operational data (usage metrics, headcount, project hours), a custom billing automation script is required. Native NetSuite's memorized transaction feature is insufficient at this scale.
• Multi-Tier Consolidation with Complex Ownership Structures. For groups with partial ownership, cross-holdings, or complex equity structures, NetSuite's consolidation engine produces the right numbers for simple structures but requires manual adjustments for complex ones.
• Real-Time Intercompany Confirmation Portal. A self-service portal where each subsidiary's Finance team can confirm intercompany balances, raise disputes, and track resolution status is not available natively. This is a common custom build for mid-to-large groups.

Third-Party Intercompany and Consolidation Tools

For the most complex consolidation and intercompany requirements, third-party tools integrate with NetSuite.

BlackLine is a financial close automation platform with strong intercompany accounting capabilities: transaction-level intercompany matching and confirmation, automated dispute management workflow, real-time visibility into intercompany positions, and API integration with NetSuite for transaction data. It's best for mid-to-large enterprises with high intercompany transaction volumes and SOX compliance requirements.

Trintech Cadency / Assure offers similar capabilities to BlackLine, with a focus on financial close automation and intercompany reconciliation.

Workiva is primarily a financial reporting and disclosure management tool, but includes consolidation and intercompany features.

For very large or complex groups where NetSuite is used as the subsidiary ledger but consolidation occurs in a dedicated tool, options include OneStream (enterprise consolidation and planning platform), Tagetik (similar enterprise consolidation platform), and SAP Financial Consolidation (for SAP-centric groups that acquired NetSuite subsidiaries). These tools handle the most complex consolidation scenarios (business combinations, purchase price allocations, complex NCI) that exceed NetSuite's native capabilities.

Consider a dedicated consolidation tool when you have more than 20 subsidiaries with active intercompany activity, complex ownership structures (partial ownership, step acquisitions, disposals), multiple GAAPs (some entities under IFRS, others under US GAAP), an acquisition-heavy growth strategy requiring frequent purchase price allocation work, or SEC reporting requirements with full XBRL tagging.

Month-End Close for Intercompany: A Structured Process

A rigorous intercompany close process is the operational backbone of consolidated financial reporting. Here's a day-by-day structure for the intercompany close:

Day -7 (7 Business Days Before Close):

• Each subsidiary Finance team generates their IC AR and IC AP schedules.
• Circulate the IC schedules to all counterpart entities for bilateral review.
• Begin investigation of any discrepancies identified.

Day -5:

• All bilateral intercompany differences identified and assigned for resolution.
• Post any correcting entries for amount differences or missing transactions.
• Confirm timing differences: agree which period each disputed transaction belongs to.

Day -3:

• All intercompany differences resolved and correcting entries posted.
• Final confirmation from all subsidiaries that IC balances agree.
• Run the Intercompany Matching saved search. Confirm no unmatched items remain.

Day -2:

• Update all intercompany exchange rates in NetSuite for the closing period.
• Run Currency Revaluation for all intercompany foreign-currency balances (Transactions > Financial > Revalue Open Currency Balances).
• Review unrealized FX entries on IC balances. Confirm reasonableness.
• If netting is in scope: run the Netting Statement and process settlement.

Day -1:

• Run the Intercompany Elimination process (Transactions > Financial > Intercompany > Eliminate Intercompany Transactions).
• Review elimination entries. Confirm all expected intercompany accounts are eliminated.
• Run Consolidated Trial Balance. Confirm all IC accounts net to zero.
• Review CTA movement. Confirm it's directionally consistent with currency movements.
• Post any manual elimination entries for IC profit in inventory, IC fixed asset gains, or OCI reclassifications.

Close Day:

• Sign off on the Intercompany Close Checklist.
• Save the Consolidated Trial Balance as period-end documentation.
• Save the Elimination Subsidiary journal entry detail as audit support.
• Close the accounting period for all subsidiaries.

Post-Close (within 2 business days):

• Prepare the intercompany balance schedule for the financial statement notes (disclosure of significant intercompany balances that are not fully eliminated, if any).
• Update the intercompany tracking schedule for any new intercompany agreements or changes to existing ones.
• Review economic nexus or permanent establishment implications of any new intercompany activities.

Common Pitfalls and How to Avoid Them

Pitfall 1: Subsidiary Hierarchy Designed for Reporting, Not Accounting. The subsidiary hierarchy is designed to match the management reporting structure (geographic regions, business lines) rather than the legal entity structure. This creates entities in NetSuite that are not legal entities, intercompany elimination at the wrong level, and confusion between segment reporting and legal entity reporting. The fix: design the hierarchy based on legal entities. Use Departments, Classes, or custom segments for management reporting segments that don't correspond to legal entities. Engage both Finance and Tax in hierarchy design before implementation.

Pitfall 2: No Intercompany Agreements in Place. Intercompany transactions are being processed in NetSuite without formal written intercompany agreements documenting the pricing, terms, and obligations. This creates transfer pricing exposure and, in some jurisdictions, may affect the tax deductibility of the intercompany charges. The fix: before processing any intercompany charge, confirm that a written intercompany agreement exists and is signed by authorized representatives of both entities. NetSuite can hold a reference to the agreement number on intercompany transactions (via a custom field), but the agreement itself must exist outside the system.

Pitfall 3: IC Accounts Not Configured in Elimination Rules. New intercompany accounts are added to the COA for a new type of intercompany transaction (e.g., a new royalty arrangement), but the elimination rules are not updated. The new accounts have balances at consolidation that are never eliminated. The fix: make "Review and update elimination rules" a required step whenever a new intercompany account is added to the COA. Assign an owner for the elimination rule configuration. Quarterly, run a check of all intercompany-designated accounts against the active elimination rules to confirm full coverage.

Pitfall 4: Intercompany Profit in Inventory Ignored. The company transfers inventory between subsidiaries at a transfer price above cost (as required by the transfer pricing policy). The receiving subsidiary sells most of the inventory but holds some at period-end. The unrealized intercompany profit in ending inventory is never eliminated. Over time, this creates a growing overstatement of consolidated inventory and an understatement of consolidated COGS. The fix: build a monthly process to identify ending inventory from intercompany transfers, calculate the embedded intercompany profit, and post a manual elimination entry. For companies with significant intercompany inventory movements, automate this calculation via a scheduled script.

Pitfall 5: Exchange Rates Not Updated Before Consolidated Reports. Finance runs consolidated financial statements on Day 1 of the new month before exchange rates for the closing period have been loaded. The consolidated statements use prior-period rates for balance sheet translation, producing incorrect consolidated figures. The fix: make "Load period-end exchange rates into NetSuite" a Day -1 (or earlier) close checklist item, sequenced before any consolidated report runs. Designate an owner. Consider automating rate loading via a SuiteScript integration with an exchange rate data provider.

Pitfall 6: Elimination Subsidiary Included in Standalone Reports. A user runs a departmental or subsidiary-level report and includes the Elimination Subsidiary in the scope by accident. The report shows large negative balances that have no standalone meaning, causing confusion. The fix: configure saved searches and custom reports to exclude Elimination Subsidiaries by default. Train all NetSuite users on the purpose of elimination subsidiaries and why they should only appear in consolidated reports.

Pitfall 7: No Formal IC Agreement for New Intercompany Activities. A subsidiary informally starts providing services to another subsidiary mid-year without a formal intercompany agreement, transfer pricing analysis, or documentation. The charges are processed in NetSuite, but without documentation, the arrangement may not survive a tax audit. The fix: require Finance sign-off (and Tax sign-off for cross-border arrangements) before any new intercompany relationship is created in NetSuite. Build a new intercompany relationship request workflow that routes through Finance and Tax before the customer/vendor records and IC configuration are created.

Pitfall 8: Netting Settlement Not Reconciled to IC Account Balances. The netting settlement processes successfully, but the GL entries on each entity's books are posted to the wrong accounts or at incorrect amounts. The IC AR and IC AP accounts still show balances after settlement, and the bank account doesn't reconcile. The fix: after every netting cycle, reconcile the IC AR account balance (should be zero for the settled items) to the netting settlement amount, the IC AP account balance (should be zero for the settled items) to the netting settlement amount, and the bank statement for the actual payment to the netting statement settlement amount.

Pitfall 9: Intercompany Transactions in Closed Periods. An intercompany transaction from a prior closed period is discovered and must be corrected. The period is closed, so a direct correction can't be made. The correction is posted in the current period without proper documentation. The comparative financial statements for the prior period remain incorrect. The fix: establish a formal intercompany error correction policy. Determine materiality. If material, reopen the prior period (with proper controls), make the correction, and reclose. If immaterial, post a current-period adjustment with a memo explaining the nature and prior-period amount. Notify the counterpart entity simultaneously so they can make the corresponding correction. Document both entities' correcting entries for audit support.

Summary and Recommendations

Intercompany accounting in NetSuite OneWorld is one of the most technically demanding areas of multi-entity finance. When properly configured and operated, it automates the matching, elimination, and consolidation that would otherwise require weeks of manual spreadsheet work each month. When poorly designed or operated, it produces financial statements that can't be audited, consolidated statements that don't balance, and a close process that consumes the entire Finance team.

For companies implementing OneWorld for the first time: Invest heavily in the subsidiary hierarchy design and COA structure before any transactions are posted. These foundational decisions are extremely difficult to change after go-live. Engage both Finance and Tax in the design. Hierarchy decisions have both accounting and tax consequences. Define intercompany agreements for every transaction type before configuring customers, vendors, and transaction workflows.

For companies with existing OneWorld implementations that are struggling with intercompany close: Audit the elimination rules first. Run a consolidated trial balance and identify every intercompany account that isn't zeroing out after eliminations. Trace each non-zero balance to its root cause: missing elimination rule, unmatched IC transaction, or error in one entity's books. Fix the rules and the transactions before the next period close.

For companies scaling into new geographies and entities: Establish a formal new-subsidiary onboarding checklist. It should cover subsidiary record creation, COA setup, intercompany customer/vendor records, elimination rule updates, intercompany agreement execution, and transfer pricing documentation. Every new entity added without this checklist creates intercompany debt that has to be repaid during close.

For all OneWorld companies: Build the intercompany reconciliation into the close timeline starting Day -7, not Day -1. Intercompany imbalances discovered on the day of close can't be investigated and corrected in time. They either blow the close deadline or produce incorrect statements. The earlier the bilateral reconciliation process begins, the more time there is to resolve differences without timeline pressure.

In the end, intercompany accounting is fundamentally a coordination problem as much as it is a technology problem. The best NetSuite configuration in the world won't produce clean eliminations if the subsidiary Finance teams aren't confirming balances, posting timely corrections, and following the close calendar. Invest in the process and the people alongside the system.