KSU5 — Execute Actual Assessment Cycle

KSU5 executes an actual assessment cycle that has already been defined through cycle maintenance. It reads the sender cost centers and segments in the cycle, applies the chosen allocation basis (fixed percentages, fixed amounts, or statistical key figures), and posts the result to the receivers using the assessment cost element assigned to each segment. The structural fact that drives most confusion: assessment always posts under one secondary cost element per segment, regardless of how many original primary cost elements made up the sender's balance. A receiver that expected to see the original cost element breakdown will instead see a single assessment line, and reconciling back to the sender's raw postings requires the cycle segment definition, not the receiver's cost element report.

KSU5 is run during period-end close in Controlling, after actual primary postings and statistical key figures for the period are complete, and before profitability or product costing reports that depend on fully allocated cost center costs. It is used when service or overhead cost centers need their costs pushed to consuming cost centers, orders, or segments without preserving the original cost element detail. Distribution (a separate transaction) is chosen instead when the receiver needs to see the original primary cost elements. Manual reposting transactions are used for one-off corrections rather than recurring allocation logic. On S/4HANA a Fiori app for running assessment cycles is available as an alternative entry point to the same underlying logic.

Query COEP (or ACDOCA on S/4HANA) filtered by controlling area, fiscal year, period, and cost element in the assessment cost element range used by the cycle. Compare the sender line (credit, negative debit indicator) against the receiver lines (debit) for the same cycle run to confirm the total nets to zero. Cross-check the sender's original primary-cost-element balance in COSS for the same period to confirm the basis amount the cycle actually redistributed, since the assessment line itself will not show that detail.

The transaction and its underlying cycle logic are unchanged on S/4HANA. The postings that previously lived only in COSS and COEP now also flow into the universal journal table ACDOCA, which becomes the primary reporting source, with the classic CO totals tables retained mainly for compatibility. A Fiori app exists for running assessment cycles as an alternative to the GUI transaction, but it drives the same cycle definitions and produces the same result.

This is a functional Controlling problem, not Basis or ABAP, unless the run fails with a short dump or performance timeout on a very large cycle. A good handover includes the cycle name, controlling area, fiscal year and period run, whether the run was test or live, and the job log or spool output showing the exact error or zero-allocation segment.

Cost center master data should be checked in KS03 whenever a sender or receiver is missing from the cycle results. KSB1 is the standard way to verify actual line items on both sender and receiver cost centers after the run. KB11N is the manual alternative when a one-off correction is needed instead of rerunning the whole cycle. OKB9 is worth reviewing when default account assignment logic interferes with where assessment postings land on the receiver side.