Procure to pay software comes in two architectures and the choice between them is usually made on vendor preference when it should be made on evidence. A month of your own exception reasons says which one addresses your actual problem, and the two architectures suit genuinely different situations rather than being better and worse versions of the same thing.
The suite argument
One system holds the order, the receipt and the invoice, so matching needs no integration and no reconciliation between systems. Exceptions route back to purchasing without leaving the record. Where your exceptions are dominated by missing orders and receipts, this addresses the cause directly and the consolidation is worth the larger implementation.
The point-product argument
Best-fitting products on each side, joined by an integration. Faster to land, easier to replace, and often stronger on the payables side than a procurement suite's payables module. Where your exceptions are about capture, coding and approval delay, the problem is inside payables and a point solution gets you there sooner and cheaper.
How to decide from evidence
Log exception reasons for a month. Dominated by missing orders and receipts means the seam is the problem and the suite argument is real. Dominated by capture, coding and approval waiting means the problem is inside payables. An even spread usually means nothing has been addressed yet, so start with the cheapest fix.
Questions people ask about procure to pay software solutions
Which is more expensive?
Suites usually cost more to implement and sometimes less to run, since there is one integration fewer. The larger cost is the cross-departmental agreement a suite requires.
Can we start with point products and consolidate later?
Yes, and clean data makes that possible. Consolidating later is more common than the reverse.
Who should lead the decision?
Somebody with authority over both departments, because most of the decisions are cross-departmental rather than technical.