Choosing procure to pay tooling by feature comparison produces long evaluations and mediocre fits. A better starting point is a month of your own exception reasons, because the distribution points directly at which part of the cycle is failing and therefore which tool would help. It takes an afternoon and it usually shortens the shortlist to one or two.
If the reasons are missing orders
Your problem is at the requisition and ordering stage, and the tool is requisition and order management with fast approval. Buying payables automation will produce an efficient process for the invoices that can be matched and change nothing about the ones that cannot, which will be most of your effort.
If the reasons are missing receipts
Your problem is at the delivery point, and the answer is usually mobile receipting rather than a new system: making it possible for whoever signs for a delivery to record it there and then. This is frequently a configuration or a habit rather than a purchase, which is worth knowing before an evaluation starts.
If the reasons are price and quantity differences
Your matching is running and the upstream data is arriving, so the tool is better exception handling: routing by reason, tolerance you can tune, and line-level matching with running quantities. This is the case where payables-focused automation genuinely pays, and it is the least common starting point.
Questions people ask about p2p tools in procurement
How do we capture exception reasons if we do not record them?
Log them by hand for a month. It is tedious and it is the most useful data you will gather before any purchase.
What if the reasons are spread evenly?
Then start with the cheapest fix, which is nearly always receipts, and re-measure. Even distributions usually mean nothing has been addressed yet.
Should we buy one suite for all of it?
Only if the seam between purchasing and payables is genuinely your problem. Otherwise point solutions land faster.