There is a gap in most companies between the storeroom and the ERP, and maintenance falls into it. A technician needs a part. Procurement owns the purchase order. Finance owns the invoice. The request travels by email, sits in someone's inbox over a weekend, and the technician either waits or puts the part on a company card and tells nobody. Either way the ERP finds out late, the CMMS never finds out, and the storeroom count is wrong again.
The fix is a purchase requisition process that starts where the need starts, hands off to the ERP at one defined point, and never asks anyone to type the same order twice.
Purchase requisition vs purchase order
A purchase requisition is an internal request for approval to buy something. It names the item, the quantity, the vendor if known, the reason, and the cost center. It has no legal weight with the supplier.
A purchase order is the commitment. Once approved, the requisition becomes a PO, the PO goes to the vendor, and the invoice later gets matched against it. The ERP is the right home for the PO and the invoice because that is where the money is accounted for.
The requisition is different. It belongs where the need originates, and for maintenance that is the work order and the storeroom, not the finance system.
Why the handoff breaks
Requisitions live in email or on a paper form, so nobody can see the queue or how long anything has waited.
Requests are not tied to a work order or an asset. Procurement sees "bearing, qty 2" with no way to tell whether a line is down or someone is topping up a shelf.
Approval limits are unwritten, so every request waits for the same manager, including the eleven-dollar gasket.
Someone re-keys the approved requisition into the ERP by hand. Part numbers get transposed. Vendors get picked from a different list.
Receiving is not recorded anywhere maintenance can see, so the part arrives, sits at the dock, and the CMMS still shows zero on hand.
And the company card becomes the real procurement system for anything urgent, which means the ERP has a purchasing history with holes in it and the storeroom has parts it does not know it owns.
Seven steps to a requisition process that works
1. Put the requisition where the need originates. For maintenance, that is the CMMS. A requisition should be created from a work order that needs a part, or from a stock level that dropped below minimum. The ERP owns everything from the PO forward. Drawing that line in writing settles most of the arguments between maintenance and procurement before they start.
2. Run two lanes with different rules. An emergency requisition means an asset is down or a safety issue is open. It gets a short approval path, a same-day service level, and permission to use any approved vendor. A replenishment requisition means stock hit its reorder point. It gets the standard path, batches with other replenishment orders, and goes to the preferred vendor. Mixing the lanes is how emergency parts wait behind routine ones.
3. Tie every requisition to a work order or a reorder point. No free-floating requests. The link gives procurement the context it needs (this is for the packaging line that is down) and gives finance the cost attribution it wants (this part went to asset 4417). It also closes the loop later: when the part is received and issued, the work order can proceed and the asset history records the cost.
4. Write the approval limits down. Under a set amount, replenishment requisitions auto-approve. Between two amounts, the maintenance manager approves. Above that, procurement or finance signs. Emergency requisitions get their own, higher auto-approve limit. Publish the numbers. An approval matrix that lives in one manager's head is a bottleneck with a job title.
5. Define the handoff fields once. Agree with procurement on exactly what the ERP needs from an approved requisition: internal part number, vendor part number, quantity, unit cost estimate, vendor, cost center or GL code, need-by date, and the work order or asset reference. Then move that data one way, from the CMMS to the ERP, either through an integration or through a clean export the buyer imports. Nobody re-keys.
6. Record receipt where maintenance can see it. When the part arrives, receiving updates the storeroom count, and the technician waiting on it gets notified. If receiving happens in the ERP, sync the receipt back. If it happens in the CMMS, batch-receive against the requisition so a delivery of thirty line items takes minutes to book, then let the ERP handle the invoice match. Either way, the count is right the same day.
7. Review four numbers monthly. Requisition-to-PO time, split by lane. Emergency share of total requisitions. Company-card spend on maintenance parts outside the process. Vendor lead-time accuracy against what your reorder points assume. The first two tell you whether the process is fast enough. The third tells you whether people trust it. The fourth tells you whether your min levels are honest.
Where software fits
A single site with one buyer can run this on a shared form and a weekly conversation. It stops working when requisitions need to come from work orders automatically, when approval limits need to be enforced rather than remembered, or when more than one storeroom is reordering the same parts.
Purchase requisition software for maintenance teams, built into a CMMS, handles the maintenance half of the process: requisitions raised from work orders or reorder points, approval routing by limit, purchase history against each part and vendor, batch receiving that updates inventory, and an audit trail from request to receipt. MPACT CMMS by MPulse Software, as one example, generates the requisition in the maintenance system and leaves invoicing and reconciliation to the ERP, with procurement approvals and ERP integration available as add-ons for organizations that need the full chain connected. Other CMMS platforms offer similar functions. The feature that matters is the link from work order to requisition to receipt, so the technician, the buyer, and the storeroom are looking at the same record.
Whatever you use, resist building invoice matching into the maintenance system. That is the ERP's job, and duplicating it is how two systems end up disagreeing about what was paid.
A requisition field checklist
Every maintenance requisition should carry these fields before it goes anywhere:
Work order number or reorder-point reference
Asset the part is for (if from a work order)
Internal part number and vendor part number
Quantity and unit of measure
Estimated unit cost
Preferred vendor
Cost center or GL code
Need-by date
Lane: emergency or replenishment
Requester and approver
If a field is blank, the requisition waits. That rule alone removes most of the back-and-forth between maintenance and procurement.
The honest summary
Maintenance purchasing goes wrong at the handoff, not at either end. Start the requisition where the need begins, give it a work order and a lane, approve it against written limits, hand it to the ERP once with every field filled, and book the receipt where the storeroom can see it. The systems on either side matter less than the agreement about where the line sits.