Segregation of duties in ERP finance: why paper controls fail

At a glance

What this is: This article argues that segregation of duties in modern finance fails when ERP roles, custom functions, and reconciliations are managed as paper controls rather than continuously provable access controls.

Why it matters: It matters to IAM, IGA, and audit teams because finance risk now sits in role design, entitlement combinations, and evidence quality, not just in the existence of a SoD policy.

👉 Read SafePaaS's analysis of segregation of duties failures in modern finance

Context

Segregation of duties only works when incompatible activities are actually separated in the systems that execute them, not just described in policy documents. In finance environments, that means the control has to hold across ERP roles, approval workflows, reconciliations, and compensating controls, with evidence that stands up to audit. The article focuses on that governance gap, where policy says one thing and live entitlements say another.

For IAM and IGA teams, this is an access governance problem as much as a finance control problem. ERP roles can bundle many underlying privileges, so a user may appear low risk at the role name level while still holding combinations that break SoD. That makes entitlement visibility, role recertification, and evidence generation central to proving control effectiveness.

Key questions

Q: What breaks when segregation of duties relies on annual spreadsheet reviews?

A: Annual spreadsheet reviews fail because they see access too late and too abstractly. By the time a conflict is documented, the user may already have created, approved, or concealed a transaction. That makes SoD a reporting exercise rather than a preventive control, which is a governance failure.

Q: How should teams implement segregation of duties in finance and ERP systems?

A: Start by mapping the full transaction path, then split creation, approval, posting, and reconciliation across different roles. In ERP and finance systems, the safest design is one identity starts the action, another authorises it, and a third checks it. Continuous access review is essential because role drift can recreate conflicts after the original design is in place.

Q: How do organisations know whether segregation of duties is actually working?

A: Segregation of duties is working only if no identity can combine enough permissions to complete the full banking workflow without an independent check. The test is not whether a policy exists, but whether cross-system role combinations are blocked before they create an end-to-end abuse path. If combinations are still possible, the control is only documented, not enforced.

Q: What should organisations do when finance access exceptions keep reappearing?

A: Treat recurring exceptions as role design failure, not as one-off approvals. Re-examine the underlying business process, remove unnecessary inherited privileges, and make exception approvals time-bound with explicit ownership. If the same conflict keeps returning, the access model is compensating for a broken operating design rather than enforcing one.

Technical breakdown

Why ERP role design breaks segregation of duties

ERP systems rarely map cleanly to business duties. Roles often combine menu paths, authorization objects, and field-level permissions, so a single account can end up with access to create suppliers, approve payments, post journals, or clear accounts. The technical problem is not just excess access, but overlapping entitlements that only become visible when translated into business activities. In SAP and Oracle environments, that translation is hard to do manually, which is why spreadsheet-based SoD reviews miss real conflicts. The control failure is structural: the system allows privilege combinations that the policy assumes will never exist.

Practical implication: model privileges at the entitlement level, not the role-name level, before approving finance access.

Why reconciliations stop being a control when review is not independent

A reconciliation is only effective when the reviewer is independent from the transaction flow being checked. If the same person initiates payments, posts journals, or changes master data and also signs off the reconciliation, the control becomes self-review. That destroys the detective value of the check because the reconciler is validating their own activity rather than challenging it. In modern finance stacks, this risk grows when month-end pressure, shared services, or temporary exceptions concentrate approval and review in the same hands. The issue is not the reconciliation activity itself, but the loss of role separation around it.

Practical implication: enforce independent review rules for bank, payroll, and clearing reconciliations.

How SoD matrices become live control assets

A segregation of duties matrix becomes operational only when it is continuously applied to current identities, roles, and entitlements. The matrix defines incompatible activity pairs in business language, then automated governance checks test them across ERP systems and flag conflicts as they emerge. That approach converts SoD from a static spreadsheet into a control fabric that can support remediation workflows, compensating controls, and audit evidence. It is especially useful where role creep, mergers, or project access have expanded entitlement sets beyond the original design. Without continuous testing, the matrix becomes documentation rather than control.

Practical implication: automate SoD rule testing against live access data and route violations into governed remediation.

NHI Mgmt Group analysis

