¶ Common SAP Segregation of Duties Conflicts
A segregation of duties conflict is a pair of SAP duties that lets one identity complete both halves of a business cycle unobserved, and the RedRays Security Platform reports which accounts hold both sides of such a pair.
The pairs below are the ones auditors ask about first. Each is a conflict for a specific reason, and the reason is always the same shape: the second duty removes the second pair of eyes that the first duty assumes.
¶ Which duty pairs are treated as conflicts?
| Process | Duty A | Duty B | Why it is a conflict |
|---|---|---|---|
| Purchase to pay | Maintain vendor master data | Release an outgoing payment | One person can invent a supplier, point it at an account they control, and release the payment to it. Nobody else ever sees the payee. |
| Purchase to pay | Create or change a purchase order | Post the goods receipt against it | The person who orders confirms that the goods arrived, so a payment can be triggered for goods nobody received. |
| Purchase to pay | Post a vendor invoice | Release the payment run | Invoice entry and payment approval collapse into one identity, which is the classic route for a fictitious invoice. |
| Order to cash | Maintain customer master data | Post or clear an incoming payment | Bank details and the settlement of a receivable are controlled by the same person. |
| Order to cash | Create a credit memo | Release a delivery or billing block | Revenue can be reversed and the block that would have flagged it cleared by the same hand. |
| Record to report | Post a journal entry | Maintain the general ledger master or approve the posting | A journal entry that adjusts a balance is entered and blessed by one identity. |
| Hire to retire | Maintain employee master data | Run or post payroll | Bank details on an employee record and the payroll run that pays them are held together. |
| Basis and security | Create user accounts | Create or assign roles | Whoever holds both can grant themselves any authorisation in the system and create the account to hold it. This is the pair that guards every other pair. |
| Basis and security | Change a role or its authorisations | Transport that change into production | A change to production authorisations passes no independent gate. |
The list is not exhaustive and is not the shipped ruleset. Which duties conflict depends on how a business runs its processes, and the ruleset is expected to be reviewed and extended per customer.
Every account holding both sides of a pair arrives in one list, ordered worst first, with the rule that named it on the row.
¶ What is critical access, and why is it on the same report?
Some findings have no second side. They say that nobody should hold a particular capability at all: unrestricted table maintenance, ABAP development access in production, running arbitrary reports on behalf of another user, executing operating system commands from inside SAP. These are single-sided rules, labelled as critical access rather than as segregation, so a total is never presented as though every row in it were a two-sided conflict.
The third kind of row is the superuser case: an unrestricted profile assigned straight to an account with no role in between. It carries no role path at all, which is exactly why a role-based certification returns clean for those accounts. See role names against authorisations.
¶ Why does the same conflict pair mean different things in different companies?
Because a duty is a job, not a transaction, and because organisational scope decides whether two duties can meet. Someone who raises purchase orders for one plant and can only receive goods into another cannot complete the cycle, and that separation is treated as the working control it is rather than reported as a conflict.
The other variable is what the duty is defined to require. A duty that names only a transaction records no activity, so it is satisfied by the display transaction as readily as by the maintenance one. Duties written over authorisation objects and their activity fields say create, change or post rather than open the screen. Duties, functions and SoD rules explains the difference and why it decides whether a finding is actionable.
¶ Limits of a conflict list
A published list of conflict pairs is a starting point, not a control framework. It says nothing about your organisational scoping, your mitigating controls, or which duties your business genuinely separates. It also says nothing about whether the access was used. Treat it as the agenda for a first scan, and expect the ruleset to change after the first review of what it named.
¶ Frequently asked questions
¶ How many conflict rules should a ruleset have?
Vendors count rules at different levels of their hierarchy, so the number is not comparable between products. A curated library sits in the low hundreds at the risk level, and a set built by pairing every check with every other check will run to thousands while saying less.
¶ Is a vendor-master-plus-payment conflict always critical?
It is normally treated as critical, because it needs no accomplice and leaves a clean document trail. Severity is a property of the rule and can be set to match how the business ranks the risk.
¶ We already separate these duties by role design. Why scan?
Because role design is an intention and the assignments are the fact. Conflicts arrive through composite roles, derived roles, reference users, directly assigned profiles and roles whose names no longer describe their contents.