Processing a purchase order is a longer job than producing one. The document takes a minute; the processing runs from approval through issue, delivery, receipt, revision, invoicing and closure, often over weeks. Software that focuses on the first minute and leaves the following weeks to a spreadsheet is solving the visible problem rather than the expensive one.
Approval and issue
Routing by value and cost centre to a named approver, with cover during absence, then issuing to the supplier and recording that it was sent. Approval before issue is the control; recording the send is what lets you answer whether the supplier ever received it, which is the first question in half of all delivery disputes.
Receipt and revision
Receipts recorded at line level by whoever takes the delivery, and revisions kept with their dates rather than overwriting. Together these are what make matching possible and what let you answer what was agreed when. Software that treats an order as immutable forces every real-world change into an email thread.
Closure
An order ends when received and invoiced reconcile with ordered, or when somebody decides the remainder will not arrive and records why. Orders left open indefinitely inflate commitments and eventually make the open-order report untrusted, at which point everybody goes back to asking each other, which is the state the software was bought to replace.
Questions people ask about purchase order processing software
What is the minimum useful feature set?
Unique numbering, approval before issue, line-level receipts, revisions with dates, and an open-order report. Everything else is optional at most sizes.
Does it need supplier acknowledgement?
Useful rather than essential. Knowing an order was received removes a class of dispute but matters far less than tracking what actually arrives.
How does this help payables?
It supplies two of the three documents the match needs. Most payables exceptions are caused by their absence rather than by disagreement.