Segregation of duties at scale in ERP finance and access controls

At a glance

What this is: This is an analysis of why segregation of duties weakens in ERP finance when conflicting permissions, system silos, and manual reviews let one identity control a transaction from start to finish.

Why it matters: It matters because IAM and finance controls must detect cross-system privilege combinations, not just isolated role assignments, or materially risky transaction paths will remain hidden.

Context

Segregation of duties is the control idea that no single identity should be able to originate, authorize, and complete a financially material transaction without oversight. In ERP environments, that principle becomes an identity governance problem because access decisions, approval paths, and transaction execution are often distributed across multiple applications and teams.

The practical failure is not usually the absence of policy. It is the accumulation of permissions over time, the habit of reviewing roles rather than actual transaction paths, and the inability of isolated systems to surface conflicts that span platforms such as SAP and Coupa. When those gaps line up, SoD becomes a paper control rather than a containment mechanism.

Key questions

Q: What breaks when segregation of duties is the only control in place?

A: SoD blocks some toxic combinations, but it does not clean up stale, unused, or orphaned access. Users can change roles, projects can end, and temporary access can become permanent without any SoD alert. A programme built only on prevention still accumulates governance debt over time.

Q: Why do segregation of duties conflicts and excessive privileges keep showing up in ERP access reviews?

A: These issues persist when access is granted for convenience, then left in place as roles, projects, and staff changes accumulate. In ERP systems, that creates hidden overlaps between request approval, payment, posting, and administration duties. Without periodic recertification and policy enforcement, organisations lose control over who can do what and why.

Q: How do security teams know if SoD controls are actually working?

A: SoD controls are working only if live access state matches the approved separation model across systems. Teams should verify that no identity can both initiate and validate the same sensitive transaction, and that exceptions are time-bound and independently reviewed. If certification reports look clean but operational workflows still allow self-approval, the control is failing.

Q: Who should own Segregation of Duties automation across finance, IT, and application teams?

A: SoD automation should be jointly owned, with finance, IT, internal audit, compliance, legal, department managers, data owners, business operations, and executive leadership all contributing. The article makes clear that no single team can implement strong internal controls alone. Application owners remain responsible for monitoring access in their systems, while IT and risk teams need shared governance for the broader control program.

Technical breakdown

Why role-level SoD checks miss ERP transaction conflicts

Traditional SoD analysis maps access by role or entitlement, then flags predefined toxic combinations. That works only when business processes live inside one system and permission boundaries stay stable. In modern ERP estates, the real risk sits in the transaction path, not the role name. An identity may be able to create a vendor in one system, approve a payment in another, and complete the disbursement without any single system seeing the full chain. The control therefore fails at the correlation layer, where access governance should reconcile permissions across applications and process stages.

Practical implication: Model SoD around transaction paths across systems, not only around roles inside each application.

How privilege creep turns ERP access into transaction power

Privilege creep is the gradual accumulation of access beyond original job need. In ERP finance, that matters because a small set of extra permissions can combine into material control failure. A user who can maintain master data, adjust payment terms, or post journal entries may not look high risk in isolation, but those privileges can create, approve, and complete financial actions when combined. The issue is not just excess access. It is the conversion of incremental entitlements into end-to-end operational authority across procure-to-pay, order-to-cash, and record-to-report workflows.

Practical implication: Track entitlement accumulation over time and test whether small access changes create a complete financial workflow.

Why cross-application conflicts are invisible to isolated ERP reviews

Cross-application SoD breaks when one system reviews itself and no control layer reconciles it with the rest of the finance stack. That is especially true when core processes span ERP, procurement, and payment platforms. A user may create a vendor in SAP and approve payment in Coupa, or create a customer in Salesforce and issue a refund in NetSuite, yet no single platform exposes the conflict. This is an architecture problem as much as a governance one: if the control model is application-bound, the risky combination remains distributed and therefore undetected.

Practical implication: Implement cross-application conflict analysis before relying on app-by-app access reviews.

NHI Mgmt Group analysis

