T100A table — Message Class Master Data Table
T100A is the master data table for message classes (ARBGB), one row per message class, holding attributes such as the master language in which the class was originally created. It does not hold the message texts themselves; those live in T100. Confusing the two tables is the most common mistake when tracing a message text or translation problem.
T100A is the header table behind SAP message classes, sitting alongside T100 which holds the actual per-language message texts. This page covers what a row in T100A represents, how it joins to T100 and to the repository object directory, and the reflex mistakes consultants make when they treat it as a text table.
Published 15 Sept 2026· 886 words
What it stores
One row in T100A represents one message class (identified by ARBGB), independent of any individual message number or language. It carries the master data of the message class itself: the language in which the class was originally authored (its master language) and descriptive attributes of the class as a development object. It does not store any message text and does not repeat per message number - that granularity belongs to T100, which is keyed by language, message class, and message number. T100A is consulted when someone needs to know facts about the message class as a whole rather than about a specific message, for example which language a translation should be compared against, or whether the class exists at all in the system.
Key fields
- ARBGB - the message class identifier, matches T100-ARBGB, this is the primary key of the table.
- MASTERLANG - the master (original) language in which the message class was created; used as the reference language when checking whether other languages are fully translated.
How it joins the data model
- T100A-ARBGB = T100-ARBGB, joining the message class header to its per-language, per-number texts.
- T100A-ARBGB = TADIR-OBJ_NAME where TADIR-OBJECT = 'MSAG', to find the package, original system, and transport layer the message class belongs to.
- T100A-ARBGB = E071-OBJ_NAME where E071-OBJECT = 'MSAG', to find which transport request last carried the message class.
How to read it safely
T100A is a cross-client, repository-style table - it does not carry a MANDT field, so there is no client restriction to apply and none to worry about missing. The table is small, one row per message class in the whole system, so a full read is cheap; the only real discipline is to restrict on ARBGB when joining out to T100, because T100 itself can be large once every language and every message number is counted. Do not attempt to filter T100A by language - MASTERLANG is a single attribute of the class, not a multi-language list.
How to prove it in the data
Symptom: a custom message class shows correct German text but garbled or missing text in Korean. Read T100A for ARBGB = the class in question and note MASTERLANG. Then read T100 for that ARBGB with SPRSL = the master language and separately with SPRSL = 'KO' for the same MSGNR values. If the Korean rows are missing or blank while the master language rows are populated, the translation was never maintained; this is not a display or code page bug, it is an untranslated message class.
ECC vs S/4HANA
T100A is unchanged going into S/4HANA; it remains a standard cross-client repository table maintained through the same message class maintenance transaction. There is no known compatibility CDS view built over it, since it is a development-object table rather than a business or application data table, and it was not part of any Simplification List conversion.
Common pitfalls
- Querying T100A expecting to find the actual message wording; it holds none, the text always lives in T100.
- Assuming MASTERLANG is the language the message currently displays in for a given user; it only marks the language the class was originally authored in, and has no bearing on which language a session runs in.
- Trying to restrict T100A by client; the table has no MANDT field, it is a cross-client repository table like T100 itself.
- Treating a missing row in T100A as proof that a message class was never created, without checking whether it was created directly in T100 by an older or non-standard path that bypassed the header entry; in practice this is rare but has been seen after manual table maintenance outside SE91.
- Editing T100A directly via SE16N/SM30-style table maintenance instead of through SE91 message class maintenance; direct edits bypass the transport recording that message class changes normally get through the repository tools, leaving inconsistent entries between systems.
- Assuming the message class described by T100A is package- or authorization-scoped in the same way its texts in T100 are; the transport object relevant for authorization and release purposes is the message class as a whole (object type MSAG), not individual message numbers.
Whose problem this is
A question about T100A is a development or ABAP object question, not a functional or master data question. The owner is whoever created or maintains the message class through message class maintenance - typically the ABAP developer who wrote the code raising the message, or the technical lead responsible for the custom development package the class belongs to.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/t100aERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.