What Is Segregation of Duties (SoD)?
Also known as: SoD, separation of duties, SoD conflict
Definition
Segregation of duties is an internal control that splits a sensitive process across different people so no single user can both create and approve a transaction, such as entering a vendor and also releasing its payment.
Segregation of Duties (SoD) Explained
Segregation of duties (SoD) is a control principle that assigns the steps of a risky business process to different users. In an ERP it is enforced through roles and permissions: the person who maintains the vendor master should not also post vendor invoices and approve payment runs. Auditors test it under SOX, internal audit programs and many customer quality requirements.
SoD is expressed as conflict pairs or rules. Typical conflicts include: create purchase order and approve purchase order, maintain vendor bank details and run payments, post journal entries and approve journals, adjust inventory and perform cycle count approval, and maintain item cost and post receipts. Each rule says that two functions must not sit with the same user, or must be mitigated by a compensating control such as a second reviewer.
ERPs implement the building blocks differently. NetSuite uses roles with permission levels (View, Create, Edit, Full) and offers a separate SoD tooling in its governance products. Infor SyteLine uses user groups and authorization on forms and IDOs. SAP uses authorization objects and has GRC Access Control for conflict analysis. In every case the real risk is not a single role but the combination of roles one person accumulates over years.
Small manufacturers often cannot fully segregate because one person wears several hats. The accepted answer is a documented compensating control, for example a monthly owner review of vendor changes and payment exceptions, rather than pretending the conflict does not exist.
Why It Matters
- It is a core test in SOX 404 and external audits, and a failed SoD finding is a common reason for a control deficiency report.
- It limits fraud and costly errors, such as duplicate or fictitious vendor payments and unapproved inventory write-offs.
- Role creep makes conflicts appear silently after reorganizations, so periodic review matters more than the initial design.
- AI agents that act inside the ERP inherit the permissions of their service account, so SoD must be applied to agents as well as people.
In Practice
A 120-user manufacturer runs a quarterly SoD report. It finds 6 users who can both maintain vendors and release payments, all from a consolidated AP role created during a staff shortage. The fix is to split the role into vendor maintenance and payment release, and for the two-person AP team the owner signs a monthly vendor-change report as a compensating control. Cleanup takes a few days of role work, not a project.
Frequently Asked Questions
What is an example of a segregation of duties conflict in an ERP?
A single user who can create a vendor, enter the vendor's invoice and release the payment run. That combination allows a fictitious vendor to be paid with no second person involved.
Can a small company comply if one person must do several tasks?
Yes, with compensating controls. Document the conflict, then add a detective control such as an owner or controller reviewing vendor changes and payment exceptions every month.
Is SoD the same as role-based access control?
No. Role-based access control is the mechanism that grants permissions. SoD is the rule about which permissions must not be combined, and it is tested across all the roles a user holds.
Related Terms
SOX (Sarbanes-Oxley) Compliance
SOX compliance is a US public company's obligation under the Sarbanes-Oxley Act of 2002 to establish, document, test, and certify internal control over financial reporting, including the IT general controls and segregation of duties in the systems that produce financial data.
Role-Based Access Control (RBAC)
Role-based access control grants ERP permissions to roles that match job functions, then assigns users to roles, instead of setting permissions user by user. It makes access consistent, reviewable and easier to remove.
Audit Trail
An audit trail is a secure, time-stamped record of who created, changed, approved or deleted data in a system, including old and new values. In an ERP it supports financial, quality and security audits.
Three-Way Match
A three-way match is the accounts payable control that compares the purchase order, the goods receipt, and the supplier invoice on quantity and price before releasing payment, ensuring a company pays only for what it ordered and actually received.
General Ledger
The general ledger is the central accounting record of a business, where every financial transaction posts as balanced debits and credits against accounts in the chart of accounts, producing the trial balance behind all financial statements.
Go Deeper
ERP Security Posture Checklist
Work through 30 concrete security controls across access, patching, network, data protection, and monitoring, with the highest-risk items flagged.
Free ToolAI Agent Security Review Checklist
A 30-point security review for AI agents that can call tools and write to business systems, covering identity, permissions, prompt injection, data handling, and audit.
ERP Role-Based Access Control Setup Guide
Implement role-based access control in ERP systems with role design, permission matrices, least-privilege enforcement, and ongoing access governance processes.
ERP User Access Review Process Guide
Establish a structured ERP user access review process with review cycles, certification workflows, exception handling, and audit evidence for SOX and ISO compliance.
ERP Security Best Practices Guide
Implement comprehensive ERP security best practices covering access control, encryption, monitoring, and compliance aligned with NIST CSF and CIS Controls frameworks.
Working with Segregation of Duties (SoD) in a live environment? Our engineers do this every day - and our AI agents automate most of it.