Most manufacturers running NetSuite have at least one role that quietly violates separation of duties. Not because anyone was careless, and almost never because anyone acted in bad faith.

It usually traces back to a single Tuesday afternoon. Someone couldn't finish a task. A permission got widened to unblock them. It worked, the immediate problem went away, and nobody went back to narrow it again.

Multiply that by four years, three reorganizations, a couple of ERP-adjacent projects, and a handful of departures, and you end up with a permission structure that nobody designed and nobody owns.

Why this happens in NetSuite specifically

NetSuite's permission model is granular and additive. Roles are built from individual permissions, each set to a level — typically View, Create, Edit, or Full — across areas like Transactions, Reports, Lists, and Setup. That granularity is a genuine strength. It's also what makes drift so easy.

Three forces compound:

  • Modifying a role is faster than designing one. When someone is blocked, cloning and widening an existing role takes minutes. Mapping out what that person should actually be able to do takes an afternoon nobody has.
  • The person widening the permission is solving a real problem. Every individual grant is defensible in isolation. That's precisely why the pattern is invisible — there is no single bad decision to point at.
  • Nothing forces a review. Implementations get scrutinized. Go-lives get signed off. Ongoing role drift has no equivalent checkpoint. If no one owns NetSuite administration, no one owns the permission review either — and permission review is exactly the kind of work that never becomes urgent until an auditor makes it urgent.

The three combinations we find most often

These are the pairings worth checking first. They're common, they're consequential, and each one can usually be resolved without disrupting how anybody works.

01

Vendor record edit + bill approval

The same person can create or modify a vendor record and approve payment to that vendor. This is the most common combination we find, and the one with the most direct financial exposure.

It's also the pairing that tends to surface when duplicate invoices go undetected. The control isn't just about deliberate fraud — it's that a single person creating, editing, and approving has no second set of eyes on any part of the chain, so ordinary mistakes propagate straight through to payment.

02

Item record edit + inventory adjustment

Costing fields can be changed and the resulting inventory variance absorbed in the same session, by the same person. Nothing in the audit trail looks unusual, because technically nothing unusual happened — two legitimate actions occurred, each within the user's granted permissions.

This one matters more in manufacturing than in distribution, because standard cost changes ripple into COGS, margin reporting, and variance analysis. If your monthly cost variances are difficult to explain, this pairing is worth ruling out before you assume the problem is in production.

03

Employee record edit + payroll processing

Less common in smaller instances, and often absent entirely if payroll runs outside NetSuite. But where it exists, it is remarkably durable — it survives every reorganization, because roles almost never get re-reviewed when the org chart changes.

Worth checking even if you're confident it doesn't apply. Role assignments frequently outlive the job the role was built for.

Why manufacturers get hit harder than most

Separation of duties is a general internal-controls problem, but a few things about manufacturing environments make it materially worse.

Finance teams are small and everyone wears several hats. A 300-person manufacturer might have four people in finance. Textbook separation of duties assumes more bodies than most plants have. The controls have to be designed around the team that actually exists.

Multi-site operations clone and drift. When a second or third site comes online, roles typically get copied from the original site and then adjusted locally. Each copy drifts independently. Two years later you have five variants of "Site Controller," each with a slightly different permission set, and no documentation of why they diverged.

Compliance exposure is real and specific. Manufacturers serving aerospace, medical device, defense, or ITAR-controlled markets get audited on access controls by customers, not just by their own auditors. A permission structure nobody can explain is a finding waiting to happen — and it's a finding that surfaces during a customer audit, at the worst possible moment.

OneWorld creates false confidence. Subsidiary restrictions limit which records a role can reach, which genuinely does contain the blast radius. But it doesn't address what that role can do within its assigned subsidiary. A role scoped to one subsidiary can still create a vendor and approve a payment to it. Scope and capability are separate questions, and it's easy to assume the first one resolved the second.

How to actually run the audit

This does not require a project. For most instances it's a few hours of focused work.

  1. Inventory your custom roles. Start with the full list of roles in your account and identify which are actually assigned to active users. Most instances carry roles that nobody has held in years — those are pure risk surface with zero operational cost to remove.
  2. Extract the permission set for each active role. You want this as data you can sort and compare, not as a series of screens you click through. Comparing roles side by side is where the divergence becomes visible.
  3. Flag the three pairings above first. Filter for roles holding Edit or Full on vendor records alongside any bill approval capability, then repeat for the item and employee combinations.
  4. Check who actually holds each flagged role. A role with a problematic pairing that's assigned to nobody is a cleanup task. One assigned to three people in accounts payable is a control gap.
  5. Split, then document why. The documentation matters as much as the fix. The reason permission creep recurs is that the original design rationale was never written down, so the next person to widen a permission has no idea what they're undoing.
  6. Set a review cadence. Quarterly is reasonable for most manufacturers. Tie it to something that already happens — quarter close, or your NetSuite release readiness review — so it doesn't depend on someone remembering.

A note on navigation paths: exact menu locations, report names, and available permission levels vary by NetSuite version, enabled features, and account configuration. Verify the specifics against your own instance rather than following any generic path — including ours.

When you genuinely can't separate the duties

Sometimes the department is three people and the math doesn't work. Splitting the duty would mean the work doesn't get done. This is normal, and pretending otherwise produces controls that get worked around within a week.

The answer in that case is compensating controls — you accept that one person holds both capabilities and add detection around it:

  • Threshold-based approval. One person can process below a dollar threshold; anything above routes to a second approver. Most of the volume flows uninterrupted, and the exposure is bounded.
  • After-the-fact review. A monthly report of new and modified vendor records, reviewed by someone outside the process. Detection instead of prevention is a legitimate control, provided the review actually happens and is documented.
  • Exception monitoring. Duplicate invoice detection, unusual vendor bank detail changes, or bills approved by the same user who created the vendor. These are the specific patterns worth watching when you can't prevent them structurally.
  • Document the exception deliberately. An auditor is far more comfortable with a known, documented, monitored exception than with a gap you didn't know you had. "We identified this, here's why we can't split it, here's what we do instead" is a defensible position.

What this looks like in practice

On the most recent role permissions audit we ran for a multi-site manufacturing client, five roles required adjustment.

None of the findings were malicious. Every one traced back to a specific, reasonable decision made under time pressure — a month-end that needed to close, a site that needed to go live, a person who left and whose responsibilities got absorbed by whoever was nearest. The permissions were granted to solve real problems, and they solved them.

That's the part worth sitting with. Nobody in that account did anything wrong. The gap existed because permission structures decay by default, and reviewing them was nobody's job.

The underlying problem isn't security

It's ownership.

Separation of duties in NetSuite is not a hard technical problem. The permission model supports it. The reports exist. The fixes are usually straightforward once you can see the current state clearly.

What's missing in most manufacturing instances is someone whose job it is to look. Your controller is closing the books. Your plant manager is running production. Your IT lead is keeping systems up. Permission review sits in the gap between all three, which means it sits with nobody — right up until the moment an auditor, a customer, or a duplicate payment makes it urgent.

If you're running NetSuite without a dedicated administrator, this is one of several audits that quietly has no owner. It's worth knowing which ones those are before someone else finds them for you.