🔐 SU53 vs ST22- Understanding the Core Difference
Today we are discuss SU53 vs ST22 - Core Difference. When a user cannot access a transaction or gets an error in SAP, two T-codes are commonly used for diagnosis: SU53 and ST22. However, they solve completely different problems. SU53 is the go-to tool for authorization failures (missing roles, missing authorizations), while ST22 handles ABAP runtime errors (dumps, short dumps). Confusing the two wastes hours of troubleshooting time. This guide will make you an expert at knowing which tool to use, when, and why- with real pharma, manufacturing, and finance scenarios.This tutorial or document breaks down the process step by step, using simple language and real-world examples to help you master the skill.
SU53- Authorization Check
Shows the last failed authorization check for any user. Reveals exactly which authorization object and field values are missing.
ST22- ABAP Dump Viewer
Shows ABAP runtime errors (short dumps). Used when a program crashes due to code errors- not access issues.
Why It Matters
Using the wrong tool for diagnosis leads to incorrect fixes, wasted effort, and potential security risks in your SAP system.
SU53 vs ST22- Side-by-Side Comparison
Authorization Failures vs. ABAP Runtime Errors
SU53- Authorization Analysis
T-Code: SU53- Captures the last failed authorization check for any user
- Shows exact Authorization Object and field values that failed
- Used when user gets "Not Authorized" or "No authorization" message
- Works for any user- own or others (need admin access for others)
- Provides the missing auth values needed to fix roles
- Real-time- captures the most recent failure immediately
- Primary tool for Basis / Security consultants
- Does NOT show ABAP code errors or program crashes
- Does NOT show historical authorization failures
ST22- ABAP Dump Analysis
T-Code: ST22- Shows ABAP runtime errors (short dumps / program crashes)
- Used when a program Close mid-execution
- Retains dumps for up to 2 days by default (configurable)
- Used by ABAP developers and Basis consultants
- Shows line of code where the error occurred
- Includes full call stack, system info, and variable values
- Common errors: division by zero, type mismatch, data not found
- Does NOT help with authorization issues or missing roles
- Does NOT show "No authorization" errors- those go to SU53
Golden Rule: If the user sees "You are not authorized..." or "No authorization for..." → use SU53. If the user sees a red dump screen with an error code like RAISE_EXCEPTION, DYNPRO_FIELD_CONVERSION, or MESSAGE_TYPE_X → use ST22.
🛡️ SU53- The Authorization Failure Detective
SU53 is the single most important tool for diagnosing authorization failures in SAP. When a user cannot execute a transaction, display a document, or perform an action- and the message says "Not authorized"- SU53 tells you exactly what is missing.
What SU53 Captures
Every time SAP performs an authorization check (via the ABAP statement AUTHORITY-CHECK) and it fails, the system stores the details of that failed check. SU53 reads this data and displays it in a readable format showing:
| Field | Description | Example Value |
|---|---|---|
| Authorization Object | The SAP auth object that failed the check | M_BEST_BSA (Purchase Order Activity) |
| Activity (ACTVT) | The activity the user tried to perform | 01 = Create, 02 = Change, 03 = Display |
| Field Values | The exact field and value that was checked | BSART = NB (Standard PO) |
| User Profiles | Current profiles/roles assigned to the user | Z_MM_BUYER, SAP_EMPLOYEE |
| Authorization Values | What the user currently has vs what was needed | Has: Display only / Needed: Create |
SAP Tables Behind SU53
| Table | Description | Key Fields |
|---|---|---|
| USR10 | User authorization profiles (what profiles are assigned to the user) | BNAME, PROFILE |
| USR12 | User authorization values (actual auth field values in each profile) | BNAME, OBJCT, FIELD, VON, BIS |
| UST12 | Authorization field values per profile | PROFILE, OBJCT, FIELD, VON, BIS |
| AGR_USERS | Role-to-user assignment (which roles are assigned to which user) | UNAME, AGR_NAME, FROM_DAT, TO_DAT |
| AGR_1251 | Authorization data within roles (objects, fields, values per role) | AGR_NAME, OBJCT, FIELD, LOW, HIGH |
| AGR_PROF | Profile name generated for each role | AGR_NAME, PROFILE |
| SUSR | Last failed authorization check (what SU53 directly reads) | BNAME, OBJCT, FIELD, VAL |
How to Use SU53- Step by Step
User reports "Not Authorized" error
The user tries to execute a transaction- e.g., ME21N (Create PO)- and gets an authorization error message. Ask them to note the exact message text.
Run SU53 immediately- do not delay
Go to transaction SU53. Critical: SU53 only captures the most recent failed check. If the user performs any other action, it may overwrite the relevant failure. Check within minutes of the error.
Check for other users- use SU53 with /n or username
To check another user's SU53, go to SU53 → Menu → Authorization → Display for User → Enter the username. Or use transaction SU53 and enter the username directly. You need SAP_ALL or S_USER_GRP authorization to check other users.
Read the Authorization Object and missing values
SU53 shows you the exact Authorization Object that failed (e.g., M_BEST_BSA), the field (e.g., ACTVT = 01), and what the user currently has. This is everything your Basis team needs to fix the role.
Fix the role in PFCG
Take the missing auth object and values from SU53 to transaction PFCG (Profile Generator). Add the missing authorization values to the appropriate role, generate the profile, and re-assign to the user if needed.
Test and confirm with the user
After role update and profile generation, ask the user to log out and back in (or use SU56 to refresh authorization buffer), then test the transaction again.
Real-World SU53 Scenarios
Buyer Cannot Create Purchase Order- ME21N
A buyer at Union Pharma tries to create a Purchase Order using ME21N and receives the message: "You do not have authorization to create purchase orders of document type NB in purchasing org 1000."
Basis consultant runs SU53 for the buyer's user ID. SU53 shows the failed check on authorization object M_BEST_BSA, field BSART (document type) = NB, activity 01 (Create). The buyer's current role only has BSART = RFQ assigned. Consultant goes to PFCG, opens the buyer's role Z_MM_BUYER, adds BSART = NB with activity 01, generates profile. User logs out and in- issue resolved in 10 minutes.
Why SU53 and not ST22? This is a pure authorization failure. The user got an "unauthorized" message- not a program crash. ST22 would be empty. SU53 gives the exact fix needed.
Finance User Cannot Post a Vendor Invoice- MIRO
The accounts payable user tries to post a vendor invoice using MIRO and gets blocked. The message says: "No authorization for company code 100."
SU53 reveals the failed auth object is F_BKPF_BUK (Accounting Document: Authorization for Company Codes), field BUKRS = 100. The user's role Z_FI_AP only has BUKRS = 200 (the old company code). The user was transferred to a new entity. Consultant adds company code 100 to the role. Done in minutes- no ABAP developer needed.
Sales Rep Cannot Create Sales Order for New Division- VA01
The sales representative (M.R) tries to create a sales order in VA01 for a newly launched product wise division and gets an authorization error.
SU53 shows missing auth for the new sales order type ZDIV (custom division order type created for the new product launch). The user's SD role was not updated when IT Head created the new order type. Security team adds ZDIV to the role's V_VBAK_AAT authorization values- user can now create orders for the new division.
💥 ST22- The ABAP Runtime Error Analyzer
ST22 is used when an SAP program Closed- i.e. the program pileup. mid-execution with a "short dump." This is a completely different problem from authorization failures. ST22 is for developers and Basis consultants investigating why a program stopped working.
What ST22 Shows
| Section | Information Provided |
|---|---|
| Error Category | Type of runtime error e.g. RAISE_EXCEPTION, DYNPRO_FIELD_CONVERSION, NO_HANDLER |
| Date & Time | When the dump occurred- useful for correlating with user complaints |
| User | Which SAP user was running the program when it crashed |
| Program Name | The ABAP program, function module, or class that generated the error |
| Source Code | Exact line number in the ABAP code where the error occurred |
| Call Stack | Full chain of programs and functions that were active at crash time |
| Variable Values | Content of key variables at the time of the crash |
| System Info | SAP release, database, server- useful for SAP OSS notes |
Common ST22 Error Types
| Error Type | Cause | Typical Fix |
|---|---|---|
| RAISE_EXCEPTION | An unhandled exception was raised in a method or FM | ABAP code fix or OSS note |
| DYNPRO_FIELD_CONVERSION | Field type mismatch- wrong data type passed to screen field | ABAP data type correction |
| COMPUTE_INT_ZERODIVIDE | Division by zero in arithmetic operation | ABAP: add zero check before division |
| GETWA_NOT_ASSIGNED | Attempt to access an unassigned field symbol | ABAP: check IS ASSIGNED before access |
| MESSAGE_TYPE_X | Intentional program termination via MESSAGE ... TYPE 'X' | Find the ABAP MESSAGE X statement and investigate |
| TIME_OUT | Program exceeded maximum execution time | Optimize ABAP performance or increase timeout |
| LOAD_PROGRAM_NOT_FOUND | Referenced program or class not found in the system | Transport missing- import the transport |
Production Order Confirmation Crashes- ST22 Needed
The production supervisor confirms a production order in CO11N and the SAP screen turns red with a dump. The error message is: "COMPUTE_INT_ZERODIVIDE in Program SAPLCORF." The user reports the system "crashed."
This is a program crash- not an authorization failure. The user had access rights to CO11N and was mid-confirmation when the program crashed. SU53 would show nothing useful. ST22 shows that SAPLCORF (PP confirmation program) performed a division where the denominator was zero- likely the routing operation quantity was set to zero by mistake. ABAP developer identifies line 847 in the include LCORFM01 and adds a zero check. Issue resolved with a code fix.
Common Mistake: Also many junior consultants run SU53 for this type of crash- SU53 would appear empty or show an unrelated previous failure. The red dump screen is the key indicator to go straight to ST22.
🎯 The 3-Question Decision Framework
When a user calls with a problem, ask these 3 questions in order to instantly know whether to use SU53 or ST22:
Does the error message say "Not Authorized", "No Authorization", or "You are not permitted"?
YES → Go immediately to SU53. This is a clear authorization failure. Run SU53 for the affected user right now (before they do anything else).
NO → Proceed to Q2.
Did the SAP screen turn red / show a short dump with a technical error code?
YES → Go to ST22. This is an ABAP runtime error. An ABAP developer or senior Basis consultant needs to analyze the dump.
NO → Proceed to Q3.
Can the user open the transaction at all, but gets blocked at a specific action?
YES → Still likely SU53. Authorization checks happen throughout a transaction, not just at login. The user may have partial access. Run SU53 exactly after the point of failure.
UNSURE → Check both: Run SU53 first (takes 30 seconds), then check ST22 for recent dumps for that user.
The Bottom Line
SU53 is more important for access issues because 80% of "user cannot access" tickets are authorization problems- missing roles, expired validity dates, or missing auth field values. ST22 is critical for development/technical issues but does not help with access failures at all. Every SAP functional and Basis consultant must master SU53 first.
📊 Complete SU53 vs ST22 Reference Table
| Criteria | SU53 | ST22 |
|---|---|---|
| Purpose | Authorization failure diagnosis | ABAP runtime error / short dump viewer |
| When to Use | User gets "Not authorized" message | Program crashes / red dump screen appears |
| What It Shows | Failed auth object, field, values | Error type, program, line number, call stack |
| Key Tables Read | SUSR, USR12, AGR_1251, AGR_USERS | SNAP (stores dump data) |
| Who Uses It | Security / Basis consultant | ABAP developer / Basis consultant |
| Data Retention | Last failure only (real-time) | 2 days default (configurable) |
| Fix Required | Role update in PFCG | ABAP code fix / OSS note / transport |
| Other User Check | Yes- Enter username in SU53 | Yes- Filter by username in ST22 |
| Interview Weight | ⭐⭐⭐⭐⭐ Essential | ⭐⭐⭐⭐ Important |
| Related T-Codes | PFCG, SU01, SU56, SUIM | SE37, SE80, SM21, SM50 |
Interview Tips- SU53 & ST22
Top questions asked in SAP Basis, Security & Functional interviews
"A user says they cannot execute ME21N. What do you do?"
First, I ask the user what error message they see. If it says "Not authorized" or similar, I immediately run SU53 for their user ID- timing is critical as SU53 only shows the most recent failed check. SU53 will tell me the exact authorization object (likely M_BEST_BSA for POs), the failing field (BSART = document type, EKORG = purchasing org, etc.), and the required activity (01 = create). I then take this information to PFCG to update their assigned role, generate the profile, and ask the user to re-login and test.
"What is the difference between SU53 and SU56?"
SU53 shows the last failed authorization check- it tells you what the user tried to do and was denied. SU56 shows the user's current authorization buffer- i.e., all the authorizations currently loaded in memory for the user's session. SU56 is used to check if a role change has been refreshed in the user's session without requiring a full logout/login. Together: SU53 identifies the problem, SU56 confirms the fix is active.
"SU53 shows no data- but the user still gets an error. Why?"
Three possible reasons: (1) The user performed another action after the failure, overwriting SU53's stored data- ask the user to reproduce the error and run SU53 immediately. (2) The error is NOT an authorization issue- it may be a business validation error or an ABAP exception, in which case check ST22. (3) The program uses a custom authorization check that bypasses the standard AUTHORITY-CHECK statement- in this case, check the ABAP code or use transaction STAUTHTRACE (authorization trace) for a more detailed picture.
Key Table to Remember: AGR_1251 stores all authorization field values within a role. When SU53 shows a missing value, you can cross-check AGR_1251 in SE16 using the role name to see exactly what auth values are currently in that role- before going to PFCG to fix it.