USR21 table — USR21 User to Address Link Table
USR21 stores the pointer from an SAP user name to the central address and person records used by Business Address Services. One row per user holds the PERSNUMBER and ADDRNUMBER keys that resolve to the actual name, email, and communication data stored in ADRP and ADRC. It is a linking table, not an authorization table.
USR21 connects the user master record in USR02 to the central address and person data model, giving every user a route to their display name, email, and contact details. This page covers the fields that matter, how the join to address tables actually works, and the pitfalls of assuming this table controls anything about authorizations.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 844 words
What it stores
One row in USR21 represents the link between a single SAP user name and the central Business Address Services data model. The row does not hold the name, email, or phone number itself. It holds two keys, PERSNUMBER and ADDRNUMBER, that point into the person and address tables where that data actually lives. When a user is created through SU01 and given a first name, last name, and email, the system creates or reuses a person and address record and writes the resulting keys into USR21. Reports, workflow notifications, and output that need to show a user's real name or send them an email resolve through this table first, then follow the keys into the address tables to get the actual text.
Key fields
- MANDT - client
- BNAME - user name, matches USR02-BNAME, the primary lookup key
- PERSNUMBER - person number, key into the central person address table
- ADDRNUMBER - address number, key into the central address table
How it joins the data model
- USR21-BNAME = USR02-BNAME
- USR21-ADDRNUMBER = ADRC-ADDRNUMBER
- USR21-PERSNUMBER = ADRP-PERSNUMBER
- USR21-BNAME = AGR_USERS-UNAME (for cross checking whether an address-linked user still holds any role)
How to read it safely
Always restrict by MANDT and by a specific BNAME or a small BNAME range before pulling anything from USR21. The table is one row per user, so in most systems it is small enough to scan, but the real cost sits downstream once the join follows PERSNUMBER and ADDRNUMBER into ADRP and ADRC, which are much larger and shared across HR, business partner, and vendor address data. Never join to ADRC or ADRP unrestricted just to enrich a USR21 extract. Select the USR21 rows first, collect the address and person keys, then look those up as a targeted second step.
How to prove it in the data
Symptom: a workflow notification or output form shows the wrong name or a blank email for a given user. Select USR21 for that BNAME and read PERSNUMBER and ADDRNUMBER. If both are blank, the address link was never created, which happens with mass user uploads that skip the SU01 address screen or with technical and background users that were never meant to have one. If both are populated, take those keys into ADRC and ADRP directly to see whether the address data itself is stale, blank, or shared with another person record.
ECC vs S/4HANA
USR21 is unchanged in shape and purpose on S/4HANA. Business Address Services still resolves user identity through the same PERSNUMBER and ADDRNUMBER keys, and there is no compatibility view replacing it. The table is used the same way it was in ECC, including by Fiori launchpad personalization and notification features that need to show a user's display name or email.
Common pitfalls
- Assuming a deleted user in USR02 also clears its USR21 row. It does not automatically, and the orphaned PERSNUMBER or ADDRNUMBER can be silently reused if a new user is later created with the same or a recycled ID, producing incorrect name resolution for the new account.
- Reading a blank PERSNUMBER or ADDRNUMBER as an error. Many system, batch, and communication users are deliberately created without a full address record and this is expected, not a defect.
- Assuming USR21 has anything to do with authorizations. It is purely an address pointer table; role and profile assignment live in AGR_USERS, USR04, and UST04, and USR21 has no bearing on what a user can do in the system.
- Trying to fix a wrong email by editing USR21 directly. The fields here are pointers, not the data itself; the correction has to happen through SU01 against the address record, which then updates the pointer if needed.
- Treating two BNAME rows that share the same ADDRNUMBER as proof they are the same physical person. Address numbers get reused across renamed or re-provisioned accounts, and matching on ADDRNUMBER alone in a reconciliation report produces false positives.
Whose problem this is
The security or basis team owns the technical link in USR21 because it is written through SU01 as part of user administration. When the underlying address data is wrong, the fix usually belongs to whoever owns master data governance for addresses and business partners, since USR21 only carries the pointer, not the content.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/usr21ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.