A NetSuite parent-child relationship connects related customer records so a parent company and its locations, divisions, or legal entities can be managed within one customer hierarchy. In NetSuite, we create the parent customer first, then create each related customer as a subcustomer by using the Subcustomer Of field, or the equivalent parent field on the account’s customer form. The relationship should be tested against billing, payments, reporting, permissions, and integrations before we load the full customer list.
The basic setup is straightforward, but the design decision behind it is important. A parent-child structure is appropriate when related customer records need to remain distinct for transactions or account management while still being viewed as part of a larger commercial relationship. It is not a replacement for subsidiaries, departments, locations, contacts, or custom segments. Choosing the wrong record structure creates duplicate reporting, incorrect billing ownership, and difficult data maintenance.
What a NetSuite parent-child relationship actually does
A parent-child relationship in NetSuite links a parent customer to one or more subcustomers. The parent might represent a corporate account, while the subcustomers represent branches, stores, campuses, billing accounts, or operating units.
Each subcustomer remains a customer record with its own fields and transaction history. Depending on configuration, the hierarchy can also support consolidated views of activity associated with the parent. This makes the structure useful when the business needs both levels of visibility:
A sales representative needs to work with a specific branch.
Accounts receivable needs to understand the wider corporate relationship.
Reporting needs to group related customer activity.
Integrations need to preserve the relationship between individual accounts.
The relationship does not automatically mean that every child record has identical billing, tax, currency, terms, or contact information. Those details still need to be configured and reviewed on the individual customer records.
NetSuite customer hierarchies also differ from organizational structures created through NetSuite OneWorld subsidiaries. A subsidiary represents an accounting and legal structure inside the ERP. A parent customer relationship represents a relationship between customer records. One customer hierarchy can include accounts that transact with different internal teams, but it should not be used to model an entity that requires a separate legal accounting book.
For a broader discussion of how customer and vendor structures should be mapped during an ERP transition, see our guide on building a practical NetSuite migration playbook. This article focuses specifically on configuring and validating the hierarchy after the record model has been chosen.
When should we use subcustomers instead of other NetSuite records?
Use subcustomers when each related account needs its own customer identity, transactions, balances, or operating details, while the business still needs a formal connection to a parent account.
A customer hierarchy is generally a good fit for a corporate account with separately managed branches. It is also useful when each location places orders independently, has a separate shipping address, or needs a distinct sales and service history.
Other NetSuite structures serve different purposes:
| Business requirement | Better NetSuite structure |
|---|---|
| Group branches or related buying accounts under one customer relationship | Parent customer and subcustomers |
| Track people associated with an account | Contact records |
| Report revenue by internal operating area | Departments, classes, locations, or custom segments |
| Separate legal entities and accounting books | Subsidiaries in NetSuite OneWorld |
| Track multiple addresses for one customer | Customer address book |
| Represent resellers, distributors, or other channel relationships | Customer records with appropriate classifications and custom fields |
The distinction matters because adding a customer record for every physical address produces an unnecessarily deep hierarchy. If a location does not place orders, receive invoices, maintain its own balance, or require separate account ownership, an address or location field may be the cleaner choice.
We should also decide whether a child record represents a legal entity or only an operational account. That decision affects tax treatment, credit review, currency, payment terms, and reporting. A parent-child link alone does not answer those accounting questions.
How to set up a NetSuite parent-child relationship
We can configure a basic hierarchy directly from the NetSuite customer interface. The exact field name and page layout depend on the customer form, account features, and customizations, but the underlying process remains consistent.
1. Define the hierarchy before creating records
Start with a written record model rather than clicking through the customer form immediately. Identify the parent account, every proposed child account, and the reason each child needs to exist separately.
For each record, determine:
Legal or trading name
External ID or source-system ID
Billing and shipping addresses
Currency
Tax registration details
Payment terms and credit limit
Sales owner
Subsidiary, if using NetSuite OneWorld
Whether transactions should be entered at the parent or child level
Whether the account needs a separate balance and statement
This preparation prevents a common error: creating records based on inconsistent naming rather than on a defined business relationship. We should also choose a maximum hierarchy depth. A two-level structure, such as corporate parent followed by operating account, is easier to govern than a chain of loosely understood parent records.
2. Create the parent customer
Create the top-level customer record first. In the standard interface, we can open the customer list and select the option to create a new customer. Choose the correct customer type, such as company or individual, then complete the required fields.
The parent record should contain the information that genuinely belongs to the overall relationship. That might include the corporate website, central account owner, master contract reference, or group-level contact details. We should not place branch-specific billing addresses or tax information on the parent simply because the parent was created first.
If the account uses multiple subsidiaries, currencies, or tax registrations, configure those values according to the business’s accounting model. Do not assume that a parent customer automatically overrides the settings on every subcustomer. The child record must be reviewed independently.
Save the parent and record its internal ID or external ID. The internal ID becomes especially important when we create the child records through CSV import, SuiteScript, or an integration.
3. Create each child as a subcustomer
Create a new customer record for the branch, division, or related account. On the customer form, locate the Subcustomer Of field. Select the parent customer created in the previous step.
Some account configurations or customized forms use a related label such as Parent Customer. If the field is missing, check the selected customer form, role permissions, custom form configuration, and account features before creating a workaround. A custom free-text field does not create a functioning NetSuite hierarchy.
Complete the child record with its own operational information. Use a clear naming standard, such as a legal name followed by a location identifier, when that improves searchability. The name should not be the only way to distinguish records. External IDs, addresses, tax data, and source-system identifiers should also make the relationship auditable.
The child record should have its own address book entries if it ships to or bills from a different location. Confirm the default billing and shipping addresses carefully because transaction forms often inherit defaults from the customer record.
4. Configure transactions and billing behavior
The parent-child link is only useful if transaction behavior matches the intended process. Decide where sales orders, invoices, cash sales, credits, and payments should be recorded.
For example, if each branch is responsible for its own invoices, transactions should be created against the child customer. If a central finance team pays invoices for multiple branches, the payment process needs to be tested against the selected billing design. We should not assume that grouping customers under a parent automatically creates the desired consolidated billing workflow.
Review these fields and processes on both parent and child records:
Terms and credit limits
Price levels and customer-specific pricing
Tax registration and nexus treatment
Currency
Sales rep and account owner
Payment method
Statement and aging behavior
Transaction approval workflows
Customer status
This is also where integration risk appears. An integration that sends invoices, payments, or customer updates into NetSuite must know whether the source system identifies the parent, the child, or both. When customer hierarchies are exchanged through an accounts receivable integration, the relationship should be validated before go-live, along with custom fields and approval workflows. Our guidance on mapping customer hierarchies in a NetSuite AR integration covers that related control point.
5. Test the hierarchy with real transaction scenarios
Do not validate the setup by checking only whether the child appears beneath the parent. Test the complete record lifecycle.
Create representative transactions against a child customer and confirm:
The correct billing and shipping addresses populate.
The intended subsidiary and currency are available.
Pricing and terms behave correctly.
Tax details are calculated as expected.
The transaction appears in the appropriate customer history.
Parent-level searches or reports group activity correctly.
Payments apply to the intended customer and transaction.
Users can access the records they are supposed to manage.
Searches and reports should be tested with both parent and child criteria. A report filtered only for the parent may not return every child record unless the search is designed to traverse the hierarchy. This is a practical information gain that is easy to miss during setup: record relationship visibility and reporting aggregation are separate configuration questions.
6. Document ownership and maintenance rules
A hierarchy remains reliable only when people know who can change it. Define who may create customers, who may assign a subcustomer to a parent, and who approves changes to legal name, tax status, currency, and billing responsibility.
Use a controlled intake process for new customer records. Duplicate detection should consider more than the company name. Compare tax IDs, external IDs, addresses, domains, and source-system keys where available. A duplicate parent record undermines every report and integration that depends on the hierarchy.
Where appropriate, use workflows, mandatory fields, role permissions, saved searches, and system notes to support governance. NetSuite system notes provide an audit trail for many record changes, making them useful when investigating who changed a parent assignment and when the change occurred.
How do we import parent-child customer records in NetSuite?
For a small hierarchy, manual creation is appropriate. For a large customer population, use a controlled CSV import or integration process with stable identifiers.
The safest import sequence is:
Prepare the parent customer records and assign unique external IDs.
Import or create the parent records first.
Confirm that the parents exist and their identifiers are correct.
Prepare child rows with a parent reference that matches the chosen identifier.
Import the child records with the parent relationship mapped to the appropriate NetSuite field.
Review import results, rejected rows, duplicate warnings, and relationship assignments.
Test searches, transactions, and reports after the import.
The key control is the parent reference. A child row should not rely on a similar company name to find its parent. Names change, punctuation varies, and duplicate names are common. External IDs provide a more durable matching method, provided they are unique and consistently maintained.
Before importing, export a small test set and review the resulting hierarchy in NetSuite. Test at least one parent with multiple children, one child with unique billing details, and one transaction against a child. A successful CSV import message does not prove that the record relationships are correct.
For integrations, define the system of record for each field. NetSuite might own the customer hierarchy while an ecommerce or CRM system owns selected operational attributes. That ownership model should specify whether a parent assignment can be changed downstream and how the change is approved.
Common NetSuite parent-child setup mistakes
The most damaging mistakes come from treating the relationship as a naming exercise rather than as a transaction and reporting design.
Creating the child before defining the parent. This leads to temporary records, duplicate imports, and manual reassignment. Establish the hierarchy and IDs before loading the data.
Using subcustomers for every address. A shipping address is not automatically a separate customer. Create a child only when the account needs independent transactions, balances, ownership, or reporting.
Assuming parent values always flow down. Terms, currency, tax information, contacts, pricing, and addresses require explicit testing. A parent relationship does not eliminate child-level configuration.
Confusing customer hierarchy with subsidiary structure. A parent customer does not replace a subsidiary. Subsidiaries affect accounting and legal reporting, while customer relationships organize external accounts.
Allowing unrestricted reassignment. Moving a child to another parent can change reporting results and relationship context. Establish approvals and review the impact of historical reporting before making structural changes.
Ignoring integrations. If a CRM, ecommerce platform, payment platform, or data warehouse sends customer data to NetSuite, the integration must preserve the parent identifier. Otherwise, repeated synchronization can create duplicate customers or detach children from their parents.
Testing only the customer form. A hierarchy that looks correct on screen can still fail in saved searches, SuiteAnalytics workbooks, transaction forms, statements, and API payloads. Validate every downstream use that depends on the relationship.
How should we report on parent and child customers?
The correct reporting approach depends on whether the report needs individual detail, group totals, or both. Child-level reporting shows the transactions and balances for a specific account. Parent-level reporting provides a broader view across related records, but it requires criteria or joins that include the hierarchy.
Use clear reporting definitions:
Child-level revenue: transactions associated directly with the selected subcustomer.
Parent-group revenue: transactions for the parent and all included subcustomers.
Open receivables by branch: balances grouped by child customer.
Corporate exposure: open balances assessed across the related hierarchy.
Account ownership: parent and child records displayed together for sales or service teams.
Saved searches should be tested with actual hierarchy data rather than assumed behavior. If a report must include all descendants, document whether the logic includes only direct children or deeper levels. A three-level structure introduces additional complexity, especially when reports, integrations, and user permissions were designed for only two levels.
SuiteAnalytics workbooks can help users analyze related customer activity, but the workbook joins and filters still need validation. We should also agree on whether parent-level totals include transactions entered directly on the parent. Without that definition, two teams can produce different answers from the same hierarchy.
When is a custom solution necessary?
A standard parent-child customer relationship is sufficient when the requirement is a straightforward hierarchy with recognizable parent and child accounts. Customization becomes appropriate when the business needs relationship types beyond a simple tree, automated reassignment controls, advanced hierarchy reporting, or synchronization with a source system that uses a different model.
Possible solutions include custom fields, workflows, saved searches, SuiteScript, SuiteAnalytics workbooks, and integration mapping. Each should address a clearly defined gap. A custom field that stores “corporate group” is not equivalent to the native parent-child relationship because it does not automatically provide the same record navigation or hierarchy behavior.
SuiteScript and integration logic should use stable internal or external identifiers rather than display names. It should also handle updates, inactive records, rejected parent references, and changes to the source hierarchy. For any automated process, include logging that identifies the source record, selected parent, NetSuite customer ID, and outcome.
If the account needs a many-to-many relationship, such as one customer belonging to several buying groups, a single parent field is not enough. That requirement needs a separate relationship design, typically involving custom records or another controlled data model.
Conclusion
A NetSuite parent-child relationship is simple to create, but reliable customer hierarchy management requires more than selecting a parent field. We need to define which accounts deserve separate records, distinguish customer relationships from subsidiaries and addresses, configure billing behavior, use stable identifiers, and test reporting and integrations.
The strongest implementation starts with a clear hierarchy and controlled ownership rules. Once the parent and subcustomer records are created, validate the relationship through real transactions, saved searches, statements, payments, and downstream systems. That approach keeps customer data usable for sales, finance, reporting, and automation as the account structure grows.
