I've sat in enough vendor demos to know that the version of procurement software that gets shown and the version that actually gets used are not the same product.
The demo version is clean. Spend data organized by category and supplier, contracts with expiry dates visible in one place, approval workflows that follow the org chart, supplier performance scores updating from structured inputs. It's a compelling picture. The question is what the data feeding into all of that actually looks like once the implementation team leaves.
Most procurement data in most organizations isn't clean. Purchase orders exist in different formats across different systems, some of them legacy ERP instances that aren't going anywhere. Invoice data that should match PO data doesn't always match, sometimes because of tolerance clauses, sometimes because of manual workarounds that accumulated over years and got absorbed into the process without anyone ever writing them down. Supplier master data has duplicates. Fields that were populated correctly once and then never maintained. Spend categories that don't map cleanly to the cost centers finance tracks, which means every roll-up requires a reconciliation step that somebody has to do by hand.
This matters because almost everything procurement software promises to deliver depends on data quality as a prerequisite. Spend analytics needs spend data that's been categorized and cleansed. Contract management needs terms digitized and mapped to supplier relationships. Automated matching needs consistently populated fields. If those foundations aren't there, the software runs and produces output. The output just can't be trusted, and once that trust erodes it's very hard to get back.
The organizations that get the most out of these tools are usually the ones that did the data work before or alongside the implementation, not after. That work isn't glamorous. It's sitting with transaction exports, building cleansing rules, documenting what the codes actually mean, finding the edge cases that break the standard logic. It takes longer than any project timeline allocates for it.
There's also the gap between what procurement software is and what an ERP was built to do. Those two things run in parallel at most organizations and talk to each other less cleanly than anyone would like. The ERP is financial control. Procurement software is sourcing and supplier management. The integration between them is its own project, and that project has a way of becoming the constraint nobody planned for.
Working around those gaps, rather than waiting for a perfect data state that will probably never arrive, is where most of the actually useful work ends up.