Product Costing in SAP S/4HANA — Part 1: From Production Order to Material Ledger

Product costing in SAP S/4HANA is not a single transaction or module — it is a continuous, multi-phase process that begins before a production order is created and concludes only after the Material Ledger has revalued inventory at actual cost at period close. I trace that full lifecycle: standard cost estimation, production order execution, period-end variance calculation and settlement, and Material Ledger actual costing. My central architectural argument is that S/4HANA’s mandatory Material Ledger activation, combined with the Universal Journal (table ACDOCA), eliminates the historic separation between financial and managerial accounting. Every goods movement, activity confirmation, overhead surcharge, variance posting, and inventory revaluation writes to the same table, in up to three currencies simultaneously, in real time. The reconciliation ledger — the error-prone, period-end mechanism that aligned CO postings back to FI in classic SAP ERP — is gone. For cost accountants and SAP architects alike, understanding this architecture is a prerequisite for designing correct costing configurations and period-close processes in S/4HANA.

In classic SAP ERP, product costing spanned three loosely coupled modules: Product Cost Planning (CO-PC-PCP), Cost Object Controlling (CO-PC-OBJ), and the Material Ledger (CO-PC-ACT). These modules wrote to separate tables — COSP and COSS for controlling, GLT0 for general ledger, MLHD and MLIT for the Material Ledger — and required a reconciliation ledger to ensure FI and CO remained aligned at period close. The Material Ledger itself was optional, and many clients ran without actual costing entirely, relying on standard cost as both the planning and closing valuation.

S/4HANA changes three things fundamentally. First, the Universal Journal (ACDOCA) replaces the separate FI and CO posting tables — every line item, regardless of origin, lands in a single table with a unified line-item structure. Second, the Material Ledger is mandatory for all clients using materials management, meaning multi-currency inventory valuation is no longer optional. Third, the reconciliation ledger is eliminated: because FI and CO share the same journal, they are always in sync.

The result is an architecture where the cost accountant’s period-close sequence is simpler in concept but requires a more precise understanding of posting dependencies — because everything is connected at the transaction level, not reconciled after the fact.

The diagram below renders the complete end-to-end costing lifecycle across all four phases. Color coding denotes functional layer: orange = planning and source, green = execution and integration, blue = settlement and Material Ledger processing, yellow = Universal Journal, purple = reporting.

