Purchase ordering software can be evaluated against a long requirements list or against five capabilities that decide whether it works at all. All five are inexpensive in any product and expensive or impossible to add later, and between them they support matching, accruals and delivery chasing, which is everything the software is actually for.
Numbering and approval sequence
Unique numbers issued automatically from one source and never reused, because a reused number makes two transactions permanently indistinguishable. And approval before the order is sent, because the commitment exists once the supplier acts on it. Approval afterwards is a review, which is a weaker thing worth naming honestly.
Line-level receipts and dated revisions
Ordered, received and invoiced quantities per line, so partial deliveries are representable and the accrual falls out for free. And revisions kept with dates rather than overwriting, so what was agreed when is answerable during a supplier disagreement. Products lacking either are document generators with a system's name.
A readable export
Orders, lines, receipts, revisions and approvals in a format you can open without the vendor. Organisations change these systems more often than they expect, and an export missing receipt history makes that move considerably worse. Test it during a trial rather than accepting a description of it.
Questions people ask about purchase ordering software
How do we test line-level receipting?
Order ten, receive four, invoice four, and check that six show outstanding on that line. Five minutes settles it.
Is our accounting module enough?
Sometimes. Check receipting and revisions specifically, since those are the usual gaps rather than the ordering itself.
What is worth paying more for?
Usability at the delivery point, because that is the step that most often fails and the one everything downstream depends on.