Work Order vs Purchase Order: The Difference Every CMMS User Should Know

Short answer: A work order is an internal record of a maintenance or repair task, the technician, the asset, the hours, the parts used. A purchase order is an external commitment to buy something from a supplier. A single work order can generate purchase orders for parts or contractor labor, but they are separate records and live in different systems. Confusing them creates accounting mess and breaks maintenance reporting.

See the work order types this distinction matters for.

What a work order is

A work order is the unit of work in maintenance. It records:

• Which asset needs work.
• What needs to be done (PM task, breakdown repair, modification, inspection).
• Who is assigned (technician, crew).
• How long it took (labor hours).
• What parts were used (from inventory).
• Cost (labor + parts + contractor if any).

Work orders live in the CMMS. They are how MTBF, MTTR, planned vs reactive ratio, and total maintenance cost per asset get calculated.

What a purchase order is

A purchase order is a commitment to buy from a supplier. It records:

• The supplier.
• Item or service being purchased.
• Quantity and unit price.
• Delivery date.
• Total cost.
• The internal cost center or project.

Purchase orders live in the ERP procurement module. They are how three-way matching (PO, receipt, invoice) works for AP.

How they intersect

The intersection is the maintenance event that needs a part or external service:

1. Asset fails. Technician opens a work order.
2. Replacement bearing is not in stock. Technician needs a PO to buy one.
3. CMMS generates a parts request; ERP issues a PO to the supplier.
4. Part arrives. Receiving books it against the PO and updates inventory.
5. Technician pulls the part against the WO. WO records part cost.
6. Supplier invoice arrives. ERP matches to PO and receipt for payment.

Same maintenance event, two systems, two record types, one link between them. The CMMS-to-ERP integration is what keeps the link clean.

Where confusion creeps in

1. Treating WO as PO and vice versa. Some plants use the same term for both and use the CMMS to also place orders. Tiny shops get away with this; larger plants do not because procurement controls fall apart.

2. Contractor work not on a WO. If a contractor comes in to fix something and the only record is the PO that paid them, you have no WO history for the asset. MTBF on that asset becomes wrong.

3. Parts cost not posting back to WO. If parts pulled against a PO never make it back to the originating WO, the WO cost is wrong, and asset-level cost reporting is wrong.

Why this matters for OEE and reliability

The work order is the audit trail for every fix that touches an asset. If the WO history is missing or inflated by random POs, two things break:

• MTBF and MTTR become unreliable. You cannot tell how often an asset fails or how long fixes take without clean WO data.
• OEE-to-CMMS closed loop breaks. If OEE flags a downtime event and CMMS cannot tie the resulting fix back to a specific WO with parts and labor, the loop is open and the analytics are noisy.

What good practice looks like

1. Every fix has a WO. No exceptions, including contractor work and warranty work.
2. PO is created from the WO when external spend is needed. The CMMS triggers the PO request in ERP and keeps the link.
3. Parts and labor post back to the WO. Both internal (stockroom pulls) and external (PO receipts) end up on the WO cost.
4. Contractor labor is captured on the WO. The PO pays the contractor; the WO records the hours and the work performed.

How a modern CMMS handles this

A modern CMMS supports a parts-request workflow that hands off to ERP for the PO step, then receives the PO number back so the WO and PO are linked. It captures contractor labor on the WO even when the contractor is billed via PO. And it integrates with the OEE platform so that downtime events automatically open WOs and close the analytics loop.

Fabrico's CMMS supports linked WO/PO workflows via API into the customer ERP, and captures both internal labor and PO-paid contractor labor on the same WO, keeping the reliability data clean.