Procurement software does not fail on features. It fails on adoption, and it fails in a specific way: the requests that go through the process are the ones that were always going to be fine, and the spend that causes problems arrives by a route the process never saw.
Somebody expenses it. Somebody puts it on a card. Somebody agrees it on a call and the invoice turns up 6 weeks later with no purchase order attached. Every finance team knows this pattern and most procurement evaluations ignore it, because it is not a feature gap and no vendor demo shows it.
So the useful question when comparing tools is not which has the deepest approval matrix. It is which one people will actually use when they are in a hurry.
place a request should live: where the requester already works, not a portal they have to remember
documents that must agree before payment: purchase order, goods receipt and invoice
to process a multi-line invoice at Oper Credits, submitted by photo in Slack
What to actually evaluate
Where the request starts. A procurement portal is a place people have to remember to go. A request that starts in Slack, where the person already is, gets filed. At All Gravy approvals and reimbursements run through Slack for exactly this reason, and its Head of Finance and Ops describes clearing them on the metro, which is the honest test of whether an approval flow fits a working day.
"I am on the metro with nothing else to do, so I go through my approvals there. It fits the workflow we already have rather than asking us to build a new one."
Sebastian Sandorff Jacobsen, Head of Finance and Ops, All Gravy
Whether it reaches the ledger. A procurement tool that ends at approval has solved the easy half. The commitment it just created is invisible to the books until an invoice arrives, so the forecast is wrong for the whole intervening period. Ask where an approved purchase order lives and whether the general ledger knows about it before the bill turns up.
Whether the match is automatic. The control that matters is three way matching: the invoice against the purchase order against confirmation that the goods arrived. Done by hand it degrades to a threshold, which means the routine invoices where duplicates and price creep actually hide are the ones that pass unchecked. Applied automatically it runs on the whole population.
What happens to the exception. Most spend is unremarkable and should simply post. The evaluation question is whether the tool distinguishes, and where the genuine exceptions go. Stephen Grist, CFO at Puzzel, states the requirement exactly: "I'm not interested in knowing everything it approved, but I am interested in knowing if it approved some big things or some things out of policy." An approvals feed that surfaces everything trains people to approve without reading, which is the same as having no control.
Whether the categories survive contact. Coding at the point of request only works if the requester can pick the right category without being an accountant. This is where a lot of procurement data quietly rots, and where a system that codes from the document rather than from a dropdown does better than one that asks.
Looks good in a demo
The approval matrix
Configurable thresholds, delegation rules, multi-stage routing. Genuinely useful, and never the reason a rollout fails.
Decides adoption
Where the request begins
A flow that starts in Slack gets used. A portal gets routed around by anyone under time pressure, which is when the risky spend happens.
Decides the value
Whether the ledger knows
An approved commitment the books cannot see is a forecast error waiting to arrive. The PO should reach the ledger, not just the inbox.
The integration question is really an architecture question
Most procurement tools sit beside the ledger and sync to it. That works until the definitions drift, at which point somebody reconciles 2 systems monthly and the procurement data becomes a second version of the truth.
All Gravy's stack before Light is the illustration: 4 ledgers, a card provider and 2 payment platforms, 7 systems in total, each of which worked on its own terms. The problem was never any individual tool. It was orchestrating anything across all of them. Replacing all 7 with 1 removed the orchestration rather than improving it. Too Good To Go shows the same problem from the other end: almost none of its bills carry a purchase order number, so nothing auto-matches, and the control that was supposed to catch errors has nothing to match against.
If procurement, AP and the ledger are the same system, the purchase order, the goods receipt, the invoice and the payment are 4 states of 1 record. If they are 3 systems, they are 4 documents and a reconciliation.
The shortlist test
Take the last 10 unexpected invoices the finance team received. For each one, ask which part of the process it skipped and why.
The answers are usually mundane. The requester did not know a purchase order was needed. The tool was slower than sending an email. The category did not exist. Nobody confirmed delivery because confirming delivery meant logging into something.
Then evaluate each tool against those 10 specific failures rather than against a feature list. The best procurement software for a given company is the one that would have caught the most of them, and that is almost never the one with the most configuration options. It is the one people do not have a reason to work around.
Read how the procurement agent replaced the intake form, see how procurement and bills run in Light, or book a demo.