Cost Elements Become G/L Accounts in S/4HANA

Classic ECC behaviour

S/4HANA behaviour

Project impact

• Secondary cost elements that were controlling-area scoped in ECC now require company code extension. Allocation, settlement or assessment cycles that post into a company code where the secondary element was never extended will fail at execution, typically discovered during month-end close rather than in testing, because test cycles often run against a subset of company codes.
• Custom ABAP or interfaces that read CSKA or CSKB directly, or that call cost element BAPIs expecting the old object model, may still function through compatibility views but should not be assumed correct without a check, particularly if they filter on fields that existed only on the CO side.
• Mass creation via batch input recordings built against KA01/KA06 screen sequences frequently breaks, because the underlying screens now route through G/L account logic with different field flow and additional mandatory company code data.
• Authorisation roles built around separate FI and CO cost element maintenance transactions now overlap on the same underlying object; a user restricted from FS00 but allowed KA06 may find the boundary no longer separates what it used to.
• Number range design: cost element and G/L account number ranges, historically allowed to diverge across the two objects, now must coexist without collision, which surfaces gaps in charts of accounts that were designed before this constraint existed.

Migration actions

• Run the standard pre-conversion consistency checks for cost elements against G/L accounts before scheduling the technical conversion; unresolved inconsistencies here block or corrupt the merge and must be cleared first.
• Identify every secondary cost element and confirm the full list of company codes it needs to post in, based on where allocation, settlement, and assessment cycles actually run, not just where they are configured; extend each one accordingly before cutover.
• Reconcile number ranges between the legacy cost element ranges and the G/L account ranges in the same chart of accounts; resolve any overlap before conversion, since retrofitting a number range split afterward is far more disruptive.
• Audit custom reports and interfaces that reference CSKA, CSKB, or cost element BAPIs directly; test them against the compatibility views rather than assuming pass-through behaviour.
• Rebuild or review batch input recordings and any mass-maintenance tooling built on the old KA-transaction screen flow.
• Redesign authorisation roles that relied on the FI/CO transaction split, since that boundary no longer maps cleanly onto the merged object.

Whose problem this is

Common pitfalls

• Teams assume the KA06 transaction behaves exactly as before and skip checking whether the resulting secondary cost element is extended to the company codes it will actually post to; the gap only appears when an allocation cycle runs in a company code excluded from test scope.
• Test conversions run against a shrunk landscape with a handful of company codes active, so extension gaps for secondary cost elements never surface until the full productive run at month end, when settlement or assessment cycles hit every company code at once.
• Custom reports that join cost element tables to G/L account tables assuming the pre-merge structure return silently wrong row counts rather than errors, because the compatibility views still resolve, just not the way the report author expected.
• Authorisation testing focuses on transaction access and misses that the underlying object authorisation now governs both what used to be two separate domains, leaving users with either unintended access or unintended lockout discovered weeks after go-live.