What is transaction-level access risk analysis?

Transaction-level access risk analysis flags a SoD conflict whenever a user has access to two conflicting transaction codes, regardless of whether the underlying authorization values overlap. For example, if a user has XK01 (vendor creation) scoped to company code 1000 and F110 (payment run) scoped to company code 2000, a transaction-level analysis flags the conflict even though the user cannot actually create a vendor and pay it in the same company code.

Why does authorization-level analysis matter?

Authorization-level analysis matters because transaction-level tools produce large volumes of false positives in SAP environments with multiple organizational units. A user authorized to create vendors in Germany and approve payments in the US has no real conflict: the authorization values do not intersect. Transaction-level tools cannot tell the difference and report the conflict anyway, which wastes remediation effort and undermines audit credibility.

Which SAP access risk tools perform authorization-level analysis?

SAP GRC Access Control performs authorization-level analysis within its Access Risk Analysis (ARA) module, but implementation is complex. MTC Skopos performs authorization-level analysis natively as the default mode, including across company codes, plants, profit centers, and any other organizational fields. Most lightweight SoD tools and many transaction-monitoring products only perform transaction-level analysis.

Does authorization-level analysis catch more or fewer SoD conflicts?

Authorization-level analysis typically catches fewer conflicts than transaction-level analysis, because it filters out combinations where organizational scope does not overlap. However, the conflicts it does catch are real, not theoretical, which makes remediation efficient. A typical large SAP landscape with ten company codes produces 3 to 10 times fewer conflicts under authorization-level analysis than under transaction-level, while identifying the same true-positive findings.

Authorization-Level vs Transaction-Level Access Risk Analysis: Why Depth of Analysis Changes Everything

Q: What is authorization-level access risk analysis?

Authorization-level access risk analysis evaluates SoD conflicts by checking whether the underlying authorization object values overlap, not just whether the user holds conflicting transactions. It reads the full authorization chain (transaction, authorization object, fields, values, and organizational scope) and flags a conflict only when an actual intersection exists. This produces significantly fewer false positives than transaction-level analysis.

Transaction-level access risk analysis flags any user with access to two conflicting transactions. Authorization-level access risk analysis checks whether the underlying authorization values actually overlap, so conflicts that share no company code, plant, or organizational unit are filtered out as false positives. The distinction is not academic: on a real SAP landscape with multiple company codes, authorization-level analysis typically produces 3 to 10 times fewer conflicts than transaction-level, while catching the same real findings.

If your access risk analysis returns a conflict count that alarms the board but nobody can act on, the problem is usually the depth of analysis. This guide explains the difference and why it determines whether an access risk program is taken seriously or quietly ignored.

The core difference in one example

Take a classic SoD pair: create vendor master (XK01) combined with payment run (F110). A user who can do both is the textbook fraud case: invent a vendor, pay them, pocket the money.

Now add organizational scope. The user is authorized to:

XK01 scoped to company code 1000 (Germany)
F110 scoped to company code 2000 (United States)

What transaction-level analysis reports

Conflict found. User can create vendors and run payments.

What authorization-level analysis reports

No conflict. The user can create vendors in CC 1000 but can only pay in CC 2000. The authorization values do not intersect. No company code exists in which the user can execute both sides of the conflict.

Both analyses saw the same user and the same two transactions. They reached opposite conclusions. In a landscape with 10 company codes and 2,000 users, this disagreement scales into thousands of phantom conflicts that remediation teams cannot act on.

Why transaction-level analysis over-reports

Transaction-level tools take a shortcut: check whether the user holds access to tcodes on a conflict list. It is fast and easy to implement, and it ignores three things SAP's authorization concept cares deeply about:

Authorization object fields. XK01 checks F_LFA1_BUK (company code for vendor master). Without overlap on BUKRS field values, there is no real path to execute both sides.
Organizational levels. BUKRS, WERKS, VKORG, KOKRS all scope access. A tool that ignores them assumes the worst case for every user.
Activity values. ACTVT = 03 (display) is not ACTVT = 01 (create). A user with display-only on one side of a conflict cannot modify data, so they cannot realize the conflict.

Every SAP authorization is defined by (tcode, authorization object, field, value). Analysis that stops at the tcode level ignores three of the four dimensions.

Why this matters for the access risk report

The practical consequence of transaction-level over-reporting:

Impact	Transaction-level	Authorization-level
Conflict count	Inflated (often 3-10x)	Realistic
False-positive rate	60-80% in cross-org landscapes	Near zero
Remediation team credibility	Erodes over time (too many "conflicts" are non-issues)	High (each finding is actionable)
Audit defensibility	Auditors must re-verify every finding	Auditors accept findings as real
SoD remediation velocity	Slow (analysts debate which are real)	Fast (act on every finding)

The secondary effect is cultural. Remediation teams that spend 80% of their time dismissing false positives stop taking the access risk analysis seriously. The tool becomes a compliance checkbox, not a security function.

Where each approach makes sense

Transaction-level analysis is not wrong in every case:

Small, single-company-code environments where every user's scope is effectively *. Both analyses converge.
Initial ruleset validation. A fast transaction-level pass can identify gaps in the ruleset before running a full authorization-level scan.
Vendor sales demos. Transaction-level counts produce impressive (scary) numbers that sell the tool.

Authorization-level analysis is needed in:

Multi-company-code landscapes, which covers any organization above mid-market.
Multi-plant or multi-profit-center environments (manufacturing, retail, utilities).
Organizations with derived role architectures where organizational fields are the entire scoping mechanism.
Any environment where the access risk report has to survive an external audit.

What authorization-level analysis actually checks

For every SoD conflict pair, authorization-level analysis evaluates the intersection across multiple dimensions:

Transaction codes. The user must have both tcodes in the conflict.
Authorization objects. The user must have the relevant authorization objects on both sides (e.g., F_LFA1_BUK for vendor creation, F_REGU_BUK for payment).
Field values. Specific authorization fields must have overlapping allowed values (e.g., same BUKRS values on both sides).
Activity values. Both sides must permit the activity that makes the conflict real (typically ACTVT = 01 create or 02 change, not 03 display).
Organizational levels. BUKRS, WERKS, BUDAT, KOKRS, and any others relevant to the conflict. The scope has to intersect.
SU24 proposals. The analysis has to reflect what PFCG actually generates from SU24, not a theoretical mapping.

Miss any one of these and the analysis degrades toward transaction-level accuracy. That is why SU24 maintenance is fundamental: accurate authorization-level analysis depends on accurate SU24 data.

How MTC Skopos handles this

Authorization-level analysis is the default mode in MTC Skopos. The tool reads the full authorization chain (transaction, authorization object, field, value, organizational level) and evaluates SoD pairs as set intersections on the actual values. No intersection, no conflict reported.

This is paired with:

Did-do analysis, which separates theoretical from actually-exercised conflicts
Critical access detection, which runs in the same pass with authorization-value precision, so critical access findings are not over-reported either
Cross-company-code scope verification, with organizational fields treated as first-class inputs rather than approximations

Teams moving from a transaction-level tool to authorization-level analysis usually see a dramatic drop in reported conflict count. The real conflicts did not disappear; the false-positive layer did. What remains is actionable.