Segregation of duties has become an access governance problem, not a policy problem. The article shows that the real failure sits in the gap between written control design and live ERP entitlement combinations. Once a role can carry supplier changes, payment approval, and reconciliation access in one package, the policy statement loses meaning. For IAM and IGA teams, the discipline is to prove incompatible access cannot coexist in the active role model.

Custom finance roles create a distinct form of control drift that auditors can no longer inspect manually. ERP environments accumulate exceptions through temporary workarounds, reorganisations, and inherited privileges. That creates control drift where the business meaning of a role diverges from its technical permissions. A named concept here is SoD control drift: the gradual widening of effective access beyond the intended duty separation, which turns periodic review into a retrospective exercise. Practitioners need continuous entitlement-level testing, not annual spreadsheet reviews.

Reconciliation independence is now as important as transaction authorisation. The article correctly treats reconciliation as a separate control function rather than an administrative step. If the reviewer also controls upstream posting or approval, the check cannot detect manipulation with confidence. This matters for finance governance because detective controls only work when the reviewer has no incentive or ability to validate their own work.

Continuous SoD evidence is becoming a board-level requirement, not just an audit convenience. Finance leaders now need controls that can be demonstrated across SAP, Oracle, and surrounding applications without manual reconstruction. That aligns strongly with access governance expectations in NIST CSF and least-privilege control models, even when the business framing is finance rather than identity. The practitioner conclusion is simple: if the control cannot produce current evidence, it is not operationally real.

What this signals

Finance governance teams are moving from periodic SoD review toward continuous entitlement validation because role names no longer describe actual access with enough precision. The broader signal is that audit-ready evidence now depends on identity governance tooling that can interpret business risk, not just list permissions.

Control drift: the slow expansion of effective access beyond the intended finance duty model is becoming the key operational risk. Where ERP and cloud finance tools are tightly integrated, the control boundary increasingly sits in identity governance, reconciliation independence, and exception expiry discipline.

Practitioners should expect auditors and boards to ask for current proof, not control narratives. That shifts programme design toward live rule testing, workflow-backed remediation, and evidence that can survive challenge across SAP, Oracle, and adjacent finance applications.

For practitioners

• Map finance duties to incompatible activity pairs Build a business-language SoD matrix for supplier maintenance, payment approval, journal posting, and reconciliation. Translate each pair into entitlement-level rules so conflicts are visible in the ERP access model, not just in policy documents.
• Test live ERP access continuously Run automated checks against current users, roles, and privilege combinations across SAP, Oracle, and connected finance applications. Treat new conflicts as active control failures rather than annual review items.
• Separate reconciliation from transaction ownership Ensure the person reconciling bank, payroll, or clearing accounts does not also initiate, approve, or correct the underlying transactions. Where temporary exceptions exist, document compensating controls and expiry dates.
• Route SoD violations into remediation workflows Assign each conflict to a named owner, record the remediation decision, and retain evidence for auditors and risk reviewers. Use workflow tracking so access exceptions do not disappear into email threads or spreadsheets.

Key takeaways

• The core failure is not the absence of a segregation of duties policy, but the inability to prove it continuously in live finance systems.
• ERP role sprawl, temporary exceptions, and non-independent reconciliations turn paper controls into weak evidence and hidden access risk.
• Identity governance teams need entitlement-level testing, workflowed remediation, and current evidence if SoD is to stand up to audit and board 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.
• Control Drift: Control drift is the gradual weakening or inconsistency of a control over time as systems, workflows, or business rules change. It often appears as different interpretations, missed exceptions, or uneven enforcement across applications, and it usually becomes visible only when monitoring spans the full process.
• 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.
• 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.

What's in the full article

SafePaaS's full article covers the operational detail this post intentionally leaves for the source:

• Finance-language examples of incompatible duty pairs across vendor setup, invoice processing, payment approval, and reconciliation
• Role-level examples from SAP and Oracle that show how hidden privilege combinations emerge in real ERP deployments
• Workflow and audit trail detail for routing SoD conflicts, approvals, and compensating controls
• Practical guidance on translating a segregation of duties matrix into preventive and detective controls

👉 SafePaaS's full article expands on ERP role conflicts, reconciliation risk, and control evidence.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle control, and secrets management. It helps security practitioners connect access governance to broader identity and NHI operating models.