Segregation of duties in ERP finance: why paper controls fail

At a glance

What this is: This is an analysis of why segregation of duties in finance systems fails when ERP roles, custom functions, and exceptions hide incompatible access paths.

Why it matters: It matters because finance, audit, and IAM teams need provable, continuous control over who can initiate, approve, post, and reconcile transactions across ERP estates.

Context

Segregation of duties is the control principle that no single person should be able to complete a critical transaction from start to finish without an independent check. In modern ERP and cloud finance environments, the problem is not whether the policy exists, but whether incompatible access is actually prevented and can be demonstrated across systems, roles, and exceptions.

The governance gap widens when one ERP role bundles vendor maintenance, payment release, journal posting, and reconciliation duties that should remain separate. That creates a direct IAM and IGA problem inside finance operations, because the control failure is often hidden in entitlement design rather than in the transaction itself.

Key questions

Q: What breaks when separation of duties is enforced only on paper?

A: When SoD exists only as policy, teams can still route sensitive actions through manual exceptions, informal approvals, or incomplete workflows. The result is a control that looks present in documentation but fails during execution. The practical failure is not lack of intent, but lack of enforceable entitlement design, reviewer independence, and audit evidence.

Q: Why do bundled ERP privileges create a higher control risk in finance systems?

A: Bundled privileges increase risk because segregation of duties is enforced at the entitlement level, not by job title. A single role can hide supplier changes, payment release, journal posting, or reconciliation rights, which means the same identity can cross control boundaries without the business seeing the conflict.

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 decisions when business and IT disagree?

A: Business process owners should own the risk decision, while IAM and security teams provide the control design and enforcement. If ownership sits only with IT, the rules often miss the operational realities that created the conflict in the first place.

Technical breakdown

How ERP role design hides segregation of duties conflicts

ERP roles are not simple job labels. They are collections of menus, authorization objects, field values, and inherited privileges, so a role that looks harmless at summary level can still allow conflicting actions in a specific company code or business unit. That is why business teams often miss the risk until an audit, a fraud review, or an exception report exposes it. The technical issue is not just access volume, but how entitlement combinations create paths that bypass the intended control separation.

Practical implication: review access at the privilege level, not only by role name, when testing SoD risk.

Why reconciliations stop being independent review

A reconciliation control only works when the reviewer is independent of the activities being checked. If the same person can create suppliers, initiate payments, post journals, or clear accounts, the reconciliation becomes self-review rather than detection. In that model, the control can still appear to exist on paper while the underlying assurance function is gone. Modern finance teams often inherit this problem through shared service structures, temporary workarounds, and broad super-user access that accumulates over time.

Practical implication: separate reconciliation authority from upstream transaction and master-data privileges.

Why spreadsheet-based SoD testing cannot keep up

Manual SoD testing struggles because ERP access changes faster than static control documents. New modules, mergers, inherited roles, emergency exceptions, and custom functions constantly reshape the effective risk picture, while spreadsheets lag behind. Once roles start bundling dozens or hundreds of entitlements, business owners need a live way to evaluate conflicts in finance language, not a periodic mapping exercise that goes stale before the next close cycle.

Practical implication: move SoD testing into continuous governance workflows that evaluate actual entitlements as they change.

Threat narrative

Attacker objective: The objective is to manipulate financial transactions or conceal errors through access paths that bypass independent review and approval.

1. Entry occurs through role accumulation, temporary overrides, and broad ERP access granted to keep finance operations moving.
2. Credentialed users then inherit incompatible privileges that let them create master data, approve payments, post journals, or clear accounts within the same process chain.
3. The result is either undetected fraud, concealed error, or audit failure because the same access path can initiate, process, and verify the transaction.
4. Impact lands as misstated financial records, weakened auditability, and a control environment that cannot prove independent review.

NHI Mgmt Group analysis

Hidden control overlap is the real segregation of duties failure. The problem is rarely the absence of policy language. It is the accumulation of ERP entitlements that let one user bridge initiation, approval, posting, and reconciliation in ways the business never intended. That is an IAM and IGA issue inside finance, and it should be treated as a live access governance problem rather than a documentation problem.

Paper SoD does not survive privilege sprawl. Once roles bundle multiple underlying entitlements, the apparent control design diverges from the actual control state. Static matrices cannot prove enforcement across SAP, Oracle, and adjacent finance systems unless they are continuously compared with current access.

Reconciliation becomes a weak control when it shares the same trust boundary as processing. If the reviewer can also create or approve the underlying transaction, the control no longer provides independent assurance. That failure mode matters because auditors, regulators, and boards increasingly expect evidence, not statements of intent.

Finance governance now needs continuous proof, not periodic assurance. The named concept here is continuous SoD enforcement gap: the distance between policy and provable access state. Organisations should treat that gap as a governance risk in its own right, because unmanaged exceptions and inherited roles make it predictable, not exceptional.

What this signals

Continuous SoD enforcement gap: the distance between a written control and the access state that actually exists in ERP systems. Finance programmes should expect this gap to widen as shared services, emergency access, and custom functions increase, so the control target has to move from periodic review to live entitlement governance.

The practical signal is simple: if a team cannot explain who can create, approve, post, and reconcile a transaction chain in business terms, the control is already too complex to audit reliably. That is where IAM and IGA discipline becomes part of finance control design, not just access administration.

For practitioners

• Define incompatible activity pairs in business language Create a finance-led segregation of duties matrix that maps supplier maintenance, payment approval, journal posting, and reconciliation into explicit conflicts that owners can review.
• Test access at the privilege level Evaluate entitlements inside ERP roles and profiles rather than relying on role names or job titles, especially where company codes, workflow overrides, or custom functions exist.
• Separate reconciliation from transaction control Ensure the person who reconciles bank, payroll, or clearing accounts cannot also initiate, approve, post, or clear the transactions feeding those accounts.
• Replace spreadsheet reviews with continuous SoD monitoring Route conflicts into workflow, track remediation, and retain evidence showing when exceptions were approved, remediated, or compensated.

Key takeaways

• Segregation of duties fails when ERP access combines incompatible activities that should remain independently controlled.
• The control problem is not only policy design but the inability to prove continuous enforcement across complex roles and exceptions.
• Finance teams need live entitlement governance and business-language conflict mapping if they want SoD to stand up to audit scrutiny.

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.
• Compensating Control: A compensating control is a measure that reduces risk when the ideal fix, such as immediate patching or redesign, is not possible. In OT, compensating controls often include session recording, access restriction, and tighter monitoring. They do not eliminate the underlying issue, but they narrow exposure until safer remediation can happen.
• Role Creep: Role creep is the gradual expansion of access as roles accumulate exceptions, inherited permissions, and obsolete entitlements. It is a common failure mode in large organisations because roles are often easier to add to than to redesign, review, or retire, which increases both audit burden and attack surface.
• Independent Reconciliation: A reconciliation performed by someone who does not control the transactions being checked. Independence is what makes the control meaningful, because the reviewer can challenge mismatches without auditing their own work or validating access they also used operationally.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security in a way that complements broader identity and access work. It is a practical fit for practitioners who need to connect identity controls to governance and audit outcomes.