Hi {{FIRST_NAME|readers}},
As promised last week, Part 2 of the P2P functional requirements series is live (the one for everyone running inventory, MRP, or material masters alongside their indirect spend)!
Most published P2P requirements lists silently assume you only buy office supplies, software, and consulting. They cover catalogs, requisitions, approvals, and invoice matching competently… And then the moment your buying involves a material master, an MRP run, or a storeroom, they go quiet.
And no… The answer IS NOT run two P2P systems, one for indirect and one for direct. The right answer is one platform that handles both. (More on why in the article.)
This week's Deep Dive is the part that's usually missing. 46 functional requirements specifically for direct and MRO procurement:
Material master integration.
Inventory-aware requisitioning.
MRP and replenishment.
Direct-flavored settlement.
Supplier management for production-grade relationships.
If your spend touches any of that (even just an MRO storeroom in facilities), this one's for you.
Read Part 2. Use the list (combined with Part 1). Make the vendors prove it.
Onwards!
P.S. I'm off-grid fishing for the week, so if you reply and don't hear back, that's why. Trout doesn't have wifi... (yet) 🎣
📰 In this week’s edition:
📄 Concentration Risk: The Materials Powering and Constraining the AI Boom (sponsored)
🤿 The Master P2P Functional Requirements List for Direct/MRO purchasing
📢 This week’s “Must Reads”
📋 3 procurement jobs that caught our eye
Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.
If you run a manufacturing plant, a distribution operation, a hospital, a mine, a utility, or any business that holds inventory and buys direct materials, here's a problem you've probably already hit: the standard procure-to-pay functional requirements lists don't fit you.
They're usually written for “indirect-only” buyers: organizations that buy office supplies, software, consulting, and facilities services. Buy it, receive it, expense it, done. Those lists cover catalogs, requisitions, approvals, and invoice matching competently. And then the moment your buying involves a material master, an MRP run, a lot-controlled storeroom, or a scheduling agreement, they go quiet. The requirements that govern how you actually buy simply aren't there.
This article is the missing piece. It's a functional requirements list for direct and MRO procurement: the capabilities your P2P platform needs when inventory, MRP, and material masters are part of how you buy. You can use it to build or pressure-test an RFP, to evaluate whether a platform on your shortlist can genuinely handle your operation, or to figure out why the "modern" indirect-focused suite someone recommended keeps falling short in your environment.
A note on scope: direct and MRO requirements are an extension of core P2P functionality, not a replacement for it.
Every requirement below sits on top of the universal P2P capabilities (intake, approvals, PO management, invoice capture, payment) that every organization needs regardless of what it buys.
Those core requirements are covered in depth in a companion article, The P2P Master Functional Requirements List, and if you're scoping a full P2P selection you'll want both. But this piece stands on its own for the direct and MRO-specific capabilities that indirect-focused lists consistently miss.
Who Needs Direct & MRO Requirements (And Who Doesn't)
The dividing line between an “indirect-only” P2P buyer and a “direct + MRO buyer” is concrete, not a matter of industry labels. You need the requirements in this article if any one of the following is true for any portion of your spend:
You hold goods in inventory and need to manage on-hand stock levels (storage locations, bins, lots, batches, serial numbers).
You run MRP (or any equivalent replenishment-planning logic) that automatically generates purchase requisitions from forecast or production demand.
You maintain item master records (material masters) that govern how a SKU is bought, stored, costed, and consumed across business processes.
If none of those apply (i.e. if every purchase is buy-it, receive-it, expense-it with no inventory record and no material master), you're an “indirect-only” buyer, and the core P2P requirements list is all you need.
This isn't an industry question, it's a process question.
A SaaS company with a single bonded warehouse for branded merch is still “indirect-only”.
A consulting firm that runs a parts inventory for its rental laptop fleet is (surprise!) partially direct.
A facilities operations team running a CMMS-linked storeroom for spare parts is direct, even if the parent company thinks of itself as "indirect-only."
A note on MRO specifically: if your MRO spend is purely transactional (someone needs a replacement light bulb, no inventory record, no material master), it's indirect, or handled by the core list. If your MRO spend runs through a CMMS-linked storeroom with on-hand inventory, item masters, and replenishment rules, it's direct, and the requirements in this article apply.
A Quick Note on Writing Good Functional Requirements
Every requirement in this article is written to be Specific, Testable, Unambiguous, Implementation-agnostic, and Atomic. These are five tests that separate a requirement a vendor can be held to from a vague aspiration a vendor can wiggle out of. "The system shall support lot tracking" is not a usable requirement. "The system shall capture lot or batch numbers at goods receipt for items flagged as lot-controlled" is.
If you want the full framework for writing requirements that survive contact with a vendor sales team (and the argument for why a great list scored against badly-written requirements is worse than no list at all), the companion article covers it in detail. It's worth the ten minutes before you build your RFP.
How to Use This List
Three rules of engagement:
These requirements are an extension, not a standalone RFP. If you're scoping a full P2P selection, combine the requirements below with the core P2P requirements list. Don't cherry-pick individual items from this article… The direct and MRO requirements are interdependent, and a platform that does three of five sections well will still leave you maintaining a parallel process for the rest.
Score these as strictly as anything else. Treat them as Must-haves, not "phase 2" wish list items. The moment you have a material master, an MRP run, or an inventory storeroom in scope, these capabilities determine whether your P2P platform actually works for your business… Or whether you'll quietly maintain a parallel ERP-based process to handle "the real spend." The whole point of a Procure-to-Pay system is to avoid that fragmentation.
Score by demo, not by self-assessment. Vendors will have a tendency to check "Yes" on everything (An RFP is a prisoner’s dilemma after all...). The only meaningful evaluation is watching them perform the requirement live, against a scripted scenario that includes at least one inventory-controlled item with lot capture, one MRP-generated requisition, and one consignment receipt.
One System or Two? The Architecture Question
Before the list, an architecture question worth settling early, because it shapes how you'll use everything below: should direct and indirect procurement run on the same P2P platform, or two separate ones?
Most teams that buy both direct and indirect default to assuming they need two systems (one for "the manufacturing side" running through the ERP, one for "the indirect side" running through a separate procurement suite).
For most organizations, that's a poor architecture choice made on autopilot. The whole point of a P2P platform is consolidation: one supplier record, one invoice intake, one spend cube, one AP team. Split it by goods type without a deliberate reason and you reintroduce every fragmentation problem the platform was supposed to solve.
There are legitimate exceptions (i.e. structurally separate business entities, durable functional separation between operations and finance, genuine strategic divergence in capability needs, or two systems inherited through M&A).
The companion article walks through each in detail. But for most direct + indirect buyers, the right goal is a single P2P platform that handles all your buying, even if it means accepting trade-offs in how each spend type is supported. The requirements below describe additional capabilities your single P2P system must have… Not the spec for a separate platform.
The Direct & MRO P2P Requirements
1. Material Master Integration
The system shall consume item master records from the ERP system of record (or maintain its own item master with documented synchronization to the ERP).
The system shall consume item-supplier relationships (info records, source lists), including preferred supplier, manufacturer part number, supplier part number, and minimum order quantity by source (or maintain its own with documented synchronization to the ERP).
The system shall support manufacturer part number cross-referencing across multiple approved sources, allowing buyers to search and order by manufacturer part number when the same physical part is supplied by different distributors using different supplier part numbers, with the appropriate supplier selected at PO time.
The system shall consume and expose direct-relevant item classification and commodity coding attributes (engineering category, ABC classification, planning strategy, MRP type, valuation class, and equivalent fields) to drive downstream rule-driven behavior for requisitioning, sourcing, planning, and accounting.
The system shall consume and expose bill of materials (BOM) relationships from the ERP, PLM, or MRP system to support requisitioning scenarios that reference parent items or finished goods, without acting as the system of record for BOM maintenance.
The system shall enforce item lifecycle status (active, blocked, obsolete, phase-out) and prevent or warn on requisitioning of non-active items.
The system shall support unit of measure conversions between purchasing UoM, stocking UoM, and consumption UoM, and apply them consistently across requisition, PO, receipt, and invoice.
The system shall support multiple manufacturer-approved-vendor relationships per item, including approved manufacturer lists (AML) for regulated industries.
The system shall manage production part approval (PPAP) document status per item-supplier combination, blocking active sourcing where PPAP is expired or not yet approved.
(For everything else, there’s Master Data Management solutions!)
2. Inventory-Aware Requisitioning & Receipt
The system shall check on-hand inventory before generating an external purchase requisition and offer reservation against existing stock as an alternative.
The system shall display reservation and allocation visibility at requisition time, distinguishing on-hand quantity, committed (reserved against other orders), available-to-promise, and quality-inspection stock, so requesters can evaluate whether existing inventory is genuinely accessible before initiating a new purchase.
The system shall display goods-in-transit visibility at requisition time — stock that has been shipped by a supplier but not yet received — factoring it into replenishment decisions, particularly for long-lead-time direct materials and multi-plant operations.
The system shall support multi-plant, multi-warehouse, multi-storage-location receipt with put away to a specified bin as maintained in the back end WMS system.
The system shall capture lot or batch numbers at goods receipt for items flagged as lot-controlled.
The system shall capture serial numbers at goods receipt for items flagged as serialized.
The system shall capture and enforce expiry dates for items flagged as expiry-controlled (a real-world requirement for consignment inventory, pharma, food, and chemicals — not an edge case).
The system shall support quality inspection workflow at receipt, holding goods in a quality-inspection stock status until inspection is complete.
The system shall support receipt against advance shipping notices (ASNs), allowing receiving teams to pre-stage receipts, validate against the PO before goods physically arrive, and accelerate the physical receipt process by matching against the ASN rather than re-keying data.
The system shall support receipt of a single physical delivery containing items from multiple POs, processing all referenced PO lines in a single receiving transaction without forcing the receiver to process each PO separately.
The system shall support receiver correction and cancellation of receipts (wrong quantity entered, wrong lot or serial number, wrong PO referenced) within a defined and configurable window before downstream invoice posting locks the entry, with full audit logging of the original entry, the correction, and the receiver involved.
The system shall support consignment receipt without immediate liability creation, with separate liability creation upon consumption or settlement.
The system shall support stock transfer orders (intra-company movement of inventory) and subcontract POs (provision of components to a supplier for processing) as distinct PO types.
The system shall adjust on-hand inventory on physical return to a supplier (via the platform's return merchandise authorization process) for items previously received into stock, and reverse the original goods receipt accounting entries appropriately, including any lot, batch, serial, or storage location attributes captured at original receipt.
3. MRP & Replenishment Integration
The system shall consume and update RP-generated purchase requisitions from the planning system without manual re-entry.
The system shall preserve the planning context (demand source, planned delivery date, pegging) on the resulting purchase requisition and PO.
The system shall apply automated source determination logic when MRP generates a requisition for an item with multiple approved sources, supporting preferred-supplier, quota-based split-sourcing, capacity-aware, and cost-optimized allocation strategies configurable per item or commodity, rather than requiring manual buyer allocation.
The system shall respect supplier capacity ceilings and committed-volume limits in source determination, avoiding assignments that would push a supplier beyond their declared or contracted capacity for a given period.
The system shall support scheduling agreements with delivery schedules (distinct from discrete POs) and support release of delivery schedule lines (call-offs) to suppliers.
The system shall produce and transmit demand forecasts to key suppliers in agreed formats (email, EDI 830, cXML, supplier portal, API) at configurable frequencies (monthly, weekly, daily), with forecasts clearly distinguished from firm orders.
The system shall support kanban / pull-based replenishment as a distinct replenishment mode, triggered by signals (electronic, scanned card, sensor-based) when on-hand stock reaches a defined trigger point, separate from MRP-driven planning.
The system shall support vendor-managed inventory (VMI) and supplier-managed flows where the supplier is responsible for replenishing on-hand stock to a defined min/max.
The system shall support JIT delivery call-offs against a scheduling agreement, including same-day and next-day windows.
The system shall flag and route exceptions when MRP-driven replenishment cannot be fulfilled within the required window (no source list, no contract, supplier blocked, lead time exceeded).
The system shall enable configuration of business rules on requisition fields to kick off review workflows before releasing a requisition for purchase (e.g., send workflow item to engineering for materials requiring drawings).
4. Direct-Specific Invoice & Settlement
The system shall support evaluated receipt settlement (ERS / self-billing), generating supplier payments based on goods receipt without requiring a supplier invoice.
The system shall capture freight, duty, customs, insurance, and other landed cost components at the line level, allocate them to inventory cost, and apply Incoterm-driven logic to determine which cost components are buyer-borne versus supplier-borne for a given PO.
The system shall support retroactive price adjustments (price changes effective for prior receipts) with appropriate inventory and AP adjustments.
The system shall support consignment settlement (invoice or self-billing on consumption rather than receipt).
The system shall support subcontract settlement, recognizing both the supplier's service charge and the value of components consumed during subcontracted processing, with appropriate inventory and AP entries for both elements.
The system shall support invoice posting in advance of goods receipt (for prepayments, milestone-based services, or supplier billing conventions), holding the invoice for matching against future receipt with appropriate accrual handling and clear audit trail of the timing.
The system shall produce period-end goods-receipt / invoice-receipt (GR/IR) reconciliation, accruing for goods received but not yet invoiced at period close and reversing in the following period, with full visibility of the GR/IR balance per supplier, PO, and item.
5. Direct-Specific Supplier Management
The system shall manage quality agreements, technical drawings, and material certifications per item-supplier combination, with version control.
The system shall distinguish between manufacturer and distributor relationships, supporting buy-from-distributor / approved-by-manufacturer models.
The system shall enforce supplier qualification status at the item or category level, preventing PO issuance to a supplier and/or goods receipt for items or categories where qualification is missing, expired, or revoked.
The system shall track and enforce dual or multi-source policies for designated critical components, warning when volume concentration with a single source exceeds defined thresholds or when a backup source has not been used within a defined recency window, in order to keep alternate sources operationally viable.
The system shall support supplier scorecards that include direct-relevant metrics (PPM defect rate, on-time-in-full, certificate of analysis compliance) alongside indirect metrics.
(For everything else there’s integration with Third-Party Risk Management solutions)
What This List Tells You About Vendor Fit
The requirements above are the litmus test for whether a P2P platform can genuinely serve direct and MRO buyers… Or whether it can only service indirect spend well.
“Pure-play, indirect-native” platforms will fail most of Section 3 (MRP & Replenishment) hard, regardless of how well-marketed they are. Their architecture wasn't designed to deeply integrate with processes run in another system of record…
ERP-native P2P modules tend to handle these direct and MRO requirements fluently but feel clunky for the indirect core requirements (particularly around intake, guided buying, and conversational interfaces).
Therefore, the P2P vendors worth shortlisting when you’re a manufacturer, distributor, and/or MRO-heavy operator are the ones that score competitively on both the core P2P requirements AND the direct and MRO requirements above.
They exist, but they're rarer than vendor marketing suggests. The way to find them is to score honestly, score by demo, and refuse to accept "we'll figure it out in implementation" as an answer to any of the requirements above.
A Word on Completeness
That's 46 direct and MRO requirements!
Combined with the core P2P list, well over 170. Honestly? We probably still missed a bunch. Direct and MRO procurement has corners I haven't worked in, and every plant, distribution center, and storeroom has its own quirks. We could keep adding to this list forever.
But here's the takeaway I want you to leave with: a complete list might make you feel good, but it won't increase your chances of success in your P2P transformation. Completeness is a comfort, not a strategy.
Go ahead. Build your RFP with the requirements that genuinely matter to your operation. Score them honestly. Make vendors prove them in demo (against your real data, with a scripted scenario that includes at least one inventory-controlled item with lot capture, one MRP-generated requisition, and one consignment receipt).
But more than anything else, find the best partner for you… The vendor whose product, roadmap, services capability, and cultural fit match your reality.
A requirements list is a starting point, not the answer. Don't confuse the map for the territory.
Haven't read the Core piece yet? Start with The P2P Master Functional Requirements List.
👀 In Case You Missed It…
The Last 3 Newsletters:
1/ The Master Procure-to-Pay (P2P) Functional Requirements List for Indirect Purchasing
2/ ProcureTech Unpacked Conference Summary
3/ One Year at Pure Procurement: Insights and Lessons from a Rookie
The single biggest problem in communication is the illusion that it has taken place.
2 other ways we can help this week:
Not sure if your KPI set is actually credible? Procurement teams can end up tracking too much, too little, or the wrong things entirely. Going back to the CAPS study gives you a stronger foundation, with 90 metrics practitioners considered most important for purchasing effectiveness, so you can validate what you measure and spot what may be missing.
Get more from your SAP investment. AI-powered intake and orchestration can help close the gap between what your ERP can do and what your process actually needs. This ebook, developed with Tonkean, looks at how to reduce manual work, streamline P2P flows, and create better coordination across your procurement tech stack.
See you next week {{FIRST_NAME|readers}},
— The Pure Procurement Newsletter Team
P.S. Please rate today’s newsletter.
Your feedback shapes the content of this newsletter.