flowchart TD
  classDef source fill:#fff3e0,stroke:#e65100,color:#000
  classDef integration fill:#e8f5e9,stroke:#2e7d32,color:#000
  classDef target fill:#e3f2fd,stroke:#1565c0,color:#000
  classDef reporting fill:#f3e5f5,stroke:#6a1b9a,color:#000
  classDef warning fill:#fff3b0,stroke:#cc9a06,color:#000

  subgraph PLAN["Phase 1 — Standard Cost Estimate"]
    CE["Cost Estimate<br/>CK11N / CK40N"]
    BOM["BOM Explosion<br/>Material Components"]
    RTE["Routing / Work Centers<br/>Activity Rates"]
    CCS["Cost Component Split<br/>Material · Labour · Overhead"]
    STD["Standard Price<br/>Released to Material Master"]
    CE --> BOM
    CE --> RTE
    BOM --> CCS
    RTE --> CCS
    CCS --> STD
  end

  subgraph EXEC["Phase 2 — Production Order Execution"]
    PO["Production Order Created<br/>Planned Costs = Standard Cost"]
    GI["Goods Issue MB1A / MIGO<br/>Components at std price"]
    ACT["Activity Confirmation<br/>CO11N / MF42N"]
    OVH["Overhead Surcharge<br/>KGI2 / Costing Sheet"]
    GR["Goods Receipt MIGO<br/>Finished Goods at std price"]
    WIP["WIP Calculated<br/>KKAX / KKAO"]
    PO --> GI
    PO --> ACT
    GI --> WIP
    ACT --> OVH
    OVH --> WIP
    WIP --> GR
  end

  subgraph SETTLE["Phase 3 — Period-End Settlement"]
    VAR["Variance Calculation<br/>KKS1 / KKS2<br/>Price · Qty · Resource · Lot Size"]
    SETORD["Order Settlement<br/>KO88 / CO88<br/>Variances to Cost Object or P&L"]
    PRVAR["Production Variance<br/>Posted to Universal Journal"]
    VAR --> SETORD
    SETORD --> PRVAR
  end

  subgraph ML_LAYER["Phase 4 — Material Ledger Actual Costing"]
    MLACT["ML Document Created<br/>at each goods movement"]
    MLCUR["Multi-Currency Capture<br/>Legal · Group · Profit Center"]
    MLWIP["WIP in ML<br/>Inputs and outputs per step"]
    CKRUN["Actual Costing Run<br/>CKMLCP — Period Close"]
    PPADJ["Purchase Price Variance<br/>allocated to consuming materials"]
    ACTPRC["Actual Price Calculated<br/>per material per plant"]
    REVALUE["Inventory Revaluation<br/>posted to ACDOCA and ML tables"]
    CKM3["Material Price Analysis<br/>CKM3N — Plan vs Actual"]
    MLACT --> MLCUR
    MLACT --> MLWIP
    MLWIP --> CKM3
    CKRUN --> PPADJ
    PPADJ --> ACTPRC
    ACTPRC --> REVALUE
    REVALUE --> CKM3
  end

  UJ["Universal Journal ACDOCA<br/>Single source of truth<br/>FI · CO · ML · AA"]

  subgraph RPT["Reporting — SAP Fiori"]
    PP["Product Profitability App"]
    RWIP["Real-Time WIP App"]
    INSP["Inspect WIP Variance Posting F3669"]
    MLRPT["Material Price Analysis CKM3N"]
  end

  STD --> PO
  GR --> VAR
  GR --> MLACT
  GI --> MLACT
  ACT --> MLACT
  PRVAR --> UJ
  REVALUE --> UJ
  UJ --> PP
  UJ --> RWIP
  UJ --> INSP
  UJ --> MLRPT

  class CE,BOM,RTE,CCS,STD source
  class PO,GI,ACT,OVH,GR,WIP integration
  class VAR,SETORD,PRVAR,MLACT,MLCUR,MLWIP,CKRUN,PPADJ,ACTPRC,REVALUE target
  class UJ warning
  class PP,RWIP,INSP,MLRPT,CKM3 reporting

The standard cost estimate is the planning foundation for everything that follows. It answers a single question before production begins: what should this product cost to manufacture? The answer, once released, becomes the valuation price for all inventory movements associated with that material for the period.

flowchart LR
  classDef source fill:#fff3e0,stroke:#e65100,color:#000
  classDef integration fill:#e8f5e9,stroke:#2e7d32,color:#000
  classDef target fill:#e3f2fd,stroke:#1565c0,color:#000

  PV["Production Version<br/>Selects BOM + Routing<br/>combination"]
  CK["Cost Estimate Run<br/>CK11N / CK40N"]
  BOM["BOM Explosion<br/>Component Materials<br/>at current std price"]
  RTE["Routing Explosion<br/>Work Center Activity Rates<br/>from Cost Center Plan"]
  CCS["Cost Component Split<br/>Material · Labour<br/>Machine · Overhead · Subcon"]
  REL["Mark and Release<br/>Standard Price written<br/>to Material Master"]

  PV --> CK
  CK --> BOM
  CK --> RTE
  BOM --> CCS
  RTE --> CCS
  CCS --> REL

  class CK,PV source
  class BOM,RTE integration
  class CCS,REL target

The standard cost estimate is executed via CK11N (single material) or CK40N (mass run, typically at fiscal year-end or new product launch). The system performs two concurrent explosions:

• BOM Explosion — traverses the bill of materials to identify all raw material and semi-finished components, pulling their current standard prices as input costs.
• Routing Explosion — reads the routing or master recipe to identify work center operations, then applies the activity rates planned for each cost center and activity type (planned cost ÷ planned activity quantity).

The outputs of both explosions consolidate into a Cost Component Split — a structured decomposition of total planned cost into categories: raw material, labour, machine overhead, administrative overhead, and subcontracting. This granularity is critical. The cost component split determines how variances and actuals are classified downstream, and it flows through to the Material Ledger’s actual cost component split when actual costing is activated.

