Segregation of duties (SoD) is not just a control. It´s a foundational risk containment mechanism in modern ERP environments, limiting a single identity’s ability to execute end-to-end financial transactions without oversight.
What is segregation of duties?
Segregation of duties is the principle that no single identity (human or non-human) should be able to originate, authorize, and complete a financially material transaction across its lifecycle.. In a modern ERP, that translates into preventing one user from having multiple conflicting permissions, such as creating vendors and paying them, or creating journal entries and approving them.
Why segregation of duties breaks at scale
In large ERP environments, SoD rarely fails because policies don’t exist. It fails because:
- Access accumulates across systems over time (privilege creep)
- SoD is evaluated at the role level, not the transaction level
- Cross-application conflicts are invisible (e.g., SAP + Coupa)
- Manual reviews cannot keep pace with change
Common segregation of duties examples and conflicts
Common segregation of duties examples show up in core financial processes and access administration.
Procure‑to‑pay conflicts:
- Maintain vendor master data vs. create and approve purchase orders.
- Vendor creation + payment execution (fraud triangle risk)
An identity that can create or modify vendor master data and also execute or approve payments can introduce fictitious vendors and self-authorize disbursements without detection.
- Override payment terms vs. release or approve payments. The ability to alter payment terms and approve payments enables early or unauthorized disbursements outside policy.
Order‑to‑cash conflicts:
- Create or modify customer master data vs. approve credit limits.
- Create sales orders vs. approve credit memos or write‑offs.
- Post revenue vs. process customer refunds.
Record‑to‑report conflicts:
- Journal creation + posting (financial manipulation risk)
Combining journal preparation and posting enables unauthorized adjustments to financial results, particularly during period close when oversight pressure is highest..
- Maintain the chart of accounts vs. close the general ledger.
- Configure financial reporting rules vs. approve final financial statements.
Access and configuration conflicts:
- Access provisioning + approval (control bypass risk)
- When the same identity can grant and approve access, the entire access control framework becomes self-authorizing, undermining SOX reliance on logical access controls.
- Change application configuration (tolerances, approval rules, tax settings) vs. process affected transactions.
Cross-system Segregation of Duties
Many high-risk conflicts now span multiple platforms. For example:
- Creating vendors in SAP and approving payments in Coupa
- Creating customers in Salesforce and issuing refunds in NetSuite
Traditional SoD models that analyze systems in isolation will not detect these risks.
For more detail on how leading organizations automate these checks, download:
