Companies tend to think about audit readiness in terms of the financial statements. Do the numbers tie out, are the accruals reasonable, is revenue recognized correctly. All true, all important. But the part of a NetSuite audit that catches companies off guard isn’t the numbers. It’s the system itself.
Auditors increasingly treat the ERP as a control environment. They want to know who can do what, whether anyone can both create and approve a transaction, whether administrator access is restricted, whether changes to the system are controlled, and whether there’s evidence of all of it. For companies heading toward their first external audit, a SOX requirement, a funding round with financial diligence, or an acquisition, the system access questions are the ones that produce findings.
The good news is that NetSuite has the tools to pass every one of these checks. The bad news is that most accounts weren’t configured with them in mind. Here’s what auditors look at, what typically goes wrong, and how to fix it before anyone asks.
What Auditors Actually Test
Segregation of duties
The core principle: no single person should be able to initiate, approve, and record a transaction end to end. In NetSuite terms, that means looking at whether the same role can create a vendor and pay that vendor, enter a journal entry and approve it, create a customer credit and apply it, or change an item’s cost and post inventory adjustments.
Auditors will pull your role definitions and map permissions against a conflict matrix. Roles that combine conflicting permissions are findings, even if the person holding the role would never abuse them.
Administrator access
The Administrator role in NetSuite can do everything. Auditors expect it to be held by a small, named, justified set of people, with evidence that the list is reviewed periodically. Ten administrators in a 60-person company is a finding. An administrator role assigned to a consultant whose project ended two years ago is a finding. A shared administrator login is a serious finding.
User access reviews
Evidence that someone reviews who has access to what, on a regular cadence (quarterly is the common standard), and removes access that’s no longer appropriate. Not just that the review happens, but that it’s documented: who reviewed, when, what was changed.
Joiner, mover, leaver process
How access is granted when someone joins, changed when they move roles, and revoked when they leave. Auditors sample terminated employees and check whether their NetSuite access was removed promptly. Former employees with active logins are among the most common findings in a first audit.
Change management
Who can modify the system, how changes are tested before reaching production, and whether there’s a record. Scripts, workflows, custom fields, and configuration changes all count. Auditors want to see that changes go through sandbox, are approved, and are documented. Direct edits in production with no trail are a control weakness.
Period close controls
Whether accounting periods are locked after close, who can reopen them, and whether there’s evidence of the close checklist being completed. Posting to closed periods without a documented reason is a classic finding.
Audit trails
NetSuite logs system changes and transaction history. Auditors expect those logs to be enabled, retained, and reviewable. The System Notes and Transaction Audit Trail features need to be on and understood.
What Typically Goes Wrong
In accounts that were implemented quickly, or that have been running for years without a formal review, the same gaps appear repeatedly.
Roles were built for convenience during implementation. Someone needed to do a task, the quickest fix was adding a permission, and nobody went back to tighten it. Over time, roles accumulate permissions far beyond what the job requires.
Standard roles were customized in ways nobody documented, or custom roles were copied from Administrator and trimmed, which leaves a lot of residual access.
Nobody owns offboarding. HR tells IT, IT handles email and laptops, and NetSuite access falls through the gap.
Approvals exist on paper but not in the system. The policy says journal entries over a threshold need controller approval, but there’s no approval workflow enforcing it, so the control depends on people remembering.
Sandbox exists but changes get made directly in production anyway, because it’s faster.
Periods are left open because closing them creates friction when someone needs to post a late adjustment.
How to Get Ready
Start with a role and permission audit
Export every active role, every permission on each role, and every user-role assignment. Map the permissions against a segregation-of-duties matrix. Identify conflicts, over-provisioned roles, and users with multiple roles whose combination creates a conflict. This is tedious and it’s the foundation of everything else.
A structured NetSuite health check typically includes exactly this review, along with the broader configuration, customization, and process assessment, and it produces the prioritized remediation list that an audit prep effort needs.
Redesign roles around jobs, not people
Build roles that reflect actual job functions, with the minimum permissions each needs. Separate initiate and approve functions. Restrict sensitive permissions (vendor record creation, bank account changes, journal approval, period reopening) to specific roles with small membership.
Shrink the administrator list
Define who legitimately needs Administrator and why. Move everyone else to a tightly scoped custom role. Document the justification for each remaining administrator.
Enforce approvals in the system
Use approval workflows for journal entries, vendor bills, purchase orders, and credit memos above defined thresholds. A control that lives in a workflow produces evidence automatically. A control that lives in a policy document does not.
Formalize access reviews
Set a quarterly review. Pull the user-role report, have managers confirm their team’s access, remove what’s no longer needed, and file the signed-off review. After the first cycle it takes an hour.
Build the offboarding link
Make NetSuite deactivation an explicit step in the termination checklist, with a named owner and a time standard (same day is reasonable).
Lock periods and control reopening
Close periods on schedule. Restrict the permission to reopen them to the controller. Require a documented reason when it happens.
Route changes through sandbox
Establish the rule that customizations and configuration changes are built and tested in sandbox, approved, and then deployed, with a change log. For a company with regular development activity, this needs an owner and a process.
The Ongoing Part
Audit readiness isn’t a project you complete. Access drifts, people change roles, new customizations arrive, and the next audit is twelve months away. The companies that pass audits cleanly year after year have someone responsible for keeping the controls in place between audits: running the quarterly access reviews, maintaining the change log, keeping administrator access tight, and watching for drift.
For companies with a strong internal NetSuite administrator, that’s part of the role. For companies without one, it’s one of the recurring responsibilities that a NetSuite managed services arrangement handles well, since the same team that manages users and deploys changes is positioned to keep the control evidence current.
Why It’s Worth Doing Before You’re Asked
Companies that wait for the auditor to find these issues pay twice: once for the finding and once for the scramble to remediate under deadline. Companies that tighten their NetSuite controls before the audit walk in with clean role definitions, documented reviews, enforced approvals, and a change log, and the system portion of the audit becomes a formality.
It also makes the business safer, which is the actual point. Controls exist because the alternative is discovering a problem after it’s happened. A NetSuite account with proper segregation, limited administrator access, and enforced approvals isn’t just audit-ready. It’s a system you can trust.