Once marked and released, the standard price is written to the material master (accounting view). From that point forward, every goods movement involving that material — goods issues to production, goods receipts from production, stock transfers — uses this price as the valuation basis.

A notable change from classic SAP ERP is that production versions become mandatory in S/4HANA for selecting the BOM and routing combination used in costing. Each production version can carry its own cost estimate, enabling direct cost comparison across alternative manufacturing processes for the same finished material — a capability that in ERP required workarounds or manual analysis.

When a production order is created, its planned costs mirror the released standard cost estimate for the material and production version. This planned cost is the benchmark against which all subsequent actual postings are measured.

For high-volume repetitive manufacturing where individual order-level traceability is impractical, a product cost collector may be used instead. The product cost collector is a long-lived cost object that aggregates costs across all production orders for a given production version, settling at period close rather than per order.

flowchart TD
  classDef source fill:#fff3e0,stroke:#e65100,color:#000
  classDef integration fill:#e8f5e9,stroke:#2e7d32,color:#000
  classDef target fill:#e3f2fd,stroke:#1565c0,color:#000
  classDef warning fill:#fff3b0,stroke:#cc9a06,color:#000

  PO["Production Order Created<br/>Planned Cost = Standard Cost Estimate"]

  subgraph POSTINGS["Actual Cost Postings During Execution"]
    GI["Goods Issue<br/>MB1A / MIGO<br/>Components at std price<br/>ML document created"]
    ACT["Activity Confirmation<br/>CO11N / MF42N<br/>Labour and machine hours<br/>at planned activity rate"]
    OVH["Overhead Surcharge<br/>KGI2 / Costing Sheet<br/>Percentage or qty-based<br/>absorbs cost center overhead"]
  end

  WIP["WIP Balance on Order<br/>KKAX / KKAO<br/>Real-Time WIP App — Fiori"]
  GR["Goods Receipt<br/>MIGO — Finished Material<br/>Valued at STANDARD price<br/>Delta left on order as variance"]
  ERR["Error Log<br/>Inspect WIP Variance Posting<br/>F3669 — missing account determination"]

  PO --> GI
  PO --> ACT
  PO --> OVH
  GI --> WIP
  ACT --> WIP
  OVH --> WIP
  WIP --> GR
  WIP --> ERR

  class PO source
  class GI,ACT,OVH integration
  class WIP,GR target
  class ERR warning

Raw material and semi-finished components are issued to the order at the standard price of the component, debiting the production order and crediting inventory. The delta between the component’s standard price and its actual purchase price is not resolved at this point — it is captured by the Material Ledger as a price difference and resolved at period close through the actual costing run. A Material Ledger document is created simultaneously, recording the transaction in up to three currencies.

Labour hours, machine hours, and other activity types are confirmed against the order via CO11N / MF42N. The system applies the planned activity rate to calculate the actual activity cost posted to the order. Any difference between the planned rate and the rate ultimately absorbed at period close represents an activity price variance.

In S/4HANA, the Universal Journal captures work center and operation-level detail for each activity confirmation — fields that did not exist in SAP ERP. This granularity is visible in the Costs by Work Center/Operation SAP Fiori app under the Production Accountant role (SAP_BR_PRODN_ACCOUNTANT), but is not surfaced in legacy SAP GUI transactions CO01–CO03 or KKBC_ORD, which use compatibility views.

The costing sheet applies overhead surcharges to the order — either as a percentage of direct costs or as a quantity-based rate — absorbing cost center overhead into the production order cost. This step can be executed periodically or triggered automatically via the period-close cockpit.

Throughout execution, WIP is calculated at each goods issue and activity confirmation for orders that have not yet received a goods receipt for the finished material. WIP represents the investment in partially completed production and must be reported on the balance sheet. It is monitored in real time via the Real-Time WIP App in SAP Fiori. Where account determination configuration is missing, movements still post but errors surface in the Inspect WIP Variance Posting App (F3669) under the Production Accountant role.

When the goods receipt for the finished material is posted (MIGO), the inventory is valued at the standard price of the finished material — not at the actual cost accumulated on the order. This is the pivotal design point of standard costing: the standard price absorbs the theoretical cost into inventory, and the gap between theoretical and actual remains on the production order as a variance balance to be resolved at period close.

