SOX Controls in NetSuite for a pre-IPO company work when three things are ready before the auditor arrives: roles that enforce segregation you can prove, approvals on the transaction paths they will sample, and change evidence for configuration and scripts that matches System Notes and deployment logs. With that in place, NetSuite SOX compliance becomes a sampling exercise rather than a scramble through screenshots.
The trap is treating access reviews and SuiteFlow diagrams as the control. Auditors sample users, transactions and changes. A clean role spreadsheet that never matches who posted journals in Q3 fails the sample. An approval flowchart that is not enabled on the journal form fails the walkthrough.
Start from the financial statement assertions and the processes that feed them, then name the NetSuite objects that hold the control. For a typical pre-IPO SaaS or product company those processes include order-to-cash, procure-to-pay, record-to-report, payroll or contractor spend, and IT general controls over access and change. Revenue may also sit under NetSuite ASC 606 requirements that already demand evidence of performance obligations and recognition timing.
Write one row per control: assertion, process, NetSuite object (role, approval routing, saved search, script deployment, period close checklist), owner, frequency and the evidence an auditor can pull without a custom export. Keep the sheet short. Thirty controls you can sample beat ninety controls that live only in a policy PDF.
Confirm with the account owner which SuiteApps, bundles and custom records are in scope. A control that points at a field that was never deployed wastes the walkthrough hour.
Role design for SOX is a testable matrix rather than a permission dump. Pair each sensitive duty with a compensating duty that must live in a different role, then prove that production users do not hold both. Our guide to NetSuite segregation of duties for small finance teams covers the pairing logic for thin teams; here the bar is higher because the auditor will pick users from the employee list and ask for their role assignments on a date.
Use standard NetSuite roles as the base and document every customization. Prefer global permissions only where a named control owner has signed off. Separate roles that create vendors from roles that pay them. Separate roles that enter journals from roles that approve them. Separate roles that deploy scripts from roles that own the production account.
Run a quarterly access review that exports employees, roles and last login, then record who reviewed exceptions and what changed. The NetSuite roles and permissions access review guide walks through that export and exception handling. Store the signed review with the SOX pack so the sample can start from a dated file instead of a live screen.
Auditors sample journals, vendor bills, customer credits, period-end adjustments and often master-data changes. Put SuiteFlow or native approval routing on those forms before you write more policy. The control is the enabled routing plus the System Notes that show who submitted and who approved, on which date, against which threshold.
Document the thresholds in the same place the workflow reads them. A USD 5,000 journal threshold that exists only in a Slack message will not match the workflow definition the auditor downloads. For multi-subsidiary OneWorld accounts, confirm whether routing is subsidiary-aware and whether the CFO role can self-approve in a subsidiary they also post in.
Test a reject-and-resubmit path. Many samples fail because the approval history shows only the final approve and loses the earlier rejection. Keep inactive workflows listed so nobody re-enables a draft path during close.
IT general controls for NetSuite focus on who can change roles, workflows, scripts, bundles and accounting preferences, and how those changes reach production. Capture System Notes on the role, workflow and script deployment records. Keep SuiteCloud Development Framework or Account Customization Project release tickets with the ticket id, reviewer, sandbox test result and production deploy time.
A change that moves from sandbox to production with no ticket fails the sample even when the script is correct. Tie each production deploy to a named request and a named approver who does not hold the Administrator role used to deploy. For bundle updates and SuiteApp installs, keep the vendor release note and the internal acceptance sign-off next to the install date.
Period-end preference changes (closing tasks, accounting periods, revenue settings) need the same trail. If a preference can move recognition or cut-off, treat it as a financial control change.
Take a hypothetical US pre-IPO software company, illustrative only, with 180 NetSuite users and a target IPO window 14 months out. External auditors selected 25 users and 40 journal entries from Q2 for SOX walkthroughs and operating-effectiveness testing.
Of the 25 users, four held both a journal-entry role and a journal-approval role because a temporary close role from the prior year was never removed. Two contractors still had Administrator access after a sandbox project ended in March. The access review for April listed the four journal conflicts and missed the contractors because the export filtered to full-time employees only.
On the journal sample, 40 entries were selected above USD 10,000. Thirty-six showed a submitter and a different approver in System Notes. Three were posted by a CFO role with self-approval still enabled. One was a reversing entry with no approval because the workflow excluded the reverse journal type.
Remediation before the next quarter: remove the temporary close role from production, extend the access export to all login-enabled users, disable self-approval on the CFO journal role and add reverse journals to the SuiteFlow audience. Re-test on a fresh sample of 15 journals and 10 users. The pack now shows the defect, the fix date and the re-test result an auditor expects to see.
Period-end is where samples concentrate. Prove that accounting periods open and close under a named owner, that adjusting journals above threshold follow approval, and that vendor bank-detail and customer credit-limit changes leave System Notes a reviewer can filter. Link the close checklist to the same people named in the SOX matrix so the walkthrough does not invent a second org chart.
Master-data edits often sit outside finance workflows. If AP clerks can change remittance bank details without a second approver, payment fraud and SOX testing collide. Put approval or a dual-control saved search on those fields and review hits weekly during the pre-IPO year.
Our note on NetSuite audit evidence in System Notes shows how to pull who-changed-what without screenshots of every record. Use that method for the journal and vendor samples so evidence stays consistent across quarters.
Build one folder structure the auditor can follow: process narratives, control matrix, role and SOD reviews, workflow definitions, System Notes extracts, change tickets and period-close checklists. Name files with the period and control id. When the auditor asks for five journals, hand the extract and the approval history in the same zip rather than scheduling another screen share.
Rehearse the walkthrough with the control owner using last quarter's sample. If the owner cannot find the approval on a live transaction in five minutes, fix the routing or the evidence path before the auditor arrives. CuriousRubik implementation teams often fold this evidence design into a pre-IPO NetSuite hardening pass so roles, approvals and change tickets are testable before the first external sample. Our NetSuite work in the United States covers the wider US operating setup, including NetSuite 1099 reporting controls that often sit beside SOX for US vendor spend.
No. NetSuite provides roles, approvals, System Notes and deployment logs that you configure into controls. SOX Controls in NetSuite are the design and evidence you put around those features, reviewed against your auditor's sampling plan.
Do not. Administrator bypasses the segregation the sample tests. Use a named close role with the minimum permissions and keep Administrator behind a break-glass request with a ticket and an end date.
No. Diagrams show design. Operating evidence is System Notes on the sampled transactions showing submitter, approver, timestamps and that the workflow was deployed and active in that period.
Re-test in the next period after the fix date, on a fresh sample, and keep both the finding and the clear re-test in the pack. One fixed user is design evidence; a clean sample is operating evidence.
Mirror the control design in sandbox for testing, then prove production matches. Auditors sample production. Sandbox screenshots without a production deploy ticket do not close the change-control sample.