Why Segregation of Duties Matters

Segregation of Duties exists for one fundamental reason: to prevent fraud and errors by ensuring no single person can complete a high-risk transaction from start to finish without oversight. It's one of the oldest principles in accounting, dating back centuries to the basic wisdom that the person handling cash shouldn't also be the person recording it.

The principle is simple. The implementation—especially in a flexible system like NetSuite with its granular permission structure—is considerably more complex. It's surprisingly easy to create role combinations that undermine the entire control, often without anyone realizing it.

Effective SoD implementation requires understanding not just what to segregate, but why, and what to do when perfect segregation isn't possible. It also requires ongoing vigilance, because access tends to accumulate over time and what was properly segregated at implementation may not stay that way.

Understanding the Risk Categories

Not all SoD conflicts are equal. Focus your attention on the combinations that create actual risk—situations where a single person could commit and conceal fraud or where errors could go undetected.

Accounts Payable Fraud Risks

Create and Approve Payments

The classic AP fraud scenario: someone creates a fake vendor, enters a fraudulent bill, and cuts themselves a check. If one person can do all three, you have no control. This is the most critical segregation in AP.

In NetSuite terms, this means separating: vendor record creation/editing, bill entry, and payment processing/approval. At minimum, the person approving payments should not be the person who created the bills being paid.

Modify Vendors and Process Payments

A variation on the above: someone modifies an existing vendor's bank details to their own account, then processes a payment. By the time anyone notices, the money is gone.

Segregating vendor master maintenance from payment processing addresses this risk.

Accounts Receivable Fraud Risks

Create Customers and Apply Cash

The AR equivalent of AP fraud: create a fictitious customer, record fake revenue, then intercept actual customer payments and apply them to the fictitious account (lapping scheme). Or divert payments from real customers to personal accounts.

Segregating customer creation from cash application and receipt processing helps prevent this.

Issue Credits and Process Refunds

Issuing credits without authorization, then processing refunds to accomplices. Segregating credit memo creation from refund processing limits this risk.

Financial Manipulation Risks

Edit Chart of Accounts and Post Journal Entries

Creating hidden accounts and posting entries to them can conceal fraud or manipulate financials. If the same person controls the account structure and can post entries, they can hide transactions in accounts that don't get reviewed.

Segregating chart of accounts maintenance from journal entry posting limits this risk.

Modify Financial Reports and Close Periods

Altering reports after the fact to hide problems, or closing periods to prevent corrections. Segregating report modification from period management helps maintain integrity.

Inventory and Asset Risks

Adjust Inventory and Manage Counts

Stealing inventory and then adjusting the records to conceal it. If the same person can take inventory and adjust the system, theft becomes easy to hide.

Segregating physical inventory management from system adjustments addresses this.

Create and Dispose of Assets

Creating fictitious assets for depreciation benefits or disposing of assets while retaining them. Segregating asset creation from disposal processing limits these risks.

The NetSuite Permission Challenge

NetSuite's permission system is remarkably granular—which is both a strength and a weakness for SoD implementation.

The Granularity Challenge

NetSuite has hundreds of individual permissions. Each can be set to None, View, Create, Edit, or Full at various levels. Role definitions become complex matrices of permissions across record types, transactions, reports, and setup areas.

This granularity enables precise access control—in theory. In practice, understanding how all these permissions interact is challenging. Two permissions that seem unrelated might combine to create a segregation conflict.

Standard Role Problems

NetSuite's standard roles (A/P Clerk, A/R Clerk, Accountant, etc.) were designed for functionality, not segregation. They often include more access than SoD would prefer because they're built to let people do their jobs without constant access barriers.

Using standard roles without modification almost certainly creates SoD conflicts. You need to either customize standard roles or create entirely custom roles designed with segregation in mind.

Permission Accumulation

Over time, access accumulates. Someone needs to do something urgently, so they get added to a role. A workaround requires access that wasn't originally planned. Someone covers for a colleague and gets their access too, which never gets removed.

Without active governance, roles drift and users accumulate access until original segregation design is completely undermined.

Implementing SoD Effectively

Here's a practical approach to implementing segregation of duties in NetSuite.

Step 1: Create a Conflict Matrix

