Every MRO parts planner knows the difference between a rotable and an expendable at the part level. A brake control unit is a rotable: it comes off the aircraft, goes to a repair station, and eventually returns to the serviceable pool. An O-ring seal is an expendable: once installed and removed, it is gone. The distinction is basic inventory vocabulary.
The problem is that many planning systems do not honor the distinction when building demand models. They apply the same reorder logic, the same safety-stock calculation, and the same MTBR-derived interval to both part categories. The result is a model that consistently misreads demand for each type in opposite directions.
What a Rotable Demand Model Actually Needs to Track
For a rotable component, the relevant demand question is not just "how often is this part removed from aircraft." It is "how many units are outside the serviceable pool at any given time, and when will they return."
This requires tracking three things that a simple MTBR-based model ignores. First, the repair turnaround time (TAT) at the repair station: if your brake control unit averages a 45-day repair cycle, you need to know how many units are currently sitting in that 45-day window. Second, the repair shop's work-in-progress queue: a repair station processing 12 units ahead of yours will deliver well past their stated TAT. Third, the rate at which condemned units are scrapped rather than returned: a component with a 15% condemnation rate has an effective pool shrinkage that the removal count alone will not reveal.
A rotable demand model that ignores TAT and pool status will trigger unnecessary procurement. We have seen cases where a planner's system kept flagging new buy orders for a rotable because it saw on-hand quantity below the reorder point, while three units were already 30 days into a 45-day repair cycle and due back before the next predicted removal.
How Expendable Demand Works Differently
Expendable demand is simpler in structure but requires different discipline. Because nothing returns, the demand signal equals gross consumption. Every installation is a permanent subtraction from inventory.
Where expendable models typically fail is in the handling of pack sizes and shelf-life constraints. An O-ring seal that comes in a kit of 50 gets logged as a single kit consumption event, even if only 3 seals were used. The planning system records one kit removal, not 3 units consumed. Over time, the model underestimates actual unit consumption by a factor tied to average kit utilization rate.
Shelf-life is a second distortion. An expendable with an 18-month shelf life that sits in a slow-moving category gets written off as waste rather than consumed, but the write-off looks like a stock adjustment in most systems, not a demand event. A model that does not distinguish consumption from waste will undercount true demand.
A Regional Operator Case
We worked with a Southwestern US regional carrier operating 18 ATR 72s on a mixed scheduled and charter network. Their maintenance planning system used a single min/max rule across all inventory, calibrated by historical removal rates. No distinction was made between rotable and expendable logic.
For their brake control units (rotables), the system was triggering procurement orders because on-hand quantity was below the reorder point. What the system did not see was that four units were currently in the repair pipeline at an FAA Part 145 repair station in Texas, all due back within six weeks. The actual pool was adequate; the visible pool looked short.
At the same time, their actuator seals (expendables) were running out faster than the model predicted. The model was treating a batch purchase from eight months prior as "available inventory" without accounting for the fact that the batch had been distributed across three heavy checks in the prior quarter. The stock was gone; the records said it was not.
Two different problems, same root cause: the model did not understand what type of part it was forecasting.
Where the Unified Formula Breaks Down
The unified reorder formula typically looks something like: reorder point = (average removal rate x lead time) + safety stock. For expendables, lead time is supplier delivery time. For rotables, it should be the longer of: supplier delivery time (for new buy) or expected repair TAT plus transit time (for pool return). But if the system uses a single lead time field, it will use whichever number was last entered, which is often the supplier quote, not the repair TAT.
Safety stock calculation is the second failure point. For rotables, safety stock should account for TAT variability, not just demand variability. A repair station that can swing from 30 days to 90 days depending on parts availability introduces a fundamentally different risk profile than a supplier with a two-week delivery variance.
What Separate Models Change in Practice
Separating rotable and expendable demand logic in a planning system requires more data but produces substantially more accurate reorder timing. For rotables, the model needs to consume pool status data (units at repair, units in transit, units condemned) alongside removal history. For expendables, it needs true unit consumption stripped of kit-size distortion and shelf-life write-offs.
We should be clear: this is not an argument that rotables are harder to manage than expendables or vice versa. Some rotable pools are straightforward if TAT is consistent and condemnation rates are low. Some expendable categories are genuinely difficult to forecast if consumption is irregular or pack-size granularity is poor. The point is that the demand drivers are structurally different, and a model that treats them identically will be wrong in different directions for each type.
At Aerotrax, when we ingest removal history from an operator's MRO system, one of the first categorization steps is separating rotable pool dynamics from expendable consumption rates. The demand signal coming out of each category has a different shape, a different confidence interval, and a different set of upstream variables that explain variation. Trying to fit both into one model is like using the same weather forecast for two cities 800 miles apart and hoping they both get it right.
See Aerotrax on your own fleet data
30-day pilot on your removal history. CSV upload, no integration project required.
Request a pilot