The same segregation-of-duties risk looks different to a process owner and to a security administrator. That gap decides who owns a finding, whether a report can be trusted, and how the conflict finally gets resolved.
Every segregation-of-duties has two dimensions - One as a business risk, the possibility that one person can both create a vendor and pay it. And one as a technical reality: the transaction codes, authorization objects, and field values that either make that possible or quietly prevent it. Business teams routinely see only the first version. Security teams work almost entirely in the second. Most of the friction in an SOD remediation program traces back to that split.
The two layers of every SOD conflict
A functional SOD conflict is a statement about the business process. It says two activities should never be with the same individual, because combining them lets that person initiate and conceal an error or a fraud without a second pair of hands. On the other hand, A technical SOD conflict is a statement about the system. It says a specific role, profile, or user actually holds the authorizations that let both activities be executed.
The two are related but not identical. A ruleset connects them, translating a business risk into the technical entitlements that would trigger it. When that translation is complete and accurate, the functional and technical views agree. When it is not, and in most SAP landscapes it is not entirely, the two diverge, and the business is left interpreting reports it does not fully trust.
What a functional SOD conflict represents
At the functional level, a conflict is named in business language. Maintain the vendor master and release outgoing payments. Create a purchase order and post the goods receipt against it. Change customer credit limits and release blocked sales orders. Each pairing describes a control weakness that internal audit, process owners, and risk functions recognise on sight, independent of how SAP is configured.
The functional definition carries the rationale, the account of what could go wrong. It is the layer where risk ranking lives, where a payment-fraud conflict outranks a master-data-hygiene one. It is where business ownership sits, and where the decision to remediate or accept is ultimately made.
Source: The COSO framework treats segregation of duties as a preventive control within the control environment. The functional layer is where that principle is expressed in business terms.
What a technical SOD conflict represents
At the technical level, the same conflict is expressed as authorizations.
In SAP GRC Access Control, each business function decomposes into Actions and Permissions. Actions are every route that launches an activity: transaction codes, Fiori apps and the OData services behind them, RFC-enabled function modules, CDS-based apps, and Web Dynpro applications. On an S/4HANA landscape a single business function almost always has several of these launch paths at once. Permissions are the authorization objects, fields, and values, that govern what any of those routes can actually touch.
A technical conflict exists when a user or role holds the Actions and Permissions on both sides of the risk. This is where the security team works: S_TCODE values, org-level fields such as company code and plant, activity values of 01 to create, 02 to change, 03 to display, and the difference between merely holding a transaction and holding it with authority that matters.
Functional and technical, side by side
The distinction is easiest to hold in view when the two layers are laid against the same dimensions.
| Dimension | Functional SoD Conflict | Technical SoD Conflict |
|---|---|---|
| Layer | Business process | Authorization / entitlement |
| Expressed as | A Risk built from two conflicting Functions . | Actions (transactions, Fiori apps, OData services, RFC modules, CDS apps, Web Dynpro) plus Permissions (authorization objects, field values, organizational levels). |
| Question it answers | Should one person be allowed to perform both activities? | Can one person actually perform both activities in this SAP system? |
| Primary owner | Process owner, Risk Management, Internal Audit | SAP Security and GRC Administration |
| Worked example | Maintain vendor master and release outgoing payments. |
XK01/BP and F110, together with the corresponding Fiori apps and OData services, with authorization objects such as
F_LFA1_BEK
and
F_REGU_BUK
carrying effective values that enable both functions.
|
| Common false-positive source | Business context such as dual approvals, organizational separation, or compensating controls. | Required actions exist, but authorization values, field restrictions, or organizational levels prevent the user from actually performing the conflicting activity. |
Where the two layers diverge
The gap between functional and technical is where most disputes happen, and it runs in both directions.
Technical presence without functional risk, the false positive. A role may contain a transaction code, the Action, while the underlying Permission restricts it to display, to a company code the user never operates in, or to a plant that was decommissioned years ago. Action-level analysis flags the conflict; permission-level analysis clears it. Reports run only at action level overstate exposure, and business owners who treat every line as a live fraud risk lose confidence in the whole exercise.
Functional risk without technical detection, the blind spot. The more dangerous direction. A custom Z-transaction that duplicates a standard function, an industry add-on, or a business process the ruleset never mapped can carry real conflict while showing clean on every report. Here the technical layer is silent, not because the risk is absent, but because the ruleset is incomplete.
I have seen this play out more than once on S/4 migrations. A ruleset mapped XK01 and BP cleanly on the vendor side, but the equivalent Manage Business Partner Fiori app and its OData service were never added, so the same vendor-creation risk walked straight back in through the launchpad and showed clean on every report. The functional risk had not changed at all. Only one of its technical routes had been left out of the translation.
Context that only the business holds. A conflict can be technically real and operationally irrelevant, segregated by a dual-approval workflow, a downstream reconciliation, or a geographic split the system does not encode. Only the process owner can supply that context, and no report will surface it on its own.
How the ruleset bridges the two
The ruleset is the translation layer, and its structure is worth understanding, because its quality decides whether the functional and technical views agree.
Source: Rules are organised as Risk, then Function, then Action and Permission. A Risk names the business conflict. Each Function within it groups the transactions and authorizations that perform one side of the activity. Actions and Permissions hold the technical detail.
A ruleset inherited unchanged from SAP's delivered content covers standard transactions well and custom development not at all. Every Z-transaction, every localisation, every bolt-on process that carries risk has to be added deliberately. That maintenance is not a one-time security task. It is an ongoing business responsibility, because only the business knows which custom transactions replicate a sensitive standard function.
The business team's role at each layer
Business teams own the functional layer outright. They decide which pairings constitute unacceptable risk, how those risks rank, and, most consequentially, whether a flagged conflict is remediated by removing access or accepted and controlled. That last decision cannot be delegated to security. Removing a transaction to clear a report can break a legitimate process; only the business can weigh the operational cost against the risk.
At the technical layer the business role is narrower but not zero. Business teams confirm whether the transactions a ruleset maps to a function are the right ones, flag custom transactions that belong in scope, and validate that the permission-level restrictions the security team proposes actually match how the process runs. The security team executes; the business verifies the translation is faithful.
Mitigating controls (Materialization): a functional answer to a technical reality
When access cannot be removed without harming the business, the residual technical conflict is accepted and paired with a mitigating control. This is where the two layers meet in practice. The conflict remains real at the authorization level; the control operates at the business level, whether a monthly reconciliation, an independent review of the sensitive activity, a compensating approval step, or an exception report that someone actually reads.
A mitigating control is only as good as its operation. It has a named owner, a defined frequency, and evidence that it ran. On more than one review I have found the control documented and the owner named, with no evidence it had actually run in months, which is precisely the state an auditor is trained to find.
Source: Supporting ITGC guidance treats a documented, operating control as the accepted response to a segregation weakness that cannot be eliminated. A control that exists on paper but never executes converts a known technical risk into an audit finding.
Closing perspective
The distinction between functional and technical SOD conflicts is not academic. It decides who owns a finding, whether a report can be trusted, and how a conflict gets resolved. Organizations that treat every technical flag as a business risk drown in false positives and lose credibility with process owners. Organizations that trust the functional view without validating the technical layer miss the custom transactions and residual authorizations that audits eventually find.
The mature position holds both layers at once: a ruleset accurate enough that the technical view reflects real business risk, business owners engaged enough to supply the context the system cannot, and mitigating controls that operate rather than merely exist. The functional layer says what matters. The technical layer says what is true. A credible access-risk program refuses to choose between them.
