SoD Conflicts in SAP: Detection, Assessment & Resolution

Segregation of Duties (SoD) is a fundamental control principle in every SAP system. When a single user can both create a purchase order and post the goods receipt, an essential control against fraud and errors is missing. In practice, SoD conflicts in legacy SAP systems are ubiquitous – the question is not whether they exist, but how many.

What Are SoD Conflicts?

An SoD conflict arises when a user holds authorisations for two or more activities that should be separated from a control perspective. Typical examples: create vendor and release payment, create purchase order and post goods receipt, create user and assign roles, post journal entry and execute year-end closing. SoD conflicts significantly increase the risk of fraud, errors and compliance violations.

Creating an SoD Matrix

The foundation of any SoD analysis is an SoD matrix (also called a risk rulebook). This matrix defines which function combinations constitute a conflict. A practical matrix typically contains 100–300 rules, organised by business process: procurement, financial accounting, human resources, materials management and IT administration.

Important: the matrix must fit the organisation. A standard matrix from SAP or a consulting firm is a good starting point but must be adapted to specific business processes and risk tolerance.

Detecting SoD Conflicts

Three approaches are available for detection:

• SAP GRC Access Control (ARA): The most comprehensive solution with real-time analysis, simulation and workflow. Analyses conflicts at role and user level against a configurable rulebook.
• Manual analysis with SUIM: Transaction SUIM enables queries for critical authorisation combinations. Labour-intensive but possible without additional licences.
• Custom reports: Custom ABAP reports or SQL queries against the authorisation tables (USR02, AGR_1251, AGR_USERS). Flexible but maintenance-intensive.

Risk Assessment: Not Every Conflict Is Equally Critical

Experience shows: in a typical SAP system, 30–60% of users have at least one SoD conflict. Resolving all simultaneously is unrealistic. Prioritise by risk:

• High: Conflicts with direct fraud risk (e.g. create vendor + release payment)
• Medium: Conflicts with error risk or compliance relevance (e.g. create purchase order + goods receipt)
• Low: Conflicts with low risk or existing compensating controls

Also consider actual usage: a user who has the authorisation but never uses it presents a lower risk than a user who actively performs both functions.

Resolution Strategies

Several strategies are available for resolving SoD conflicts:

• Role redesign: The most sustainable solution – restructure roles so that conflicts are structurally avoided
• User reassignment: Distribute activities across different users
• Compensating controls: When separation is not possible (e.g. in small teams), implement additional monitoring measures
• Monitoring: Actively monitor transactions with SoD conflict potential and review regularly

Using Compensating Controls Correctly

Compensating controls are not a free pass but a documented measure that reduces residual risk to an acceptable level. Example: if a user in a small department must both create purchase orders and post goods receipts, a monthly sample report by the department head can serve as a compensating control. For each compensating control, document: which conflict is addressed, who performs the control, how frequently, and what happens when irregularities are found.

Continuous Monitoring

SoD management is not a one-off project but a continuous process. Integrate SoD checks into the role maintenance process (with every role change), the user provisioning process (with every role assignment) and regular recertification. This is the only way to prevent new conflicts from arising while you resolve existing ones.

Conclusion

SoD management in SAP is complex but essential. Start pragmatically: create an adapted SoD matrix, identify the most critical conflicts and resolve them by priority. It does not need to be perfect immediately – but it must be documented and traceable.

Get in touch →

Related Articles

Need support with this topic?

We help you with implementation – from analysis to go-live.

Get in touch

← All articles