Segregation of duties (SoD) is the internal control principle under which the tasks involved in a high-risk transaction process are divided among multiple individuals — so that no single person has the ability to initiate, approve, execute, and record a transaction without the oversight of another. The principle applies most directly to financial processes where the combination of capabilities creates fraud risk: a person who can both create a vendor and approve vendor payments; a person who can both enter a sales invoice and post a credit note; a person who can both request a purchase and approve the purchase order.
The practitioner distinction: SoD is not about distrust. It is about removing the opportunity for undetected error or misconduct — protecting the individual as much as the organisation. An employee with excessive access who makes an error, or who is later accused of misconduct, is harder to defend in either the finance function or a regulatory investigation. Proper SoD protects the employee from accusations they cannot disprove because no one was checking.
In the Context of Egypt and the GCC
ERP implementations in GCC enterprises — Oracle EBS, SAP, and Microsoft Dynamics are the most common — carry default role configurations that frequently violate SoD principles if applied without review. During implementation, access is typically granted broadly to meet go-live deadlines and narrowed later through an access review. In practice, the narrowing often does not happen. Organisations operating Oracle EBS or Fusion with four-year-old role configurations may be carrying access conflicts that were introduced at go-live and have never been reviewed. ZATCA audit procedures in Saudi Arabia include user access review as part of the IT general controls assessment — meaning unresolved SoD conflicts are not only an internal risk, they are a regulatory exposure.
How This Connects to EPM and Systems
SoD in EPM environments governs who can prepare a budget, who can approve it, who can adjust actuals data, and who can override a consolidation. Oracle EPM applications support role-based access at granular levels — read, write, and approval rights can be configured at the form, entity, and scenario level. A budget administrator who can both enter budget data and approve their own submission has an EPM-level SoD conflict as material as an ERP-level one. EPM access design must be reviewed against the SoD control framework with the same rigour as ERP access.
What Goes Wrong
The failure that concentrates risk invisibly is role accumulation over time: an employee joins the finance team with appropriate, limited access. Over three years, they take on additional responsibilities and are granted additional system access for each. No single access grant created a conflict. The cumulative set does. By the time an access review is conducted — if one is ever conducted — the employee has a combination of capabilities that would never have been approved if requested together. In the absence of automated SoD conflict detection tools (Oracle Identity Governance, SAP GRC), this accumulation is invisible to the finance function until an auditor or a loss event surfaces it.
How Loop Wise Solutions Encounters This
SoD review is a standard component of our ERP and EPM assessment work. We analyse the current role-to-responsibility mapping against a defined SoD conflict matrix — the combinations of access that create unacceptable risk — and produce a remediation plan that resolves conflicts through role redesign, compensating controls, or additional oversight. In most organisations we assess across the region, the number of active SoD conflicts is higher than the finance leadership expects, and the resolution requires both system reconfiguration and process change.
Answers before you ask.
The internal control principle that different individuals should be responsible for each step of a high-risk transaction process — so no single person can initiate, approve, execute, and record a transaction without oversight. By splitting incompatible duties across people, it prevents any one individual from both committing and concealing an error or fraud.
Because most fraud requires one person to both perpetrate and hide it — for example creating a fake supplier and approving its payments. Splitting those steps across people means no single individual can do both, so fraud requires collusion, which is harder and riskier. Segregation removes the single point of control that unchecked fraud depends on.
Typically initiating a transaction, approving it, executing it (such as making the payment), and recording it in the accounts — these should not all sit with one person. Combining, say, the ability to set up a vendor and approve its payments creates fraud risk. Separating these authorisation, custody, and recording roles is the essence of the control.
In a small finance team, there may not be enough people to separate every duty cleanly, so one person ends up with incompatible responsibilities. This is a common weakness. Compensating controls — management review, system logs, oversight — are then used to mitigate the risk that full segregation cannot, since simply lacking people does not remove the underlying exposure.