NetSuite Global Dimension Setup for Multi-Subsidiary

The 12-Subsidiary Question: Shared or Per-Entity Dimensions

Consolidating ten or more subsidiaries into one NetSuite account raises a real modeling decision: do you give each subsidiary its own dimension values, or standardize one shared set across the entire chart of accounts? The wrong call creates either a reporting nightmare or a maintenance burden you'll carry for years.

For most multi-entity rollouts, the right answer is a shared dimension set with controlled per-subsidiary tagging. NetSuite's consolidation engine rolls up by legal entity using the subsidiary field, not by separate dimension values. If your Cost Center or Department dimensions differ across subsidiaries, your consolidated income statement won't reconcile cleanly against your trial balance. As the NetSuite Basics Guide confirms, each transaction in OneWorld is tied to one subsidiary, so the dimensions on each line carry the weight of that entity assignment.

Why Per-Subsidiary Dimension Values Break Reporting

A controller once asked me to fix a consolidated P&L where Canadian revenue was sitting in a US bucket. The root cause: each subsidiary had its own "Region" dimension, so when the financial report rolled up by subsidiary, the dimension filter applied differently across rows.

The fix took three weeks. The prevention takes five minutes of planning.

When you mark a dimension value as restricted to one subsidiary, it disappears from transactions entered under other subsidiaries. That's the trap. Your consolidated report asks for "Region = North America" and only sees US transactions because the Canadian subsidiary has its own "Region-NA" value restricted to that entity. Per the Financial Statements Guide, grouping or filtering by subsidiary works at the section level of a report, so mismatched dimension values across entities will silently produce different totals on each row.

The Standard Pattern That Works

For each global dimension (Department, Class, Location, and any custom segments), build one master list. Then use the Subsidiary restriction field on each value to control where it can be used.

This gives you clean consolidation while still letting you isolate shared-services allocations or regional cost centers that don't exist in every entity.

Setting Up Subsidiary Restrictions

Go to Lists > Accounting > [Dimension Name] > New. On the dimension value record, you'll see a Subsidiaries field (multi-select). By default, a new dimension value is available to all subsidiaries in a OneWorld account. To restrict it:

1. Open the dimension value record
2. Click the Subsidiaries field
3. Remove subsidiaries that shouldn't see this value
4. Save

By default, a newly created dimension value is unrestricted and visible across all subsidiaries. The restriction field is what makes it entity-specific.

For bulk maintenance, export the dimension list view to CSV, edit the subsidiary column in Excel, and re-import via Setup > Import/Export > Saved CSV Imports. Map the internal ID column so existing values update rather than duplicate.

Bulk Dimension Value Imports That Don't Create Chaos

This is where teams lose hours. A 12-subsidiary rollout can mean 200+ dimension values across four or five dimensions. Hand-keying invites typos, duplicates, and inconsistent subsidiary tagging.

The saved CSV import approach with Add/Update mode handles this well. Key fields to include in your CSV:

• name (required, must be unique within the dimension)
• subsidiary (internal IDs, comma-separated for multi-subsidiary values)
• isinactive (set to F for active)
• description (your auditors will thank you for clear descriptions during the audit)

After import, run a saved search to verify nothing duplicated. Go to Reports > Saved Searches > All Saved Searches > New, select the dimension record, and add a formula that flags any name appearing more than once. Any row that returns is a duplicate you need to clean before go-live.

Approval Workflows for Dimension Maintenance

Once you're live, dimension creep is the real risk. Every controller wants a new department code. Without a workflow, those requests arrive as direct database edits or vendor-side mass updates.

NetSuite's native Workflow Manager (Customization > Workflow > Workflows) can route dimension value creation through approval. The Before Record Submit trigger fires on the server after a user clicks Save but before NetSuite writes the data. A basic workflow checks whether the requester has the Accounting Manager role; if not, it sets the record to Pending Approval and emails the controller.

For more granular control, restrict the Edit permission on dimension records to a custom role (Setup > Users/Roles > Manage Roles). Most subsidiary accountants get Create but not Edit or Delete, so corrections route through the consolidation team.

The Intercompany Catch

Global dimensions interact with intercompany elimination in ways that surprise people. When Subsidiary A bills Subsidiary B for consulting, both sides post to the same Department and Class. If those dimensions are restricted to different subsidiaries, the transaction fails at entry. Intercompany journal entries post to two subsidiaries, so the dimension values on each leg must be available to both entities.

The control here is verifying that shared intercompany dimensions are unrestricted across all trading subsidiaries before go-live.

Run a test intercompany transaction in your sandbox during the dimension setup phase. If it blocks, your restriction logic is too tight.

What to Verify Before Cutover

Before you flip the consolidated switch, run three checks:

1. Dimension coverage report: Saved search on all dimension records, grouped by subsidiary restriction. Any value restricted to only one subsidiary must have a documented reason.
2. Intercompany dimension matrix: Cross-tab all global dimensions against all subsidiary pairs that trade with each other. Confirm overlap.
3. Historical transaction mapping: For any opening balance journal entries loaded during migration, confirm each line carries the correct dimension and subsidiary combination. Retroactive fixes require JE reversals.

When the Shared Model Breaks

Shared dimensions fail when one subsidiary operates in a fundamentally different business line. A manufacturing subsidiary and a financial services subsidiary under the same parent often need different Department hierarchies because their cost structures aren't comparable. In that case, keep the master list shared but create subsidiary-specific values for the divergent categories. Mark them clearly in the description field so report builders know to exclude them from segment-level rollups.