Project Settlement Errors at Period Close

Controlling reports that period close is stuck because project costs have not moved off the WBS elements onto cost centers, the P&L, or the asset under construction. Finance says the P&L for a cost center or profit center looks understated because expected settlement postings never arrived. A specific project manager notices their WBS still shows a balance after month-end that should have gone to zero. Sometimes the report is vaguer: 'the settlement job ran three hours and finance is asking why costs are still sitting there'. Nobody has looked at the job log yet, because a background job that finishes 'successfully' with a list of object-level errors looks, at a glance, like it worked. The complaint surfaces days into close, close to the hard deadline.

Run the settlement transaction in test mode for the specific project or WBS and capture the full error log rather than the summary line; each entry names the object and the exact rejection reason. Cross-check that object's settlement rule (stored in the settlement rule tables behind CJ20N) against the receiver's current master data status and the allocation structure's cost element group assignments for the period in question. The combination of error message plus rule detail plus receiver status is what turns 'settlement didn't work' into a specific, assignable defect.

The path depends entirely on which check above triggered. A missing or incomplete settlement rule is a data fix at the project object level, corrected in CJ20N or via mass rule maintenance, and does not need a transport. A locked or invalid receiver is also a data fix, resolved by unlocking or correcting the receiving master record, coordinated with whoever owns that receiver, not by changing the project. A settlement structure that does not cover the cost element is a configuration gap; adding the cost element to the correct settlement cost element group in the allocation structure requires a transport through the normal change path and should be tested against a representative sample of projects before release, since it affects every project using that structure. A closed CO period is not a defect at all; it is a timing dependency on the close calendar and is resolved by coordinating with the period-close owner to reopen the period for correction postings, not by forcing the settlement date. A status that blocks settlement is either a business decision, set technical completion if the work is genuinely finished, or a configuration correction to the status profile if settlement was wrongly excluded, which again needs a transport. Missing PA transfer structure entries and expired rule validity dates are configuration and data fixes respectively, applied at their own layer.

The reflex fix is to rerun the settlement job again, sometimes repeatedly, on the theory that it is a locking or timing issue that will clear itself. It rarely does, because CJ8G in background mode finishes with a 'completed' status even when individual objects have errored, so the job looks successful while the actual failing population never changed. A second reflex is deleting and recreating the settlement rule from scratch without reading the specific error message first, which sometimes hides the real cause and reintroduces it the following period. A third is disabling availability control or forcing budget through to let the posting go, which can create a masked budget problem on top of the settlement problem.

Settlement rule correctness on individual projects belongs to the project controller or project manager maintaining the WBS. Allocation structure, PA transfer structure, and status profile configuration belong to the CO/PS configuration team and require a transport, not a quick fix during close. Period lock timing belongs to the controlling period-close coordinator. The handover note should carry the object ID, the exact error message, the receiver, the period, and whether the fix is data-level or configuration-level.