SoD in ERP is a transaction-containment problem, not just an access policy problem. The article shows that the decisive failure mode is the gap between permission review and financial workflow reality. A role can look acceptable while the actual combination of entitlements still permits vendor creation, payment approval, or journal manipulation. That means practitioners should treat SoD as lifecycle governance over transaction power, not as a static role-design exercise.

Privilege creep is the named control failure that most often converts routine access into financial risk. The article’s examples show how small access additions can combine into end-to-end control over procure-to-pay, order-to-cash, and record-to-report processes. This is exactly where access recertification that stops at the role layer misses the real issue. The implication is that governance must test for conflicted process outcomes, not just permitted actions.

Cross-application review blind spots create the hidden SoD gap in modern finance stacks. The article’s SAP-plus-Coupa and Salesforce-plus-NetSuite examples make the point clearly: isolated review models cannot see a conflict that is distributed across systems. That is why the control problem is structural rather than procedural. Practitioners need a conflict model that follows the transaction, because the risk lives in the chain, not the individual application.

Access provisioning and access approval should never be governed as separate trust decisions when they can converge in one identity. When the same identity can request, grant, and validate access, the control system becomes self-authorizing. The article ties that directly to SOX-relevant logical access controls, which means the governance question is not only who has access but who can shape access outcomes. Practitioners should treat that convergence as a high-severity SoD design flaw.

Cross-system SoD drift: the broken premise is that financial control can be inferred from one application at a time. That assumption fails when conflicting permissions are distributed across ERP, procurement, and finance platforms. The implication is that organisations must rework control evidence around business process paths, not around isolated system inventories.

What this signals

Cross-system SoD analysis is now the baseline requirement for ERP governance. A control model that only inspects permissions inside one platform will miss the real risk path, because financial execution is often distributed across ERP, procurement, and payment systems. Practitioners should assume the conflict exists until they have correlated the transaction trail end to end.

Privilege reviews need to move from entitlement lists to process outcomes. The practical question is no longer whether a role looks reasonable, but whether an identity can still create, approve, and settle the same financial event after access changes. That shift changes how recertification, audit evidence, and exception handling should be designed.

Segregation of duties is strongest when it is treated as lifecycle governance. Joiner, mover, and leaver processes, periodic recertification, and configuration change review all need to reflect the same conflict model. Otherwise the organisation certifies access that already contains the next control failure.

For practitioners

• Map SoD to transaction paths Trace the full financial workflow from master-data change through approval and settlement, then mark every identity that can influence more than one step in the chain.
• Test cross-application toxic combinations Run SoD analysis across SAP, Coupa, Salesforce, NetSuite, and similar systems together so distributed conflicts are visible before certification.
• Re-certify access against process outcomes Review whether an identity can still create, approve, and complete a materially sensitive transaction, not whether the person still matches the original role title.
• Separate access grant and approval authority Block any identity from both provisioning access and approving that same access path, because the self-authorizing pattern undermines the control model.
• Target privilege creep in finance roles Prioritise roles with vendor master data, payment, journal, refund, or credit-limit authority, then remove combinations that create end-to-end transaction control.

Key takeaways

• SoD breaks in ERP when one identity can combine permissions across procurement, finance, and approvals into a full transaction path.
• The article shows that role-only reviews and system-only reviews both miss cross-application conflicts that can enable unauthorized payments or journal actions.
• The control that matters is not just access restriction but process-level conflict detection across the applications where financial work actually happens.

Key terms

• Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
• Privilege Creep: Privilege creep is the gradual accumulation of access rights beyond what an identity actually needs. It usually happens when permissions are added for convenience and never removed. For NHIs, privilege creep expands blast radius and makes old credentials far more dangerous than their original purpose suggests.
• Cross-Application Conflict: A toxic access combination that only becomes visible when permissions are evaluated across multiple systems together. This matters in ERP and finance stacks because a user may hold harmless-looking rights in separate tools that, when combined, enable an unauthorized business action.
• Transaction Path: A transaction path is the full sequence of steps needed to create, approve, execute, and reconcile an action. It matters in governance because control failure often comes from one identity owning too many steps, which removes challenge points and makes review effectively meaningless.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.