A sub-customer that no longer transacts should generally be made inactive rather than deleted. NetSuite sub-customer deactivation preserves existing transactions, balances, relationships, and audit history while preventing the record from being used for new operational activity in the same way as an active customer. Before making the record inactive, we should review open transactions, recurring billing, integrations, workflows, saved searches, and any users or scripts that rely on the sub-customer. We should also confirm whether the parent customer remains active and whether other sub-customers still need to transact independently. The safest approach is to deactivate each qualifying sub-customer deliberately, verify the inactive status, test downstream processes, and document the decision in the customer record or an administrative change log.
What NetSuite sub-customer deactivation actually does
NetSuite sub-customer deactivation changes the record’s operational status. It does not erase the sub-customer, remove historical transactions, or dissolve the parent-child relationship from the database.
The central control is the Inactive checkbox on the customer record. When selected, the sub-customer is treated as inactive for future record selection and routine processing. Existing sales orders, invoices, cash sales, payments, credits, cases, activities, and other related records remain available for historical reporting and audit review.
That distinction matters because deactivation is a lifecycle decision, not a data destruction action. A sub-customer might be inactive because a branch closed, a buying account was consolidated, a customer relationship ended, or a temporary operating unit no longer places orders. In each case, the business may still need to report on the account’s previous revenue, open receivables, tax treatment, fulfillment history, or communications.
Deactivation also does not automatically:
Close open sales orders or invoices
Void transactions
Write off an outstanding balance
Cancel subscriptions or recurring billing arrangements
Remove the sub-customer from historical reports
Delete contacts, activities, files, or communications
Deactivate every related sub-customer
Deactivate the parent customer
The exact effect depends on the account configuration, permissions, forms, workflows, scripts, and integrations. We should therefore treat the inactive flag as one control within a broader record-retirement process.
For the broader configuration process, see our guide on setting up parent-child customer relationships in NetSuite. That article addresses how to structure customer hierarchies. This article focuses on the later lifecycle question: how to retire a sub-customer without damaging history or downstream controls.
When should a NetSuite sub-customer be made inactive?
A sub-customer should be made inactive when the account no longer needs to participate in new transactions or operational workflows, but its historical record still has business, financial, legal, or analytical value.
Common examples include a closed branch, a duplicate account replaced by another sub-customer, a purchasing location that has been consolidated into its parent, or an account that has stopped trading permanently. In these cases, changing the record to inactive provides a cleaner outcome than deleting it or leaving it active indefinitely.
We should not deactivate a sub-customer simply because it has not had recent activity. Dormancy is a useful review signal, but it is not proof that the account is obsolete. A record with no recent sales might still support an open invoice, a long-term service agreement, a renewal, a return, a tax document, or a customer-specific pricing arrangement.
The decision should answer four questions:
Does the sub-customer still need to receive new orders, invoices, cases, or communications?
Are there open financial or operational obligations?
Does another system still send data to or receive data from this record?
Is the sub-customer’s historical data needed for reporting, audit, or customer service?
If the answer to the first question is no, and the remaining obligations are resolved or intentionally retained, inactivation is normally more appropriate than deletion.
How to deactivate sub-customer records in NetSuite
The standard process is straightforward, but the review around it determines whether the change is safe. We recommend separating the decision, the status change, and the validation rather than treating them as one click.
1. Confirm the correct customer record
Open the sub-customer and verify its name, internal ID, parent customer, subsidiary, currency, primary contact, and recent activity. Customer names can be similar, particularly when multiple locations use the same naming convention.
The internal ID is especially important when integrations, saved searches, SuiteScript, or external systems refer to the record. If the account uses a customer number or external ID, compare that value before changing the status. A mistaken inactivation on the wrong customer record can disrupt order entry while appearing at first to be a routine administrative update.
Review the System Notes subtab before making the change. System Notes provide a useful audit trail for field changes, including who changed the record and when. They also help us identify whether the record has recently been modified by another process.
2. Review open activity and financial obligations
Check for open sales orders, pending fulfillments, invoices, credit memos, customer deposits, payments, returns, cases, projects, subscriptions, or other active records. The relevant record types depend on the account’s NetSuite configuration.
An inactive customer does not automatically resolve those obligations. If an invoice remains unpaid, the receivable still requires collection or accounting treatment. If a sales order remains open, the order management team needs a documented decision about whether to fulfill, close, cancel, or transfer it.
Recurring billing and subscription activity require particular attention. A status change on the customer record should not be treated as a substitute for reviewing the billing arrangement itself. Where SuiteBilling or another recurring process is enabled, inspect the related subscription or billing records and follow the appropriate cancellation or amendment process.
3. Review dependencies outside the customer record
A sub-customer may be referenced by more than transactions. Before deactivation, inspect:
Saved searches and dashboards
Workflows and approval routing
SuiteScript and scheduled scripts
CSV import templates
External integrations and middleware
Customer-specific pricing or terms
Email campaigns and marketing lists
Support cases and service processes
Custom records with customer fields
A List/Record field that points to a customer may continue to store the inactive record as historical data, but a new process that expects to select only active records may behave differently after deactivation. This is why testing should include both record creation and record lookup.
Our guide to the NetSuite custom field setting that controls record deletion explains a related dependency principle. Although inactivation is different from deletion, both decisions require us to understand how other records reference the target record.
4. Select the Inactive checkbox
On the sub-customer record, select the Inactive checkbox and save the record. The exact location and available fields depend on the form, role permissions, and account configuration.
If the checkbox is not visible, do not assume that the record cannot be inactivated. The form may hide the field, the role may lack permission, or a customized form may present the field differently. An administrator should review the form and permission configuration rather than bypassing the control with an untested import or script.
For a small number of records, editing the record directly is generally the clearest approach. For a larger population, CSV import, mass update, or SuiteScript 2.x may be appropriate, but the process should begin with a limited test set and a documented rollback plan.
5. Validate the result
After saving, reopen the record and confirm that Inactive remains selected. Then test the processes that matter to the business. A basic validation should confirm that:
The sub-customer remains visible in historical transactions and reports
New transaction forms do not offer it as an active choice where the configuration excludes inactive customers
Open transactions remain available for authorized follow-up
Integrations do not fail because they expect an active customer
Workflows and scripts do not generate errors
The parent customer and unrelated sub-customers remain unchanged
The result should be documented with the reason, effective date, approving user, and any open obligations. System Notes provide the platform audit record, while an internal change log can capture the business rationale that System Notes do not explain.
Does deactivating a sub-customer deactivate the parent customer?
No. Deactivating a sub-customer does not automatically deactivate its parent customer. The parent record and each sub-customer have their own status, transactions, settings, and operational purpose.
This is one of the most important distinctions in a customer hierarchy. A parent may remain active because other branches continue to order, because the parent receives consolidated statements, or because it remains the commercial relationship owner. Conversely, a parent might be inactive while an account review still requires separate decisions about related records, depending on the account structure and configuration.
We should review the hierarchy after changing one record. Confirm that the remaining sub-customers still point to the correct parent, that consolidated reporting still reflects the intended structure, and that users understand which record should be selected for future transactions.
NetSuite customer hierarchies are not the same as subsidiaries in NetSuite OneWorld. A subsidiary represents an accounting and legal structure, while a parent customer and sub-customer relationship connects customer records. Deactivating a sub-customer does not change the subsidiary structure or the legal entity configuration.
What happens to transactions after a sub-customer is inactive?
Historical transactions remain associated with the sub-customer after it becomes inactive. Inactivation is designed to restrict future operational use, not to rewrite the transaction history.
Users with the right permissions should still be able to locate historical invoices, payments, sales orders, fulfillments, credits, and related records. Reports that include inactive customers should continue to show the historical activity, provided the report criteria do not explicitly exclude inactive records.
The practical issue is that many searches and forms intentionally filter out inactive records. A saved search might use an Inactive is False criterion, while another report may include all customers for revenue analysis. If a finance or service team expects to find the record after deactivation, the relevant search must be reviewed.
For financial reporting, we should also verify whether the report is based on transaction joins, customer joins, or both. A report filtering on the customer record’s active status can exclude historical transactions even though the transactions themselves remain intact. That is a reporting design issue, not a data loss event.
Should we delete a sub-customer instead?
In most cases, no. Inactivation is safer when the sub-customer has transactions, balances, references, or historical value. Deletion removes the record and can create dependency errors or eliminate the context needed to interpret historical activity.
Deletion is appropriate only after a controlled data governance review confirms that the record is genuinely erroneous, unused, and not required for audit, reporting, integration, or legal retention. Even then, NetSuite may block deletion when dependent records exist. Removing references or changing a custom field’s behavior to permit deletion should not be used as a shortcut for ordinary account cleanup.
A duplicate record may require a different approach. The correct answer could be to preserve one record, map future activity to it, close or reclassify open transactions, and inactivate the duplicate. That preserves an audit trail while preventing additional activity on the wrong customer.
Bulk deactivation requires stronger controls
Bulk deactivation is efficient, but it increases the impact of a mapping error. A CSV import or mass update should not rely only on customer names because names are not guaranteed to be unique. Use internal IDs or verified external IDs, and include a clear source file showing the records selected for inactivation.
A controlled bulk process should include a test import, a saved export of the original status, a review by the business owner, and post-import validation. We should also confirm whether workflows, scripts, or integrations execute during the update. A bulk change that triggers notifications or downstream synchronization requires additional testing.
SuiteScript 2.x is another option for controlled automation. A script using the customer record’s `inactive` field can update records programmatically, but the script should log each internal ID, previous status, new status, timestamp, and error. Governance limits, permissions, deployment status, and error handling should be tested before production execution.
The goal is not simply to change many records quickly. The goal is to create a repeatable process that is explainable, reversible where possible, and safe for reporting and integrations.
A practical control model for inactive sub-customers
A mature process treats deactivation as a customer lifecycle control. The record owner identifies the reason, finance reviews open balances, operations reviews open transactions, and the NetSuite administrator checks technical dependencies.
We recommend defining a standard inactive-record policy that answers these questions:
Who can approve a sub-customer deactivation?
What conditions require finance review?
How long should open transactions remain unresolved?
Which integrations need notification?
Should inactive customers be excluded from user-facing searches?
How will reactivation be approved?
Where will the business reason be documented?
Reactivation also deserves attention. An inactive sub-customer should not be made active casually because a user needs to enter one transaction. The request should confirm that the account is still valid, the parent relationship is correct, pricing and terms are current, and integrations will accept the record. Temporary reactivation without an owner or expiry date creates the same data-quality problem the original deactivation was intended to solve.
If the process involves complex workflows, custom records, or integration dependencies, contact Versich to discuss NetSuite administration and record lifecycle controls.
Conclusion
NetSuite sub-customer deactivation is a controlled way to retire an account without destroying its history. The Inactive checkbox changes future operational use, but it does not close financial obligations, cancel recurring billing, or remove dependencies from workflows and integrations.
The safest process is to verify the record, review open activity, inspect technical references, make the sub-customer inactive, test downstream behavior, and document the reason. When the hierarchy is complex or the change affects a large population, a governed administrative process protects both data quality and business continuity.
