A role-based map of procurement technology

A framework built from the problem, not the pitch.

This platform came out of years of buying, deploying, and integrating procurement technology in the real world — and hitting the same walls every time. Every part of it answers a problem that had no single solution anywhere else.

One place to find them all, and one language to compare them.

The market moves faster than anyone can track, with no comprehensive list and no two sources that agree. Before you can evaluate anything, you have to know it exists.

We built the directory: every vendor, in one place, kept current.

Every vendor describes itself in its own terms, obscuring what it actually does behind the language of the moment. Comparing two means translating two vocabularies before you can even begin.

We built the capability framework: twelve functional areas, ninety-six concrete capabilities, applied identically to every vendor.

A system, not a shopping list.

You don't buy a sourcing tool because a vendor calls it one. You buy it for where it fits in the architecture you're building. Every vendor earns its place by what it fundamentally does — its core role, and the adjacent strengths worth knowing about.

We built the five-layer market map: where each vendor truly sits, and what else it can do.

The whole stack, seen at once.

Choosing one vendor is straightforward. Building a platform is not. You need to overlay vendors, identify the gaps, and understand what happens to your coverage if you replace one with another. Comparison isn't a feature — it's how real decisions get made.

We built head-to-head and multi-vendor comparison, capability by capability.

Proof, not promises.

A shortlist of capable vendors is still just a shortlist. Are they enterprise-ready or early-stage? Is the technology genuinely AI-native or a legacy stack with AI added at the edges? How mature are the APIs and the user experience? Do the analysts recognise them? Is there real momentum behind them? When two vendors match on capability, these signals are what separate them.

Four Composite Scores
Market Signals

We built the evaluation layer: enterprise readiness, technology, analyst and peer recognition, market presence and momentum — the evidence behind every shortlist.

The same problem, from every direction.

This was never one audience's problem. Procurement teams face it. So do the vendors seeking to understand how they are positioned, the emerging players establishing their place in the market, and the investors and operating partners assessing a target or a portfolio. Different reasons, identical need: to see this market clearly, in one consistent language, and reason about it as a system.

Built once, properly, for all of them.

Built by people who have lived this from the inside — who have run global procurement functions, advised on them, and scaled the technology that powers them. Not analysts describing the market from the outside, but operators who understand not just what each tool does, but how it fits together and how you build a procurement platform that works.

The Principle
"If the solution were removed, what would stop working? That answer reveals its true role in the system."

There's always a primary reason you buy a piece of software. Take an end-to-end suite — by definition it claims to do everything, but you don't buy it to do everything. You buy it to execute the process of procurement: to run sourcing, manage contracts, get the work done. The analytics and intelligence come after. Remove it and a lot would break — but what critically breaks reveals its true role. That's the test we apply to every vendor: what critically breaks if you remove it? We classify each by that single primary role — which forces clarity in a world where AI is blurring capabilities — and let the comparison tools reveal everything else it does, so you can sweat your assets without over-buying.

The architecture

Think of procurement not as a pile of tools, but as one system: the people who use it at the top, your core enterprise systems — the ERP and other systems of record — at the bottom, and five layers of capability in between. This is a modern, AI-native procurement architecture: a point of view on how the whole system fits together, onto which every vendor in the market can be placed.

This is the modern, AI-native procurement architecture.

Strip away the users and the ERP beneath — focus on the procurement layer.

Each block has one role — defined by what the system relies on it to do.

Five roles. One system — seen in full.

Business user
Procurement
AI agents
Suppliers
Leadership
Core functionality
Sourcing & category mgmt
Contract lifecycle (CLM)
Supplier mgmt (SRM) & onboarding
Procure-to-pay (P2P)
Procurement enablement
Value mgmt & finance
AI, agentic productivity & autonomous work
Process Execution
Where transactions happen — sourcing events, contracts, P2P.
Coupa
SAP Ariba
Ivalua
Jaggaer
Icertis
Analytics layer
Spend analytics
Benchmarking
AI recommendations
Decision support
Decision Intelligence
Analytics, AI copilots and agents that turn data into decisions.
Sievo
Tropic
Pando
Globality
Data platforms and repositories
Internal data
Master & spend data
Taxonomy & integration
External data
Supplier risk & ESG
Market & price signals
Data Foundation
The clean, classified, connected data layer everything else relies on.
External Intelligence
Outside-in signals — supplier risk, ESG, market and price intelligence.
Stibo
Reltio
Tealbook
EcoVadis
Sayari
Mintec
Workflow & orchestration
Intake, routing & system of record across the stack
Workflow Control
Intake, orchestration and policy that route work end-to-end.
ORO Labs
Zip
Levelpath
Core ERP
SAP · Oracle · Workday · finance systems
Boundary clarity · what each role is not
Two Types of Overlap

Embedded capabilities vs adjacent capabilities.

The problem is not that vendors have multiple features. The real issue is two fundamentally different types of overlap.

An embedded capability exists purely to enhance the vendor's core role — a CLM platform managing contract data and generating insights, all in service of contract process execution.

An adjacent capability extends into a nearby use case without redefining the product — a spend analytics platform that also surfaces contract expiry dates remains fundamentally an analytics tool.

Vendors are classified by their primary role only. Embedded capabilities strengthen it. Adjacent capabilities extend it without changing it.

What it lets you do

Reason about your stack by intent.

Laid out this way, you can reason about your stack by intent. Are you trying to execute a process, make a decision, manage your data foundation, control the workflow, or bring in external intelligence? You can see where you're strong, where capabilities overlap, where you've over-bought, and where the gaps are — and understand clearly what's due for a refresh as the function evolves.