A NetSuite audit is an independent, structured review of a live account: how it is configured, what data it holds, what has been built on top of it and how it behaves day to day. It is the right first step when a project has gone wrong, because it replaces opinions and blame with a list of facts. It is also the safest basis for a NetSuite project rescue, whether you keep your current integrator or move to another.
This page is written for finance directors, operations leaders and IT managers at UK small and mid-sized businesses who have a NetSuite account that is not delivering what was agreed.
Signs that a NetSuite audit is overdue
Most troubled projects do not fail dramatically. They drift. The following signals, taken together, usually justify an audit.
- Go-live keeps slipping, or the system went live with a long list of "phase two" items that never arrived.
- Month-end still depends on spreadsheets. Your accountant exports data from NetSuite to rebuild the numbers elsewhere.
- Users work around the system. Sales, warehouse or purchasing staff keep their own lists because they do not trust what NetSuite shows.
- Every change is slow or expensive, and the integrator cannot explain why a small request needs so much effort.
- Integrations fail silently. Orders, payments or stock levels from a web shop or bank feed do not match, and nobody knows when they stopped matching.
- Key knowledge sits with one person, inside the integrator or inside your own team, and there is no usable documentation.
- Compliance worries. You are unsure that VAT returns, Making Tax Digital submissions or payroll reporting to HMRC rest on solid configuration.
None of these proves the platform is wrong. Very often the product is sound and the implementation is the problem. An audit tells you which.
What a NetSuite audit examines
A thorough review follows the same areas regardless of your sector. The depth varies with the scale of the account, but nothing in this list should be skipped.
Configuration and processes
The reviewer checks the chart of accounts, subsidiaries, currencies, tax codes, approval routing, item and customer set-up, and the way transactions flow from quote to cash and from requisition to payment. The question is whether the configuration reflects how your business actually works today, not how it was described in a workshop long ago. This is also where unused modules, duplicated workflows and abandoned custom records come to light. Our overview of NetSuite implementation shows what a sound set-up normally looks like.
Data quality
Data problems are the most underestimated cause of failed projects. The audit samples customers, suppliers, items, opening balances and historical transactions for duplicates, gaps, inconsistent naming and mapping errors left over from the original load. It reconciles key balances with the ledger and with your external accountant's records.
Custom development
Scripts, workflows, custom fields, saved searches and bespoke forms are inspected for logic, error handling, naming and maintainability. The reviewer asks who wrote each item, whether it is documented and whether it still serves a purpose. Heavy or undocumented customisation is a common reason for high running costs, so this section deserves attention. See NetSuite customisation for how it should be approached.
Integrations
Connections to your web shop, bank, payroll provider, CRM, warehouse system or reporting tools are traced from end to end. The audit checks authentication, retry behaviour, monitoring and what happens when a message fails. Our page on NetSuite integrations lists the typical patterns.
Performance
Slow saved searches, heavy scripts, large dashboards and badly designed reports can make an account feel unusable. The reviewer looks for the specific items responsible rather than concluding that "the system is slow".
Security and access
Roles, permissions, segregation of duties, administrator accounts, former employees who still have access, integration credentials and sign-in methods are all reviewed. NetSuite 2026.2 documentation mentions passwordless sign-in with passkeys among its covered areas, so the audit should also check whether your account takes advantage of current authentication options. Finance data in particular needs a clear separation between those who raise and those who approve.
Version and release discipline
NetSuite is upgraded on a planned schedule, twice a year, with monthly improvements in between and separate notes for SuiteApps. The audit establishes whether anyone in your company or at your integrator reads those notes, tests customisations before each release and keeps SuiteApps current. A team that ignores release management accumulates risk. Our page on NetSuite versions and editions explains the cycle.
Using the Release Preview account as a diagnostic tool
Oracle provides a Release Preview account: a temporary, isolated test account, separate from production, that runs the new version of the software. It allows customisations, scripts, web-services integrations, web stores and SuiteAnalytics Connect access to be tested before the upgrade. It remains available until the source account is upgraded, or until it has gone without a login for fourteen consecutive days, after which it is purged. Initially only administrators can reach it, and they can then open it to other users. It must be used for testing only.
For a rescue, this account is valuable. It shows how fragile the existing developments are, without putting your live ledger at risk, and it gives the incoming integrator a safe place to prove their work.
Compliance checks specific to the UK
A UK audit has a statutory layer that a generic review misses. The reviewer should confirm that VAT codes and returns behave correctly, that digital records support your Making Tax Digital obligations, and that payroll and real-time information reporting are handled either in NetSuite or in a connected payroll tool without gaps. Our guides to Making Tax Digital and ERP and the wider NetSuite in the UK page describe the points to verify. Involve your accountant: they often notice reporting weaknesses before anyone in IT does.
Repair, reconfigure or rebuild: reading the audit result
An audit should end with a clear classification of each finding. A useful way to sort them is the following.
| Finding type | Typical example | Usual response |
|---|---|---|
| Configuration gap | Approval routing does not match current structure | Reconfigure in place |
| Data defect | Duplicate customers, wrong opening balances | Cleanse and reload in a controlled way |
| Weak custom code | Undocumented scripts, no error handling | Rewrite or retire, with testing |
| Integration fault | Orders not reaching the ledger reliably | Redesign the connector and add monitoring |
| Security exposure | Dormant administrator accounts, shared logins | Fix immediately |
| Process mismatch | Core business flow does not fit the platform | Reassess scope, possibly the product |
Most accounts land in the first four rows. A true platform mismatch is rarer, but it does happen, and it is better discovered through an audit than after another year of spending. If that is where the findings lead, our page on alternatives to NetSuite and the guide on common ERP project mistakes help frame the decision.
Changing NetSuite integrator without starting again
Switching integrator is often feared more than it should be. Your company holds the licence, and the account, the data and the configuration belong to you. The new team inherits a working system, not a blank page. Handled properly, the change looks like this.
- Commission the audit first, preferably from the team you are considering, so that the scope of the rescue rests on evidence.
- Notify the outgoing integrator formally and ask for a structured handover, referring to your contract terms.
- Run both teams in parallel for a short, defined handover, so that knowledge transfers while the old team is still reachable.
- Move access under your control and then to the new team under named accounts.
- Agree a rescue plan that fixes the highest-risk items first and leaves the rest for planned releases.
Avoid asking the new integrator to "start the project again" unless the audit supports it. Re-implementation is expensive and should be a conclusion, not a reflex. Our advice on choosing a NetSuite partner applies equally to a replacement, with extra weight on their ability to read and inherit someone else's work.
Documents and access to recover before you leave
Whichever way the relationship ends, secure the following before access is withdrawn.
- The original statement of work, proposal and any change requests, so scope can be compared with delivery.
- Functional and technical specifications, process maps and design notes.
- A list of every script, workflow, SuiteApp, custom record and integration, with its owner and purpose.
- Source code for custom scripts and any external middleware, ideally in a repository you control.
- Data migration files, mapping tables and reconciliation reports from the original load.
- Test scripts, user-acceptance sign-offs and training material.
- Credentials for integration users, API tokens and third-party services, rotated once handover is complete.
- Administrator rights for at least two named people in your own organisation.
- Support history and any open issues, with their status.
If any of these do not exist, that in itself is an audit finding, and the new team will need time to rebuild the picture.
A practical rescue plan
A recovery plan should be sequenced, not simply long. A sensible order is as follows.
- Stabilise. Close security gaps, secure backups of critical data and fix anything that blocks invoicing, payment or statutory reporting.
- Restore trust in the numbers. Reconcile ledgers, clean the data that feeds reports and agree the figures your board relies on.
- Repair integrations. Make the flows that move orders, stock and cash reliable and monitored.
- Simplify the customisation. Retire what nobody uses, document what remains and test it against the Release Preview account before each upgrade.
- Re-train users. Many adoption problems come from poor onboarding, as set out in our page on NetSuite training.
- Put support on a proper footing. Agree responsibilities, response expectations and release testing. The page on NetSuite support and maintenance outlines the options.
- Resume the roadmap. Only then return to the modules or entities that were deferred.
Set governance around this plan: a named sponsor on your side, a single backlog, regular reviews and a clear definition of finished for each stage. Rescues fail when they inherit the vagueness of the original project.
How we help
ERP Integrator is a free service that puts you in touch with an ERP integrator suited to your situation. We do not carry out audits or projects ourselves and we are not tied to any software vendor. Tell us what has gone wrong, which processes are affected and what you want from an audit, and we will introduce you to integrators with experience of reviewing and recovering NetSuite accounts. Our page on how it works explains the process.
Frequently asked questions
What does a NetSuite audit actually cover?
A proper NetSuite audit looks at configuration, data quality, custom development, integrations, performance, security and roles, and how far the account has kept up with Oracle's release cycle. It also compares what was promised in the original scope with what is live today. The output is a prioritised list of findings, not a sales proposal.
Can we change NetSuite integrator without starting the project again?
Usually yes. The licence and the account belong to your company, so the system, its data and most of its configuration stay in place. What you need from the outgoing integrator is documentation, scripts, access and a clean handover. An audit by the incoming team shows what can be kept and what has to be reworked.
How do we know whether to repair NetSuite or replace it?
Look at where the problems sit. If they are in the way the account was configured, the data loaded or the customisations written, they can be corrected. If the core processes of the business do not fit the platform at all, the audit will show that too, and it is better to learn it before spending more. Our page on alternatives to NetSuite covers that scenario.
Do we need NetSuite administrator access for an audit?
Yes, a reviewer needs administrator-level, ideally read-focused, access to inspect roles, scripts, workflows and saved searches. Give it to the auditor under a named account rather than sharing a login, and remove it when the work ends. This keeps the audit trail clean and protects your data.
Is a NetSuite release a risk for a project that is already in trouble?
It can be, because customisations, scripts and integrations that were poorly built tend to break first when the platform is upgraded. Oracle provides a Release Preview account so that these can be tested before the upgrade reaches production. A troubled account that has never been tested this way should be treated with extra care.
Sources
- Oracle NetSuite documentation, NetSuite 2026.2 release notes
- Oracle NetSuite documentation, Release Preview accounts
Software names mentioned are trademarks of their respective publishers and are referred to for information only. This site is independent and is not affiliated with any software publisher.