MRP software, short for material requirements planning software, calculates what to buy or make, in what quantity, and by when, by running demand through your bill of materials. It has sat inside production planning for six decades, and it still runs the material side of most ERP systems today. It is also the reason planners across many organizations pull everything into a spreadsheet the moment a run finishes. The output is correct and incomplete at the same time.
This guide explains what an MRP run actually does, where it runs out of road, and where a planning layer on top of it starts adding value.
What Is MRP Software?
Material requirements planning software converts a production schedule and a bill of materials (BOM) into a time-phased plan for every component underneath a finished item. It calculates gross requirements, subtracts on-hand and on-order stock, and outputs planned orders for purchase or production.
MRP began as a standalone calculation in the 1960s and expanded into MRP II through the 1980s to add capacity checks and shop floor scheduling, a lineage traced in detail by Jacobs & Weston (2007). Today it usually sits inside a broader ERP system as one module among several, rather than as a separate tool, a pattern confirmed across the same ERP literature.
Any organization running discrete or process production, from mid-sized component makers to large multi-plant groups, depends on some version of this calculation, whether it is packaged as dedicated MRP planning software or as the planning module inside an ERP suite. Most organizations with more than one plant still run a single, common ERP across every location, with the MRP calculation running separately for each plant’s own BOM and inventory position inside that one system.
The calculation itself has barely changed. The problem it solves has not gone away either.
How an MRP Run Actually Works
Regardless of which MRP software runs the calculation, an MRP run moves through the same five steps.
- Demand inputs. The system gathers confirmed sales orders, the forecast, and the master production schedule (MPS) for finished items.
- BOM explosion. Each finished item is broken into its bill of materials, level by level, to produce gross requirements for every component.
- Netting. Gross requirements are reduced by on-hand inventory and open supply orders to arrive at net requirements.
- Lead time offsetting. Net requirements are pushed back in time using each item’s lead time, so an order lands exactly when it is needed.
- Planned orders and purchase requisitions. The system generates a planned order or purchase requisition for every net requirement, ready for a planner to review and release.
A simple example makes this concrete. A finished good needs two units of Component A and one unit of Component B. An order for 100 finished goods creates gross requirements of 200 units of A and 100 units of B. If 50 units of A are already in stock, netting drops that requirement to 150. Lead time offsetting then works backward from the need date, using each component’s lead time, to set the actual order date.
That five-step sequence is the entire calculation. Every other feature in an ERP system builds around it.
MRP vs ERP vs Planning Layer: What Sits Where
The comparison people search for most on this topic is MRP vs ERP, and the honest answer is that MRP is a calculation and ERP is the system it usually lives inside. A planning layer is a separate, newer piece that sits above both.
| Layer | Scope | What It Optimizes | What It Ignores |
| MRP | Material and component supply timing within one plant’s BOM and inventory | Order timing and quantity for purchase or production | Production and machine capacity limits, priorities, scenario comparison |
| ERP | Company-wide transactions: finance, procurement, sales, inventory, records | Data consistency and workflow across departments | Trade-offs between conflicting priorities under material or capacity constraints |
| Planning Layer | Decision support across plants and functions, built on the same ERP and MRP data | Priority calls, capacity checks, and scenario comparison before a plan is committed | Transaction processing and system-of-record functions, which stay with the ERP |
MRP and ERP answer “what does the system say we need.” A planning layer answers “given everything we cannot have at once, what should we actually do.” Those are different questions, and most organizations only have software for the first one.
Where MRP Stops: 6 Built-In Limits
MRP software is reliable at the calculation it was built for. Six assumptions baked into that calculation are where it stops being reliable at everything downstream of it.
| MRP Assumption | Reality on the Floor | Consequence |
| Infinite capacity | Every plant has a finite number of machine hours and shifts | Plans get generated that no plant can physically run, so planners re-sequence work orders by hand instead of relying on capacity-aware production scheduling or advanced planning and scheduling. |
| Static, single-value lead times | Actual lead times move with supplier load, season, and order size | Planned order dates drift out of sync with real deliveries, driving expedite costs |
| Nervousness | Small demand or supply changes reshuffle the whole plan | Shop floor priorities flip overnight, and trust in the system erodes (detail below) |
| Data dependency | BOM and inventory records are rarely fully accurate | Inaccurate inputs cascade into bad orders at every level, which is why master data cleanup comes before any planning fix. |
| No priorities or trade-offs | Every shortage looks equally urgent | Planners decide by instinct which order to protect first |
| No scenarios | The run produces one deterministic answer | Nobody can test a what-if before committing material and capacity |
Nervousness deserves more space than the other five limits combined, because it is the least explained problem on most MRP resources and the most common complaint from planners.
MRP nervousness is instability in planned orders, caused by demand and supply uncertainty interacting with lot-sizing rules, as defined by Blackburn, Kropp & Millen (1985). A forecast change entered on a Tuesday night can reshuffle tomorrow morning’s work orders after the nightly regeneration run, because most MRP systems have no time fence protecting the near-term schedule. Push that reshuffling down through three or four BOM levels, and it starts to resemble the bullwhip effect running inside a single product structure: small changes near the top amplify into large swings at the component level.
Research on this exact problem produced one counterintuitive finding worth knowing before reaching for the obvious fix. Adding safety stock at the master schedule level does improve stability, but only up to a point. Past a certain amount, extra buffer stock increases both instability and cost instead of reducing them, according to Sridharan & LaForge (1989). Freezing part of the near-term schedule, or adding a cost penalty to discourage last-minute changes, tends to outperform stacking on more safety stock, per Blackburn, Kropp & Millen (1986).
MRP tells an organization what it needs. It does not tell anyone what to do when it cannot have it.
Where a Planning Layer Begins
A planning layer is a decision layer that sits on top of the ERP and its MRP software module, not a replacement for either. It reads the same demand, BOM, and inventory data MRP already uses, then adds three things MRP was never built to do: awareness of finite production capacity, side-by-side scenario comparison, and a way to rank competing priorities when supply cannot cover every order, worked out collaboratively across functions (S&OP or IBP logic) rather than by one planner alone.
This is where Oritiq’s planning layer operates. It reads master data and MRP output from the ERP an organization already runs, cleans and organizes that data as part of onboarding, and lets planners run production and inventory simulations at a shift-by-shift level rather than promising an update every minute. Labor scheduling stays outside its scope. The platform’s job is material, capacity, and inventory decisions, because that is where planning breaks down first.
For an organization running several plants on one shared ERP, the planning layer sits above all of them at once, giving one shared view of priorities instead of a separate spreadsheet per plant.
Bring one week of MRP output into a working session, and the gap between what MRP calculated and what the plant can actually do becomes visible within the hour.
Do You Need Better MRP Software, or a Layer on Top?
Organizations searching for the best MRP software are often trying to fix a symptom rather than a cause, and swapping tools without addressing that cause is one of the reasons supply chain software implementations fail. Before switching MRP tools or ERP modules, four questions usually settle which fix is actually needed:
- Does the plan assume unlimited machine capacity, or does it check load against real capacity?
- Do small forecast changes reshuffle the whole schedule overnight?
- Can planners compare two or three scenarios before committing an order, or is there only one answer?
- When supply falls short, does anything rank which orders matter most?
A “no” on any of the last three points to a planning layer gap, not an MRP defect. A “no” on the first, paired with genuinely broken BOM or lead-time data, points to an MRP or ERP data fix first.
FAQs
What does MRP software do?
It calculates what materials an organization needs to buy or produce, in what quantity, and by when. It does this by exploding demand through the bill of materials, netting against current stock, and offsetting for lead time, so every component gets a planned order tied to a real need date.
What is the difference between MRP and ERP?
MRP is the material calculation. ERP is the wider system that the calculation usually lives inside, connecting it to finance, procurement, sales, and inventory records across the organization. Most organizations run MRP as one module within a broader ERP, not as a standalone system.
What are the main limitations of MRP software?
MRP assumes unlimited capacity, uses fixed lead times, and produces one answer with no scenarios or priorities. It is also highly sensitive to small forecast changes, a problem known as nervousness, and depends entirely on accurate bill of materials and inventory data to output a usable plan.
Is MRP still relevant in 2026?
Yes. Every organization running production still needs the underlying calculation MRP software performs. What has changed is that the calculation alone rarely covers what planners need. Most organizations now pair it with a planning layer that adds capacity awareness, scenarios, and priority calls on top of the same data.
What is a planning layer on top of ERP?
A planning layer is a decision-support system built above ERP and MRP, using the same data to add finite-capacity checks, side-by-side scenario comparison, and priority ranking when supply cannot cover every order. It supports the ERP instead of replacing it.
Do we need to replace our ERP to fix MRP problems?
No. A planning layer is built to sit on top of the ERP an organization already runs and read its existing MRP output, not replace it. Most MRP-related planning gaps need an added decision layer, not a new core system.
Conclusion
MRP software still does one job well: turning a bill of materials into a dated order list. The gap sits in everything that calculation was never built to handle: capacity limits, priority calls between competing orders, and scenario testing before material gets committed.
Closing that gap doesn’t require replacing the ERP or the MRP module already in place. It requires a planning layer that reads the same data and answers the questions MRP was never designed to answer.
See how Oritiq’s planning layer works with the ERP and MRP setup your organization already runs. Talk to our team.