What Is MRP? A Complete Guide to Material Requirements Planning

What MRP actually is, in one sentence

MRP isn't a piece of software, and it isn't a system in itself. It's a repeatable calculation: for every component of every item a business plans to produce, work out how much is needed in each period, subtract what's already available or already coming, and check whether there's enough lead time left to get more before it's needed. A planner has always been able to do this on paper or in a spreadsheet, one item and one period at a time. What changed over the decades is how many items, levels, and periods that calculation had to run across before software became the only practical way to do it fast enough.

That distinction matters for the rest of this guide, because the underlying logic doesn't change based on what's running it. A notebook, a spreadsheet, and a production ERP module are all doing the same arithmetic. What differs is how many components each can net correctly, how quickly each can redo the math when something changes, and how reliably each keeps every level of a multi-level bill of materials in sync.

The three inputs: MPS, BOM, and item records

MRP can't produce anything without all three of these. Missing or wrong data in any one of them doesn't make the calculation fail outright, it makes it confidently wrong, which in practice is worse than no plan at all.

1. The Master Production Schedule (MPS)

   The MPS states what end items need to be completed, in what quantity, and in which time period, over the planning horizon. It's built from confirmed sales orders, a demand forecast, or a blend of both, and it's the starting point the entire calculation works backward from. Everything MRP calculates for components and raw materials is ultimately derived from the MPS.

2. The Bill of Materials (BOM)

   The BOM defines the product structure: for one unit of a given item, which components are required and in what quantity. MRP uses that structure to calculate dependent material demand, translating a schedule for finished goods into a schedule for everything that goes into them. A BOM can be single-level, raw materials straight into a finished good, or multi-level, where a component is itself an assembled sub-item with its own BOM underneath it. The complete guide to BOMs covers this structure, BOM explosion, and BOM roll-up in full depth.

3. Item and inventory records

   Every item carries its own planning data, and MRP needs all of it, not just a quantity on hand:

   • On-hand inventory: what's physically available right now.
   • Scheduled receipts: purchase or production orders already placed, with their expected arrival dates.
   • Lead time: how long a new order takes to arrive once it's released, whether purchased or manufactured.
   • Safety stock: the buffer quantity the plan is not allowed to fall below.
   • Lot-sizing rule: how a net requirement gets converted into an actual order quantity, exact match, a fixed batch size, or something else.

The same three inputs exist in a process environment, generally represented as a formula rather than a BOM, with constraints layered on top: batch size, yield, potency, shelf life, lot availability, and minimum production quantities all affect what counts as a feasible plan. The process manufacturing guide covers that environment in full; where the underlying structure should be called a BOM, a formula, or a recipe is covered in BOM vs. formula vs. recipe.

Independent vs. dependent demand

This distinction is the reason MRP exists as a separate discipline from ordinary inventory replenishment, so it's worth being precise about it before working through the calculation itself.

A finished good sold to a customer is independent demand: nothing inside the business dictates how many units will sell next month, so that number has to come from a forecast, a sales order, or both. Once the master production schedule says how many of that finished good will be built, though, the components required to build it are no longer uncertain. If one unit requires two of a given bracket, and the schedule calls for 150 units, the bracket's requirement is exactly 300, not an estimate. That's dependent demand, and it's calculated, not guessed.

This is also why applying an independent-demand forecasting method to a dependent-demand item, treating a component's historical consumption as if it were its own smooth, ongoing demand pattern, tends to produce a badly distorted picture. Component demand isn't smooth. It arrives in the lumps and batches dictated by the parent item's production schedule, and MRP is built specifically to calculate those lumps correctly instead of averaging them away.

How the calculation works, with a full worked example

The MRP calculation runs the same six-line logic for every item, in every period, working from the top of the bill of materials down. Each line depends on the ones above it in the same period, and on the running balance carried from the period before.

1. Gross requirement

   The total quantity of the item needed in this period, from the MPS for a top-level item, or from a parent item's planned order release for a dependent-demand component.

2. Scheduled receipts

   Orders already placed against this item that are due to arrive in this period. These are commitments already made, not proposals the calculation is generating.

3. Projected available balance

   The running inventory position: the balance carried from the prior period, plus this period's scheduled and planned receipts, minus this period's gross requirement.

