What is MRP? A Plain-English Guide for Manufacturers

MRP stands for Material Requirements Planning. Strip away forty years of enterprise-software jargon and it answers three questions that every manufacturer asks daily, whether they use software or a whiteboard: What do we need to buy or make? How much? And when?

If you have ever counted jars in a storeroom before confirming an order, or discovered mid-production that the labels ran out, you have done manual MRP. The software category exists because doing it by memory stops working surprisingly early.

The three inputs every MRP calculation uses

MRP is not magic. It is bookkeeping plus arithmetic, done relentlessly. Every MRP system, from a 1970s mainframe to a modern cloud tool, combines three things:

1. Demand - what you have promised or plan to make. Sales orders, a production schedule, or a forecast.
2. The bill of materials (BOM) - the recipe for each product. A candle needs 180 g of wax, one wick, one jar, one label. Multi-level BOMs nest: the gift set contains three candles, each with its own recipe.
3. Inventory status - what is on hand, what is already reserved for other orders, and what is on order from suppliers.

The output is a plan: purchase 4 kg of wax by Tuesday, start a 200-unit batch on Thursday. When the inputs change - an order cancels, a delivery slips - the plan recalculates. That recalculation is the whole point. A human can build this plan once; nobody can rebuild it every time something moves.

What MRP looks like in practice

Say you make hot sauce. On Monday a distributor orders 500 bottles of your habanero line for the 25th. An MRP system walks the BOM and checks stock:

• 500 bottles need 250 kg of pepper mash - 180 kg in stock, so buy 70 kg. Supplier lead time is 7 days, so the purchase order must go out by the 14th.
• Glass bottles: 620 on hand, but 400 are reserved for a retail order shipping the 20th. Free stock is 220. Order 280 more.
• Labels: enough on hand. Nothing to do.

Notice the second line. The naive count said 620 bottles, plenty. The correct answer needed to know about reservations. This is where spreadsheets quietly fail: they store counts, but the promises live in people's heads.

MRP, MRP II, and ERP - untangling the acronyms

MRP (1960s–70s) planned materials only. MRP II - Manufacturing Resource Planning - arrived in the 1980s and added machine capacity, scheduling, and cost accounting. ERP extended the idea to the entire company: finance, HR, sales, everything in one system.

Modern cloud MRP tools blur the first two: any serious one handles production scheduling and costing without calling itself MRP II. The MRP-vs-ERP line still matters, though. ERP is a company-wide commitment, usually with an implementation project. MRP is an operations tool you can adopt in a week. Our guide on choosing MRP software covers when each makes sense.

What modern MRP adds beyond the calculation

The requirements calculation is table stakes now. What separates current systems is everything wrapped around it:

• Lot traceability. Each receipt of material is a lot with its own number, dates, and cost. When a supplier recalls a batch, you query which lots went into which orders instead of reconstructing it from receipts and memory.
• Expiry-aware picking. FEFO (First Expired, First Out) allocates the stock that ages out soonest - essential for food, cosmetics, and supplements.
• Quality gates. Received stock can be held for inspection, and stock that fails cannot be used or shipped. In good systems this is enforced by the allocation engine, not by a sticky note.
• Real per-order costing. Because the system knows which specific lots an order consumed, it can state that order's true cost and margin, not a monthly average.
• Sales channel sync. For e-commerce manufacturers, stock levels flow to the storefront automatically, so the website never sells what production already claimed.

How MRP calculates a purchase order, in more detail

It helps to see the actual sequence, because "explode the BOM" hides three separate steps that each have their own failure mode.

1. Netting. The system takes gross requirements (what the BOM says you need) and subtracts what you already have - but only the portion that is not already reserved for something else. This is the step spreadsheets get wrong most often, because a reservation is a promise, not a count, and promises are exactly what a static sheet cannot represent well.
2. Lot sizing. Once net requirement is known, the system decides how much to actually order or produce - exactly what is needed, a supplier's minimum order quantity, or a standard batch size. Ordering exactly to need looks efficient on paper but ignores the fact that most suppliers will not sell you 43 kg of something with a 200 kg minimum.
3. Time-phasing. The system offsets the order date backward from the need date by the supplier's lead time (for purchases) or the production duration (for manufactured sub-assemblies), so the purchase order or work order fires early enough to arrive on time - not on the day you actually need the material, which is already too late.

Do this by hand for one product and it is a Tuesday-afternoon task. Do it for forty SKUs with shared components and overlapping orders, recalculated every time something changes, and it becomes the actual job - which is why MRP exists as software rather than as a good habit.

What MRP does not do

Worth being direct about the edges of the category, since overselling software is exactly the kind of thing this whole guide is arguing against.

• MRP does not replace demand forecasting. It answers "given this demand, what do we need" - it does not predict the demand itself, though some systems layer basic forecasting on top.
• MRP does not manage your whole company. Payroll, CRM, and general ledger accounting live in other systems, sometimes integrated, sometimes not.
• MRP does not fix a bad BOM. If the recipe is wrong - wrong quantities, missing steps - the plan built on it will be confidently wrong too. The software calculates correctly from whatever data you give it; it does not know your process better than you do.
• MRP does not eliminate the need for a physical count occasionally. It tracks every recorded movement perfectly; it cannot catch a movement nobody recorded (theft, breakage, a forgotten scan). Periodic cycle counts stay part of the job.

When do you actually need it?

Honestly: later than software vendors say, earlier than most founders admit. The trigger is not company size, it is consequence size. The first oversold launch, the first two-day hunt for a bad batch, the first order that shipped at a loss without anyone noticing - each of those usually costs more than a year of software.

A rougher, more concrete test: count how many places the same piece of information lives right now - a stock count in a spreadsheet, again in a notebook by the receiving door, again in someone's memory of what they promised a customer. If that number is more than one, you already have the coordination problem MRP solves; you just have not automated the solving of it yet.

We wrote a separate, more detailed piece on the switching decision: MRP system vs Excel. And if you want to see what the concepts in this article look like in a real product, here is how IEMSuite approaches MRP for small manufacturers.

Frequently asked questions