Before configuring anything, document which permission combinations create conflicts. This becomes your reference for role design and ongoing access reviews.

The matrix should identify:

• The specific permissions that conflict

• The risk created by the conflict

• Whether the conflict is absolute or can be mitigated

• Potential compensating controls if perfect segregation isn't possible

You can't manage what you haven't defined. The conflict matrix is your foundation.

Step 2: Design Roles Around Functions

"John's Role" is a red flag. Roles should represent job functions—AP Clerk, AR Specialist, Staff Accountant, Controller—not individuals. When John leaves, the role should work for his replacement without modification.

For each function:

• Identify the job responsibilities

• Determine what NetSuite access those responsibilities require

• Check the required access against the conflict matrix

• Resolve any conflicts by redesigning responsibilities or implementing compensating controls

Step 3: Implement Minimum Necessary Access

Every permission should have a business justification. "They might need it someday" isn't justification—it's a control gap waiting to happen.

Start with zero access and add only what's needed. It's easier to add a missing permission when someone identifies a need than to discover inappropriate access created a segregation conflict.

Step 4: Configure and Test

Once roles are designed, configure them in NetSuite and test thoroughly:

• Verify each role can perform intended functions

• Test that role combinations don't create unintended conflicts

• Verify that conflicting transactions are actually blocked

• Document the testing and results

Step 5: Implement Monitoring

SoD isn't a one-time configuration—it's an ongoing discipline. Build monitoring that runs regularly, not just at audit time.

Custom saved searches can:

• Identify users with potentially conflicting role combinations

• Flag transactions processed by users who shouldn't have that access

• Track role changes and new access grants

• Highlight anomalies for investigation

  
  

Dealing with Small Team Reality

The textbook says you need different people for each step in a process. But what if you only have three people in finance? Or two? What if the same person has to do things that theoretically should be segregated?

This is the reality for many mid-market companies. True segregation may be impossible, but that doesn't mean you give up on controls.

Compensating Controls

When you can't segregate, compensate. Alternative controls can provide oversight without requiring additional headcount:

Management Review

Someone senior reviews transactions or reports that include transactions processed by the person with conflicting access. The review should be documented—actually documented, not just "I looked at it."

System-Enforced Limits

Even if someone has access to both sides of a transaction, system controls can limit risk. Dollar thresholds requiring additional approval. Automated holds on unusual transactions. Mandatory supporting documentation.

Reconciliation by Outside Party

If the person processing transactions also has access to records, have someone outside the process reconcile results. Bank reconciliation by someone other than the person recording cash, for example.

Audit Trail Review

Regular review of audit trails looking for anomalies. This is detective rather than preventive, but it creates accountability.

Documentation

When conflicts exist with compensating controls, document everything:

• What the conflict is

• Why perfect segregation isn't feasible

• What compensating controls exist

• Who is responsible for operating those controls

• Evidence that controls are operating

This documentation is critical for auditors. A documented exception with compensating controls is compliant. An undocumented conflict is a finding.

Custom Solutions for SoD Enforcement

NetSuite's native capabilities can enforce basic segregation, but custom development can take it further.

Automated Conflict Detection

Custom scripts can evaluate role combinations and flag conflicts automatically. When access is granted, the system checks against the conflict matrix and alerts administrators if a conflict would be created.

Workflow-Based Segregation

Custom approval workflows can enforce segregation that role-based security can't. For example: the system allows a user to create bills, but requires a different user to approve before payment can be processed—regardless of whether the original user technically has payment access.

Enhanced Audit Trails

Custom logging can capture additional detail beyond standard system notes—recording who had what access at the time of each transaction, flagging transactions that touched segregation-sensitive areas, creating searchable audit records for compliance review.

Real-Time Monitoring Dashboards

Custom dashboards can show SoD health in real-time: current conflicts, recent access changes, transactions requiring review, exceptions awaiting investigation. This makes ongoing monitoring manageable rather than a periodic burden.

Bottom Line

SoD in NetSuite isn't about checking boxes for auditors—it's about building controls that actually prevent problems. Design roles thoughtfully from the start. Monitor continuously. Document everything. When conflicts are unavoidable, implement real compensating controls and document them.

The investment in proper SoD implementation pays off in reduced fraud risk, cleaner audits, and operational confidence that your controls actually work.