How to Change Primary Subsidiary in NetSuite Customers

Your client has a multi-subsidiary customer record with subsidiaries they want gone, and the CSV import quietly did nothing. You're not alone: the primary subsidiary field on a customer is locked once transactions post, and the subsidiary sublist on a OneWorld customer behaves differently than most people expect. Here's what actually works, and what wastes your afternoon.

Why the Import "Didn't Work"

The subsidiary list on a customer record is not a normal body field you can overwrite with a CSV update. It's a sublist of customer-subsidiary relationship records. When you run a CSV import with Update mode and map the Subsidiary column, the Import Assistant adds or updates rows on that sublist. It does not delete the rows already there.

NetSuite's CSV Imports Guide documents this directly: "You can't fully delete sublist data. You can only overwrite it with new CSV file sublist data, and not remove it by leaving CSV file sublist rows blank." That's the trap you hit. Leaving the subsidiary column blank in the CSV does not clear the sublist. It just skips it.

There is one import setting that comes close: Replace/Overwrite Sublists.

The Replace/Overwrite Sublists Option

In the CSV Import Assistant, on the Field Mapping step, expand Options and check Replace/Overwrite Sublists. With this enabled, the import replaces all existing sublist values with exactly what's in the CSV file.

The catch, confirmed in the NetSuite docs: enabling Overwrite Sublists cancels out the Overwrite Missing Fields option for any sublist with mapped fields. The sublist matches your CSV exactly, no matter what was there before. So your CSV must list every subsidiary you want to keep, including the primary.

For your scenario, the CSV would look like this:

With Update mode, Replace/Overwrite Sublists checked, and the Subsidiary column mapped, the import wipes the sublist down to just Acme USA. Test it on one customer first, because if the CSV is missing a subsidiary that has posted transactions, the import can error out with something like "Transaction subsidiary <name> is not valid for entity <customer>."

When the Import Still Won't Cooperate

The replace/overwrite approach works when the subsidiary sublist is the only thing you're fixing. It fails when the primary subsidiary itself is wrong, because the primary subsidiary is a body field, not a sublist row. The CSV import maps to the sublist; it cannot reassign the primary.

Here's the hard rule: after a transaction posts for the customer, you cannot change the primary subsidiary by editing the record. The field is locked. No import option, no inline edit, no record.submitFields call will move it.

What does work is the merge trick.

The Duplicate Merge Trick

Instead of fighting the locked field, create a brand-new customer record with the correct primary subsidiary, then merge the old record into it. The surviving record keeps the primary subsidiary you set on the new one, and all transactions from the old record roll over.

Setup first. Go to Setup > Company > Enable Features, and on the Company subtab, in the Data Management section, turn on Duplicate Detection & Merge. Your role needs full level of the Duplicate Entity Management permission; the default Sales Person role only has view level, so you'll likely need Administrator.

Steps:

1. Create the new customer record with the correct primary subsidiary. Save it.
2. Open the old customer record (the one with the wrong primary). This matters: NetSuite designates the record you start the merge from as the duplicate.
3. Enter edit mode. You'll see a Merge button, or it sits under the Actions menu.
4. Click Merge and select the new customer as the target.
5. NetSuite warns you this is an irreversible data change. Confirm.

The old record's transactions, open balances, and history move to the new record. The primary subsidiary on the survivor is the one you set at creation.

Why Start From the Old Record

If you trigger the merge from the new record, NetSuite treats the new record as the duplicate and merges it into the old one. You'd be right back where you started, with the wrong primary subsidiary intact. Always launch the merge from the record you want to discard.

Removing Extra Subsidiaries: Merge or Import

For your exact case, removing all subsidiaries except the primary, you have two viable paths:

• Replace/Overwrite Sublists import if the primary subsidiary is already correct. Fast, no record churn, but it only touches the sublist.
• Duplicate merge if the primary is also wrong, or if the import keeps failing. Slower, but it restructures the record completely, including the primary.

One caveat on the merge: it's a blunt instrument. System notes aren't transferred from the duplicate to the primary record, and the merge updates system notes and last-modified dates on every associated transaction. If you have audit requirements on those transactions, expect the history to show updates by the "Duplicate Resolution process."

A Map/Reduce Fallback (If Scripting Is Allowed)

If your account permits SuiteScript and you're dealing with hundreds of customers, a Map/Reduce script can delete the customer-subsidiary relationship records directly. The relationships live as their own records, not as a body field, which is why a plain record.submitFields won't remove them.

A governance-safe approach loads each customer, deletes the unwanted subsidiary rows from the subsidiary sublist via record.removeLine, and submits. Keep an eye on the governance units: processing more than a few hundred customers in a single run will blow past the Map/Reduce limit, so chunk by N/search filtering on internalid ranges.

If scripting is off the table, the manual merge route is your friend. Test one duplicate merge in the UI before you commit to doing it for every record, and confirm the surviving record carries the correct primary subsidiary and all open transactions.