Procurement technology guide
AI procurement software applies models to sourcing, supplier selection, contract review, spend classification and risk scoring. Almost every vendor in the category now claims all five, and a scripted demo cannot distinguish a system that works from one that was rehearsed. These are the questions that can.
A compelling AI demonstration is not the same as a dependable procurement operating workflow. Buyers need to test how a platform uses authorized data, explains recommendations, routes approvals, records overrides, and connects the final decision to financial evidence.
Qeluntra connects authorized supplier, contract, procurement, finance, logistics, inventory, and operating context. AI-assisted recommendations remain explainable and consequential actions remain subject to human approval.
"AI procurement software" covers at least five distinct capabilities with very different maturity. Conflating them is how evaluations go wrong, because a vendor strong in one is assumed strong in all.
| Capability | What it does | Maturity |
|---|---|---|
| Spend classification | Assigns transactions to categories | Mature. Works well, unglamorous, genuinely useful |
| Contract extraction | Pulls terms, dates and obligations from documents | Mature for structured clauses, weaker on unusual drafting |
| Supplier discovery | Finds and shortlists candidate suppliers | Variable. Depends entirely on the underlying data, not the model |
| Risk scoring | Rates supplier exposure from signals | Variable, and the hardest to validate |
| Assisted negotiation and drafting | Suggests positions or generates clauses | Newest. Treat claims with the most scepticism |
Be specific about which you are buying. "AI-powered procurement" as a whole-platform claim is not evaluable. "Classifies spend to level 3 UNSPSC at 90% accuracy on our data" is.
Ask these in writing. The quality of the written answer is itself the signal — a vendor who can answer question 3 precisely is a different proposition from one who redirects to a case study.
Question 1 is the one to run the evaluation on. Everything else can be presented well. A vendor who has built a genuine low-confidence path — a queue, a flag, a refusal to classify — has thought about being wrong, and that is most of what separates useful systems from demonstrable ones.
Scripted demos test the vendor's preparation. Four steps that test the software:
That last point is the one most evaluation frameworks miss. Accuracy is not the figure that determines value in a procurement workflow — accuracy minus the cost of finding and correcting the errors is.
The common assumption is that AI compliance belongs to whoever built the model. Several duties land on the organisation using the system.
| Source | Provision | What it requires of the buyer |
|---|---|---|
| EU AI Act | Article 26 | Deployers of high-risk systems: use per the provider's instructions, assign human oversight to competent persons, monitor operation, retain logs under your control |
| UK / EU GDPR | Article 22 | Restrictions on decisions based solely on automated processing with legal or similarly significant effects — relevant where scoring affects a supplier's livelihood |
| UK / EU GDPR | Article 28 | The model provider behind the vendor is a sub-processor and needs authorising |
| UK / EU GDPR | Article 35 | A DPIA where processing is likely to be high risk |
Two practical consequences. Supplier scoring is the feature most likely to attract Article 22 attention, because an adverse automated score can exclude a business from tendering. And the model provider is a sub-processor — if your vendor's answer to question 6 is vague, your Article 28 record is incomplete, not theirs.
Not dishonest, necessarily. Just weaker than they sound.
| Claim | What to ask |
|---|---|
| "Reduces cycle time by X%" | Measured against what baseline, at which customer, over what period? Cycle time usually falls because a process was redesigned, not because a model was added |
| "Learns from your data" | Learns what, updated how often, and can you see what changed? Often means a retrieval index rather than training |
| "Fully automated end to end" | Where is the human step? If there isn't one, Article 26 oversight is harder to demonstrate, not easier |
| "AI-powered risk scoring" | Which signals, how weighted, and what happens with none available? Many score confidently on thin data |
| "Pre-built integrations" | Read or write? Which objects? Most "integrations" read |
None of these should end an evaluation. They should all get a written answer, because the gap between the claim and the written answer is the most reliable measure of a vendor you will get before signing.
AI procurement software applies machine learning models to procurement work — classifying spend, extracting terms from contracts, discovering and shortlisting suppliers, scoring supplier risk, and assisting with drafting or negotiation. The five capabilities differ substantially in maturity and should be evaluated separately.
Send your own data, including deliberately difficult cases, before any demo; agree pass criteria in writing before seeing output; ask what the system does when it is not confident; and measure the cost of finding and correcting errors rather than accuracy alone.
What the system does when it is not confident. A system that always returns an answer is returning some it cannot support. A vendor who has built a genuine low-confidence path — a review queue, a flag, a refusal to classify — has designed for being wrong.
Article 26 places obligations on deployers of high-risk AI systems: use in line with the provider's instructions, human oversight assigned to competent persons, monitoring, and log retention under your control. Those attach to the organisation using the system, not only to the vendor that built it.
Not on its own. A system at 85% accuracy that flags its uncertainty can outperform one at 92% that does not, because the second one's errors pass silently into your records. The figure that matters is accuracy minus the cost of detecting and correcting errors.
That has to be answered in the contract rather than the sales call, and it has two parts: whether the vendor trains on it, and whether the underlying model provider does. The model provider is a sub-processor under GDPR Article 28 and needs to appear in your records.