CSKB table — Legacy Cost Element Master: Controlling-Area Data
CSKB is the classic ECC controlling-area-dependent cost-element master table, including the cost element category and validity for a cost element in a controlling area. In S/4HANA, separate cost-element master maintenance is replaced by the G/L account master, which includes controlling-area-specific cost-element attributes for both primary and secondary cost accounts.
CSKB carries the controlling-area-specific master data of a cost element, most importantly its category and validity dates within a given controlling area. This page covers how it joins to CSKA, CSKS, COEP and the general ledger account tables, and the recurring diagnostic pattern where a valid GL account has no usable cost element because CSKB has no open-ended record for the controlling area in question.
Published 20 Sept 2026· 974 words
Diese Seite ist noch nicht auf Deutsch verfügbar.
What it stores
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.
Key fields
- ECC: controlling area and cost element number.
- ECC: validity interval.
- ECC: cost element category and related CO controls.
- CSKA — chart-of-accounts-level classic cost-element data.
- S/4HANA — controlling-area-specific cost-element attributes are part of the G/L account master.
How it joins the data model
- CSKB-KSTAR = CSKA-KSTAR to bring in the chart-of-accounts-dependent header of the same cost element
- CSKB-KSTAR = SKB1-SAKNR to confirm the underlying GL account is created and extended to a company code
- CSKB-KSTAR = SKA1-SAKNR to check the chart of accounts assignment of the account
- CSKB-KOKRS = CSKS-KOKRS when validating that a cost center in the same controlling area can actually receive postings on this element
- CSKB-KSTAR = COEP-KSTAR when tracing which cost element category a posted CO line item resolved to at the time of posting
How to read it safely
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.
How to prove it in the data
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.
ECC vs S/4HANA
SAP S/4HANA documentation defines cost elements as G/L account types and exposes cost-element category in G/L account master data. Therefore CSKB should not be presented as a separately maintained strategic master table in S/4HANA; use G/L account master data and released interfaces for new designs.
Common pitfalls
- Checking only CSKA and concluding the cost element is fine, without checking CSKB for the specific controlling area; a cost element can be defined at chart-of-accounts level and still be missing in a given controlling area
- Reading an expired CSKB row and assuming the cost element is unusable, when a newer row with a later DATAB actually covers the current period
- Assuming KATYP in CSKB is fixed for the life of the cost element; the category can change across validity periods, so historical postings must be interpreted against the KATYP that was active on the posting date, not today's value
- Treating CSKB as the place to check whether the GL account exists at all; account existence and company-code extension live in SKA1 and SKB1, CSKB only confirms the CO-side attributes once the account already exists
- Confusing CSKB with CSKS; CSKB is cost element master data, CSKS is cost center master data, and mixing them up when writing a join produces a query that returns nothing or, worse, returns rows that look plausible but are unrelated
- Assuming a KSTAR value with no CSKA or CSKB row is a data error rather than simply a GL account that was never designated as a cost element, which is a normal and common state for balance sheet accounts
Whose problem this is
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.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/cskbERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.