CSKA table — Cost Elements Chart of Accounts Master Data

One row in CSKA represents a cost element's master record at the chart of accounts level, keyed by chart of accounts (KTOPL) and cost element number (KSTAR), valid for a specific date range. Because a single cost element can be used across multiple controlling areas that share the same chart of accounts, CSKA carries only the attributes that do not vary by controlling area, chiefly whether the cost element is also created as a G/L account (a primary cost element) and basic administrative data such as who created the record and when. Attributes that vary by controlling area, most importantly the cost element category that determines whether it is primary, secondary, revenue, or another type, are not stored here; they sit in CSKB, keyed additionally by controlling area.

Always filter on MANDT and KTOPL first; KTOPL is part of the key and a query without it scans across every chart of accounts in the client. Add a KSTAR range or exact value whenever the business question is about a specific cost element. Because the table is time-dependent, filter DATBI greater than or equal to the reference date to get the currently valid record rather than picking up an expired or not-yet-effective one. The table itself is small relative to CO transactional tables, so a scan restricted by KTOPL is cheap; the risk is not performance, it is picking the wrong validity slice or forgetting that BKZKS, not KATYP, is the only category-like flag available here.

Symptom: a posting fails or a report shows a cost element as unknown in a specific controlling area. Select CSKA on KTOPL and KSTAR with DATBI covering the posting date. If a row exists, the cost element is defined at chart of accounts level, so the failure is not a master data gap at this level. Next select CSKB on the same KSTAR plus the controlling area (KOKRS) in question; if no row is returned there, the cost element was never extended to that controlling area, which is the actual root cause.

CSKA remains a valid table in S/4HANA and continues to carry chart-of-accounts-level cost element master data with essentially the same structure. The unification of cost elements and G/L accounts in S/4HANA changes how primary cost elements are maintained (through the G/L account master rather than a separate cost element transaction) but does not remove or restructure CSKA itself; secondary cost elements, which have no G/L account counterpart, are still maintained and stored the same way. Current maintenance is steered toward Fiori apps and compatible CDS views rather than the classic transactions, but reading CSKA directly for master data checks still returns correct results.

Cost element master data is functionally owned by the Controlling team responsible for cost accounting and the chart of accounts. Extensions to new controlling areas, category assignment, and secondary cost element creation are CO master data governance decisions. FI gets involved only for primary cost elements, since any change ripples into the linked G/L account master in SKA1/SKB1.

CSKB carries the controlling-area-dependent counterpart to each CSKA record and is the first place to check when a cost element behaves inconsistently across controlling areas. SKA1 and SKAT hold the G/L account master and its texts for primary cost elements sharing the same number. T004 defines the chart of accounts that KTOPL must reference. Cost element master maintenance in the classic transactions is done through the create/change/display cost element transactions (commonly known as KA01, KA02, KA06 for primary and secondary creation, and KA05/KA23 for display), while CO postings that reference the cost element land in COEP and COBK.