4. Net requirement

   If the projected available balance would fall below safety stock, the net requirement is the amount needed to bring it back up to that floor. Otherwise, the net requirement is zero, meaning existing supply already covers the need.

5. Planned order receipt

   The net requirement, adjusted for whatever lot-sizing rule applies to this item, rounded up to a batch size, for instance, rather than ordered in the exact net amount.

6. Planned order release

   The planned order receipt, shifted earlier by the item's lead time. This is the date an order actually has to go out, purchased or put into production, for its receipt to land on schedule. This step is what's meant by lead-time offsetting, or time-phasing. Where that lead-time figure itself comes from, a static guess versus a number measured from real purchase and receipt history, is its own question, covered in vendor lead time and reorder points.

Level 0: the finished item, from the MPS

Take a finished item with these planning parameters: 60 units on hand, a safety-stock floor of 20 units, a 2-week lead time, and a lot-for-lot ordering rule (order exactly the net requirement, no batching). The master production schedule calls for 100 units complete in week 4 and 150 units complete in week 6. A scheduled receipt of 50 units, from an order already placed, is due in week 2.

Walk it period by period and the logic holds together cleanly. Through week 3, the balance stays comfortably above the 20-unit floor, so nothing nets. In week 4, the 100-unit requirement would draw the balance down to 10, which is below safety stock, so a net requirement of 10 appears, exactly enough to bring the balance back to 20. Offset two weeks for lead time, and that order has to release in week 2. In week 6, the 150-unit requirement would drive the balance to -130 without intervention, so the net requirement is 150, the full gap back up to the safety-stock floor. Offset again by the 2-week lead time, and that release lands in week 4.

Level 1: BOM explosion into a dependent-demand component

Say this finished item's bill of materials calls for two units of a particular bracket. BOM explosion means the bracket's gross requirement in any period is exactly the finished item's planned order release in that same period, multiplied by the quantity per BOM, not a separate forecast. The finished item released 10 units in week 2 and 150 units in week 4 above, so the bracket's gross requirements are 20 in week 2 and 300 in week 4, and nowhere else. That's dependent demand: derived, not estimated.

Give the bracket its own planning parameters: 25 units on hand, a safety-stock floor of 10, a 1-week lead time, lot-for-lot, and a scheduled receipt of 15 units due in week 1.

Week 4's 300-unit requirement is the one that matters: it would take the balance to -280, so the net requirement is 290, enough to close that gap and restore the 10-unit floor. Offset by the bracket's 1-week lead time, and its planned order release lands in week 3, one week ahead of when the finished item's own production actually consumes it. This is BOM explosion and lead-time offsetting working together across two levels: a single top-level schedule, processed correctly, produces a fully time-phased plan for everything underneath it. A real bill of materials with more levels and more components repeats this same logic further down, level by level, top to bottom.

Safety stock and lot-sizing rules

Two planning parameters shape how a net requirement turns into an actual order, and the worked example above used the simplest version of each. Real planning almost always involves a deliberate choice on both.

Safety stock

Safety stock is a floor, not a target. It exists to absorb the ordinary variability that a fixed lead time and a fixed BOM quantity don't capture: a supplier that ships a few days late, a production run that consumes slightly more than planned, a small forecast error on an independent-demand item. MRP nets to keep the projected available balance at or above that floor, not at or above zero, which is the detail that made the worked example net a requirement in week 4 instead of waiting until the balance actually went negative.

Lot-sizing rules

Lot-for-lot, used throughout the worked example, orders exactly the net requirement and nothing more. It minimizes carried inventory but can generate a lot of small, frequent orders. Other rules trade that off differently:

The lot-sizing rule doesn't change whether a net requirement exists, only how large the resulting order is and how many periods of future demand it covers in one pass. Choosing the wrong rule for a given item, ordering in large batches for something with erratic, low-volume demand, is a common source of excess inventory that has nothing to do with whether the underlying MRP math is correct.

MRP vs. reorder-point planning

A reorder point (ROP) system watches on-hand inventory and triggers a purchase the moment it crosses a threshold, typically set from average usage rate multiplied by lead time, plus a safety margin. It doesn't ask why inventory is being consumed or what's coming next; it responds to the level itself, which makes it simple to run and reasonably effective for items with steady, continuous, independent demand.

