Lesson 1 of 5
Why SoD matters
10 min
Listen to this lesson
Segregation of duties means that no single person controls every step of a sensitive transaction from start to finish. Classic control theory splits four kinds of duty: authorizing a transaction, recording it, keeping custody of the asset, and reconciling the result. When one person holds two of these for the same flow, they can commit an error or a fraud and hide it, and nobody else is in the path to notice.
In SAP, duties are granted through roles, so SoD is an access question. If one user's roles let them create a supplier and also post and pay that supplier's invoices, the system itself allows the fraud, whether or not anyone ever tries it. Auditors testing Contoso Motor Co.'s internal controls over financial reporting will look exactly for this kind of combination.
The fictitious supplier
- Create a supplierA business partner with the supplier role and a bank account the fraudster controls.
- Post an invoiceA supplier invoice for services that were never delivered.
- Pay itThe payment run picks up the open item and transfers the money.
- Hide itBlock or change the supplier afterwards so the trail looks normal.
No single step here is unusual. AP clerks post invoices every day; master data teams create suppliers every day. The risk is the combination in one user. That is the essence of an SoD risk: two legitimate functions that become dangerous together.
Common SAP SoD pairs
| Function A | Function B | What could go wrong |
|---|---|---|
| Maintain supplier master data | Post supplier invoices or run payments | Payments to fictitious or altered suppliers |
| Create or change purchase orders | Post goods receipts | Orders confirmed as received without independent check |
| Create or change purchase orders | Post supplier invoices | Buyer invoices their own orders, bypassing three-way match independence |
| Maintain customer master and credit limits | Create sales orders | Credit raised to push through risky orders |
| Post goods issues | Run physical inventory adjustments | Stock removed and the difference written off |
| Maintain users or roles | Any business function | Granting yourself access and using it |
Typical conflicts in an S/4HANA rule set. Exact definitions vary by company and are agreed with process owners.
Critical access: risky on its own
Some access is risky without any second function. Maintaining users and roles, changing client settings, maintaining tables directly, running the ABAP debugger with change rights, or holding profiles such as SAP_ALL can each bypass every other control. These are critical access risks: a single action or a single permission that needs to be restricted to very few people and monitored. Rule sets express them as critical action and critical permission risks, alongside SoD risks.
Preventive and detective SoD
Controls come in two flavors. A preventive control stops the problem from happening: if no user can both maintain suppliers and run payments, the fictitious supplier fraud cannot be completed by one person. A detective control finds it afterwards: a monthly review of new suppliers and bank detail changes would spot a suspicious record. Well-designed roles are the strongest preventive control SAP offers, because they are enforced on every transaction, every day, without anyone having to remember. Detective controls fill the gaps that roles cannot close, as lesson 4 shows.
What would you do?
Grace asks Nadia why SoD should be on the conversion plan at all: "Our people are honest, and nobody has committed fraud in fifteen years." What is the best answer?
- SoD means no single person controls authorizing, recording, custody and reconciling for the same flow.
- In SAP, SoD is an access question: the risk exists when roles combine conflicting functions.
- Classic pairs: supplier master plus invoice or payment; purchase order plus goods receipt or invoice.
- Critical access, such as user maintenance or SAP_ALL, is risky on its own.
Check your understanding · not graded
Lesson check
1. Which combination in one user is the textbook SoD conflict?
2. What makes an access risk a critical access risk rather than an SoD risk?
3. Which four kinds of duty does classic SoD theory keep apart?
4. Why is a system conversion a good time to address SoD?