SKAT table — G/L Account Master Text by Language

Each row in SKAT represents the description of one G/L account, for one chart of accounts, in one language. SAP separates the language-independent attributes of a G/L account (control data, account group, sample account indicators) into SKA1, and the language-dependent name into SKAT, because the same account number can carry different descriptions in different logon languages without duplicating the master record. When a G/L account is created or its text is changed, a corresponding row is written or updated per language that has been maintained. If a language was never maintained for an account, no row exists for that language and the account will display blank or fall back to the account number in reports run in that language.

SKAT is joined to the control record and to the company code segment almost every time it appears in a query, because on its own it has no company code and no balance.

MANDT is the first restriction, as always. After that, KTOPL and SPRAS are the two fields that actually control what comes back. Selecting on SAKNR alone across multiple charts of accounts will return one row per chart, per language, and can look like duplicate master data when it is not. If SPRAS is left open, the result set fans out to one row per maintained language, which is the single most common reason a quick SE16 pull looks wrong to someone expecting one row per account. The table itself is small and cheap to read; the risk is entirely in under-restricting it, not in its size.

Symptom: a report run in a second logon language shows the account number instead of a description for certain G/L accounts. Select SKAT with KTOPL equal to the chart of accounts in use, SAKNR equal to the account in question, and SPRAS equal to the language the report was run in. No row returned confirms the text was never maintained in that language; a row returned with blank TXT50 confirms only the short text was maintained.

SKAT continues to exist as a transparent table in S/4HANA in the same shape as in ECC. It was not absorbed into ACDOCA, since ACDOCA carries posted line item data and SKAT is master data text, not a transactional table. G/L account master maintenance in S/4HANA writes to the same underlying SKA1 and SKAT structures even where the maintenance transaction itself has been consolidated under a newer account master app.

The chart of accounts owner, usually a central FI master data or GL accounting function, owns account descriptions. Local company code teams cannot rename an account for their own entity, since the description is tied to the chart of accounts, not to the company code, and a change is visible everywhere that chart of accounts is used.

SKA1 holds the chart-of-accounts-level control data for the same account and is maintained by the same G/L account master transaction that writes SKAT. SKB1 holds the company-code-specific segment, including currency and reconciliation account settings. T004 lists the charts of accounts themselves, and T001 links company codes to the chart of accounts that determines which SKAT rows are relevant for that company code.