Invoices and purchase orders can live in one system or in two joined by an integration, and both architectures work. The choice should be made on where your exceptions come from rather than on architectural preference, because the two arrangements fail in different places and your own exception mix says which failure you can least afford.
One system
The order, the receipt and the invoice live together, so matching needs no integration and nothing has to be reconciled between systems. Exceptions can be routed back to purchasing without leaving the record. Where your exceptions are dominated by missing orders and receipts, this addresses the cause and the larger implementation is justified.
Two systems, joined
Best-fitting products on each side with an integration carrying orders and receipts into payables. Faster to land, easier to replace, and often stronger on payables than a procurement suite's payables module. The risk is the join: an integration that fails quietly leaves payables matching against stale data and nobody notices for a while.
What to ask about the join
How often it runs, what happens when it fails, and whether anybody is told. A silent failure is the specific danger, because matching continues against whatever data arrived last. Ask to see what a failed sync looks like operationally rather than whether a connector exists.
Questions people ask about invoice purchase order software
Which is cheaper?
Two point products usually cost less to implement; one system usually costs less to operate. The larger cost is the cross-departmental agreement one system requires.
Can we start with two and consolidate?
Yes, and that is the commoner direction. Clean data makes it possible.
What breaks most often?
The integration, quietly. Monitoring it is worth more than most features on either side.