flowchart LR
  classDef source fill:#fff3e0,stroke:#e65100,color:#000
  classDef integration fill:#e8f5e9,stroke:#2e7d32,color:#000
  classDef target fill:#e3f2fd,stroke:#1565c0,color:#000
  classDef reporting fill:#f3e5f5,stroke:#6a1b9a,color:#000

  GR2["Goods Receipt Posted<br/>Order balance = Actual minus Standard"]

  subgraph VARCALC["Variance Calculation — KKS1 / KKS2"]
    PV["Price Variance<br/>Input purchased above/below std"]
    QV["Quantity Variance<br/>More/less material than BOM"]
    RV["Resource-Usage Variance<br/>Different activity type used"]
    LV["Lot-Size Variance<br/>Actual qty differs from base qty"]
  end

  SETORD["Order Settlement<br/>KO88 / CO88<br/>Zero out order balance"]

  subgraph DEST["Settlement Destination"]
    CO["Cost Object<br/>Product Cost Collector<br/>Cost Center / WBS"]
    PL["P&L — Expense in Period"]
  end

  UJ2["Universal Journal ACDOCA<br/>Variance posted with full<br/>CO-PA and FI attributes"]
  PP2["Product Profitability App<br/>Variance by category<br/>vs standard cost"]

  GR2 --> PV
  GR2 --> QV
  GR2 --> RV
  GR2 --> LV
  PV --> SETORD
  QV --> SETORD
  RV --> SETORD
  LV --> SETORD
  SETORD --> CO
  SETORD --> PL
  CO --> UJ2
  PL --> UJ2
  UJ2 --> PP2

  class GR2 source
  class PV,QV,RV,LV integration
  class SETORD,CO,PL target
  class UJ2,PP2 reporting

Variance calculation compares the actual debits accumulated on the production order against the standard cost of the confirmed delivery quantity. The system disaggregates the total variance into four categories:

This decomposition is analytically important: it directs corrective action to the right function. A persistent price variance points to procurement; a persistent quantity variance points to the shop floor or BOM accuracy; a lot-size variance typically reflects a planning issue. In high-frequency manufacturing environments — such as food processing running shift-by-shift — all four variance types are identifiable and posted at the end of every shift, providing real-time cost visibility without waiting for period close.

Order settlement clears the variance balance from the production order, routing it to either:

• A cost object (product cost collector, cost center, WBS element) for cases where costs are to be further aggregated; or
• P&L directly, where the variance is expensed in the period.

The settlement posting writes to ACDOCA. After settlement, the production order balance is zero. The settled variances flow into the Product Profitability App, giving management a decomposed view of where standard diverged from actual across the production run.

Before detailing the process, it is essential to distinguish the two capabilities that sit under the Material Ledger umbrella:

A client can have the Material Ledger active without enabling actual costing. In that configuration, inventory is valued in multiple currencies at standard price, but no periodic unit price is calculated and inventory is not revalued to actual cost at month-end. Actual costing must be explicitly activated and requires price determination to be configured in Transaction OMX1.

Every goods movement — goods issue, goods receipt, stock transfer, invoice receipt — generates a Material Ledger document. The diagram below shows how these documents accumulate during the period and feed the period-close actual costing run.

