K-10
Excess & Obsolete (E&O)
How much inventory has no forward demand to justify it — and is excess defined by coverage horizon, by age, or by the accounting reserve policy?
There is a reference build of this metric: the Inventory Health & Working Capital dashboard in the showcase runs this definition over frozen, simulated data — not a live client system.
Definitions and source tables below are current to the date above — verify against current SAP, Oracle, Microsoft, Infor, and Databricks documentation before you build.
What E&O measures
Excess and obsolete is two populations wearing one acronym. Excess is inventory you own more of than the horizon needs — still good, still sellable, just early or overbought. Obsolete is inventory with no path to demand at all: superseded, expired, discontinued, or built for a customer who left.
Blending them into a single number hides the split that decides the action. Excess is a planning problem with an operational answer — rebalance it, sell it through, slow the replenishment. Obsolete is a write-off with an accounting answer. A dashboard that reports one combined figure gives its audience no way to tell whether the exposure is recoverable, and the two components can move in opposite directions inside a flat total.
The other thing to settle early is what defines excess in the first place. A coverage horizon is the planning definition — value beyond N months of forward demand — and it is honest as long as the horizon is printed next to the number, because extending the horizon reduces reported excess without a single unit moving. Age-based definitions are how finance reserves; recency of last movement is the cheap approximation. They disagree, and reconciling them is the work.
Also answers to E&O · SLOB · Excess Stock · Obsolescence · Slow-Moving Inventory
The decision switches
Three switches. The first one is also the one most often adjusted quietly, which is why the horizon belongs on the chart.
| Switch | Settings | Practice default |
|---|---|---|
| Excess definition | Coverage beyond a declared horizon · Age-based · Last-movement recency | Coverage-based for operations, reconciled to the age-based reserve — and print the horizon, because moving it moves the number with no physical change. |
| Obsolete trigger | Zero forward demand · Lifecycle status · Reserve policy | Lifecycle status corroborated by zero demand — either signal alone misfires. |
| Gross vs net of reserve | Gross value · Net of reserve | Report both, labeled — they answer different questions for different audiences. |
Excess definition
- dependsCoverage beyond a declared horizon — the planning default — value beyond N months of forward demand
- dependsAge-based — how finance usually reserves, and structurally blind to future demand
- dependsLast-movement recency — cheap to compute, crude, and it misses seasonal items entirely
Practice default Coverage-based for operations, reconciled to the age-based reserve — and print the horizon, because moving it moves the number with no physical change.
Obsolete trigger
- dependsZero forward demand — catches dead stock, and also catches items between planning cycles
- dependsLifecycle status — end-of-life flags on the item master, which are only as current as the maintenance behind them
- dependsReserve policy — the accounting definition, which follows rather than leads the operational one
Practice default Lifecycle status corroborated by zero demand — either signal alone misfires.
Gross vs net of reserve
- dependsGross value — the operational exposure — what is actually sitting there
- dependsNet of reserve — the P&L view, already reduced by what has been written down
Practice default Report both, labeled — they answer different questions for different audiences.
Formula & grain
E&O value = Σ value beyond the coverage horizon (excess) + Σ full value of obsolete items
- Numerator
- Value beyond the horizon, and the full value of items flagged obsolete — kept as two figures
- Denominator
- Total inventory value at the same valuation, when reporting E&O as a percentage
- Grain
- Item × location, valued at the declared cost basis
- Note
- Age of stock is derived from movement history through a FIFO replay, not read from a column.
Common pitfalls
- One blended number — Excess is a planning problem and obsolete is a write-off, and a single combined figure hides both. Report them as two numbers with two owners.
- Age from the receipt date of the oldest record — Age is a derivation over the movement ledger — a FIFO replay that consumes the oldest layers first — not a column anyone maintains. Stock that predates the movement history is right-censored, not exactly as old as your history is long.
- Horizon games — Extending the coverage horizon from six months to twelve fixes excess on paper and changes nothing in the warehouse. Print the horizon wherever the number appears, and treat a change to it as a restatement.
- Demand basis drift — Coverage measured against a forecast inherits the forecast's bias: an over-forecast portfolio shows artificially clean excess, right up until the forecast is corrected and the excess appears all at once.
Source tables — SAP
Source tables — JD Edwards
Source tables — Dynamics 365
InventSum and InventTrans give the coverage and age views; the item master carries the lifecycle state. Every quantity reaches site and warehouse through InventDim, and the company is pinned throughout.
Source tables — Infor M3
Source tables — Oracle EBS
Sum the on-hand quantity detail before joining, take movement history from material transactions, and read lifecycle status from the item definition — which is organization-striped, so an item can be active in one org and not another.
Source tables — Oracle Fusion
On-hand and material transactions give exposure and movement history; the item definition carries lifecycle status and standard costs carry the valuation. The forward-demand side, where the horizon definition needs it, comes from planning extracts.
Store the components, not the ratio
Every switch above is a different way of reading the same underlying facts, so the components — quantities, dates, values, flags — are what belongs in the gold layer, never the finished percentage. Bronze keeps the source tables as extracted, silver resolves the encodings once, and gold carries a component-level fact that each variant of Excess & Obsolete (E&O) reads as a SELECT — the pattern worked through in full in the OTIF entry's landing pattern.