MRP doesn't wait for a threshold to be crossed. It calculates ahead, from a known production plan, exactly when and how much a dependent-demand item will be needed, before consumption starts. For a component whose demand is lumpy, arriving in large batches tied to specific production runs rather than a steady trickle, an ROP threshold is a poor fit: it can trigger too early against a quiet period or fail to trigger early enough ahead of a large batch, since it has no visibility into the schedule driving that batch in the first place.

In practice, most manufacturers run both at once, ROP for low-value, steadily consumed items like fasteners or shop supplies where the simplicity is worth more than the precision, and MRP for the components and sub-assemblies whose demand is directly tied to a production schedule. Neither approach is universally correct; each fits a different demand pattern.

What MRP doesn't solve

Classic MRP calculates material requirements correctly and says nothing about whether those requirements are actually achievable. That gap is worth stating plainly, since it's the most common source of an MRP plan that looks right on paper and falls apart on the shop floor.

• Production capacity. MRP assumes unlimited capacity by default. It will plan a production order with no awareness of whether any work center has open hours to run it in the required window. Capacity Requirements Planning (CRP) and MRP II exist specifically to check a plan against actual capacity after MRP generates it.
• Labor availability. The same blind spot applies to crew and skilled-labor availability. A materially feasible plan can still be a staffing impossibility.
• Machine availability. Scheduled maintenance, unplanned downtime, and changeover time aren't part of the calculation unless they're fed in through a separate scheduling layer.
• Supplier uncertainty. Lead time is a fixed input, not a probability. MRP doesn't model the odds that a given vendor ships late; it plans as if every lead time will be met exactly as entered.
• Data accuracy. The entire calculation is only as trustworthy as the bill of materials, on-hand counts, and lead times feeding it. Wrong inputs don't cause MRP to fail visibly; they cause it to produce a confidently wrong plan that looks identical to a correct one until something doesn't show up.

How MRP evolved into MRP II and ERP

MRP's capacity blind spot is precisely what the next generation of planning methodology was built to address, which is worth understanding in outline, even though the details matter less than the core calculation covered above.

Each step widened the scope of what got planned together rather than replacing the math underneath it. MRP II didn't discard MRP's gross-to-net logic, it wrapped capacity and resource constraints around it. ERP didn't discard MRP II's manufacturing logic, it connected it to the rest of the business's data. The calculation described in this guide is still, in some form, what's running underneath all three.

Running MRP in a spreadsheet

It's worth being precise here rather than absolute. A sufficiently well-built spreadsheet can implement time-phased netting, multi-level BOM explosion, safety stock logic, and lot-sizing rules correctly; none of that math requires dedicated software to execute. The real argument against spreadsheet-based MRP isn't that it can't do the calculation. It's that maintaining it correctly gets disproportionately harder as several dimensions grow at once, and none of them grow in isolation.

• SKU count. Every additional item is another set of rows, another set of planning parameters, and another set of formulas that have to reference the right cells correctly.
• BOM depth. Every additional level means the explosion logic linking a parent's planned order release to a child's gross requirement has to be built, and rebuilt, one level deeper, and a structural change anywhere in that chain risks breaking every formula downstream of it.
• Number of locations. Each location typically needs its own on-hand, scheduled-receipt, and sometimes lead-time data, multiplying the surface area for a stale or mistyped figure.
• Number of people editing it. The more people who touch the inputs, the more ways a formula gets overwritten, a row gets inserted in the wrong place, or a reference silently stops pointing where it should.
• Planning frequency. Rerunning the calculation daily rather than monthly means far less time to catch an error before it feeds into a purchasing or production decision.

None of these problems is fatal on its own, and a disciplined, well-documented spreadsheet can hold up for a surprisingly long time. What tends to happen in practice is that the maintenance burden becomes one person's specialized knowledge, and correctness quietly depends on that person's availability and attention, in a way that's easy to underestimate until the day it's tested.

MRP terminology glossary

A quick reference for the terms used throughout this guide, and a few adjacent ones that come up in the same conversations.

Frequently asked questions