KAKO table — Costing Header for Product Cost Estimates

One row in KAKO represents the header of a single product cost estimate run for a material at a plant, identified by a costing number, for a specific costing type, valuation variant, costing version, and costing date. It carries the overall status of that estimate (marked, released, error, without quantity structure, and so on) and the control settings that governed the run, such as lot size and costing date used to price materials and activities. It is the anchor record that CK11N, CK13N, and mass costing runs like CK40N create and update. The actual priced detail, the exploded BOM and routing quantities, and the cost component values are held in separate itemization and cost component tables, not in KAKO itself. A material can accumulate many KAKO rows over time as estimates are re-run for different periods or versions.

Always restrict on MANDT and on plant (WERKS) before anything else; KAKO accumulates across every material ever costed at that plant and grows continuously with each costing run. When chasing a specific estimate, filter by costing type (KALKA) and costing date (KADKY) rather than pulling the full history for a material, since the same material can have dozens of header rows across periods and versions. Status (STATU) has to be read before trusting any row as current; a row can exist with an error or incomplete status and still show up in a naive select. Avoid joining directly on assumed BOM/routing fields since KAKO does not store them; resolve the quantity structure separately through MAPL, MAST, STKO and PLKO for the same material, plant and date.

Symptom: a standard cost estimate for a material looks like it used an outdated routing. Select KAKO for MANDT, WERKS and the material's costing number, order by KADKY descending, and read STATU and TVERS on the most recent row to confirm which run is actually current. Then separately check MAPL for the same material and plant, comparing the validity dates of the task list assignment against KADKY, to confirm which routing alternative was in force on that costing date rather than assuming the current routing was used.

KAKO is retained in S/4HANA as part of the classic product cost estimate data model; it was not absorbed into the universal journal the way FI/CO actuals were. Cost estimates created through CK11N, CK13N or CK40N still populate this header table alongside the related itemization and cost component tables. Reporting apps may expose the data through compatibility or analytical views, but the underlying table structure and its role as the costing run header are unchanged from ECC.

A product costing (CO-PC) consultant owns questions about KAKO status, costing variant configuration and why a run failed or produced an unexpected result. A PP consultant gets pulled in when the dispute is about which BOM alternative or routing/task list was actually selected for the quantity structure on a given costing date, since that logic sits in MAPL and MAST/STKO rather than in KAKO itself.

MAPL supplies the task list assignment (routing selection) used when a costing run needs a quantity structure, feeding into PLKO, PLPO and PLAS for the operations valued. MAST and STKO/STPO supply the BOM alternative for the same material and plant. CK11N, CK13N and CK40N are the transactions that create and update KAKO rows; CK24 and related marking/release transactions change STATU without creating a new costing run.