Why most NetSuite environments fail their first audit
The companies that struggle in their first audit share a common profile. They built their NetSuite environment during the growth phase, when the priority was speed. Every configuration decision, every workaround, every piece of custom code that bypassed the standard approval chain made sense at the time. None of it was documented. By the time the auditors walk in, the environment reflects 3 or 4 years of decisions no one can fully explain.
There are 3 failure patterns that appear in nearly every pre-IPO audit finding letter. They are specific, predictable, and avoidable.
Segregation of duties violations
NetSuite's user permission structure is flexible enough that small companies routinely grant staff access that creates direct control conflicts. A Controller who can both create and approve journal entries. An accounts payable manager who can add new vendors and release payments. A system administrator with unrestricted access to every financial record. Each of these is a segregation of duties violation. PCAOB auditors test for them with user access reviews, and they document every instance.
The underlying issue is that NetSuite's default user roles are too broad for a public company environment. The standard roles most companies start with contain permission combinations that create conflicts when left unmodified. Most companies adjust these roles over time but do not document what was changed or why, which creates a second problem: the record of those changes does not exist.
Missing or undocumented approval workflows
Auditors require evidence that every material transaction was reviewed and approved before posting. In NetSuite, that means workflow-enforced approval gates on journal entries, purchase orders, vendor bills, expense reports, and period close procedures. If the approval happened via email, Slack, or verbal sign-off and was then entered into NetSuite by someone else, the auditor cannot verify it. The control does not exist for audit purposes.
What auditors actually test is whether the system prevented an unauthorized transaction from posting. Manual approval processes layered on top of NetSuite are not sufficient. The workflow must enforce the control before the record is committed to the ledger. Archer's Approvals Appis built specifically to enforce this at the system level, with audit-ready evidence generated automatically.
Undocumented system changes
Every piece of custom code, every automated rule, and every third-party tool installed in the live system must be documented in a way that satisfies PCAOB requirements for managing system changes. What it does, when it was put in place, who authorized it, and what testing happened before it went live. Most pre-IPO companies cannot produce this documentation because it was never created.
Auditors treat undocumented system changes as a control gap. If a change affects a financial process, a missing record of that change can escalate from a minor finding to a significant deficiency or material weakness depending on the risk the auditor assigns to the transactions it touches.
The NetSuite environment that supported rapid growth was built for speed. The environment that survives a PCAOB audit was built for evidence. They are not the same configuration.
The 5 IT general control categories PCAOB auditors test in NetSuite
IT general controls are the baseline checks every PCAOB auditor applies to any financial system that supports public company reporting. For NetSuite specifically, all 5 categories are tested through a combination of interviews, direct observation, and review of system-generated records. Policy documents alone are not sufficient. The controls must be built into the system and demonstrably operating.
Access controls
How users are granted and removed from the system. Who has access to what, and is that access appropriate for their role. Evidence that staff who leave the company lose system access promptly. Formal review of user access conducted at least once a year.
Change management
Every change to the live system documented and formally approved before it goes in. Changes tested in a separate environment before reaching production. A named individual responsible for authorizing urgent changes. A complete log of what changed, when, and why.
Backup and recovery
NetSuite's Oracle-managed infrastructure handles the underlying data backup. Companies must document their understanding of what Oracle is responsible for versus what the company owns, and confirm that recovery capabilities meet financial reporting requirements.
Operations controls
Automated processes run on schedule and exceptions are flagged. Errors in system-generated transactions are caught, investigated, and resolved within a defined window. A clear process for raising and resolving operational issues.
Monitoring
A complete record of who accessed what and when. Evidence that someone reviews login failures, unusual access activity, and changes to sensitive records on a regular basis. The record must be reviewed, not just retained.
NetSuite passes the infrastructure checks automatically because Oracle manages the underlying systems. The controls companies fail are the ones they must build and operate themselves: managing who has access, keeping a record of every system change, and actually reviewing the activity log rather than simply having one. Of the 5 categories, the record of system changes generates the most audit findings at pre-IPO companies because the documentation gap is almost always large and takes the longest to close.
The 4 financial process controls auditors require
Beyond the IT general controls reviewed above, PCAOB auditors test the approval and oversight controls tied directly to financial statement line items. In NetSuite, 4 process areas draw the most scrutiny at life sciences companies. Each must be enforced at the system level, not managed through policies or informal processes.
01. Journal entry approval
Every manual journal entry must be reviewed and approved by someone other than the preparer before it posts to the general ledger. NetSuite can enforce this rule automatically, but it must be set up to reflect the company's approval authority limits. The system must capture who approved the entry, when, and the record must not be changeable after posting. Auditors request a full list of all journal entries for the period and review a sample. For each one, they expect to find an approval record inside NetSuite, not an email chain.
02. Purchase order approval
PO approval workflows must enforce dollar threshold limits and route to the appropriate authority level based on the company's approved delegation of authority. A $50,000 purchase order approved by someone with a $25,000 limit is a control failure even if the purchase was legitimate. Auditors test whether the system would have prevented an out-of-authority approval or simply allowed it. Most pre-IPO NetSuite environments allow it.
03. Vendor bill approval
Three-way matching, the comparison of the purchase order, the receiving record, and the vendor bill, must be enforced before a vendor bill is approved for payment. NetSuite can automate this matching and hold bills that do not reconcile. The configuration must be in place and enforced. Auditors look for evidence that the system flagged discrepancies and that someone with appropriate authority resolved them before the payment released.
04. Period close lock
Once a period is closed, no transactions should post to it without documented approval from the Controller or CFO. NetSuite's period close functionality locks prior periods, but the lock must be enforced and the bypass permission must be restricted to a named individual. Auditors test whether the lock exists, who has permission to override it, and whether any override activity was reviewed and approved during the audit period.
A note on Archer's Approvals App.Archer built the Approvals Appbecause building multi-level approval routing with proper authority limits from the ground up in NetSuite takes months when done manually. The Approvals App is in use at more than 80 percent of Archer's publicly traded life sciences clients. It compresses the time to fully operational controls from months to weeks and generates the evidence record the auditor needs automatically. For life sciences companies with 21 CFR Part 11obligations, Archer's electronic signature module ensures that approvals also meet FDA's requirements for identity confirmation and record integrity.
What a SOX-ready NetSuite looks like versus what most pre-IPO companies actually have
The contrast below is drawn from actual audit preparation engagements. It is specific rather than theoretical because the gap is always specific.
| Control area | SOX-ready configuration | What most pre-IPO companies have |
|---|---|---|
| User access | User permissions designed to prevent conflicts. Quarterly access reviews. Staff who leave the company are removed from the system the same day. The system administrator has no ability to approve financial transactions. | Permissions granted informally over time. No scheduled review process. System administrator access shared across finance and IT staff. Some former employees still active in the system. |
| Journal entry approval | System requires a second person to approve every journal entry before it posts. Approval authority is tied to dollar thresholds. No entry moves to the general ledger without a timestamped approval record. | Approvals happen by email or verbal sign-off. The same person who prepares the entry posts it. No system-level enforcement exists. |
| System change records | Every change to the live system is documented and approved before it is applied. All changes are tested in a separate environment first. A named individual is responsible for authorizing urgent changes. | Changes applied directly to the live system by the administrator. No change log. A test environment exists but is not consistently used. |
| Period close | Prior periods are locked once the Controller signs off. Override access is restricted to 1 or 2 named individuals. Any override is logged and reviewed by the Audit Committee. | Lock is enabled but override access is given to multiple staff including junior accountants. No review process for overrides. |
| Activity log | A complete record of every financial record change is enabled and reviewed monthly. Unusual activity is flagged and investigated. Retention matches regulatory requirements. | Activity logging is on at the system level but no one reviews it. No process for flagging or following up on unusual changes. |
| Approval authority limits | A formal approval authority policy is documented and enforced in the system. NetSuite blocks any approval where the user's authorized limit is below the transaction amount. | The policy exists as a document. It is not enforced in the system. Any approver can approve any amount. |
| Electronic signatures (life sciences) | Electronic approvals require individual login credentials and a second confirmation at the moment of signing. The record captures the user's intent, the timestamp, and their identity. Archer's 21 CFR Part 11 module and Quality Management System are configured together in most life sciences implementations. | Logging into the system is treated as the signature. No second confirmation step. Approval records do not capture what the regulation requires. |
The pattern is consistent. A SOX-ready configuration requires deliberate decisions made either during the original implementation or during a structured remediation program. The typical pre-IPO configuration reflects organic growth without that design layer in place.
Timeline: how long it takes to close control gaps
Most organizations should expect at least 3 months for a company with minor gaps, and companies with significant deficiencies in access controls and change management should budget 9 months or more. The timeline below reflects realistic sequencing, not the best-case scenario.
Months 1 to 2
Controls assessment and gap identification
Document every user's access, every system change made to date, every approval process, and every automated rule in the system. Identify conflicts and gaps. Produce a prioritized list of what needs to be fixed and in what order. This work cannot be rushed without risking incomplete findings.
Months 2 to 4
Access redesign and remediation
Redesign user permissions to eliminate conflicts. Move staff to updated access levels. Remove access from anyone who no longer needs it, including former employees. This phase requires coordination with HR and often meets resistance from staff accustomed to broader access. Budget time for that conversation.
Months 3 to 6
Approval workflow build and testing
Build system-enforced approval rules for journal entries, purchase orders, vendor bills, and period close. Test them in a separate environment before applying to the live system. Begin collecting the approval records the auditor will eventually review.
Months 4 to 7
System change documentation
Create records for every system modification made in the past, working backward. This is the most time-consuming phase for companies with complex environments. Every piece of custom code, every automated rule, and every installed tool requires a documented record. For life sciences companies, electronic signature validation adds a parallel workstream.
Months 6 to 9
Operating period and evidence accumulation
Auditors need to see controls that have been working, not controls that were just put in place. Most auditors require at least one full quarter of documented operation before they will conclude the controls are effective. Companies that finish building controls in month 6 cannot demonstrate that quarter of evidence until month 9 at the earliest.
For companies in regulated industries, the timeline often extends further. Archer's system validation engagementsfor CDMOs, specialty pharmacies, and biotech companies routinely run 9 to 14 months because FDA's electronic records requirements under 21 CFR Part 11are separate from, and in addition to, what the financial audit requires. Both must be in place before the first audit year.
The one thing most CFOs do wrong
They wait until the IPO process is already underway.
The decision to pursue an IPO triggers a cascade of workstreams: underwriter selection, auditor engagement, legal preparation, financial restatement if needed, and investor relations infrastructure. Every one of these workstreams has a natural priority over "fix the ERP controls" because none of the other workstreams will surface the ERP problem until the auditor does. And by the time the auditor does, the timeline problem is structural, not fixable.
A PCAOB auditor who finds a material weakness during the first integrated audit does not simply note it for next year. They report it in the audit opinion. A material weakness disclosed during the IPO process can significantly delay or complicate an offering and may affect investor confidence in ways that are difficult to reverse within the original timeline.
The CFOs who avoid this outcome begin the conversation when a 24-month IPO timeline is set. At that point, 9 months of remediation work leaves 15 months of clean operating history before the auditors arrive. That is a passable position.
The auditor's job is to find control deficiencies. Give them 18 months of remediated, documented, operating controls and the conversation changes from finding problems to verifying adequacy.
Archer's Approvals Appand Delegation of Authority module were built specifically because building these controls from scratch in NetSuite takes too long for companies already running behind the IPO timeline. At more than 80 percent of Archer's publicly traded life sciences clients, these tools reduced the time from gap identification to operating controls by 60 to 70 days compared to building everything from the ground up. For a company on a tight pre-IPO timeline, 60 days is the difference between passing and disclosing. Learn more about Archer's NetSuite implementation servicesfor life sciences.
Frequently asked questions
Q: Our auditor said we have a "significant deficiency" in journal entry controls. What does that actually mean and how serious is it?
A: A significant deficiency sits between a control deficiency and a material weakness on the severity scale. It means auditors have found a control design or operating failure that is important enough to flag to those charged with governance, typically your Audit Committee, but not severe enough on its own to conclude that a material misstatement could occur without being detected. For journal entry controls specifically, a significant deficiency usually means either the preparer-approver separation is not enforced at the system level, or the approval authority thresholds are not configured to match your delegation of authority policy. Both are fixable. The question is whether you fix it before it becomes a material weakness. That determination hinges on the dollar volume of transactions affected and whether any actual misstatements occurred. If the auditor is raising this before your integrated audit year, you have runway. Commission the remediation immediately.
Q: We are a biotech company that has never operated under SOX. Do we need to comply with Section 302 and Section 404 at the same time?
A: Section 302 requires your CEO and CFO to certify quarterly and annually that you have evaluated disclosure controls and procedures and are reporting accurately on their effectiveness. This requirement begins with your first quarterly filing after the IPO closes. Section 404 requires management's assessment of internal control over financial reporting and, for most companies, an auditor attestation on that assessment. The 404 attestation requirement typically applies in the second full fiscal year as a public company for accelerated filers, though the management assessment begins earlier. The practical implication is that you need the controls in place before 302 certifications begin, because certifying that controls are effective when they are not is a legal exposure, not just an audit finding. Your outside counsel and auditor will set the specific timeline based on your expected market cap and filer status. Build the NetSuite control environment as if both requirements apply on day one. Retrofitting later costs more than building correctly in advance.
Q: How do auditors test whether our NetSuite roles actually enforce segregation of duties, versus just taking our word that the policy exists?
A: They do not take your word. The audit procedure starts with a full list of every active user, every level of access assigned to them, and every action they are permitted to take. The auditor runs that list against a defined set of access conflicts to identify anyone who can both initiate and approve the same type of transaction. Common conflicts they look for include the ability to create and approve the same transaction type, the ability to add new vendors and release payments to them, and anyone with unrestricted administrative access combined with authority over financial records. If conflicts are found, the auditor asks for a compensating control, meaning a separate oversight process that reduces the risk. Compensating controls are harder to document and maintain than simply removing the access conflict in the first place.
Q: Our NetSuite implementation partner originally set us up and they no longer work with us. We have no documentation of what was customized. Where do we start?
A: Start by producing a complete inventory of everything that has been added to or modified in the system since it was first set up. NetSuite provides a way to export this list from the system settings. From there, identify which items touch a financial process and prioritize documenting those first. For each item, you need to record what it does, when it was put in place, who authorized it, and what testing was done before it went live. Where no testing record exists, document how the modification behaves today and create a record of that review. This is not ideal, but it is defensible when combined with a formal process for managing all future changes. Auditors understand that pre-public companies operated without formal procedures. What they require is evidence that those informal practices have stopped and that a proper process is now in place for the period under audit.
Q: We are a CDMO and our CFO thinks the 21 CFR Part 11 requirements are separate from SOX. Are they, and does satisfying one help with the other?
A: They are separate regulatory frameworks with different authorities, different scopes, and different documentation requirements. 21 CFR Part 11 is an FDA regulation that governs electronic records and electronic signatures used in FDA-regulated activities. SOX is a securities law that governs internal control over financial reporting. They overlap in NetSuite when the same financial system is also used to manage regulated records, which is common in CDMOs where project accounting, batch records, and compliance documentation coexist. Meeting Part 11 requirements does help with the financial audit in specific ways. Part 11 sets a higher bar for activity records, user identity confirmation at the point of signing, and access controls than SOX requires. A system built to satisfy FDA inspectors will generally meet or exceed what financial auditors need in those same areas. The gap tends to be in the records of system changes: Part 11 requires formal testing documentation before any system is put into use, which is more rigorous than what SOX auditors require but satisfies them when structured correctly. Archer's system validation engagementsfor CDMOs are designed to produce documentation that satisfies both sets of requirements at the same time, avoiding the duplicate effort that results when the two are treated as entirely separate projects.