flowchart TD
  classDef source fill:#fff3e0,stroke:#e65100,color:#000
  classDef integration fill:#e8f5e9,stroke:#2e7d32,color:#000
  classDef target fill:#e3f2fd,stroke:#1565c0,color:#000
  classDef reporting fill:#f3e5f5,stroke:#6a1b9a,color:#000

  subgraph MOVEMENTS["Goods Movements During Period"]
    GI2["Goods Issue<br/>Component to Production Order"]
    GR3["Goods Receipt<br/>Finished Material from Order"]
    IR["Invoice Receipt<br/>Actual purchase price confirmed"]
    ST["Stock Transfer<br/>Plant to Plant / Storage Location"]
  end

  MLDOC["Material Ledger Document<br/>Created per movement<br/>Legal · Group · Profit Center currencies"]

  subgraph MLTABLES["ML Period Accumulation"]
    MLBEGIN["Opening Stock Value<br/>at standard price"]
    MLDELTA["Price Differences<br/>accumulated during period"]
    MLCLOSE["Closing Stock Quantity<br/>ready for revaluation"]
  end

  CKRUN2["Actual Costing Run<br/>CKMLCP<br/>Period Close"]

  subgraph ALLOCATION["Multi-Level Variance Allocation"]
    PPV["Purchase Price Variance<br/>from raw material receipts"]
    PRODV["Production Variances<br/>from settled orders"]
    ROLLUP["Multi-Level Rollup<br/>Upstream variances allocated<br/>to consuming materials"]
  end

  ACTPRC2["Actual Periodic Unit Price<br/>per material per plant"]
  REVALUE2["Inventory Revaluation<br/>Delta posted to ACDOCA"]
  CKM3N["CKM3N Material Price Analysis<br/>Standard vs Actual<br/>by Cost Component"]

  GI2 --> MLDOC
  GR3 --> MLDOC
  IR --> MLDOC
  ST --> MLDOC
  MLDOC --> MLBEGIN
  MLDOC --> MLDELTA
  MLDOC --> MLCLOSE
  MLBEGIN --> CKRUN2
  MLDELTA --> CKRUN2
  MLCLOSE --> CKRUN2
  CKRUN2 --> PPV
  CKRUN2 --> PRODV
  PPV --> ROLLUP
  PRODV --> ROLLUP
  ROLLUP --> ACTPRC2
  ACTPRC2 --> REVALUE2
  REVALUE2 --> CKM3N

  class GI2,GR3,IR,ST source
  class MLDOC,MLBEGIN,MLDELTA,MLCLOSE integration
  class CKRUN2,PPV,PRODV,ROLLUP,ACTPRC2,REVALUE2 target
  class CKM3N reporting

When the Material Ledger is active, every goods movement is recorded in up to three currencies and two valuation views:

• Local currency — legal valuation in the company code currency
• Group currency — corporate consolidation currency across a multinational group
• Profit center currency — transfer pricing valuation, capturing intercompany margins

This combination is called a valuation approach. In intercompany scenarios, delta profit cost components (IDs 998/999) capture the intercompany margin. These are analysable in CKM3N only when actual costing is active. For clients running transfer pricing across profit centers or legal entities, the Material Ledger must be configured to carry all three valuation currency types simultaneously — configuration that must be completed before go-live, as it cannot be changed retroactively on active materials.

The actual costing run is the period-close engine of the Material Ledger. It executes in a defined sequence of steps:

flowchart LR
  classDef source fill:#fff3e0,stroke:#e65100,color:#000
  classDef integration fill:#e8f5e9,stroke:#2e7d32,color:#000
  classDef target fill:#e3f2fd,stroke:#1565c0,color:#000
  classDef reporting fill:#f3e5f5,stroke:#6a1b9a,color:#000

  S1["1 — Selection<br/>Define plant and period<br/>scope for run"]
  S2["2 — Single-Level<br/>Price Determination<br/>Actual price per material<br/>from direct postings only"]
  S3["3 — Multi-Level<br/>Price Determination<br/>Upstream variances rolled<br/>down consumption chain"]
  S4["4 — Revaluation<br/>of Consumption<br/>Goods issues revalued<br/>at actual price"]
  S5["5 — WIP Revaluation<br/>Open orders revalued<br/>at actual input prices"]
  S6["6 — Post Closing<br/>Inventory revaluation<br/>delta posted to ACDOCA"]
  CKM3F["CKM3N<br/>Actual cost component<br/>split available"]

  S1 --> S2
  S2 --> S3
  S3 --> S4
  S4 --> S5
  S5 --> S6
  S6 --> CKM3F

  class S1 source
  class S2,S3,S4,S5 integration
  class S6 target
  class CKM3F reporting

The multi-level price determination step is the most analytically significant. It traverses the entire consumption chain — from raw material purchase through semi-finished production through finished goods — and allocates upstream variances downstream to all materials that consumed the affected input, in proportion to actual consumption quantities. A purchase price variance on a raw material flows through to every semi-finished and finished material that consumed it during the period. This is the mechanism that makes actual costing more than a restatement exercise: it produces a fully loaded actual cost that reflects the true economics of the period, including procurement performance, rather than a theoretical standard.

