CJ88 — Actual Settlement of a Single WBS Element

CJ88 executes actual settlement for a single WBS element (or a whole project run at individual-object level), moving accumulated debit costs to the receivers named in the object's settlement rule - a fixed asset under construction, a cost center, a G/L account, another order or WBS, or a profitability segment. This is a real posting run: each execution creates a settlement document, and depending on the receiver type, a parallel FI document. The structural fact that explains most confusion is that settlement only moves what the settlement rule and the underlying settlement/allocation structure allow it to move. If the rule's distribution percentages do not sum to 100%, or the structure has no mapping for a given cost element, part of the balance stays on the WBS as an unsettled residual, and the run does not error out loudly - it just settles less than expected.

CJ88 sits at period-end close for capital and internal-order-style projects, after costs have been collected on the WBS through purchasing, time confirmation, or internal activity allocation, and after a settlement rule has been maintained (via CJ02 or the project builder). It is the tool of choice when troubleshooting one problem WBS element - a rejected settlement, a wrong receiver, a residual balance - rather than rerunning the entire portfolio through CJ8G's collective processing. Consultants also use it to test a settlement rule change on a single object before releasing a batch job. It is not a reporting transaction; CJI3 or the line item reports are used to check balances before deciding whether CJ88 needs to run again.

Query COBRB filtered on the WBS element's object number to see the maintained receivers and whether the percentages sum to 100%. Query COEP for the same object number filtered on the settlement transaction type to see what has actually been posted, by period and fiscal year. Compare the total actual cost in COSP or COSS for the WBS against the total settled amount in COEP for that transaction type - the difference is the unsettled residual, and it should match whatever the settlement rule's completion gap explains.

The settlement logic and the transaction itself are unchanged on S/4HANA - CJ88 still runs individual settlement the same way, against the same rule and structure concepts. The underlying totals move into the universal journal, so postings that used to sit only in CO totals tables now also appear directly in the universal journal line items, which changes where a consultant looks to verify a posting but not how the transaction is operated. Any Fiori app claiming to replace individual WBS settlement should be treated as unconfirmed until checked in the specific system.

This is a PS/CO functional problem in nearly all cases - the settlement rule, the allocation structure assignment, and the WBS status are all configuration and master data, not code. Basis involvement is limited to period-lock and job-scheduling issues. A good handover states the WBS element, the period and fiscal year attempted, the exact log message, and whether test-run and live results differ.

CJ8G is the collective-processing counterpart for settling many WBS elements or projects in one background job, worth reviewing once individual runs via CJ88 are understood. CJ02 and CJ20N are where the settlement rule itself is created and maintained, so most fixes for a failed CJ88 run happen there rather than in CJ88. CJI3 gives the actual cost line items on the WBS before and after settlement, which is the fastest way to confirm a run actually moved what was expected. CJ01 and CJ03 are useful for confirming WBS master data and status when a settlement run is blocked.