Inventory aging, done as aging

How to prepare an inventory aging report is among the longest-running recurring questions on SAP’s community forums, spanning versions, decades, and deployment models. The honest answer has not changed: the delivered analyses show slow movers by consumption and days since last movement, and neither is aging. Stock is not old because it moved rarely; it is old because the units on hand entered the warehouse long ago and did not leave.

The structural reason there is no standard report: answering properly requires attributing today’s on-hand quantity to the historical receipts that produced it, first in, first out. The live data model stores quantities and movements, not surviving receipt layers, so the delivered tools have nothing to age.

In the warehouse, the receipt-layer table is derived once from movement history: every receipt becomes a layer, every issue consumes the oldest open layers, and what remains is today’s stock with its true entry dates attached. Aging bands, valuation of each band, and the slow-burning excess a consumption report never shows all fall out of that one derivation.

The bands sum to the same on-hand total the daily stock snapshot stores for the date, so aging and stock reporting cannot drift apart. Sample values are illustrative, never client data.

Aged bands with values attached are the working input for excess and obsolescence reserves, for write-down proposals a controller can defend line by line, and for the purchasing conversation about why a year of demand sits on a shelf.

The consumption-based analyses flag candidates; the receipt-layer model prices the problem. That difference is why the fifteen-year thread keeps reopening, and why the answer lives in a model you own rather than a report you wait for.