CKM3N is the primary analytical transaction for the Material Ledger. It presents a full reconciliation of standard versus actual cost for a material in a period, broken down by cost component. The cost component split in CKM3N is only available when actual costing is active — without it, the transaction shows price differences in aggregate but cannot decompose them into material, labour, overhead, and other categories.

Every posting across the entire costing lifecycle — goods movements, activity confirmations, overhead surcharges, WIP calculations, variance postings, order settlement, and Material Ledger revaluation — writes to a single table: ACDOCA, the Universal Journal.

flowchart TD
  classDef source fill:#fff3e0,stroke:#e65100,color:#000
  classDef integration fill:#e8f5e9,stroke:#2e7d32,color:#000
  classDef target fill:#e3f2fd,stroke:#1565c0,color:#000
  classDef reporting fill:#f3e5f5,stroke:#6a1b9a,color:#000
  classDef warning fill:#fff3b0,stroke:#cc9a06,color:#000

  subgraph FEEDERS["All Posting Sources"]
    FI2["FI — Financial Accounting<br/>Invoice receipts, payments"]
    CO2["CO — Controlling<br/>Activity confirmations, settlements"]
    ML2["ML — Material Ledger<br/>Goods movements, revaluations"]
    AA2["AA — Asset Accounting<br/>Depreciation, asset transfers"]
  end

  ACDOCA["ACDOCA — Universal Journal<br/>Single table · Real time<br/>Full FI-CO-ML-AA line items<br/>Multi-currency · Multi-ledger"]

  subgraph ELIMINATED["Eliminated in S/4HANA"]
    RECON["Reconciliation Ledger<br/>No longer required"]
    COPA["Classic CO-PA<br/>Replaced by margin analysis"]
    TRGR["Totals Tables GLT0 COSP COSS<br/>Now compatibility views only"]
  end

  subgraph REPORTING2["Real-Time Reporting"]
    PP2["Product Profitability App<br/>Margin by product and plant"]
    RWIP2["Real-Time WIP App<br/>Open order investment"]
    CKM3R["CKM3N<br/>Standard vs Actual cost"]
    INSP2["F3669 — Inspect WIP<br/>Variance Postings"]
  end

  FI2 --> ACDOCA
  CO2 --> ACDOCA
  ML2 --> ACDOCA
  AA2 --> ACDOCA
  ACDOCA --> PP2
  ACDOCA --> RWIP2
  ACDOCA --> CKM3R
  ACDOCA --> INSP2

  class FI2,CO2,ML2,AA2 source
  class ACDOCA warning
  class RECON,COPA,TRGR integration
  class PP2,RWIP2,CKM3R,INSP2 reporting

The elimination of the reconciliation ledger is not merely a technical simplification — it has direct operational consequences that affect both the configuration landscape and the period-close process:

• No period-end FI-CO reconciliation run required. In classic ERP, the reconciliation ledger had to be manually aligned to FI at period close, a process prone to timing differences and errors when intercompany postings or currency translations crossed module boundaries. In S/4HANA, FI and CO are always in sync because they share the same journal line items.
• Real-time reporting without aggregation. ACDOCA holds full line-item detail, so the Fiori reporting apps read directly from it without requiring period-end aggregation into totals tables. GLT0, COSP, and COSS still exist as compatibility views to support legacy reporting queries, but they are no longer the primary data source.
• Multi-ledger support natively. Different accounting principles — IFRS, local GAAP, US GAAP — are handled through parallel ledgers within ACDOCA, not through separate parallel accounts or company codes. The cost accountant configures ledger assignment at the accounting principle level; all subsequent postings carry the ledger identifier and can be reported on independently.

The following diagram renders the recommended period-close execution sequence, integrating all four phases into a single operational view for the cost accountant. The sequence has a hard dependency structure: variance calculation cannot run meaningfully until all goods movements and activity confirmations are posted; order settlement cannot run until variance calculation is complete; and the actual costing run cannot produce correct actual prices until all vendor invoices are posted and all order settlements are complete.

