Purchase order processing is usually pictured as creating and sending a document, which takes a minute. The processing is what follows: weeks in which deliveries arrive in pieces, prices change, invoices come in against lines and somebody eventually decides the order is finished. Software that addresses the minute and not the weeks solves the visible problem rather than the expensive one.
Approval and issue
Routed by value and cost centre to a named approver with cover during absence, approved before the supplier sees anything, then issued and the sending recorded. Approval before issue is the control. Recording the send answers whether the supplier ever received it, which is the first question in a good share of delivery disputes.
Delivery, receipt and revision
Receipts recorded at line level by whoever takes the delivery, at the time. Revisions kept as dated changes rather than overwrites. These two make matching possible and let you answer what was agreed when. Both are performed by people outside finance, which is why usability matters more than feature depth here.
Invoicing and closure
Invoices matched against the order and the receipts, and the order closed when quantities reconcile or when somebody decides the balance will not arrive, with a reason recorded. Orders left open indefinitely inflate commitments and erode trust in the open-order report, which is how a good report becomes an ignored one.
Questions people ask about purchase order processing
Who should close orders?
Purchasing, with a periodic review of anything open beyond its expected lead time. Leaving closure to nobody is how the report degrades.
How do we handle over-delivery?
Flag it rather than accepting it silently. Over-receipt is how you end up paying for more than you ordered.
What about orders for services?
Same shape, with the receipt being confirmation that the work was done. Services are where untracked commitments most often accumulate.