SAP SU53 — Display Authorisation Check
When SAP tells you that you have no authorisation, it is not being vague on purpose. Underneath, something very precise happened: a program asked whether your user has an authorisation object with particular field values, and the answer was no.
An authorisation object is a named check with up to ten fields. S_TCODE has one field, TCD, holding a transaction code. A financial document object will have a field for the activity (display, change, create) and a field for the company code. Your roles grant combinations of values; the program asks for one combination; if no role covers it, the check fails.
SU53 displays that failed check. It names the object, lists each field, shows the value the program asked for, and shows what your user actually has. That turns "no authorisation" into a specific, actionable sentence.
The one rule that matters: run it immediately, in the same session, and do nothing in between. SU53 shows the last check for your user. Navigate somewhere else first and you may overwrite it with a successful check from another screen.
When you would actually use SU53
- Immediately after any "no authorisation" message, before doing anything else.
- Producing the evidence a security team needs to grant the right access.
- Confirming whether a failure is genuinely an authorisation problem or something else wearing the same message.
- Checking, after a role change, that the object you expected is now covered.
What the screen looks like
Failed authorisation check
The fields, in plain English
The name of the check that failed. S_TCODE means you cannot start the transaction at all. Anything else means you got into the transaction and were stopped by a check inside it.
Watch out: This distinction is the most useful thing on the screen. S_TCODE is a different request from a data-level check, and confusing the two wastes a round trip with the security team.
The field present on most objects saying what you were trying to do. 01 is create, 02 change, 03 display, 06 delete. Being granted 03 and not 02 is the normal shape of read-only access.
For each field of the object, the value the program requested. Read them as a sentence: this object, this activity, this organisational value.
Watch out: A failure on an organisational field such as company code or plant usually means your access is correct in kind but does not cover that entity. That is a much smaller request than "give me this transaction".
Whose check is being shown. By default your own. Users with the right authorisation can enter another user name to see theirs, which is how a support desk investigates without asking for a screenshot.
When the check was recorded. Worth reading — if the timestamp is not from the last minute, you are looking at an older failure and not the one you just hit.
Step by step
- 1Hit the authorisation error.
- 2Open a new session and run SU53 straight away, without navigating anywhere else first.The check buffer holds the most recent check. Anything you do in between can replace it.
- 3Read the object name, then the field values.
- 4Take a full screenshot including the object, the fields and the timestamp.
- 5Send it to the security team with what you were trying to do and why.
- 6After the role change, repeat the original action and run SU53 again to confirm.
Errors you will hit, and what they mean
No authorisation data exists for this user
Why: No failed check is in the buffer. Either the last check succeeded, or the failure happened in a different mode or session, or something already overwrote it.
Fix: Reproduce the error and run SU53 immediately afterwards, in a second session opened beforehand so you do not navigate away.
SU53 shows a successful check in green
Why: The last check your user performed passed. The problem you hit was not an authorisation failure at all.
Fix: Look elsewhere. A missing configuration entry, a locked object or a status restriction can all produce messages that read like access problems.
The failure was in a background job or an RFC call
Why: SU53 reports checks in your own dialog session. A check that failed under the job user or the RFC user is not in your buffer.
Fix: For a background job, read the job log in SM37. For an RFC, the check happened under the destination’s user and has to be traced there.
Common questions
What is the difference between SU53 and an authorisation trace?
SU53 shows the single most recent failed check. A trace, run through the authorisation trace transactions, records every check over a period, successful and failed. SU53 answers "why did that one thing fail" in ten seconds; a trace answers "what does this whole role actually need" and is the tool for role design.
What is the difference between SU53 and SUIM?
SU53 looks at one failed check. SUIM is the user information system: which users have an object, which roles contain it, what changed and when. SU53 tells you what is missing; SUIM tells you who else already has it and which role to add.
Why does SU53 sometimes show nothing at all?
Because the buffer holds only the latest check and you navigated after the failure. Open a second session first, reproduce the error in the original one, then run SU53 in the second.
Transactions that go with SU53
Reading about it only gets you so far
Practise SAP transactions in a safe simulated environment and keep what you learn.
Practise SAP transactions hands-on
Interactive modules, games, and an AI tutor — free to start.
Get started free →