COSPD table — CO Object Cost Totals Extended Length Table

A row in COSPD represents the periodic total of primary cost postings for one controlling object (a WBS element, a network or network activity, an internal order, or a cost center) for one fiscal year, one value type, one version and one cost element. Primary here means costs that originated outside Controlling: invoices, goods movements, payroll postings, depreciation run results, and similar external postings. The row does not hold a single document; it holds the running sum for up to sixteone periods, so the same combination of object, year, cost element and value type appears once per year, not once per posting. Plan data and actual data live in the same table structure, distinguished by the value type field, so a query that forgets to filter on value type mixes budgeted numbers with real spend and produces cost variance figures that look wrong but are actually just unfiltered.

Always restrict on MANDT implicitly through the connection, then on OBJNR or a range of OBJNR values derived from PRPS, never on cost element or fiscal year alone, since the table is large and cost element is not selective across a whole controlling area. Restrict on WRTTP before running anything, otherwise plan, actual and commitment rows all land in the same result set and get summed together. Restrict on VERSN for plan queries; a query with no version filter on plan data returns every planning version stacked on top of each other. The object number is not the WBS element number directly, it has to be resolved through PRPS or a conversion function, so joining on the raw text of the WBS element key will silently return zero rows.

To confirm that a WBS element shows no actual costs despite invoices posted against it, first resolve the object number for the WBS element from PRPS, then select COSPD for that OBJNR with WRTTP restricted to the actual value type and the relevant fiscal year and version. An empty result with a non-empty result in the commitment value type confirms the spend is sitting as a commitment (purchase order or reservation) and has not yet posted as an actual primary cost, which points at the invoice or goods receipt step rather than at a Controlling data problem.

In S/4HANA, cost totals for actual postings are sourced from the Universal Journal, and the classic COSP/COSS style tables are exposed through compatibility views so older reports and custom code keep working. COSPD sits in this same family as the technical, extended-field-length structure used where the cost element or related key fields needed more characters than the original design allowed. Plan data behaviour is less affected by this change than actual data, since plan totals were never fully absorbed into the Universal Journal in the same way. Consultants should confirm on the specific system release whether the object being queried is a genuine transparent table or a compatibility layer before relying on direct SQL access for performance-sensitive reporting.

A discrepancy surfaced in this table is jointly owned by the FI-CO controlling team, who understand value types, versions and cost element derivation, and the Project System team, who understand how the WBS element or network object number was generated and settled. Neither side should assume the other has already checked the object number resolution before escalating.

COSS holds the secondary cost equivalent of this data (internal allocations, settlements, overhead). CO line item tables hold the individual postings this table aggregates. BPJA and BPGE hold the budget side for comparison against these totals. PRPS, PROJ and PRHI supply the WBS element master data and hierarchy needed to resolve the object number. Transactions that write into this data include project cost planning transactions, actual postings from MM and FI, and periodic settlement runs.