COSB table — CO Object Total Variances Table

One row of COSB holds the summarized variance amounts and consumption quantities for one CO object (a production order, process order, product cost collector or run schedule header), one fiscal year, one value type, one version and one cost element, with values broken out into up to sixteen period buckets instead of one row per posting. Rows are created by variance calculation run against a delivered or settled cost object, representing the price, quantity, resource-usage, scrap and remaining variance categories that the standard cost estimate did not absorb. COSB is a totals table, not a line-item table: it does not record who ran the variance calculation, when, or against which document. It only shows the resulting period-by-period amount per cost element and object. Settlement later reads these totals and transfers the settlement-relevant share onward into the internal and external cost totals tables and eventually into the general ledger.

Always restrict by client, and never select COSB without an OBJNR restriction or an equivalent order number range converted upstream: the table accumulates one row per cost element per object per year, and an unrestricted scan across a large cost object controlling landscape will run long or time out. Restrict on GJAHR, VERSN and WRTTP before adding cost element filters, since the same object can carry actual, plan and multiple version rows that look similar but must not be summed together. Because the period values live in sixteen separate fields rather than sixteen rows, comparing a full-year total means summing WKG001 through WKG012 (or through WKG016 if special periods are relevant), not counting rows. For normal analysis, use the standard cost object controlling reports rather than a raw table pull; go to the table directly only to reconcile a report figure against what is actually stored.

Symptom: a settlement run appears to have pushed scrap variance to a receiver that should not carry scrap costs. Resolve the production order to its object number, then select COSB for that OBJNR with GJAHR equal to the period in question, VERSN 0 and WRTTP for actual, restricted to the scrap-related cost element range. Sum the relevant WKG fields for the periods in the settlement run. If the amount is non-zero in COSB but the receiver's actual costs do not reflect it, the discrepancy is in the settlement rule or in what was marked settlement-relevant, not in variance calculation itself.

The universal journal in S/4HANA carries the financial result of settlement, but the underlying variance calculation step and its category-level totals continue to be written to the classic CO totals structure that COSB represents in current S/4HANA releases, kept for cost object controlling behind a compatibility layer rather than folded directly into the universal journal table. Whether a given release has changed this further is worth confirming with the product costing lead on the project rather than assuming either way, since this area has moved over successive releases.

A variance figure question on COSB belongs to the product costing or cost object controlling consultant, not the FI general ledger team. If the disagreement is between the settled amount in the ledger and the total sitting in COSB, the settlement rule and the variance category settlement-relevance configuration are the first things that consultant should pull up, not a GL posting trace.

COSB sits alongside the primary and secondary cost totals tables in the same CO totals family, all keyed by object number, fiscal year, value type and version. The cost element master tables resolve KSTAR to its category and validity. CO line items provide the transaction-level detail that COSB does not carry. Settlement transactions write the settlement-relevant portion of COSB's variance forward, and the resulting financial postings surface in the universal journal against the receiver.