Costing Run Ignoring an Updated Material Price
The costing run usually still shows the old price because the valuation date used for the run predates the new condition record's validity start, because the price was entered as a future price rather than the current one, or because the valuation strategy in the costing variant reads a different price source (standard price, moving average, a different info record) before it ever reaches the updated condition. The fix is almost always a date or sourcing correction, not a manual price override.
Covers why a marked and released standard cost estimate keeps reflecting a superseded material price after purchasing or planning has updated it. Walks through the valuation date, future-price, and strategy-sequence causes in order of frequency, gives the transaction-by-transaction check sequence, and separates the data fix from the configuration fix that needs a transport.
Published 16 Sept 2026· 1,195 words
The business symptom
Controlling or the product cost analyst reports that this month's standard cost estimate for a finished good or semi-finished material still reflects last quarter's raw material price, even though purchasing confirms the new contract price was entered weeks ago. The complaint usually surfaces during margin review: 'we negotiated a lower resin price in October but the November standard cost run still shows the September number' or 'the vendor price increase went into the info record but the cost estimate did not move.' Sometimes it is phrased the other way: a manual price change was pushed into the material master directly and nobody understands why the next costing run overwrote it back to the old figure. Either way, the business does not distinguish between the costing run, the material master price fields, and the underlying purchasing condition record — they just see a number that has not moved when it should have.
The configuration behind it
- Valuation date on the costing run predates the new price's validity start. CK40N or CK11N was executed with a costing date or valuation date that falls before the effective-from date on the updated purchasing condition record, so the pricing procedure legitimately still returns the old condition.
- New price maintained as a future price, not a current one. The material master accounting view holds it in the future planned price field, but the costing variant's valuation strategy is configured to read the current standard or current planned price, so the future value is invisible to this run until the price change is executed to move it forward.
- Purchasing info record condition (PB00 or equivalent) has the right price but the wrong validity window, wrong scale quantity, or is tied to a vendor or purchasing organization the strategy sequence does not check first, so the system falls through to a different, older source.
- Valuation strategy sequence in the costing variant's valuation variant is ordered to check standard price or moving average price ahead of purchasing info records, so a purchasing price update never gets reached at all regardless of its date.
- Cost estimate was created and even released, but marking and release (CK24) happened before the price update landed, and nobody reran the costing run afterward — the mass run that populates the plan is a snapshot, not a live query.
- Quantity structure (BOM/routing explosion date) is stale, pulling components or a routing version that predates a related engineering or sourcing change, which is sometimes confused with a pure price issue when the real cause is a wrong component being costed.
- Costing run for a different plant, costing version, or lot size than the one the price change was maintained against, or a special procurement key redirecting the material to a different valuation source (subcontracting, stock transfer) that has its own price logic.
What to check
- CK13N or CK11N: display the cost estimate itemization and check the valuation date, costing lot size, and which price source (origin indicator) was used for the line in question.
- MM03: accounting view of the material, current standard price, moving average price, and future price fields, to see what value actually sits in the material master right now.
- ME13 or ME11: the purchasing info record's condition records, checking validity start and end dates, scale quantities, and vendor/purchasing organization against what the costing run should be reading.
- CK40N run log: costing variant used, valuation variant assigned to it, and the costing date entered for that run.
- OKKN or the valuation variant configuration behind it: strategy sequence order for material valuation to confirm whether info record price is checked before or after standard/planned price.
- CK24: marking and release status and date, to confirm whether a run happened after the price update but was never released into the material master.
How to prove it in the data
Pull the cost estimate itemization for the material and compare the valuation date on the header against the validity start date on the purchasing info record condition — a valuation date earlier than the condition's start date is conclusive. Separately, list the material master's current price fields against the future price fields to show which one holds the new value, and check the CK24 release date against the date the price change was posted, to see whether a stale released estimate is simply being reused.
Resolution path
If the cause is a valuation date issue, this is a data-only fix: rerun CK40N or CK11N with a costing date on or after the condition record's validity start, then mark and release again through CK24. If the price was parked as a future price, either wait for the scheduled price change activity to move it into the current field, or correct the field the costing strategy actually reads — also a data change, no transport needed. If the info record condition itself has the wrong validity window or scale, correct it in ME12 or via the relevant condition maintenance, again a data fix owned by purchasing. If the root cause is the valuation strategy sequence in the valuation variant reading the wrong price source ahead of purchasing conditions, that is a controlling configuration change to the valuation variant, requires sign-off from the product costing lead, and moves through a transport — it should never be patched ad hoc in production. If the quantity structure was stale, refreshing the BOM/routing explosion date and rerunning the costing job resolves it without any config change.
The fix people try first (and why it fails)
The reflex fix is to open CK11N for the affected material and manually overtype the price in the itemization, or to push the number directly into the material master via a price change transaction and call it done. This produces a cost estimate that looks correct for one period but breaks the automated logic — the manual override is not traceable back to a condition record, gets silently overwritten the next time the mass run executes with the old strategy sequence, and the same complaint reopens next month. It also hides the fact that the info record or valuation variant is genuinely wrong, so nobody ever fixes the source.
Whose problem this is
Product costing within controlling owns the costing variant, valuation variant, and strategy sequence configuration. Purchasing owns the info record and condition record accuracy. The handover note should state the material and plant, the costing run and version affected, the valuation date used versus the condition validity date, and whether the fix is a data rerun or a valuation variant change requiring a transport and sign-off.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-functional-issues/costing-run-not-picking-up-the-new-material-priceERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.