← All articles
- Procurement AI
- Technology Stack
- Category Management
- Strategy
Six kinds of procurement AI, as we see them
A working classification of procurement AI systems by unit of analysis. Most of the category is a better interface on an ERP, and the data it produces is never reused.
By EXOS Research · · 10 min read
This is our classification, not an industry standard. Nobody has appointed a committee, and if they had we would probably disagree with it. What follows is the map we use internally to work out which systems compete, which coexist, and which are solving a problem we are not solving. We publish it because we have not found a better one, not because it is authoritative.
It rests on one argument, which we will make before the list.
Most procurement software is an ERP with better manners
Procurement software did not begin as software for procurement decisions. It began as a module. In the 1990s and 2000s the enterprise resource planning systems that ran finance and manufacturing grew purchasing functions, because purchasing generated transactions and transactions had to be recorded. The requirement was accounting. A purchase order needed an approval trail, a goods receipt needed to match an invoice, and the general ledger needed to close. Everything the system knew about a supplier existed because a payment had been made to them.
That inheritance is not a historical footnote. It is the reason the data model looks the way it does today.
The ERP's atomic unit is the transaction and its organising entity is the vendor master record. Both are well designed for the question what did we pay, to whom, under which cost centre. Both are structurally incapable of the question what should we agree to in this negotiation. Not because the software is bad, but because the second question concerns something that has not happened yet, and a transaction record can only describe something that has.
The generation of tools that followed did not change the unit. It changed the experience of the unit. Intake systems put a friendly front door on requisitioning. Guided buying put a search box over the catalogue. Analytics suites put classification and visualisation over the same purchase history that had always been in the ledger. Every one of these was a genuine improvement — anyone who used the 2005 version of these screens will not want them back. The improvement was to the interface, the workflow and the reporting layer. Underneath, the system still reasons in transactions organised by vendor.
Large language models arrived and the same pattern repeated at speed. A conversational layer went on top of the intake form. Natural-language querying went on top of the spend cube. Contract summarisation went on top of the document store. This is useful work and we do not dismiss it. It is also the third or fourth interface generation over an unchanged foundation, and it inherits the foundation's blind spot exactly. A chat window over a transaction database answers questions about transactions, fluently.
This is why so much high-value procurement analysis still happens in spreadsheets. Not because teams enjoy it. The spreadsheet is the only place in the stack where the thing being decided about — this renewal, this tender, this consolidation — can be assembled with its alternatives, constraints and cost of being wrong side by side. No system of record produces that object, so people build it by hand, use it once, and let it die in a shared drive.
So the first question we ask about a procurement AI system is not what the model can do. It is: what unit does this system reason in, and where did that unit come from?
The six classes
| # | Class | Unit of analysis | Position in the lifecycle | Where the data goes |
|---|
| 1 | Market intelligence and category data | The market category | Continuous, unattached | A report or dashboard. Connection to a specific negotiation is manual |
| 2 | Scenario-based procurement analytics | The project, within a category | Before award | Into the decision directly |
| 3 | Autonomous sourcing | The sourcing event | During the event | Into the award logic |
| 4 | Transactional and intake AI | The transaction | After the decision | Into the record |
| 5 | Spend analytics and audit | The supplier spend line | Retrospective | Into a finding about a decision already made |
| 6 | Supply chain risk monitoring | The supplier, and the tiers behind it | Continuous | An alert on a screen |
1. Market intelligence and category data
Market intelligence systems reason in the market category. They provide curated research on how a category behaves — price formation, supply structure, cost drivers, who the players are. Broad, continuously maintained, and genuinely expert.
Our reservation is not about quality. The output arrives disconnected from anything. You receive a report or a dashboard about a market, and the work of turning it into a position in a specific negotiation is entirely yours, done manually, usually once. The index that told you resin prices were moving does not attach itself to the resin contract you are renewing next month.
2. Scenario-based procurement analytics
A scenario-based procurement analytics system reasons in the project within a category. It models total cost of ownership, negotiation scenarios and supplier risk before a contract is awarded. Not a report about a market and not a record of a transaction — an examination of one decision that has not been made yet, in the terms in which it will be made.
This is our class, so read the entry with that in mind. The claim is specific: the unit is not inherited from the ERP, which means it can hold things the ERP has no field for, and the data gathered for it feeds the decision directly rather than arriving as a separate document.
3. Autonomous sourcing
Autonomous sourcing systems reason in the sourcing event. They automate the running of tenders and auctions: bid collection, combinatorial optimisation, award logic, in some cases automated negotiation with suppliers. Where they fit, they are the most efficient thing on this list, and the efficiency is not marginal.
Where they fit is the constraint. Optimisation needs a settled specification, enough competing suppliers for the outcome to be genuinely contested, and enough event volume for automation to pay back. Placed on the Kraljic matrix, that describes the leverage and non-critical quadrants, and it describes them well.
It describes the strategic and bottleneck quadrants poorly, and the reason is structural rather than a question of product maturity. A negotiation agent works from the parameters it is given. In a high-value, low-frequency deal the parameters are the work: what the total cost of ownership is across the term, what the switching cost looks like, how exposed the supplier's own supply chain is, what the market will bear this quarter. Assembling that context is a different discipline from optimising against it.
4. Transactional and intake AI
Transactional and intake systems reason in the transaction. Requisitions, approvals, orders, contract execution. This is the operational backbone, the direct descendant of the ERP module, and by volume where most procurement software spend goes.
We are not critical of this class — it does something indispensable that nothing else does. We are only clear about what it is. It executes decisions, it does not form them. The intelligence layer added on top makes execution faster and more pleasant. It does not change the unit.
5. Spend analytics and audit
Spend analytics systems reason in the supplier spend line. They perform retrospective analysis across the whole spend base: classification, compliance testing, savings tracking, and the detection of what this part of the market calls value leakage — the gap between what a contract specified and what was actually paid.
The term belongs here, and it is worth being precise about it, because it is used loosely across the category. Value leakage as this class measures it is a post-award discrepancy: contracted price against invoiced price, negotiated rate against applied rate. That is a real and quantifiable loss. It is also definitionally backward-looking. Every insight concerns a decision already made and, frequently, a contract with two years left to run. Knowing where value leaked is worth something. It is worth less than not leaking it, and the terms that determined whether it would leak were set before signature.
6. Supply chain risk monitoring
Supply chain risk monitoring systems reason in the supplier and the tiers behind it. They perform continuous observation of the supply base, including suppliers' suppliers. The specialist platforms in this class go considerably deeper into multi-tier mapping than we do, and we would not claim otherwise. Regulation is pulling in the same direction: the German Supply Chain Due Diligence Act and the EU Corporate Sustainability Due Diligence Directive both make upstream visibility a legal obligation rather than a good practice.
Our reservation mirrors the one in class 1 and has the same shape. The monitoring is a stream that terminates in a screen. An alert fires, someone reads it, and whether it ever reaches the negotiation it should have influenced depends on that person remembering that a contract exists. The signal and the decision are in different systems, connected by human attention. Monitoring that never becomes a negotiating position is expensive awareness.
The pattern in the reservations
Read classes 1, 5 and 6 together and the same complaint appears three times. Each produces good data, and in each the data terminates. A category report, a leakage finding, a risk alert — each lands somewhere a person has to notice it, interpret it, and manually carry it to whatever decision it bears on. The intelligence is real. The connection is a human being with a spreadsheet.
This follows directly from the ERP inheritance. Where the organising unit is the transaction or the vendor record, there is nowhere for a forward-looking signal to live. It has to be published as a document, because there is no object for it to attach to.
The project is that object. It is also the one unit in this list that no system of record produces, which is why it has been the last to be built.
Why we do not expect this to be solved from above
The reasonable objection: the large AI labs are moving quickly, so surely a general-purpose assistant absorbs all of this before long.
Look at where the frontier effort is actually going. The competitive race among the major labs is concentrated on code generation, agentic execution and general reasoning — capabilities with enormous horizontal markets. Procurement is not a target. It is, at best, something someone else builds on top. Gartner's forecast that a third of enterprise software will embed agentic AI by 2028 describes distribution of a commodity capability, not the arrival of domain judgement.
The practical consequence is that raw model capability is becoming a commodity input. Every serious system in all six classes is buying broadly similar intelligence at broadly similar prices. What separates them is not the model. It is the unit they reason in, the domain logic around it, and whether the data they gather connects to anything. Cheaper, more capable models do not fix an inherited data model. If anything they make the domain layer the only thing left to compete on.
Three questions before you evaluate anything
- What unit does it reason in, and where did that unit come from? If the answer is a transaction or a spend line, expect strength in record-keeping and structural weakness on decisions not yet made.
- Does the data it produces connect to anything, or does it terminate in a report? Ask specifically what happens to an alert or a finding after someone reads it.
- Is this a second system or a replacement? A different unit means it coexists. The same unit means one of the two is redundant.
EXOS occupies the second class: scenario-based procurement analytics, reasoning in projects and categories, upstream of the systems that execute. The full classification — definitions, lifecycle position, unit of analysis, typical buyer and representative tools for each class — is published as a reference page rather than a sales page.
Read the full classification of procurement AI systems →
Sources:
Portfolio model: Kraljic, P. (1983) 'Purchasing must become supply management', Harvard Business Review
Agentic AI adoption: Gartner — Top Predictions for IT Organizations and Users in 2025 and Beyond
Supply chain due diligence: German Supply Chain Due Diligence Act (LkSG) · Directive (EU) 2024/1760 (CSDDD)
Operational resilience: Regulation (EU) 2022/2554 (DORA), Articles 28–30