A purchase order system is often bought to produce a tidy document to send a supplier, which is the least valuable thing it does. Its real job is to hold three quantities against every ordered line, ordered, received and invoiced, and to keep them accurate as reality diverges from the plan. If it does that, everything downstream gets easier. If it does not, it is a form with a numbering scheme attached.
Three quantities, one line
Ordered is what you committed to. Received is what actually turned up, recorded when it did. Invoiced is what you have been billed for so far. These diverge constantly and legitimately, and every useful question about the order is a comparison between two of them. A system that stores only the ordered quantity cannot support matching, cannot produce an accrual and cannot tell you what is late.
Approval before the order goes out
The commitment is made when the supplier receives the order, not when the invoice arrives, so approval belongs at the front. Systems that let an order be sent and approved afterwards are recording a decision that has already been made by somebody else, which is not a control. One threshold and one named approver is usually enough to start.
The open order report
Everything a purchase order system is for shows up in one report: what is open, how old it is, what has been received against it and what has been invoiced. Purchasing uses it to chase late deliveries, finance uses it to accrue at period end, and payables uses it to see what invoices to expect. A system that cannot produce it cheaply is making three teams do manual work to compensate.
Questions people ask about purchase order system
Do we need a purchase order system if we are small?
The control matters at any size; the tooling may not. A shared numbered sheet with an approval column works for a very small team. The move usually comes when more than one person raises orders or when open commitments stop being memorable.
Does it need to integrate with our accounting software?
It helps, chiefly so that the accrual and the invoice match do not need rekeying. It is not mandatory at low volume, and integration is where implementations most often overrun, so weigh it deliberately.
What about services rather than goods?
Services have no physical receipt, so they are usually matched two-way, invoice against order, with a separate confirmation that the work was done. Decide which purchases are which rather than forcing everything down one path.