CSKS table — Cost Center Master Data Table

One row in CSKS represents a single time slice of a cost center's master data within one controlling area. Because attributes such as company code, profit center, currency, person responsible, or hierarchy assignment can change over the life of a cost center, SAP does not overwrite the record on change: it closes the current slice by setting its validity end date and inserts a new row for the new period. So a cost center that has been reorganised five times over ten years has five rows in CSKS, not one. The table carries organisational and control attributes only. It has no amount fields and no fiscal year or posting period fields, because it is not a balance table; it is the definition of the object that later postings reference by number.

Always restrict by MANDT first, then by KOKRS, since KOSTL is not globally unique and a query without controlling area can silently join the wrong cost center across areas that happen to reuse the same number. For any lookup tied to a specific date, filter DATAB less than or equal to that date and DATBI greater than or equal to that date rather than assuming DATBI equals 99991231, which only catches the open-ended slice and misses historical or future-dated records. The table itself is not large in most landscapes, so performance is rarely the issue; correctness of the date filter is.

Symptom: a posting to a cost center is rejected as not valid for the posting date. Selection: read CSKS for the KOKRS and KOSTL in question with no date filter, list all rows sorted by DATAB, and compare the posting date against each slice's DATAB and DATBI range. If the posting date falls in a gap between two slices, or after the last DATBI, the cost center has no valid master record covering that date, which explains the rejection independently of any authorization or blocking issue.

CSKS remains a transparent table in S/4HANA with the same time-sliced structure it had in ECC; cost center master data was not absorbed into the universal journal or restructured the way FI totals tables were. It is still maintained through the same cost center maintenance transactions and still feeds ACDOCA as a characteristic on posted line items. Reporting tools increasingly read cost center data through compatibility views rather than the table directly, but the underlying table and its field layout are unchanged.

Cost center creation, blocking, and hierarchy assignment sit with the controlling or FP&A master data team, usually governed by a change request process tied to the org structure. Business unit finance owns the accuracy of the person responsible and cost center category. A dispute over whether a cost center was valid, blocked, or correctly hierarchy-assigned on a given date is resolved by pulling CSKS history, not by asking the requester to recall what they intended.

CSKT carries the language-dependent description for each CSKS time slice. CSKB defines which cost elements are permitted to post to the cost center in a given period. CSKA holds the controlling-area-level cost element master that CSKB references. Maintenance runs through the standard cost center create, change and display transactions and through the cost center group and hierarchy maintenance transaction; mass changes typically go through a dedicated mass maintenance transaction rather than direct table edits.