CJ8G — Collective Settlement of Projects and WBS Elements

CJ8G executes settlement for a batch of projects and WBS elements selected by variant rather than entered one at a time. It does not calculate anything new; it takes actual costs and revenues already posted on the sender WBS element and books them to whatever receivers are defined in the settlement rule, in the proportions or amounts already maintained there. The structural fact that causes most confusion is that CJ8G is purely a distribution engine driven by a pre-existing rule and a pre-existing balance. If the settlement rule is wrong, missing, or incomplete, or if there is no balance to move because nothing was posted in the period selected, CJ8G will either error out object by object or silently settle nothing, and neither outcome looks like the other from the log alone.

CJ8G belongs to period-end closing in PS, run after actual cost postings, overhead calculation, and any interest calculation have already happened for the period, and typically scheduled as a background job across a large portfolio of projects rather than triggered interactively. A consultant reaches for CJ8G when settlement needs to run for many projects in one job, often nightly or as part of a closing cockpit chain, and reaches for CJ88 instead when isolating why one specific project failed to settle. Fiori equivalents exist for monitoring settlement results in S/4HANA closing apps, but the mass execution logic and the transaction itself remain the same underlying process.

Start in COBRB filtered on the sender object number for the WBS elements in question, and confirm a distribution rule exists with receivers and percentages summing to a valid total. Cross-check COSP and COSS for the same WBS and fiscal period to confirm there is an actual balance under the relevant cost elements to move. Then use CJI3 filtered on the same WBS range and period to see whether settlement line items were actually posted; if COBRB and COSP show a valid rule and a balance but CJI3 shows nothing, the run either excluded the object from the selection variant or errored on it, not that there was nothing to settle.

CJ8G exists unchanged in S/4HANA as a classic GUI transaction, and the underlying settlement logic and rule structure are the same as in ECC. What changes is visibility downstream: settlement postings land in the universal journal alongside other actuals, so reconciliation against the general ledger is more direct than in ECC's separate CO tables. There is no dedicated Fiori app that replaces the collective run itself for scheduling purposes; monitoring is typically done through closing cockpit or job monitoring apps layered on top of the same transaction.

Functional PS and CO own the settlement profile, allocation structure, and the settlement rule configuration on the WBS itself. Basis owns background job scheduling, memory limits, and lock contention for large collective runs. A good handover includes the failed-object list from the run log, the specific error text per object, the fiscal period and year used, and a COBRB extract for the affected WBS elements rather than a screenshot of the summary log alone.

Read CJ88 next to understand single-object settlement error diagnosis, since every collective run failure eventually gets isolated and rerun there. CJI3 is the report to confirm what actually posted after a run, independent of what the CJ8G log claims. CJ20N and CJ02 matter because settlement rules and WBS status, the two most common root causes of failure, are maintained through the project builder or the classic change transaction. CN41 is useful for comparing costs before and after a collective settlement run across a hierarchy.