CSKB table — Cost Elements Data Dependent on Controlling Area

One row in CSKB represents one cost element, in one controlling area, valid for one time slice defined by a start and end date. The row does not carry the cost element's number range or chart-of-accounts assignment (that lives in CSKA); it carries what CO needs to process the element inside that controlling area, principally the cost element category, which determines whether the element behaves as a primary cost element, a secondary cost element for internal allocations, a revenue element, or another CO-specific type. A cost element with no CSKB row for a controlling area cannot be used for postings or planning in that controlling area even if the underlying GL account exists and is extended to the company code.

MANDT is the first filter, as always. Restrict next by KOKRS and KSTAR together; either one alone against the full table returns far more rows than useful, since KSTAR ranges typically span the same number range as GL accounts across every controlling area in the client. Because the table is date-sliced, always add a check on DATAB and DATBI against the posting date or the date under investigation rather than assuming the first row returned is the active one. It is common to find two or three CSKB rows for the same KOKRS/KSTAR combination representing successive validity periods, and picking the wrong one gives the wrong cost element category for the period being analyzed.

Symptom: a posting to a GL account fails in CO with an error that the account is not a cost element, or the wrong cost element category is being used for automatic account assignment. Select CSKB with KOKRS equal to the controlling area in question and KSTAR equal to the account number, restricting DATAB/DATBI to bracket the posting date. No row returned confirms the cost element does not exist for that controlling area on that date; a row with an unexpected KATYP confirms the category mismatch driving the error.

CSKB remains a physical table on S/4HANA and continues to be maintained through the standard cost element maintenance transactions, since primary cost elements are represented as GL accounts with CO extension and secondary cost elements retain their own master record structure. The underlying data model has not been collapsed into the universal journal for master data purposes; CSKA and CSKB continue to carry the split between chart-of-accounts-dependent and controlling-area-dependent attributes. Consultants should still expect the same two-table pattern when tracing cost element master data on S/4HANA systems.

Cost element master data is owned by CO configuration and master data teams, usually the same group that maintains the chart of accounts and cost center hierarchy. When a posting fails because a cost element is missing in a controlling area, the fix is a master data creation task for CO, not an FI account issue, even though the symptom often surfaces as a GL posting error.

CSKA holds the chart-of-accounts-dependent half of the same cost element and is checked alongside CSKB in almost every lookup. CSKS and CSKT carry cost center master data and texts that cost elements post against. COEP holds the CO line items that reference KSTAR at posting time. SKA1 and SKB1 confirm the account exists at chart-of-accounts and company-code level before CSKB is even relevant. Cost element maintenance and mass changes are typically performed through the standard cost element master data transactions in the CO-CCA area rather than direct table maintenance.