Understanding the Two IDs on a Customer Address Record
NetSuite has two distinct identifiers that are easy to confuse:
1. The Address Internal ID (the “ID” field)
This is the field labeled “ID” directly on the address sub-record when you open it under the customer record. It’s a user-facing label — a way to distinguish between multiple addresses on the same customer.
2. The Address Record’s Internal ID
This is NetSuite’s own system-generated identifier for the address record itself — the numeric ID on the back end.
Important to note that these two IDs are not the same thing.
The CSV Mapping/Import
NetSuite’s CSV import framework for address sub-record only allows you to reference the address by the “ID” field. This is the field NetSuite exposes as a key for matching during the import process.
Practical implication: Before running any mass address update, your customer address records must have unique, populated “ID” values. If your addresses don’t have IDs set, you won’t have a reliable way to tell NetSuite which address to update — and the import may create duplicates instead.
When NetSuite processes a CSV import update to a customer address, it does not update the existing address record in place. Instead, it deletes the old address record and creates a brand new one.
This means the original address record Internal ID is gone. The newly created address record gets a brand new Internal ID assigned by NetSuite.
The “ID” label field, however, carries over — it’s part of the data you’re importing, so it will reflect whatever you’ve put in your CSV.
Why This Matters (And When It Becomes a Problem)
For most use cases, this behavior is invisible. Your addresses look the same, the “ID” labels are intact, and everything appears to have updated cleanly.
But if anything in your environment references the address record’s Internal ID directly, you will have a broken reference after the import. Common places this surfaces:
- SuiteScript that stores or retrieves a specific address Internal ID
- Saved searches or reports filtered by address Internal ID
- Third-party integrations or middleware that cached Internal IDs for sync purposes
- Custom fields or records that cross-reference an address by its Internal ID
After the import, those references point to IDs that no longer exist.
Key Takeaway
Before you run a mass update on your addresses, make sure to keep the above in mind. Understanding the difference between the Address ID label and the system Internal ID — and knowing that updates regenerate the underlying record — can save you from mysterious data issues or broken integrations after what looked like a clean import.