flowchart TD
  classDef source fill:#fff3e0,stroke:#e65100,color:#000
  classDef integration fill:#e8f5e9,stroke:#2e7d32,color:#000
  classDef target fill:#e3f2fd,stroke:#1565c0,color:#000
  classDef reporting fill:#f3e5f5,stroke:#6a1b9a,color:#000

  PC1["1 — Confirm all production activity<br/>CO11N / MF42N<br/>Ensure all hours posted"]
  PC2["2 — Post all goods movements<br/>MB1A / MIGO<br/>Ensure all GIs and GRs complete"]
  PC3["3 — Run overhead surcharge<br/>KGI2<br/>Absorb cost center overhead"]
  PC4["4 — Calculate WIP<br/>KKAX / KKAO<br/>For all open orders"]
  PC5["5 — Variance Calculation<br/>KKS1 / KKS2<br/>For all completed orders"]
  PC6["6 — Order Settlement<br/>KO88 / CO88<br/>Zero out order balances"]
  PC7["7 — Post invoice receipts<br/>Ensure all vendor invoices<br/>matched and posted"]
  PC8["8 — Actual Costing Run<br/>CKMLCP — Steps 1 through 6<br/>Single-level then multi-level"]
  PC9["9 — Review CKM3N<br/>Validate actual prices<br/>and cost component split"]
  PC10["10 — Financial Close<br/>ACDOCA balanced<br/>Fiori apps reflect actuals"]

  PC1 --> PC2
  PC2 --> PC3
  PC3 --> PC4
  PC4 --> PC5
  PC5 --> PC6
  PC6 --> PC7
  PC7 --> PC8
  PC8 --> PC9
  PC9 --> PC10

  class PC1,PC2 source
  class PC3,PC4,PC5,PC6,PC7 integration
  class PC8,PC9 target
  class PC10 reporting

One operational nuance worth flagging: invoice receipts (step 7) often arrive after initial goods receipt posting, creating price differences between the standard purchase order price and the actual invoice price. These differences are captured in the Material Ledger as they post and are picked up by the actual costing run in step 8. Clients that run the actual costing run before all invoices are posted will calculate an actual price that understates the true period cost. The sequence above reflects this dependency explicitly — the actual costing run must be the last substantive step before financial close.

S/4HANA’s product costing architecture is coherent in a way that classic SAP ERP never fully was. The Universal Journal resolves the structural tension between financial and managerial accounting by making it a non-issue: there is one posting table, and everything goes into it. The mandatory Material Ledger extends that logic to inventory, ensuring that material values are always expressible in multiple currencies and — if actual costing is activated — always reconcilable to the actual economics of the period.

For practitioners configuring or operating this landscape, three recommendations follow from my analysis:

1. Activate actual costing if inventory accuracy at period close matters to the business. The Material Ledger without actual costing provides multi-currency valuation but leaves inventory on the balance sheet at standard price. For businesses with volatile input costs, significant purchase price variance, or regulatory requirements for actual-cost inventory reporting, this is an incomplete solution. Actual costing is the mechanism that closes the gap. The configuration investment is front-loaded — price determination settings, cost component structure, ledger assignments — but the period-close process thereafter is largely automated through CKMLCP.

2. Treat the cost component split as a design decision, not a default. The cost component split defined in the standard cost estimate propagates through variance analysis, Material Ledger actual costing, and CKM3N reporting. A poorly designed cost component structure — too few categories, or categories that mix material and conversion costs — limits analytical value downstream. The structure should be designed with the end reporting questions in mind: what level of cost decomposition does management need to drive decisions?

3. Sequence period-close activities with the actual costing run last. The most common period-close error in Material Ledger environments is running CKMLCP before all vendor invoices are posted, resulting in an actual price that does not reflect the full period cost. The period-close sequence in Section 9 above is the correct dependency order. Clients using the SAP Closing Cockpit should encode these dependencies as predecessor relationships to prevent out-of-sequence execution.

The broader implication is architectural: S/4HANA makes the costing system a real-time operational tool rather than a period-end reporting exercise. WIP is visible in real time. Variances are calculable at the end of every shift. The product profitability app reads from ACDOCA without aggregation. For finance teams still running period-close as a multi-day manual process, the constraint is no longer the system — it is the operating model around it.