COBK table — CO Document Header Table

One row in COBK represents a single CO document header: a distinct posting event inside Controlling, identified by controlling area, CO document number, and fiscal year. It is created whenever a business transaction generates a controlling document — a primary cost posting from FI, an internal allocation, a settlement of an internal order, direct activity allocation, or a manual reposting. The header carries administrative data: dates, user, and a pointer back to the originating application document. It does not carry the financial content of the posting itself; amounts, cost objects, and cost elements are recorded separately at line item level. COBK exists purely to group those line items under one document and to answer 'who posted this, when, and from where' without touching the line item volume.

Always restrict by KOKRS and GJAHR before running any selection; the table spans every CO posting for every controlling area and year the client has ever run, and a scan without those two fields is expensive. PERBL narrows further to a period. GLVOR is useful to isolate one type of posting (settlements versus allocations versus direct FI-triggered postings) when investigating a specific process. AWTYP is the fastest way to separate CO documents that originated in FI from those generated purely inside Controlling. MANDT is implicit in most tools but matters when working through raw SQL or a database-level tool.

Symptom: actual costs appear posted to the wrong cost center for a given period. Select COBK with KOKRS, GJAHR, PERBL fixed and, if the posting type is known, GLVOR restricted to the relevant business transaction. Take the resulting BELNR values and read COEP with the same KOKRS, BELNR, GJAHR to see the actual line items, cost elements, and amounts. If the origin is unclear, check AWTYP and AWREF on the header to trace back to the FI document that triggered it.

COBK still exists in S/4HANA and continues to be written for compatibility with classic CO reporting and older custom code. The authoritative record of actual postings, including the controlling dimensions, now lives in the universal journal table ACDOCA, which merges FI and CO data at line item level. New reporting and analysis should go through ACDOCA rather than COBK/COEP where possible, but COBK is not obsolete for existing programs that still read it. The structural shape of COBK itself has not materially changed.

The CO functional consultant owns interpretation of GLVOR and the reconciliation of a CO document to the process that generated it. FI/CO integration questions — matching a CO document back to its FI origin — sit with whichever consultant owns the integration point (usually CO, sometimes joint with FI). Basis or data teams get involved only when the concern is volume or query performance, not content.

COEP holds the CO line items keyed by COBK and is where cost element, cost object, and amount actually live. On the FI side, BKPF and BSEG are the tables COBK points back to via AWTYP/AWREF/AWORG when the CO document originates from a financial posting. In S/4HANA, ACDOCA carries the combined FI/CO record and is the preferred source for new reporting. CSKS and CSKB are master data tables referenced from COEP, not from COBK directly.