MRP vs ERP
MRP (material requirements planning) is the system that calculates what parts to order and when, based on production demand and on-hand inventory. ERP (enterprise resource planning) is the broader business system that holds finance, inventory, purchasing, sales, and HR records together, often including MRP as a module. For a production buyer, MRP creates the buy signal; ERP holds the PO and the receipt.
Part of the Procurement Glossary
How it works in practice
In a typical day, you interact with MRP through whatever screen tells you "buy these parts, in these quantities, by these dates." That output (often called planned orders or order suggestions) is the result of MRP running the BOM, the on-hand position, the open POs, and the safety-stock policy against the production schedule. You convert those suggestions into POs and place them.
Once the PO exists, you mostly live in the ERP. The PO lives there, the supplier acknowledgment gets keyed in there (when it gets keyed in at all), the goods receipt lands there, and AP processes the invoice from there. The ERP is the system of record for "what was ordered and what was received". MRP is the system of record for "what should we be ordering".
Some practical mapping for the buyer: SAP, Oracle, NetSuite, and Microsoft Dynamics are ERPs that include MRP modules. Standalone MRP tools exist (and are common at smaller manufacturers) but the trend is toward MRP-inside-ERP. The cleaner mental split is by function (planning vs records) rather than by product name.
Why it matters
Knowing which system does what shapes where you go to fix a problem. A wrong order-suggestion quantity is an MRP issue (often a wrong demand signal, a wrong BOM, or a wrong safety-stock setting). A missing receipt is an ERP issue. Conflating the two leads to chasing the wrong fix and wasting time on the wrong screen.
The deeper issue is that neither system natively knows about the email layer between them. MRP does not see that the supplier emailed a date change. ERP does not flag that an acknowledgment never arrived. The buyer ends up bridging the gap by hand, which is where most of the daily firefighting comes from.
Tips
Trust MRP for what; verify with ERP for whether
MRP tells you what should be on order. ERP tells you what actually is. When the two diverge (an order suggestion that already has an open PO, or a missing PO for a part the line needs), the gap is usually where the answer lives.
Update the ERP with what the supplier actually said
Date changes, partial acknowledgments, and revised lead times need to make it into the ERP, not just stay in your inbox. MRP's next pass uses ERP data; if the supplier confirmed a slip and the ERP still shows the original date, the next plan will be wrong.
Resist the urge to "just fix it in MRP"
Overriding MRP suggestions to work around an ERP data gap solves the immediate problem and creates two more. Fix the ERP record (the real PO date, the real on-hand) and let MRP recalculate.
How PO-Relay helps
PO-Relay is neither an MRP nor an ERP. It reads from the ERP (POs, receipts, basic part data) and watches the email layer that sits between the supplier and your system of record. When a supplier emails a date change, an acknowledgment, an ASN, or a quality flag, PO-Relay catches the message, classifies it, and surfaces the implication on the right open PO.
The intent is to fill the gap that MRP and ERP leave: keeping the open-PO list honest with what is actually being said by suppliers in real time, so the data MRP reads from the ERP next time matches reality. The planning math, the BOM, the receipt records, and the financial transactions all stay in the systems that already own them.