Pure Procurement

What Is a Source-to-Pay Suite?

Tue, 07 Jul 2026 19:28:11 +0000

A Source-to-Pay suite, often shortened to “S2P Suite”, is a single software platform that connects every step of the procurement process: from identifying a sourcing need, through supplier selection and contracting, all the way to purchasing, supplier invoicing, and payment. Instead of running separate tools for each stage, an organization manages the full cycle inside one connected system, with shared data flowing from one step to the next.

That's the textbook definition. After 15+ years implementing these platforms across more than a dozen industries, here's what it actually means in practice, and why the distinction matters more than most vendor pages let on.

The Short Answer

A Source-to-Pay suite combines two halves of procurement that often live in separate systems:

Source-to-Contract (S2C): spend analysis, sourcing events, supplier management, and contract lifecycle management.
Procure-to-Pay (P2P): requisitioning, purchase orders, invoicing, and payment.

When these pieces run on a shared data model, with the same supplier records, the same item catalogs, and the same approval logic, you have a S2P suite. When they're stitched together through integrations between two different products, you have something else, and that distinction is the first thing to check when a vendor uses the term "suite."

How the Market Defines It

This isn't just a matter of opinion. The Gartner Magic Quadrant for Source-to-Pay Suites lays out a mandatory feature set the market is expected to meet, including sourcing event management (RFI, RFP, RFQ, and the negotiation and award process that follows) and contract lifecycle management spanning initiation through award, compliance, and renewal. That baseline is a useful checklist when you're comparing platforms that all claim to be "full suites." We broke down what this year's Magic Quadrant actually confirmed about the market if you want the deeper read.

Why the Term Gets Used Loosely

Plenty of platforms market themselves as Source-to-Pay suites without actually offering an end-to-end data model. Some are P2P tools with a sourcing module bolted on. Others are sourcing platforms that added light requisitioning/ordering functionality. The practical test isn't the marketing page, it's whether you can run and end-to-end procurement workflow from initial requirements to payment without a manual re-entry or a middleware sync job.

This is the kind of thing that only becomes obvious once you're in an implementation, which is exactly why so many RFPs miss it. It's also part of why the legacy idea of the all-in-one modular S2P suite is being challenged as best-of-breed and next generation AI-native point solutions chip away at the modular model.

The Core Modules of an S2P Suite

1. Spend Analysis

Aggregates and categorizes spend data across the organization, usually the starting point for identifying sourcing opportunities and tracking savings. If you're starting from scratch, here's how to build a spend cube from raw transactional data.

2. Sourcing

Manages RFx events (RFI, RFP, RFQ), e-auctions, and supplier bid comparisons. This is where category managers run competitive events and select suppliers, though it's worth knowing where standard RFPs break down on complex projects before you lean on one by default.

3. Contract Lifecycle Management (CLM)

Handles contract authoring, redlining, approval workflows, and obligation tracking after signature. In a true suite, contract terms (like pricing and rebates) flow directly into purchasing and invoicing. Not every organization needs a dedicated CLM tool on day one, we covered how to tell if you actually need one separately.

4. Supplier Management

Centralizes supplier onboarding, risk scoring, performance tracking, and compliance documentation (insurance certificates, diversity status, ESG data, and so on) in parallel to the other processes (e.g. you need different types of information at different parts of the lifecycle). Supplier data quality is what makes or breaks this module in practice.

5. Procurement / Requisitioning

Lets employees request goods and services through catalogs or free-text forms, routed through approval workflows tied to budget and policy. We've written about how the different purchasing channels actually work in more depth.

6. Purchase Order Management

Enables conversion of approved requisitions into POs, sent to suppliers and tracked through fulfillment (e.g. order confirmations, expediting, late PO follow-ups, etc.)

7. Invoice Management

Captures, matches, and routes supplier invoices when exceptions arise, typically using two-way or three-way matching against POs and receipts when available, or invoice approvals for non-PO invoices.

8. Payments

Manages payment execution, sometimes including early payment / dynamic discounting programs and virtual card capabilities.

Not every platform offers all eight as native modules. Many are strong in five or six and rely on partner integrations for the rest. Furthermore, not every organizations needs every module. These are not necessarily problems, but it's something to map out explicitly before you sign a software contract.

S2P vs. P2P: What's the Difference

These terms get used interchangeably, but they're not the same scope. Procure-to-Pay covers only the transactional back half of the cycle: requisition, purchase order, invoice, payment. Source-to-Pay starts earlier, adding sourcing, supplier selection, and contract negotiation before any transaction happens. A platform that's strong on P2P but thin on sourcing and CLM is a P2P tool, not a full S2P suite, regardless of what it's marketed as.

What an S2P Suite Is Not

It's worth being precise here, because procurement teams often inherit terminology without unpacking it:

It is not the same as an ERP. ERPs (like SAP S/4HANA or Oracle) manage finance, HR, and operations broadly, and most provide a reasonably solid Procure-to-Pay base.
Where they fall short is the end-to-end procurement process: deep sourcing, supplier management, and contract lifecycle capability.
That gap is a big part of why dedicated S2P suites (SAP Ariba, Coupa, Ivalua, Jaggaer, GEP, Zip, Zycus, and others) came about in the first place. Which one makes sense often comes down to your industry more than company size.
It is not a guarantee of integration. As noted above, "suite" is sometimes a marketing label rather than an architectural one. Due diligence required.

Why Organizations Move to S2P Suites

The case for consolidating onto a single S2P platform usually comes down to four things:

Data continuity. Supplier and spend data created during sourcing carries through to contracting, purchasing, and invoicing without manual re-entry, which reduces maverick spend and improves audit trails.
Visibility. Leadership gets one place to see committed spend, contract compliance, and supplier risk, instead of reconciling exports from multiple tools.
Process efficiency. Procurement and AP teams spend less time on data reconciliation and more on category strategy and supplier relationships.
Business model fit. Organizations that are primarily indirect-purchasing-based, meaning no MRP, inventory management, or materials planning, have less need to keep procurement tightly bound to the ERP.
With limited integration required to other business functions (unlike direct procurement businesses like manufacturing), it becomes feasible to run procurement on a dedicated platform built for a better user experience rather than defaulting to the ERP's native modules.

The tradeoff is implementation complexity. S2P suites are significant projects, not point-tool rollouts, and the modules that look easiest to configure (like requisitioning) often surface the most change management friction because they touch the most end users.

Where AI Actually Shows Up in S2P Today

AI gets attached to every procurement product page right now, so it's worth being specific about where it's genuinely useful rather than where it's a feature checkbox.

Most major suites are now shipping some version of an "AI Studio," a toolbox of configurable, LLM-backed agents that let you automate specific S2P workflows (drafting RFx documents, summarizing supplier responses, triaging intake requests) without needing a dedicated build team. However, you can also use the same tools the vendor uses to build your own workflows and “agents”.

These are still early and vary a lot in maturity between vendors, but they're quickly becoming the default way suites package AI rather than a single bolted-on feature.

None of this replaces sourcing strategy or supplier negotiation, which still depend on human judgment, but it does meaningfully cut the drafting and administrative loads procurement must handle.

How to Measure Whether It's Working

A suite is only as good as what it lets you track. A few KPIs worth building into any S2P rollout from day one:

Contract utilization rate: how much of your spend with a contracted supplier is actually covered by the negotiated terms, which reveals off-contract or maverick buying.
Policy adherence: the rate at which purchases follow required approvals and process controls, a direct measure of whether the platform is actually changing behavior.
Cycle time: how long it takes to move from requisition to PO, and from invoice receipt to payment, which tends to be the most visible win to finance leadership early on.

Start with two or three KPIs tied to your most pressing business goal rather than trying to dashboard everything on day one.

How to Evaluate a S2P Suite

A few questions are worth asking any vendor, beyond the standard RFP checklist (and beyond the critical success factors that tend to separate good S2P projects from stalled ones).

If you're scoping the P2P side specifically, our P2P functional requirements series is a more granular reference, including requirements specific to manufacturers, distributors, and MRO-heavy operations if that's closer to your business model:

Is the data model genuinely unified across sourcing, contracting, and procurement, or are modules connected by APIs between acquired companies?
What does supplier onboarding look like once, not per module?
How does the platform handle services procurement versus goods, which often have very different workflows?
What's the actual implementation timeline based on comparable company size and industry, not the vendor's best-case example?
Who owns the roadmap for the modules you care about most, and how often do they ship updates to those specifically?

Can You Implement an S2P Suite in Phases?

Yes. Most organizations don't go live with all modules at once, and trying to is one of the more common ways these projects stall and fail. A typical sequence starts with the most structural modules first: supplier management, P2P processes, and spend analytics. These are the modules that generate good data and help you analyze it, and that data is what lets you correctly calculate your baselines and determine the highest-value next moves, whether that's CLM, deeper sourcing capability, or payments automation.

The Bottom Line

A Source-to-Pay suite is, at its core, a promise: that procurement can run as one connected process instead of a series of handoffs between disconnected tools. Whether any given platform actually delivers on that promise depends entirely on its underlying architecture, not its website. The label tells you what a vendor is selling. The data model tells you what you're actually buying.

It's also worth remembering that no S2P system stays static, and the suite model itself is being tested by a market that's increasingly asking whether bundled platforms still make sense against best-of-breed alternatives. The definition above is a starting point, not a permanent answer.

This article is part of ProcureTech Foundations, a series from Pure Procurement breaking down core procurement technology concepts for practitioners. Vendor-independent, built from hands-on implementation experience.

Supplier Risk Management 101: What It Actually Takes to Build a Program That Works

Joël Collin-Demers — Mon, 22 Jun 2026 01:25:54 +0000

A rchive | Upgrade to Premium | Sponsor

Supplier Risk Management 101: What It Actually Takes to Build a Program That Works
Building a Program That Produces Results, Not Just Checkboxes
Supplier Risk Management 101: What It Actually Takes to Build a Program That Works

Supplier Risk Management 101: What It Actually Takes to Build a Program That Works

Here's a confession most vendor marketing won't make: supplier risk management is genuinely hard. Not because the lifecycle is complicated, it isn't, once you've done the groundwork. Not because the technology is immature, it isn't, at least not anymore. It's hard because the groundwork is harder than people expect, and most organizations skip it entirely.

This article is a practitioner's guide to building a supplier risk management program that actually holds up, from defining what you're trying to accomplish, to structuring your risk dimensions, to understanding where the real implementation traps hide.

What Is Supplier Risk Management, and What Is It Not?

Let's start with a definition worth using: supplier risk management is the set of processes and capabilities that help your organization achieve three distinct objectives.

Ensuring compliance with legal or regulatory obligations related to your supply base, whether that's anti-bribery legislation, mandatory human rights due diligence, or sector-specific regulatory requirements
Reducing the probability of issues occurring, proactively identifying and addressing conditions that make bad outcomes more likely
Mitigating impact when issues materialize, limiting the damage when something does go wrong, and responding faster than you otherwise would

Notice what's buried in that second objective: issues, not risks. This distinction matters more than most programs acknowledge.

Conflating the two is surprisingly common, and it leads to bad program design. A risk management process is built around probability and prevention. An issue management process is built around detection, response, and recovery. You need both, and they operate differently. If your "risk management" program only kicks in after a supplier has already failed an audit or missed a delivery, you've built an issue log with extra steps.

One more framing point worth naming: TPRM and SRM are increasingly the same conversation. Third-Party Risk Management (TPRM), historically owned by compliance, legal, or IT, covers substantially the same supplier population that procurement manages. The growing consensus in the market is that these functions belong under unified ownership or at least tightly coordinated processes. If your organization runs them separately, expect gaps where risk hides between the handoffs.

Risk Doesn't Live in One Place, It Lives at Three Levels

One of the most persistent structural errors in supplier risk management is treating "supplier risk" as a single, undifferentiated thing. In practice, risk exists at three distinct levels, and each level demands different processes, different inputs, and different triggers.

Supplier Level

Supplier-level risk is about who this supplier is as an organization: their financial health, their operational capacity, their governance practices, their ESG posture, their geopolitical exposure. This risk profile exists regardless of what you're buying or what contract you have in place.

You assess supplier-level risk at initial onboarding, when a supplier enters your universe, and then on an ongoing basis for as long as that supplier remains active in your supply base.

Contract Level

Contract-level risk is about what you've committed to together. A given supplier might have a low financial risk profile but present significant compliance risk under a specific contract, for example, if that contract involves access to sensitive personal data, operations in a high-risk country, or regulatory obligations that attach to the specific product or service being delivered.

Your contract-level risk profile may be heavily shaped by the supplier-level profile. A supplier you've classified as Tier 1 critical will face a more rigorous contract-level assessment than a low-spend, low-criticality supplier. The risk work follows the relationship and the transaction type, not just the supplier identity.

Engagement / Transaction Level

Engagement-level risk is about what's happening right now, the specific purchase order, statement of work, or delivery in flight. This is where you assess whether a given transaction introduces risks that aren't fully covered at the supplier or contract level. A blanket purchase order to a well-understood supplier is low-engagement-risk. A new statement of work with a software vendor for a system with privileged access to your financial data is not.

Why does this matter? Because most supplier risk programs collapse these three levels into one assessment and call it done. The result is either over-engineering (every PO triggers a full due diligence review) or under-engineering (one supplier questionnaire covers everything forever). Neither works. The level determines the instrument.

The Risk Dimensions Practitioners Actually Use

There is no single authoritative, freely available framework that defines supplier risk dimensions with canonical definitions.

This is worth saying plainly, because vendors and consultants often imply otherwise. Gartner has useful material behind a paywall. CIPS has rigorous definitions behind a membership gate. ISO 31000 provides governance structure but doesn't name specific supply-side risk categories.

What exists instead is a practitioner consensus that has converged across industry over time. The most credible sources, Gartner, S&P Global, CIPS, and others, have largely landed on the same set of eight dimensions:

Financial risk, supplier insolvency, credit deterioration, cash flow stress, or ownership changes that impair their ability to deliver
Operational risk, capacity constraints, quality failures, key person dependency, or supply continuity gaps
Compliance risk, the risk that a supplier's operations, or your use of that supplier, violates a mandatory legal or regulatory requirement
Reputational risk, ESG and conduct-related exposures that can cascade into legal, regulatory, and financial consequences for the buyer
Geopolitical risk, political instability, trade tensions, export controls, or government actions in a supplier's country or region that could disrupt supply
Cybersecurity / information security risk, unauthorized access, data breaches, weak controls, or inadequate security practices within the supplier's environment
ESG / sustainability risk, environmental, social, and governance exposure tied to the supplier's own operations and upstream supply chain
Concentration risk, overreliance on a single supplier or a small cluster of suppliers for critical inputs, creating systemic vulnerability

That's the list. But here's the part most articles skip: you don't have to start with all eight.

If you're a manufacturer whose primary risk exposure is supply assurance, continuity of raw material flow, your most critical dimensions on day one are operational risk, financial risk, geopolitical risk, and concentration risk. You don't need a mature cybersecurity questionnaire program yet. A SaaS-heavy company with no direct materials exposure has the inverse profile: cybersecurity and compliance risk are critical; supply assurance and concentration risk may barely apply.

Right-sizing your starting taxonomy to your actual risk exposure isn't laziness. It's the difference between building a program your organization will actually use and one that collapses under its own weight before it reaches maturity.

Start with the dimensions that matter most to your industry, your spend profile, and your regulatory environment and design the framework to scale from there.

The Hardest Part of Supplier Risk Management (It's Not the Technology)

Here's the part of supplier risk management that rarely makes it into vendor collateral: the hard work is alignment, not execution.

Before you can assess a single supplier, your organization needs to agree on a deceptively difficult set of questions:

Which risk dimensions are in scope for your program, and which aren't, at least for now?
How is each dimension defined specifically enough that two different evaluators would produce consistent assessments?
Which level does each dimension map to, supplier, contract, or engagement (or many)?
What inputs do you actually need to run each evaluation at which level? Who provides them? Where does that data come from?
Who owns each risk dimension, procurement, legal, IT security, finance, compliance?

This alignment work is unglamorous. It involves workshops, debates, and at least one meeting where someone from IT security and someone from procurement can't agree on what "cybersecurity risk" means at the supplier level versus the contract level. It takes longer than anyone plans for.

And yet it's the foundation everything else rests on. Without it, your questionnaires will be inconsistent. Your risk scores will be incoherent. Your program will produce data no one trusts and therefore no one uses.

Here's the trap we see over and over again: organizations don’t have this conversation UNTIL they're implementing a TPRM platform. They expect the system to force the alignment, to make the definitions visible and concrete through configuration.

It unfortunately never works out that way. 😭

Choosing your risk taxonomy after the project start is like choosing your pasta shape after the spaghetti is already cooking in the pot. You're not configuring a program; you're retrofitting a philosophy into a tool that's already in deployment.

The implementation becomes slower, messier, and more expensive than it needed to be, because the conceptual work that should have happened in a room with a whiteboard is now happening inside a software configuration screen with a project team on the clock (and payroll 😬).

Do the alignment work first. Build the taxonomy on paper. Get cross-functional agreement on definitions, ownership, and inputs. Then evaluate and configure your technology.

The Supplier Risk Lifecycle, Once You've Done the Hard Part

Once your taxonomy is aligned and your levels are clear, the lifecycle itself is relatively straightforward. The program spans onboarding through offboarding, with ongoing monitoring running throughout the active relationship.

Pre-Signature: Due Diligence

Before you onboard a supplier or execute a significant contract, you run whatever assessments are required by the risk profile of that relationship. For a low-risk, low-spend supplier, that might be a basic financial check and a compliance certification. For a Tier 1 critical supplier with access to sensitive data, that could involve a full financial analysis, a cybersecurity assessment, a compliance questionnaire, site visits, and reference checks.

The key principle: the depth of pre-signature due diligence should be proportional to the assessed risk level, which is why supplier segmentation and tiering need to be functional before this process can work at scale.

Post-Signature: Ongoing Monitoring

Onboarding is not a finish line. A supplier's risk profile changes, sometimes gradually, sometimes suddenly. Ongoing monitoring is what keeps you from being surprised.

Effective ongoing monitoring typically includes:

Periodic reassessments, scheduled reviews tied to the supplier's risk tier (quarterly or annually for high-risk, less frequently for low-risk)
Trigger-based reassessments, unscheduled reviews initiated by a specific event: a credit rating downgrade, a news alert, a failed audit, an ownership change, a significant regulatory fine
Performance monitoring, tracking KPIs (on-time delivery, quality scores, compliance rates) as leading indicators of emerging operational or relationship risk
External data feeds, for organizations with mature programs, automated signals from third-party data providers (financial health scores, sanctions lists, ESG ratings, cyber risk scores) that flag changes between scheduled reviews

The goal of ongoing monitoring is not to generate paper. It's to give you early warning of conditions that are drifting toward an issue, so you can intervene before the risk materializes.

Anything more than that and you run the risk of notification fatigue…

Offboarding

Supplier exit is a phase most programs neglect entirely. When a supplier relationship ends, whether through contract expiry, termination for cause, or strategic rationalization, there are risk management obligations that don't stop at the last invoice… Data deletion, IP recovery, regulatory reporting, access revocation, and transition risk management all belong in a coherent offboarding process.

How Your Industry and Geography Shape Your Program

There is no universal supplier risk management framework. This isn't a gap in the literature, it's a feature of the reality. Risk is context-dependent, and context varies enormously across industries and geographies.

Industry shapes your risk priorities. A pharmaceutical manufacturer has supply assurance and quality compliance as existential risks. A financial services firm faces cybersecurity and regulatory compliance as primary concerns, with supply assurance barely on the radar. A retailer with a complex global supply chain has ESG and concentration risk at the top of its list. A defense contractor has export controls and geopolitical risk as non-negotiables.
Your industry determines which dimensions require the most rigor and which are lower priority at the outset.
Geography shapes your mandatory obligations. The legal landscape for supply chain due diligence has shifted dramatically in recent years. The German Supply Chain Act (LkSG), the EU Corporate Sustainability Due Diligence Directive (CSDDD), the UK, Canadian and Australian Modern Slavery Acts, and equivalent legislation in other jurisdictions have converted what was previously voluntary ESG risk management into a legal compliance requirement.
Which obligations apply to your organization depends on where you operate, where your suppliers operate, and the size thresholds that trigger each regime.
Maturity shapes your starting point. If your organization is early in its supplier risk management journey, trying to build a sophisticated, multi-dimensional program on day one is a trap. You'll create a structure so complex that it can't be consistently executed… And an inconsistently executed risk program is arguably worse than no program at all, because it creates the illusion of coverage without the substance.

Start simple. Pick the two or three dimensions that represent your most acute risk exposure. Build a process you can actually run. Prove that it produces results. Then extend the framework. Crawl before you run, not because ambition is wrong, but because a working simple program beats a broken complex one every time.

Perfection is the enemy of progress.

Where Technology Fits, and Where It Doesn't

TPRM and supplier risk platforms have matured significantly. The leading solutions (and there are a number of credible ones in the market) provide meaningful capabilities: centralized supplier profiles, configurable risk questionnaires, automated scoring, external data integrations, workflow management, audit trails, and dashboards that give leadership visibility into portfolio-level risk exposure.

These systems are genuinely useful. But they are not magic.

What a good TPRM platform actually solves:

Operational consistency, ensuring that assessments are conducted, tracked, and documented in a standardized way
Scale, enabling you to manage risk across a large supplier population that you couldn't manage manually
Visibility, surfacing risk signals across the portfolio in a way that a spreadsheet never could
Auditability, creating a defensible record of your due diligence activities for regulatory or contractual purposes

What a good TPRM platform cannot solve:

A taxonomy that hasn't been agreed upon
Definitions that different stakeholders interpret differently
Ownership questions that haven't been resolved between procurement, legal, IT, and compliance
Risk assessments that aren't grounded in real business context

This is the implementation trap, and it's endemic.

Organizations buy a TPRM platform before they've done the alignment work, then spend months in configuration fighting about questions they should have answered before the contract was signed. The platform becomes the venue for the alignment conversation, which is the most expensive possible venue.

The sequencing is non-negotiable: taxonomy first, technology second.

Building a Program That Produces Results, Not Just Checkboxes

The ultimate test of a supplier risk management program is not whether it exists. It's whether it produces verifiable business results.

What does that mean in practice?

Issues are caught earlier, before they become crises (and a $ value can be put to the avoidance)
Compliance obligations are met consistently and can be demonstrated to regulators
Sourcing decisions are meaningfully informed by risk data, not just cost and quality
The organization responds faster and more effectively when disruptions occur
Risk exposure in the portfolio visibly decreases over time as mitigations take hold

If your program produces questionnaires and scores but doesn't influence decisions, it's a checkbox exercise. Checkbox exercises create compliance theatre, they look like risk management from the outside and provide none of the protection on the inside.

How do you build a program that avoids this?

Start with outcomes, not activities. Before you design a questionnaire, ask: what decision will this inform? Who will use this data? What action will they take if the score is red?

Keep the initial scope honest. A risk program that covers 50 suppliers well is more valuable than one that covers 500 suppliers superficially. Depth of assessment beats breadth of coverage, especially early in program maturity.

Build feedback loops. Track whether risk signals predicted actual issues. When a supplier with a high financial risk score subsequently went insolvent, did your monitoring catch it early enough to make a difference? If not, why not? The answer should drive program improvement.

And resist the pressure to make the program look more sophisticated than it is. Complexity that can't be executed consistently isn't sophistication… It's risk in itself.

What to Take Away

Supplier risk management is one of those disciplines where the conceptual framework is straightforward and the execution is hard. The lifecycle isn't complicated. The risk dimensions are well-understood. The technology is available.

What makes programs fail, consistently, predictably, is skipping the foundational alignment work: agreeing on what you're measuring, at what level, with what inputs, owned by whom. Do that work first, match your starting scope to your actual risk profile, and build toward sophistication rather than starting there.

The organizations that get this right don't have the most sophisticated programs. They have programs that run consistently, produce data people trust, and inform decisions that matter. That's the bar worth building toward.

👀In Case You Missed It…
This week’s episode of ProcureTech Unpacked

👀 In Case You Missed It…
The Last 3 Newsletters:

1/ Do You Need a Contract Lifecycle Management (CLM) Tool?
2/ Foundational Procurement System by Industry: ERP vs S2P Suite
3/ Coupa's Tonkean Acquisition. Game Changer or Smoke and Mirrors?

2 other ways we can help this week:

Why do so many procurement transformations fall short?
Gabe Perez and Joël Collin-Demers break down where teams miss the mark, and why real progress starts with sharper strategy, clearer alignment, and a better operating model, not just more technology.
Read it here.
Real procurement transformation takes more than new technology.
This webinar replay brings together Bristol Myers Squibb’s CPO, Paula Glickenhaus & Joël Collin-Demers to break down how leading teams define scope, align sponsors, build the business case, and turn complexity into progress.
Watch the replay.

See you next week {{FIRST_NAME|readers}},

— The Pure Procurement Newsletter Team

What is Procurement Intake & Orchestration? Definition & Examples

Thu, 18 Jun 2026 02:27:38 +0000

What is Procurement Intake & Orchestration?

Procurement Intake & Orchestration (I&O) refers to two complementary capabilities that help organizations manage how work flows into and through their procurement function.

In simple terms:

Intake management is the "front door" to procurement: a single, unified entry point where stakeholders submit requests for goods, services, or supplier-related needs.
Orchestration is the coordination layer that ensures requests flow through the right steps, systems, and approvals to completion.

Together, they solve a common problem: stakeholders avoiding procurement because the process is too fragmented, confusing, or slow.

Procurement Intake Management: The Front Door

Procurement intake management is the process of capturing, validating, and routing incoming requests into your procurement function.

Think of it as the entry point where stakeholders submit requests regardless of what they need: a new software license, a contract renewal, a supplier onboarded, an invoice disputed, or a one-off payment approval.

The key insight: intake is about the requester experience. It's designed to make following the process easier than circumventing it.

Good intake management:

Captures structured information upfront
Validates completeness before routing
Directs requests to the right workflow automatically
Provides real-time status visibility
Meets users where they already work (Slack, Teams, email) instead of forcing them into unfamiliar portals

Procurement Orchestration: The Coordination Layer

Procurement process orchestration coordinates end-to-end workflows across multiple systems, teams, and data sources throughout the procurement lifecycle.

Unlike intake (which focuses on the initial request), orchestration manages what happens after: ensuring the right steps happen in the right sequence, across whatever combination of processes, systems and stakeholders need to be used/consulted based on the scenario.

The key insight: orchestration is about process coherence.

Good orchestration:

Connects disparate systems (ERP, CLM, P2P suite, risk tools, supplier portals) into unified workflows
Automates handoffs without manual re-keying
Applies business rules consistently
Enables process changes without rebuilding integrations from scratch
Coordinates cross-functional dependencies (Legal, IT Security, Finance) that procurement depends on

Why Do Companies Need Intake & Orchestration?

The symptoms of a broken procurement front door are everywhere:

Maverick spend that shows up in your analytics months after the fact
Email tennis between requesters, approvers, and buyers that eats hours every week
Invisible requests stuck in someone's inbox while stakeholders assume you're ignoring them
Shadow IT purchases that bypass procurement entirely because "it was easier"
Duplicate supplier onboarding because nobody knows what's already in progress

This isn't a training problem. You can't train your way out of broken processes and fragmented systems. And it's not purely a technology problem either.

What I&O solutions address is the user experience problem: the gap between how procurement needs data formatted to work and the fragmented reality stakeholders actually experience.

When Do You Actually Need I&O?

5 Signs You Need I&O

Adoption problems are bleeding you dry. Spend-under-management is stuck, maverick spend keeps climbing, stakeholders routinely bypass procurement.
Your tech stack has become a maze. A simple purchase request requires touching three systems and four handoffs.
Buyers are drowning in request management. More time triaging and chasing approvals than doing actual procurement work.
Cross-functional coordination is a nightmare. Legal, IT Security, Finance dependencies, and you're manually playing "air traffic controller."
You can't answer basic performance questions. When executives ask "how long does it take to process a purchase request?" you genuinely don't know.

4 Signs You DON'T Need I&O

Your S2P suite is working. Adoption is strong, stakeholders are reasonably satisfied, native workflows meet your needs.
Your processes are the problem, not your systems. Insane approval matrix, unclear policies, undefined roles. Fix those first.
You can't commit to integration work. I&O only delivers value when connected to other systems.
You're small and simple. One ERP, handful of categories, team of three. Your existing tools likely have sufficient native workflow capabilities.

The I&O Vendor Landscape

The I&O market has exploded. Today, you'll find:

Pure-play I&O vendors
I&O-first platforms
S2P suites adding I&O
Specialized players

The lines between these categories are blurring. A year from now, we may not talk about "I&O vendors" and "S2P vendors" as distinct categories, just "end-to-end procurement platforms" with different strengths and origins.

Go Deeper: The Complete I&O Guide

This article covers the fundamentals. For a comprehensive breakdown:

4 technology architecture scenarios and where I&O fits
7 questions to ask every I&O vendor
14 enterprise vendors reviewed with differentiators
Implementation timelines and success metrics
The I&O and S2P convergence you need to watch

Read the full guide:

Procurement Intake & Orchestration: The Complete Guide (2026)

Frequently Asked Questions

What is the difference between intake and orchestration?

Intake is the front door: it captures, validates, and routes incoming requests into procurement. Orchestration is the coordination layer: it ensures requests flow through the right steps, systems, and approvals to completion. Intake collects requests; orchestration ensures they follow the right process.

What is a procurement intake process?

A procurement intake process is a structured method for capturing purchase requests from stakeholders. It typically includes a single entry point (portal, form, chatbot, or Slack/Teams integration), validation of required information, automatic routing based on request type and value, and real-time status visibility for requesters.

What is the difference between intake orchestration and S2P suites?

Traditional S2P (Source-to-Pay) suites focus on executing procurement processes: sourcing, contracts, purchasing, and payments. Intake & orchestration solutions focus on how work enters and flows through those processes. Some organizations use I&O as a layer on top of their S2P suite; others use I&O platforms that include their own S2P capabilities.

Do I need intake orchestration if I have Coupa or SAP Ariba?

Maybe not. If your S2P suite's native intake works well and adoption is strong, an additional I&O layer may add complexity without proportional benefit. However, if stakeholders are bypassing your suite because the interface is clunky, or if you need to coordinate workflows across multiple systems (including non-procurement systems like ServiceNow or legal CLM tools), I&O can provide significant value. Coupa and Ariba have come out with their own flavors of I&O recently as well.

What does procurement orchestration software cost?

Pricing varies widely: per-user, per-transaction, per-workflow, platform fee plus consumption, or various combinations. Enterprise deployments typically range from $50K-$1M+ annually depending on scope, user count, and integration complexity. Always clarify the pricing model structure before detailed vendor discussions.

How long does it take to implement intake and orchestration?

Implementation timelines vary based on scope:

Quick-win deployment (4-8 weeks): Single use case, limited integrations, standard workflows
Departmental rollout (2-4 months): Multiple intake types, deeper integrations, customized workflows
Enterprise deployment (12-24 months): Organization-wide intake, comprehensive cross-functional orchestration, complex integrations

Do You Need a Contract Lifecycle Management (CLM) Tool?

Joël Collin-Demers — Mon, 15 Jun 2026 01:00:00 +0000

A rchive | Upgrade to Premium | Sponsor

Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.

Do You Need a Contract Lifecycle Management (CLM) Tool? Most Procurement Teams Are Asking the Wrong Question

Do You Need a Contract Lifecycle Management (CLM) Tool?

Most procurement teams asking "do we need a CLM tool?" are already three steps ahead of where they need to be.

They've seen the demos. They've sat through the pitch deck. They know the vendors. And they're ready to go to the CFO with a business case.

Here's the problem: a significant chunk of those teams don't have a functioning contract repository. No central storage. No metadata standards. No clear owner. Contracts living in email threads, shared drives with no naming conventions, and that one folder on a legal assistant's desktop that nobody can find.

That's not a CLM problem. That's a foundation problem. And buying a CLM platform to solve it is like installing a home automation system in a house with no electrical wiring.

The Question Isn't "Do We Need CLM?", It's "Have We Fixed the Basics?"

The CLM software market is projected to hit several billion dollars over the next few years, and every vendor in the space has a vested interest in telling you that you need their platform. That's not cynicism, it's just the incentive structure of the industry.

What you're less likely to hear from a CLM vendor: you might not need us *yet*.

So let's answer the actual question procurement teams should be asking, not "which CLM should we buy?" but "what contract management maturity level are we actually at, and what does that imply about our next move?"

What Is Contract Lifecycle Management (CLM)?

Contract lifecycle management (CLM) is the systematic process of managing contracts from initial request through execution, performance monitoring, renewal, and expiration.

A CLM platform is software that automates and centralizes that process, handling authoring, negotiation workflows, approvals, e-signature, obligation tracking, renewal alerts, and reporting in a single system.

That's the full definition. The important word in there is “systematic”. CLM software doesn't create a process/system, it automates one. If the underlying process doesn't exist yet, the software has nothing to automate.

The Foundation Problem Nobody in the CLM Industry Wants to Talk About

Here's what I keep encountering when I talk to procurement teams about contract management: they want to jump straight to platform selection. Best-of-breed evaluation. RFP. Demo. Negotiation.

And when I ask the diagnostic questions, where do your contracts live right now, who owns contract data quality, what's your process for ensuring every executed contract gets stored, the answers are not great.

No central repository. No single owner. No consistent process.

That's not a knock on those teams. Contract management is genuinely hard to prioritize when you're running sourcing events, managing supplier relationships, and fighting fires. But it does mean that a CLM platform isn't your next move. Your next move is building a foundation.

Here's the five-step progression that actually matches where most procurement teams are starting from:

Step 1: Set Up a Central Repository

The first requirement for contract management isn't software sophistication. It's centralization. Every executed contract needs to live in one place, full stop.

SharePoint works. Google Drive works. A well-structured network folder with a sensible naming convention works. Is it ideal? No. Is it infinitely better than contracts scattered across inboxes and desktop folders? Absolutely.

The key requirements for a functional repository at this stage are simple:

A single, authoritative location everyone knows about
A consistent folder structure and file naming convention
Basic metadata captured at upload: counterparty name, contract type, effective date, expiry date, owner
Access controls so the right people can find what they need and the wrong ones can’t
Don't let perfect be the enemy of functional. A disciplined SharePoint deployment outperforms a half-implemented CLM platform every time.

Step 2: Assign a Single Owner for Contract Data Quality

This is the step most organizations skip, and it's why their repositories decay within 18 months.

You need one person, not a committee, not a shared responsibility… One person, accountable for contract data quality. Their job is to enforce the metadata standards, chase down missing contracts, audit the repository periodically, and be the person everyone knows to call when something can't be found.

This doesn't have to be a full-time role. In most mid-sized procurement teams, it's 20% of someone's week. But it has to be explicit and it has to be someone's name on the org chart.

Step 3: Build the Process Discipline to Actually Use It

A repository that people don't consistently use is just a fancy filing cabinet that's also partially wrong.

The process question is simple: what is the mandatory step in your contracting workflow that ensures every executed contract ends up in the repository with good metadata? If you can't answer that precisely, you don't have a process, you’re operating on hope.

This usually means embedding repository upload into your existing sourcing or contracting workflows. Before a contract goes to the counterparty for signature, someone is responsible for pre-registering it in the repository. Once executed, the signed version goes in. No exceptions. No "I'll add it later."

Perhaps the supplier record can’t get created in your payment system without proof this is done… Whatever works.

It sounds obvious. Almost no teams do this consistently.

Steps 4 and 5: Integration and AI Query Layer

Once you have a functioning, well-maintained repository, two upgrades unlock significant value with relatively low investment.

Step 4: Integration into your sourcing and contracting workflow

Connect your repository to wherever contracts originate. If contracts are drafted in Word and signed via DocuSign, build the handoff so executed documents land in the repository automatically. If you're using a Source-to-Pay platform, most have lightweight contract storage or repository integration built in. Use it.

Step 5: Plug in your corporate LLM

This is where things get interesting. A well-structured, consistently maintained contract repository is a genuinely high-quality, high-value dataset. If you connect a corporate LLM (e.g. Microsoft Copilot against SharePoint) or a purpose-built contract AI tool, you can query that repository in natural language.

What contracts with Supplier X expire in the next 90 days? Show me every contract with an auto-renewal clause. Which agreements have an uncapped liability provision?

Ad-hoc querying your contract database is a meaningful capability... And it doesn't require a CLM platform to get there today.

What That Foundation Actually Gets You

Let's be honest about what steps 1 through 5 actually deliver, because this is where the conversation usually gets muddier than it needs to be.

A well-executed foundation, central repository, single owner, consistent process, workflow integration, LLM query layer… This satisfies roughly 80% of what most procurement teams think they need a CLM platform for.

Specifically, it covers:

Contract visibility: You can find any contract in seconds
Expiry and renewal tracking: Automated alerts via your LLM or even basic SharePoint date fields
Basic obligation tracking: Flagging key terms and dates through AI extraction
Spend and supplier reporting: Counterparty and contract type data for basic portfolio analysis
Compliance evidence: An auditable record of executed agreements with version history

That's not nothing. That's actually a big part of the core value proposition of most mid-market CLM platforms, delivered through tools you likely already own.

The teams that get this right often find they've solved 80% of their problem for the cost of a few weeks of disciplined setup work and one person's partial attention. That's a very different ROI conversation than a six-figure software investment.

The 20% Where a Dedicated CLM Platform Earns Its Place

None of this means CLM platforms aren't worth the investment, though... They absolutely are in the right circumstances. Here's what those circumstances actually look like.

Consistent contract authoring at scale. If you have hundreds of people across business units drafting contracts, sales, procurement, HR, operations, and you need consistent templates, clause libraries, and approval workflows at that scale, a spreadsheet-backed repository breaks down fast. CLM platforms are built for this. SharePoint is not.

An oncoming wave of renewals you can't handle manually. If your contract portfolio has a renewal concentration, dozens or hundreds of contracts expiring within a 12-month window, and your team doesn't have the bandwidth to manage them one by one, a CLM platform's automated workflows and renewal management pays for itself.

Obligation management at scale. Tracking SLAs, milestones, performance commitments, and deliverables across a large supplier portfolio requires more than date fields and LLM queries. If contractual obligations drive real business outcomes, penalties, payment triggers, performance reviews, you need purpose-built obligation management.

High-risk contract environments with material compliance exposure. Regulated industries, government contracting, complex cross-border agreements, environments where a missed clause or an untracked obligation creates legal or financial exposure at scale. This is where CLM's audit trails, clause libraries, and compliance workflows justify enterprise pricing.

Complex multi-agreement contract hierarchies. Master agreements, statements of work, amendments, side letters, order forms, all linked, all affecting each other. Managing that hierarchy manually is error-prone and time-consuming. CLM platforms handle this natively.

Complex multi-stakeholder workflows across functions. When a single contract requires serial or parallel review from Legal, Finance, Risk, and a business unit, with version control, commenting, and audit trail, you need a proper workflow engine. Email chains don't cut it at this complexity level.

If you're nodding your head at two or more of those, you probably do need a CLM platform. If none of those describe your situation, go back to steps 1 through 5.

How to Know Which Side of the Line You're On

Here's a simple diagnostic. Answer honestly.

You're in foundation territory if:

You couldn't tell me today how many active contracts your organization has
You don't know which supplier contracts are expiring in the next 6 months without manually checking
You have contracts living in more than two or three unconnected locations
Nobody has explicit ownership over contract data quality
Your "repository" is a shared drive with inconsistent naming conventions

You're ready to evaluate CLM if:

Your repository is well-maintained, centralized, and consistently used
You're managing 500+ active contracts across your portfolio
Multiple teams (procurement, legal, sales, HR) need to author contracts using shared templates
You have meaningful obligation tracking requirements that go beyond expiry dates
You're in a regulated environment where compliance audit trails are non-negotiable
You've already got the foundation right and have clearly identified what it doesn't cover

The honest answer for most procurement teams reading this: you're in foundation territory. That's not a failing, it's just where the average organizations actually is... The teams that acknowledge it and fix it before going to market for a CLM are the ones that get the most out of the platform when they do eventually buy it.

CLM Platforms Worth Evaluating (If You Actually Need One)

If you've done the diagnostic and you're genuinely in CLM territory, here are nine best-o-f-breed platforms that come up consistently in procurement and legal evaluation conversations.

This isn't a ranked list and it isn't a recommendation, it's a starting point for your own research.

Icertis
Sirion
Ironclad
Agiloft
Gatekeeper
Juro
Terzo
Filevine
Leah

Furthermore, your Source-to-Pay Suite and/or Intke & Orchestration-first providers may also have CLM functionalities worth looking at.

In any case, Do the foundation work first, know your requirements before you talk to any of them, and don't let a great demo override a clear-eyed view of what you actually need.

The Bottom Line

Most procurement teams don't have a CLM problem. They have a foundation problem masquerading as one.

Fix the repository. Assign an owner. Build the process discipline. Integrate the workflow. Add an AI query layer. You'll cover 80% of what you thought you needed a platform for, and you'll know with clarity whether the remaining 20% justifies the investment.

The teams that skip the foundation and go straight to platform selection end up with expensive software sitting on top of a broken process. The foundation doesn't fix itself just because you bought a CLM. It just becomes a very costly way to have the same problem.

👀 In Case You Missed It…
The Last 3 Newsletters:

1/ Foundational Procurement System by Industry: ERP vs S2P Suite
2/ Coupa's Tonkean Acquisition. Game Changer or Smoke and Mirrors?
3/ The Day Nobody Came to Our eAuction

2 other ways we can help this week:

Why most procurement teams do not have a software problem. They have a clarity problem. In this conversation, our consulting principal breaks down why digital procurement still needs mentorship, how teams should think about the 600+ ProcureTech solutions on the market, and why the goal is not to buy more tools, but to build the right capabilities in the right order.
Watch the replay.
Get your team aligned on the basics. Download our free Procurement Function Overview poster. It’s a visual map of the entire procurement function on one page. Bonus: all of our content is built on this model, so it's the foundation for everything we publish. Teams that read together transform togethers.
Grab the free poster.

See you next week {{FIRST_NAME|readers}},

— The Pure Procurement Newsletter Team

P.S. Please rate today’s newsletter.
Your feedback shapes the content of this newsletter.

Foundational Procurement System by Industry: ERP vs S2P Suite

Joël Collin-Demers — Mon, 08 Jun 2026 01:07:08 +0000

A rchive | Upgrade to Premium | Sponsor

Hi {{FIRST_NAME|readers}},

It's conference season… And it’s been a wild few weeks in ProcureTech as every company tries to “one up” each other 😅

SAP rebranding as a Business AI company.
Coupa acquiring Tonkean (and Rossum, and Cirtuo).
Vertice acquiring Vendr.
Tropic and Omnea partnering up.
Zip dropping AI governance functionality in-platform.
Funding rounds across the board.
And I'm probably missing lots of things... 😅

If you're a procurement pro in the middle of a procurement technology decision right now, it probably feels like the ground is shifting beneath you. Like maybe you should just... wait.

I think that's the wrong call. And I'm happy to tell you exactly why.

This Wednesday, 12pm ET / 6pm CEST, I’ll be hosting a live AMA on Vertice’s WhatsApp community.

Bring your questions about any of the above, your architecture debates, your vendor shortlist, whatever's keeping you up at night. I'll be there answering questions via video for 60 mins for free.

Otherwise, in tonight’s note, we break down how to think about your procurement system decisions based on your industry.

Onwards!

📰 In this week’s edition:

📄 The Executive Introduction to AI Superagents (sponsored)
🌙 Foundational Procurement System by Industry: ERP vs S2P Suite
📢 This week’s “Must Reads”
📋 3 procurement jobs that caught our eye

Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.

One of the most consequential architecture decisions in procurement technology gets made for all the wrong reasons.

It's not made based on your business model. It's not made based on your operational complexity. It's made based on who shows up to the meeting with the better slide deck, your ERP vendor or your S2P suite vendor.

Most ProcureTech sales reps have never implemented the software they're selling. They understand features. They don't understand the operational nuance of what happens when those features have to coexist with your production planning cycle, your maintenance workflows, or your multi-entity finance structure.

And why would they? They're not measured on your operational complexity.

They're measured on the sale. Your team will spend years living with the consequences of a decision informed by someone who is on to their next deal before your go-live.

The right foundational procurement system for your organization is not a matter of taste. It follows from your industry. The moment you accept that, a huge percentage of your ProcureTech architecture debates resolve themselves.

Let me show you exactly how.

The Two Principles That Should Drive Every Architecture Decision

Before we get into the industry breakdown, I want to anchor this in two principles I use as a starting point for any procurement technology discussion.

Principle 1: Adoption drives data quality. Data quality enables automation. Automation is where the ROI lives.

You want people to actually use your systems. That means giving them the best possible user experience. An overly complex, fragmented system (one that asks users to toggle between multiple interfaces to complete a single task) is adoption poison. And without adoption, your data is garbage. And without clean data, your AI initiatives, your automation plays, your category analytics... all of it will falter.

Principle 2: Every data interface is a liability. Integration is where business transformation goes to die.

Every time data needs to cross a system boundary, you've introduced latency, error risk, reconciliation overhead, and a potential failure point. Point-to-point integrations are expensive to build, fragile to maintain, and painful to troubleshoot. The fewer of them you have, the better (yes, even with “out of the box” integrations).

Those two principles will keep you honest when vendor presentations start sounding too good to be true.

Your Industry Determines Your Foundation — Full Stop

The core question isn't "ERP vs. S2P suite." The core question is: what are the critical business functions that procurement must integrate with in your organization?

Because wherever those integrations are most complex, most frequent, and most consequential, that's where your foundational system needs to live.

Indirect-Only Industries: You Don't Need ERP as Your Core

If you're in insurance, banking, SaaS, professional services, media, or any other primarily indirect-spend environment, the story is relatively clean.

Your procurement process covers: requisitions, sourcing, contracts, purchase orders, goods/services receipts, and invoice processing. That's it. There's no production planning involved. No maintenance work orders. No inventory to manage. No MRP cycle to feed.

In this world, a modern end-to-end procurement platform, whether that's an S2P suite or an Intake & Orchestration-led architecture, can handle the entire procurement lifecycle natively. The meaningful integrations are limited to master data flowing in from your financial system (vendors, GL codes, cost centers, organizational hierarchy) and approved invoices flowing out for payment at the end of the lifecycle.

Two sources of integration points. Two boundaries. Two places for things to break.

That's not just acceptable, it's genuinely the right architecture.

Direct, MRO, and Mixed Industries: ERP Is Non-Negotiable as Your Foundation

Now change the scenario. You're in manufacturing, energy, utilities, telecommunications, mining, oil & gas, healthcare, or any other asset-heavy, operationally complex environment.

Suddenly, procurement isn't an island.

Your purchasing activity is entangled with:

Production planning and scheduling. Purchase orders must align with MRP runs and production windows
Maintenance and asset management. MRO purchases are triggered by work orders and maintenance plans
Inventory management. Incoming goods affect stock levels across multiple locations
Quality control. Goods receipt isn't just confirmation of delivery; it's the input to inspection workflows
Finance and cost accounting. Direct material costs roll up into product costing, COGS, project accounting, and work-in-progress accruals

These aren't adjacent workflows. They are the workflows. And they live in your ERP. They've always lived in your ERP. They will always live in an ERP-type, integrated system.

"But what if our ERP is ancient?"

Nothing above changes. The operational reality is the same whether you're on SAP S/4HANA or a 20-year-old on-premise system held together with custom code and goodwill. The integrations are still critical. The process dependencies are still real.

What does change is this: if your ERP is truly archaic, the most impactful thing you can do for procurement, and for the business, is modernize it. You don't build a house extension on concrete blocks because you're in a hurry. You pour a proper foundation first. Building the house anyway might feel like progress. But it will catch up with you. It always does.

The brutal truth: you will never fully extract procurement from that environment. The integration is too deep, too bidirectional, and too operationally critical. Trying to run your procurement foundation outside the ERP and then sync everything back in is architecturally expensive and operationally brittle.

Your ERP is your foundational system. Full stop. The conversation then becomes: where does the ERP fall short, and how do you augment it?

Two Scores That Tell the Whole Story

Here's a useful heuristic: count the interfaces. Then count the screens.

Most procurement technology debates optimize for one dimension and ignore the other. That's how you end up with an architecture that's technically elegant but operationally miserable, or one that's beautifully simple for end users but a maintenance nightmare underneath.

You need both scores.

Interface count is your IT and integration complexity score. It's a proxy for risk, cost, maintenance burden, and data quality degradation. Every system-to-system boundary is a place where data can drift, latency can creep in, and things can silently break.

User experience is your adoption score. What you're really optimizing for is how intuitive, frictionless, and complete the procurement workflow feels for the people who have to live in it every day. Screens and clicks are a useful proxy, fewer systems to touch, fewer steps to complete a transaction, less cognitive load, but don't reduce it to a number. Two clicks in a confusing interface is worse than five clicks in one that makes sense. Use your (and your super users') judgment.

The question to ask is simple: would a reasonably intelligent person be able to complete this workflow without training?

The goal is to minimize both… But unfortunately, the architecture that wins on interface count often loses on screen count, and vice versa. That tension is exactly what makes the industry segmentation so important, because the right tradeoff depends entirely on what your business does.

Let's run through four realistic scenarios and score them both.

Scenario 1: Indirect-Only Business Running Everything Through ERP

You're a financial services firm. Your IT team chose SAP or Oracle as the enterprise backbone. Procurement is getting pushed into ERP because "it's already there."

Here's what your interface map looks like:

Internal interfaces:

ERP ↔ HR/Identity/SSO (for user provisioning and org hierarchy)
ERP ↔ Expense management tool (if separate)

Process gaps that create shadow systems or workarounds:

ERP ↔ Email/Outlook (for supplier communication, because ERP sourcing UX is terrible)
ERP ↔ Excel (for sourcing events, bid tabulations, and contract tracking, because users won't use ERP for this)
ERP ↔ SharePoint or shared drives (for contract storage, because nobody can find anything in ERP)
ERP ↔ E-signature tool (if you've got one)

The uncomfortable reality: The "one system" story only holds if your users actually use the system for everything. In indirect-only environments, ERP procurement UX is rarely good enough to achieve strong adoption. So you end up with an ERP plus a sprawl of shadow tools. The interfaces are just informal ones, which are actually worse, because nobody manages them.

Apparent interface count:

2 formal
Real interface count (including shadow systems): 6–8

UX / screen count:

High, users bounce between ERP, email, Excel, and SharePoint to complete a single transaction. Nobody calls that a good experience.

Scenario 2: Indirect-Only Business on an E2E Procurement Platform

Same financial services firm. Different decision: deploy a modern S2P suite or an Intake & Orchestration platform as the procurement backbone.

Formal interfaces:

Procurement platform ↔ ERP/Financial system
- Master data in: vendor master, Plants, companies, GL codes, cost centers, org hierarchy, etc.
- Transactional data out: approved invoices for payment
Procurement platform ↔ HR/Identity/SSO (user provisioning and org data)
Procurement platform ↔ E-signature tool (often native or embedded)
Procurement platform ↔ Banking/payment rails (if the platform handles supplier payments and you're not doing this from the financial system)

What you don't need:

Separate contract repository (native in platform)
Separate sourcing tool (native in platform)
Separate supplier portal (native in platform)
Separate intake/request management (native in platform)

Interface count:

3–4 formal, minimal shadow system pressure.

UX / screen count:

Low, one system, purpose-built for procurement workflows. Users live in a single environment from request to payment.

And critically, the user experience is designed for procurement. The UX is built around the workflows your team actually runs. Adoption is meaningfully higher. Which means your data is meaningfully better.

This is the correct architecture for indirect-only businesses. If you're running everything through ERP here, you're making your life harder than it needs to be.

Scenario 3: Direct + Indirect Business with ERP as Foundation

Now you're a discrete manufacturer. SAP S/4HANA is your operational backbone. Production, maintenance, inventory, quality… They’re all in ERP. Your procurement team covers direct materials, MRO, and indirect.

Formal interfaces:

ERP ↔ Supplier Experience/Adoption Layer (collaboration on forecasts, quotes, order confirmations, shipping notices, quality issues, etc.)
ERP ↔ E-signature tool (for contract execution)
ERP ↔ Contract lifecycle management (if not using native SAP CLM)
ERP ↔ Spend analytics tool (if not using native BI)
ERP ↔ Sourcing optimization tool (if needed for complex direct sourcing)
ERP ↔ Catalog management platform (for managed content, punchout, and catalog governance)

*Ideally, accesses are managed centrally so SSO/Identity management is done for centrally for each system above.

What you keep native in ERP (no interface required):

PR/PO processing for direct and MRO
Goods receipt and inventory movements
Work order-to-PO linkage (maintenance)
MRP-driven purchasing proposals
Supplier invoice processing (LIV)
Product costing and COGS

Interface count:

10+ formal interfaces, assuming P2P stays in the ERP (scenario #4 explains why…)

UX / screen count:

Medium, ERP UX is rarely beautiful (especially in the leading ones), but augmentation at the edges (better sourcing UI, contract portal, supplier collaboration) meaningfully reduces friction for the workflows where it matters most.

Here's the key insight: the most operationally critical Procure-to-Pay flows require zero interfaces to work because they're native in ERP. The supplier adoption layer and the other augmentation tools enhance the existing process, they don't create a parallel one. That's a fundamentally different integration posture than Scenario 4.

That's a sustainable architecture. The ERP is your single system of record for everything that matters operationally. Everything else augments the edges.

What about a multi-ERP environment? This still holds. You just have the added complexity of needing to support different data models and train staff on different P2P processes and user interfaces across each ERP instance, based on their business unit.

It's not elegant, but the architectural principle is the same. Your ERPs are still your foundation. The integration surface grows with each instance, but it doesn't fundamentally change which system should be running the show.

Scenario 4: Direct + Indirect Business on E2E Procurement Platform Integrated to ERP

Same manufacturer. Different decision: deploy an S2P suite as the "procurement system," with ERP handling everything else.

Now let's count what needs to talk to what:

Formal interfaces — transactional:

ERP ↔ S2P suite: Purchase requisitions (inbound to S2P from ERP)
S2P suite ↔ ERP: Approved POs (must land in ERP for inventory and accounting)
S2P suite ↔ ERP: Order confirmations (planning needs up-to-date delivery dates, and that data lives in ERP)
S2P suite ↔ ERP: Goods receipt confirmations (inventory movements happen in ERP)
S2P suite ↔ ERP: Invoice match replication (payment in ERP still needs 3-way match information from S2P)
ERP ↔ S2P suite: Material master and item data (catalog items, UOM, costing)
- If you’re going to try to match catalog items to SKUs…
S2P suite ↔ ERP: Vendor master (supplier data must be consistent across both)
S2P suite ↔ ERP: Work order data (MRO purchases need maintenance context)
S2P suite ↔ ERP: Inventory levels (affects purchasing decisions for stocked items if also available in catalogs)
S2P suite ↔ ERP: Cost centers, GL accounts, and project codes (for PO accounting)

Formal interfaces — supporting:

S2P suite ↔ HR/Identity/SSO
S2P suite ↔ E-signature tool
S2P suite ↔ ERP analytics/BI (or does S2P have its own? Now you have two sources of truth for spend data)

Interface count:

15+ formal integrations

UX / screen count:

Low on paper, High in practice. Yes, users work in a modern S2P interface. But the moment something breaks at an integration boundary, a PO that didn't land in ERP, a GR that didn't trigger invoice matching, they're in a support ticket, not a workflow. The UX score collapses the moment the integrations start misbehaving. And they will.
And here's the kicker: most of these are bidirectional. Data doesn't just flow one way. A purchase order approved in S2P needs to exist in ERP. A goods receipt posted in ERP needs to trigger invoice processing in S2P. A work order created in ERP needs to trigger a purchase requisition in S2P.

Every one of those is a reconciliation risk. Every one is a latency problem. Every one is a failure point.

You haven't simplified your procurement architecture. You've built a distributed system with 10+ integration points, and you're responsible for keeping them synchronized.

That's not a procurement technology strategy. That's an integration nightmare masquerading as a dream that prevents you from having to look at foundational ERP problems... (sorry 😬)

What about a multi-ERP environment? It gets worse. The whole premise of this architecture is that you're centralizing P2P processes in the S2P suite to create consistency and simplicity…

But in a multi-ERP landscape, you're not centralizing anything, you're multiplying interfaces. Every ERP instance needs its own set of transactional integrations. Different data models, different reconciliation logic, different failure modes. You've taken the most complex scenario and made it combinatorially harder.

So What Does This Actually Tell You?

Let me put the four scenarios side by side:

Scenario	Industry Type	Foundation	Interface Count	UX / Screen Count	Verdict
1	Indirect Only	ERP	Low (2 formal; real 6-8)	High, ERP UX forces workarounds	❌ Shadow systems fill the gaps
2	Indirect Only	E2E Platform	Low (3–4)	Low, purpose-built UX, one system	✅ Recommended
3	Direct + Indirect	ERP	High (10+)	Medium, ERP UX augmented at the edges	✅ Recommended
4	Direct + Indirect	E2E Platform	Very High (15+)	Low, but at enormous integration cost	❌ Integration risk outweighs UX gain

The pattern is clear.

For indirect-only businesses: a modern E2E procurement platform should be your foundation. Your ERP is your financial system, not your procurement system. Approve the invoice there. Do everything else in the tool built for procurement.

For direct, MRO, and mixed businesses: your ERP is your foundation because it's already the operational system of record for everything procurement touches. Augment it where the UX or functionality falls short, better sourcing tools, contract management, supplier collaboration, but keep the transactional core in ERP.

The goal is always the same: minimize interfaces, maximize adoption, protect data quality. The path to get there just looks different depending on what your business actually does.

Of course, there are always exceptions… Adapt to your situation as needed… This article aims to give you a framework for thinking about this solution architecture problem based on your industry.

If you want the detailed functional requirements that each of these system types needs to cover, regardless of which architecture you land on, our Master P2P Functional Requirements List breaks it down across 19 sections, including direct and MRO extensions.

Requirements don't change based on your foundation. What changes is which system is responsible for meeting them.

👀 In Case You Missed It…
The Last 3 Newsletters:

1/ Coupa's Tonkean Acquisition. Game Changer or Smoke and Mirrors?
2/ The Day Nobody Came to Our eAuction
3/ P2P Requirements for Manufacturers, Distributors, and MRO-Heavy Operations

2 other ways we can help this week:

Get more from your SAP investment. AI-powered intake and orchestration can help close the gap between what your ERP can do and what your process actually needs. This ebook, developed with Tonkean, looks at how to reduce manual work, streamline P2P flows, and create better coordination across your procurement tech stack.

Grab it here.
Need a cleaner way to get buy-in? A roadmap only works if people outside procurement can actually understand it. This template helps you turn a complex ProcureTech plan into a one-page story executives, IT partners, and stakeholders can follow without getting lost in the weeds.

Grab it here.

See you next week {{FIRST_NAME|readers}},

— The Pure Procurement Newsletter Team

P.S. Please rate today’s newsletter.
Your feedback shapes the content of this newsletter.

Coupa's Tonkean Acquisition. Game Changer or Smoke and Mirrors?

Joël Collin-Demers — Mon, 01 Jun 2026 01:39:12 +0000

A rchive | Upgrade to Premium | Sponsor

Hi {{FIRST_NAME|readers}},

The acquisition press release dropped on a Thursday.

By Friday, the LinkedIn posts were already calling it a "game changer."

Nobody had seen the combined product yet. Nobody had asked about the new org chart. Nobody had talked to a single customer running both tools in production.

That's the thing about ProcureTech press releases. They're written like endings. "We're thrilled to announce..." "This positions us to..." "Together, we will..."

It's the same energy as a Go-Live celebration. Cake in the break room. A VP giving a speech. A team photo for the internal newsletter.

And then Monday morning hits. The approvals are routing to the wrong people. The data isn't flowing. Finance is asking why the new tool doesn't match what they saw in the demo.

That's because your Go-Live isn't the ending. It's the beginning. The real work starts the next day. Anyone who’s gone through this feels it in their soul…

Press releases work the same way. They announce the intention. What follows is what matters.

That’s why we don’t usually cover them here…

BUT a big one dropped this week… And we have questions… (If only for the teaching moment)

Onwards!

📰 In this week’s edition:

📄 Source-to-Pay Process: A Practical Guide for Enterprise Indirect Procurement Teams (sponsored)
🌙 Coupa's Tonkean Acquisition. Game Changer or Smoke and Mirrors
📢 This week’s “Must Reads”
📋 3 procurement jobs that caught our eye

Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.

Coupa's Tonkean Acquisition. Game Changer or Smoke and Mirrors?

Three years ago, I compared buying a Source-to-Pay system to buying an old, renovated house (list of all acquisitions for 5 top Source-to-Pay Suites).

The house looks great during the tour (demo). New kitchen. Fresh paint. Open-concept living room.

But behind the walls? Load-bearing structures from previous owners. Plumbing that was "good enough" at the time. An extension that doesn't quite connect to the original foundation.

You don't find this stuff during the open house. You find it six months after you've moved in, when you try to renovate the bathroom and discover that the pipes run through a wall you can't touch.

I bring this up because Coupa just added 4 new impressive wings to their house (or maybe they’re just going to be sheds..? Let’s wait and see).

And they've been busy renovating over the years...

The acquisition timeline:

Pre-IPO (2006-2016):

1 → Xpenser: Expense management

2 → ZenPurchase: Procurement collaboration

3 → TripScanner (2015): T&E

4 → InvoiceSmash (2015): Invoice digitization

Post-IPO (2016-2022):

5 → Contractually (2016): Contract collaboration

6 → Spend360 (2017): AI spend classification

7 → Riskopy (2017): Supplier risk

8 → Deep Relevance (2017): AI fraud detection

9 → Trade Extensions (2017): Sourcing optimization

10 → Simeno (2017): Catalog search & management

11 → DCR Workforce (2018): Contingent workforce / VMS

12 → Acquiire (2018): Real-time catalog search

13 → Hiperos (2018): Third-party Risk Management

14 → Exari (2019): CLM

15 → Yapta (2020): Travel rebooking

16 → Executive Travel App (2020): Corp Travel Tech

17 → ConnXus (2020): Supplier diversity

18 → BELLIN (2020): Treasury management

19 → LLamasoft (2020): Supply chain design

20 → Pana (2021): Travel booking

Post-Thoma Bravo acquisition (2023-present):

21 → Cirtuo (2025): AI-powered category management

22→ Scoutbee (late 2025): AI supplier discovery

23 → Rossum (May 12, 2026): Intelligent document processing

24 → Tonkean (May 21, 2026): Agentic intake & orchestration

That's 24 acquisitions over 20 years (If I didn't miss any...). This is a house that has been renovated many, many times.

But the last four are worth singling out. Four acquisitions in roughly 18 months, each one addressing a genuine gap in Coupa's platform.

On paper, it's a masterclass in strategic M&A. Coupa now has category intelligence, supplier discovery, document processing, and workflow orchestration layered on top of their core S2P network.

And the Tonkean piece, specifically, makes a lot of sense. Tonkean brings 250+ native connectors (a slew of which are already for Coupa), a no-code workflow builder, multi-agent orchestration, and (critically) experience beyond pure procurement (pun intended) in legal, HR, IT, and finance.

Coupa's own intake & orchestration product, launched just last year, was improving fast but still catching up to best-of-breed competitors (I'm guessing it’s never going to be mentioned ever again after this acquisition 😅).

This deal should accelerate the modernization timeline significantly.

So yes, these last 4 acquisitions are a big deal for Coupa's competitive positioning.

Here's the irony, though.

Coupa now has the exact same problem you have if you're running multiple systems in your own enterprise ProcureTech stack.

A sourcing tool that doesn't talk to your CLM. A spend cube that lives on a different planet from your P2P suite. An SRM tool that has never heard of your ERP. And if you have multiple ERPs? You know this hell intimately.

None of them are written on the same code base. You spend half your time being the human integration layer between tools that were each sold to you as "the platform."

The only difference? Coupa's core business is making sense of messes like this. And they also, just like leading procurement teams, have acquired Intake & Orchestration capabilities to help “connect the tubes” 😅 So, if anyone can pull off these integrations, they are certainly a contender...

The question is whether being a contender turns into "actually pulled it off."

Given Tonkean’s “raison d’être” is integration/orchestration between different systems, is it going to be the glue that's supposed to pull the above pieces together? Does this mean it should be more of a Tonkean + Coupa situation than Coupa + Tonkean?

(Tonkean the hub, all other Coupa apps the spokes?)

Given the press release is full of terms like “native integration”, “unified” & “united”, one would imagine so…

Everyone's talking about what Coupa + Tonkean means for the ProcureTech market.

Nobody's asking what it means for you, the buyer…

I've watched a horror movie with a similar beginning in the past...

SAP bought Ariba in 2012. Made sense on paper. Augment ERP procurement processes with a best-of-breed procurement suite and business network. I was excited for the possibilities.

Six, seven years later, Ariba was still a separate org and a separate product, just sold via the same website... Integration to SAP ERP remained harder than catching a greased watermelon in a swimming pool... while blindfolded. 😅

(And I, a competent ProcureTech implementer, almost burned out trying to make the marketing work in real life.)

13 years later, SAP announced they were rewriting Ariba from scratch.

(And Ariba only had 13 acquisitions when SAP acquired it…)

That experience shaped a rule I now apply to every major ProcureTech acquisition:

The questions tech-savvy procurement pros should be asking:

So, if you're a Coupa customer (considering becoming one), here's the list of questions I'd bring to your next conversation with your account team to validate this isn’t a cheap horror movie reboot… 😱

The answers will tell you if you're really getting any "synergies" from this new combined organization (I love a good synergy, don't you? 😅).

Sales & Go-to-Market:

→ How are Coupa and acquired sales teams going to market together? Integrated, unified, or will you now just have a Coupa rep sitting in on all the Tonkean, Rossum & Cirtuo calls, adding bodies, noise and complexity to the conversation?

→ How are sales incentives being drawn up? In the best interest of customers, or according to solution business units?

Delivery & Support:

→ How are delivery and customer success teams being cross-trained on each other's solutions to provide 1 seamless experience (given that's the undertone of all this M&A activity)?

→ What does the implementation methodology look like for the combined products? Is it one methodology or multiple methodologies stitched together?

→ Are Coupa's SI partners going to be trained on these new products/modules? Or do we need to add 3+ new specialized functional analysts to every end-to-end delivery project?

Product & Roadmap:

→ How are product teams being integrated to build one INTEGRATED roadmap, not two (or five)?

→ How is the org structure changing to ensure common objectives, language and culture between what used to be separate organizations?

→ How will data models, workflows, and process ownership actually be unified across tools/platforms? (Because in ProcureTech, integration challenges are almost never about features. They're about data models, operating models, user experience and adoption.)

Tonkean has its own data model (albeit a flexible one). Coupa has its own data model. Cirtuo, Scoutbee, and Rossum each have theirs. Getting five sets of data structures to behave as one coherent platform is not a press release problem. It's an engineering problem that can take years to solve well (if at all).

(It’s also why I ask if viewing it as Coupa on top of Tonkean instead of Tonkean on top of Coupa makes more sense?)

Why the System Integrator questions matter more than you think

Those delivery & support questions are important…

Most analysis is viewing this M&A activity through a functionality/capability lens… I think the more important question is “How is this ‘new Coupa’ (and its ecosystem) going to deliver client benefits at scale?”

Traditionally, Coupa has mostly outsourced implementation to solution integrators (SIs). These SIs have built big consulting practices around Coupa. Coupa's position has long been "we don't want to be in the consulting business." (Fair enough, that’s the position of most software providers...) But that means the people designing your processes, configuring your workflows, and managing your change aren't Coupa employees.

The newer I&O-first players took advantage of this (Zip, Focal Point, Pivot, Vertice, ORO Labs, Tonkean, etc.)… They largely implement directly with clients. They have “Forward Deployed Engineer” roles in-house. SI partnerships are starting to develop for business analysis and configuration work as they scale, but nothing like the heavy functional and development consulting work that characterizes a typical Coupa (or “old guard” S2P Suite) implementation.

So, what happens now? Are existing Coupa SIs going to be trained on Tonkean's orchestration platform? On Rossum? On Cirtuo and ScoutBee? Is Coupa going to be doing solution architecture in-house more seriously? Will Tonkean's implementation teams be spun-off into Coupa's partner model? Or will there be a gap where nobody fully owns the end-to-end experience?

I’m sure the answer is going to be “a unified, ONE Coupa approach”, by the way…

But in a world with unlimited distractions, simplicity and focus are at a premium. And these 4 acquisitions have created a huge, complex set of questions that need concrete answers (and aligned action) before this vision can become reality.

The bigger point (and this applies to every ProcureTech decision, not just Coupa)

Once your "functionality bar" has been cleared when sourcing ProcureTech, you should be almost disinterested in solution capabilities...

I know that sounds counterintuitive. But hear me out.

At a certain point, features become table stakes. Every serious vendor clears the bar. The demo looks great. The roadmap slide is inspiring. The competitive matrix has green checkmarks everywhere you want them.

After that, the ONLY thing that matters is the vendor's ability to deliver the business outcomes you're actually looking for. And that ability comes from the business capabilities you develop when/while implementing their tools. Not the tools themselves.

If you’ve got a Ferrari in the garage but never learned how to drive, you won’t be impressing anyone (And, no, I don’t care if it’s an AI-enabled Ferrari 😅)

Ability to deliver has two components:

→ A technology component (consistently overrated). The platform, the connectors, the AI, the dashboards.

→ A domain-specific implementation component (consistently underrated). The people. The change management. The process redesign. The organizational readiness.

These two components are linked together by the processes you design, implement and support *with* the tools. That's where value is created. Not in the feature list.

So, when you see a headline like "Coupa acquires Tonkean," don't just ask "what new features does this give me?" Ask "does this combined organization have the people, the methodology, and the implementation depth to help me build the business capabilities I need, in context, without needing a PhD to navigate their organization and license structure?"

“Who gets me to business results on the shortest, straight(-ish) line?”

Don't get tickets to the functionality circus. You'll be entertained by the ROI illusionist. Popcorn will be available. But you won't have learned how to juggle anything…

Juggling is the core skill you need to be successful.

Juggling school with a proven juggling instructor is a better investment (bonus if they provide the equipment!) 😅

What this means for the broader market

Our thinking on implications:

For existing Coupa customers: You now have a much stronger intake & orchestration story with your existing vendor. That's genuinely good news for your internal discussions. But, you’ll still need to push hard on the integration timeline (yes for product, but mostly for org structure!). Don't assume "acquired" means "integrated."

For organizations evaluating I&O solutions: Coupa just became a more serious contender, but the combined product (Coupa + Tonkean) works just as it did yesterday. And unless Coupa starts shutting other partners out, all the other solutions have their Coupa connectors as well… If you need something production-ready today, ask to see it working, not just demoed (yes, even if they are throwing in Tonkean for free!).

Free can turn out to be quite expensive…

For other S2P suites: The pressure just increased. They now face a Coupa with (on paper) best-of-breed orchestration capabilities layered into their suite. Perhaps we see more acquisition activity from competitors trying to keep pace in months to come? I’ll leave those predictions up to the real analysts…

For best-of-breed I&O vendors (Zip, Focal Point, Pivot, Vertice, ORO Labs, etc.): Selling against the Coupa + Tonkean combination is a new challenge, but the "we're already an integrated platform, they're still assembling" argument is a strong counter for the next 12-24 months while answers find the hard questions.

The 1 product with 0 acquisitions narrative surely stays compelling as well.

For the orchestration market more broadly: Further consolidation is surely coming unless the different players can find strong, durable differentiators providing a competitive advantage, if only for a slice of the total addressable market (TAM)…

The bottom line

Congratulations to all teams involved. These are smart deals on paper.

But the real work starts now.

(Just like the real work of digital procurement starts AFTER your Go-Live.) 😊

The coming months will reveal whether “unified, united and integrated” go from press release to practice. I sure hope they do.

Until the dust settles, getting strong answers (and proof!) to the questions above is required for diligent ProcureTech buyers who want the actual business outcomes they are looking for...

In the meantime, this is just another press release…

Disclosure: Zip, Pivot, Vertice, Focal Point, and ORO Labs are Pure Procurement content partners. Tonkean has been a content partner in the past. This piece represents our independent editorial perspective.

👀 In Case You Missed It…
The Last 3 Newsletters:

1/ The Day Nobody Came to Our eAuction
2/ P2P Requirements for Manufacturers, Distributors, and MRO-Heavy Operations
3/ The Master Procure-to-Pay (P2P) Functional Requirements List for Indirect Purchasing

2 other ways we can help this week:

Stop comparing apples to oranges. Most ProcureTech evaluations break down early because teams compare suites, point solutions, and hybrids as if they solve the same problem. This framework gives you a sharper way to read the market, structure your thinking, and build a technology stack around fit, integration, and business outcomes instead of vendor noise.

Grab it here.
Make your implementation more likely to succeed. Procurement system rollouts rarely fail because of the software alone. They fail when the fundamentals get missed. This quick-reference poster highlights the success factors that matter most, from data quality and governance to team setup and change management, so your project stays focused on what actually drives results.

Grab it here.

See you next week {{FIRST_NAME|readers}},

— The Pure Procurement Newsletter Team

P.S. Please rate today’s newsletter.
Your feedback shapes the content of this newsletter.

The Day Nobody Came to Our eAuction

Joël Collin-Demers — Mon, 25 May 2026 00:00:00 +0000

A rchive | Upgrade to Premium | Sponsor

Hi {{FIRST_NAME|readers}},

This week's piece on lessons learned from eAuctions comes from Laura Damian, a procurement and business transformation leader with 20+ years of international experience across FMCG, pharma, and fashion.

Based in Barcelona, Laura is the Indirect Procurement Manager at Desigual, where she also serves as Innovation & AI Ambassador, identifying automation opportunities and supporting digital agent development across the procurement function.

I've run a few eAuctions over the years myself, and they are a legitimate sourcing tool worth having in your toolbelt. The technical setup is honestly easier than most people expect.

However, where things get tricky is everything around the auction:

The supplier relationships,
The category fit,
The market conditions,
and knowing when a competitive bidding format will create value versus when it will destroy trust.

That's exactly what Laura digs into tonight.

She shares a story from early in her career about a reverse auction that went sideways, and uses it as a launching point to challenge how to think critically about eSourcing tools.

If you’ve ever wondered about the double-edged sword that is eAuctions, tonight’s piece is for you.

Onwards!

P.S. Yes, fishing was amazing. Thanks for asking.

📰 In this week’s edition:

📄 Procurement Architecture before AI Agents (sponsored)
🌙 The Day Nobody Came to Our eAuction
📢 This week’s “Must Reads”
📋 3 procurement jobs that caught our eye

Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.

The Day Nobody Came to Our Auction (And What It Taught Me About E-Sourcing Tools)

Picture this: a procurement team, a carefully configured reverse auction platform, and a strategic raw material contract on the line. Launch day arrives. The clock ticks. And nobody shows up.

That actually happened to me early in my career. We had set up a reverse auction for our annual MSG contract (monosodium glutamate), a strategic raw material sourced from a Japanese supplier we had worked with for years. The platform was configured, the invitations sent. And our suppliers simply chose not to participate. No bids. No result. Just weeks of work to repair a relationship we had quietly damaged by treating a long-term partner like an interchangeable vendor. It was an expensive lesson… Not in money, but in culture and trust.

That experience stuck with me. Not because it was dramatic, but because it was entirely avoidable.

What These Platforms Actually Sell

Online negotiation platforms offer a standard set of features: category-based sourcing, RFQ templates, selection criteria frameworks, award workflows, and document storage. Useful on paper. But the real mechanic behind e-auctions is psychological pressure. Suppliers compete against each other in real time, watching prices drop, with the implicit message that the lowest number wins.

That works in a narrow set of conditions: true commodities, standardised specs, liquid markets with multiple qualified suppliers. Public procurement also has a legitimate case, where transparency and auditability are regulatory requirements.

Outside those conditions, the logic breaks down quickly.

The Price You Don't See on the Screen

Back around 2010, I observed a logistics auction with an auto-extension rule… Every last-minute bid reset the clock by five minutes. The price kept dropping. At some point it became obvious that no credible carrier could deliver at those rates. We stopped the auction manually.

The savings that look good in a report have a way of showing up later as
service failures, quality issues, or suppliers who quietly deprioritise your
account. eAuction metrics capture the price. They rarely capture what comes after.

Rigid Tools for Complex Realities

For anything beyond a true commodity (which in indirect procurement is most things), rigid tender formats create their own problems. Fixed criteria and locked structures force both sides into a framework that doesn't reflect how markets actually work.

Effective negotiation requires flexibility: the ability to adjust variables as you learn what the market can offer, to factor in elements that don't fit a dropdown menu, to understand what matters to a supplier beyond price. That's not subjective… It's information. A buyer who ignores the human dimension of a negotiation isn't being more objective. They're just working with less data.

Why Classic Platforms Are Losing Their Case

The procurement tech landscape has changed dramatically… And that's exactly the point. The argument here is not against technology. It's against rigid, legacy negotiation platforms that haven't evolved with the market.

Today, AI and digital agents are making global sourcing genuinely accessible. You can scan international supplier markets in hours, analyse fifty-page proposals with different structures and formats without forcing every supplier into an identical template, and run scenario modelling that would have taken a team weeks.

Documents and contracts live in SharePoint, Teams, or any collaborative tool your organization already uses, not locked inside a proprietary platform that charges per sourcing event.

There are exceptions worth acknowledging. In my current company, the
logistics department runs a dynamic auction system where carriers bid
continuously for individual loads (not annual contracts, but spot assignments based on real-time availability and pricing).

Multiple providers work in parallel, competing on each transaction. That model makes sense: the category is transactional by nature, the market is liquid, and the system creates genuine efficiency without pretending to build a strategic relationship. That's the difference. It's not about the technology… It's about knowing what you're actually buying.

What Actually Drives Good Outcomes

Technology has a clear role in procurement. It should reduce administrative load, accelerate research, and improve analysis. What it shouldn't do is replace the conversations where real value gets created.

The best commercial outcomes I've seen came from negotiations where both sides had room to move, where the buyer understood the supplier's constraints, and where the relationship was strong enough to have an honest conversation about risk, quality, and price together. No platform replicates that. And no auction captures the value of a supplier who trusts you enough to bring their best ideas to the table.

In procurement, technology should be a bridge between people… Not a
substitute for them.

So here are my eSourcing key takeaways:

eAuctions put suppliers under pressure and damage the long-term relationships that drive real value
They are a valid tool in specific, limited contexts, not a default sourcing strategy
Dynamic auction models work well for transactional, spot-based categories… The key to using eAuction effectively is knowing the difference
Rigid tender formats reduce the commercial intelligence a buyer brings to complex negotiations
AI and flexible, adaptive digital sourcing tools are making classic legacy platforms increasingly redundant
Technology should support procurement conversations, not substitute for them

👀 In Case You Missed It…
The Last 3 Newsletters:

1/ P2P Requirements for Manufacturers, Distributors, and MRO-Heavy Operations
2/ The Master Procure-to-Pay (P2P) Functional Requirements List for Indirect Purchasing
3/ ProcureTech Unpacked Conference Summary

2 other ways we can help this week:

Want to cut through the AI noise? Most vendors say they “use AI.” Very few tell you which type, where it fits, or what it should actually do in procurement. This free poster helps you sort signal from spin by breaking down the AI subdomains that matter, where they apply, and where they don’t.

Grab the free poster.
A Skeptic’s Take on AI in Procurement. Our consulting principal recently took the stage at Zip Forward: LLM market overview, vendor motivations, and a framework to chart your own path… Without the hype.

Watch the replay.

See you next week {{FIRST_NAME|readers}},

— The Pure Procurement Newsletter Team

P.S. Please rate today’s newsletter.
Your feedback shapes the content of this newsletter.

P2P Requirements for Manufacturers, Distributors, and MRO-Heavy Operations

Joël Collin-Demers — Mon, 18 May 2026 00:00:00 +0000

A rchive | Upgrade to Premium | Sponsor

Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.

Who Needs Direct & MRO Requirements (And Who Doesn …
A Quick Note on Writing Good Functional Requiremen …
How to Use This List
One System or Two? The Architecture Question
The Direct & MRO P2P Requirements
What This List Tells You About Vendor Fit
A Word on Completeness

If you run a manufacturing plant, a distribution operation, a hospital, a mine, a utility, or any business that holds inventory and buys direct materials, here's a problem you've probably already hit: the standard procure-to-pay functional requirements lists don't fit you.

They're usually written for “indirect-only” buyers: organizations that buy office supplies, software, consulting, and facilities services. Buy it, receive it, expense it, done. Those lists cover catalogs, requisitions, approvals, and invoice matching competently. And then the moment your buying involves a material master, an MRP run, a lot-controlled storeroom, or a scheduling agreement, they go quiet. The requirements that govern how you actually buy simply aren't there.

This article is the missing piece. It's a functional requirements list for direct and MRO procurement: the capabilities your P2P platform needs when inventory, MRP, and material masters are part of how you buy. You can use it to build or pressure-test an RFP, to evaluate whether a platform on your shortlist can genuinely handle your operation, or to figure out why the "modern" indirect-focused suite someone recommended keeps falling short in your environment.

Who Needs Direct & MRO Requirements (And Who Doesn't)

The dividing line between an “indirect-only” P2P buyer and a “direct + MRO buyer” is concrete, not a matter of industry labels. You need the requirements in this article if any one of the following is true for any portion of your spend:

You hold goods in inventory and need to manage on-hand stock levels (storage locations, bins, lots, batches, serial numbers).
You run MRP (or any equivalent replenishment-planning logic) that automatically generates purchase requisitions from forecast or production demand.
You maintain item master records (material masters) that govern how a SKU is bought, stored, costed, and consumed across business processes.

If none of those apply (i.e. if every purchase is buy-it, receive-it, expense-it with no inventory record and no material master), you're an “indirect-only” buyer, and the core P2P requirements list is all you need.

This isn't an industry question, it's a process question.

A SaaS company with a single bonded warehouse for branded merch is still “indirect-only”.
A consulting firm that runs a parts inventory for its rental laptop fleet is (surprise!) partially direct.
A facilities operations team running a CMMS-linked storeroom for spare parts is direct, even if the parent company thinks of itself as "indirect-only."

A note on MRO specifically: if your MRO spend is purely transactional (someone needs a replacement light bulb, no inventory record, no material master), it's indirect, or handled by the core list. If your MRO spend runs through a CMMS-linked storeroom with on-hand inventory, item masters, and replenishment rules, it's direct, and the requirements in this article apply.

A Quick Note on Writing Good Functional Requirements

Every requirement in this article is written to be Specific, Testable, Unambiguous, Implementation-agnostic, and Atomic. These are five tests that separate a requirement a vendor can be held to from a vague aspiration a vendor can wiggle out of. "The system shall support lot tracking" is not a usable requirement. "The system shall capture lot or batch numbers at goods receipt for items flagged as lot-controlled" is.

If you want the full framework for writing requirements that survive contact with a vendor sales team (and the argument for why a great list scored against badly-written requirements is worse than no list at all), the companion article covers it in detail. It's worth the ten minutes before you build your RFP.

How to Use This List

Three rules of engagement:

These requirements are an extension, not a standalone RFP. If you're scoping a full P2P selection, combine the requirements below with the core P2P requirements list. Don't cherry-pick individual items from this article… The direct and MRO requirements are interdependent, and a platform that does three of five sections well will still leave you maintaining a parallel process for the rest.
Score these as strictly as anything else. Treat them as Must-haves, not "phase 2" wish list items. The moment you have a material master, an MRP run, or an inventory storeroom in scope, these capabilities determine whether your P2P platform actually works for your business… Or whether you'll quietly maintain a parallel ERP-based process to handle "the real spend." The whole point of a Procure-to-Pay system is to avoid that fragmentation.
Score by demo, not by self-assessment. Vendors will have a tendency to check "Yes" on everything (An RFP is a prisoner’s dilemma after all...). The only meaningful evaluation is watching them perform the requirement live, against a scripted scenario that includes at least one inventory-controlled item with lot capture, one MRP-generated requisition, and one consignment receipt.

One System or Two? The Architecture Question

Before the list, an architecture question worth settling early, because it shapes how you'll use everything below: should direct and indirect procurement run on the same P2P platform, or two separate ones?

Most teams that buy both direct and indirect default to assuming they need two systems (one for "the manufacturing side" running through the ERP, one for "the indirect side" running through a separate procurement suite).

For most organizations, that's a poor architecture choice made on autopilot. The whole point of a P2P platform is consolidation: one supplier record, one invoice intake, one spend cube, one AP team. Split it by goods type without a deliberate reason and you reintroduce every fragmentation problem the platform was supposed to solve.

There are legitimate exceptions (i.e. structurally separate business entities, durable functional separation between operations and finance, genuine strategic divergence in capability needs, or two systems inherited through M&A).

The companion article walks through each in detail. But for most direct + indirect buyers, the right goal is a single P2P platform that handles all your buying, even if it means accepting trade-offs in how each spend type is supported. The requirements below describe additional capabilities your single P2P system must have… Not the spec for a separate platform.

The Direct & MRO P2P Requirements

1. Material Master Integration

The system shall consume item master records from the ERP system of record (or maintain its own item master with documented synchronization to the ERP).
The system shall consume item-supplier relationships (info records, source lists), including preferred supplier, manufacturer part number, supplier part number, and minimum order quantity by source (or maintain its own with documented synchronization to the ERP).
The system shall support manufacturer part number cross-referencing across multiple approved sources, allowing buyers to search and order by manufacturer part number when the same physical part is supplied by different distributors using different supplier part numbers, with the appropriate supplier selected at PO time.
The system shall consume and expose direct-relevant item classification and commodity coding attributes (engineering category, ABC classification, planning strategy, MRP type, valuation class, and equivalent fields) to drive downstream rule-driven behavior for requisitioning, sourcing, planning, and accounting.
The system shall consume and expose bill of materials (BOM) relationships from the ERP, PLM, or MRP system to support requisitioning scenarios that reference parent items or finished goods, without acting as the system of record for BOM maintenance.
The system shall enforce item lifecycle status (active, blocked, obsolete, phase-out) and prevent or warn on requisitioning of non-active items.
The system shall support unit of measure conversions between purchasing UoM, stocking UoM, and consumption UoM, and apply them consistently across requisition, PO, receipt, and invoice.
The system shall support multiple manufacturer-approved-vendor relationships per item, including approved manufacturer lists (AML) for regulated industries.
The system shall manage production part approval (PPAP) document status per item-supplier combination, blocking active sourcing where PPAP is expired or not yet approved.
(For everything else, there’s Master Data Management solutions!)

2. Inventory-Aware Requisitioning & Receipt

The system shall check on-hand inventory before generating an external purchase requisition and offer reservation against existing stock as an alternative.
The system shall display reservation and allocation visibility at requisition time, distinguishing on-hand quantity, committed (reserved against other orders), available-to-promise, and quality-inspection stock, so requesters can evaluate whether existing inventory is genuinely accessible before initiating a new purchase.
The system shall display goods-in-transit visibility at requisition time — stock that has been shipped by a supplier but not yet received — factoring it into replenishment decisions, particularly for long-lead-time direct materials and multi-plant operations.
The system shall support multi-plant, multi-warehouse, multi-storage-location receipt with put away to a specified bin as maintained in the back end WMS system.
The system shall capture lot or batch numbers at goods receipt for items flagged as lot-controlled.
The system shall capture serial numbers at goods receipt for items flagged as serialized.
The system shall capture and enforce expiry dates for items flagged as expiry-controlled (a real-world requirement for consignment inventory, pharma, food, and chemicals — not an edge case).
The system shall support quality inspection workflow at receipt, holding goods in a quality-inspection stock status until inspection is complete.
The system shall support receipt against advance shipping notices (ASNs), allowing receiving teams to pre-stage receipts, validate against the PO before goods physically arrive, and accelerate the physical receipt process by matching against the ASN rather than re-keying data.
The system shall support receipt of a single physical delivery containing items from multiple POs, processing all referenced PO lines in a single receiving transaction without forcing the receiver to process each PO separately.
The system shall support receiver correction and cancellation of receipts (wrong quantity entered, wrong lot or serial number, wrong PO referenced) within a defined and configurable window before downstream invoice posting locks the entry, with full audit logging of the original entry, the correction, and the receiver involved.
The system shall support consignment receipt without immediate liability creation, with separate liability creation upon consumption or settlement.
The system shall support stock transfer orders (intra-company movement of inventory) and subcontract POs (provision of components to a supplier for processing) as distinct PO types.
The system shall adjust on-hand inventory on physical return to a supplier (via the platform's return merchandise authorization process) for items previously received into stock, and reverse the original goods receipt accounting entries appropriately, including any lot, batch, serial, or storage location attributes captured at original receipt.

3. MRP & Replenishment Integration

The system shall consume and update RP-generated purchase requisitions from the planning system without manual re-entry.
The system shall preserve the planning context (demand source, planned delivery date, pegging) on the resulting purchase requisition and PO.
The system shall apply automated source determination logic when MRP generates a requisition for an item with multiple approved sources, supporting preferred-supplier, quota-based split-sourcing, capacity-aware, and cost-optimized allocation strategies configurable per item or commodity, rather than requiring manual buyer allocation.
The system shall respect supplier capacity ceilings and committed-volume limits in source determination, avoiding assignments that would push a supplier beyond their declared or contracted capacity for a given period.
The system shall support scheduling agreements with delivery schedules (distinct from discrete POs) and support release of delivery schedule lines (call-offs) to suppliers.
The system shall produce and transmit demand forecasts to key suppliers in agreed formats (email, EDI 830, cXML, supplier portal, API) at configurable frequencies (monthly, weekly, daily), with forecasts clearly distinguished from firm orders.
The system shall support kanban / pull-based replenishment as a distinct replenishment mode, triggered by signals (electronic, scanned card, sensor-based) when on-hand stock reaches a defined trigger point, separate from MRP-driven planning.
The system shall support vendor-managed inventory (VMI) and supplier-managed flows where the supplier is responsible for replenishing on-hand stock to a defined min/max.
The system shall support JIT delivery call-offs against a scheduling agreement, including same-day and next-day windows.
The system shall flag and route exceptions when MRP-driven replenishment cannot be fulfilled within the required window (no source list, no contract, supplier blocked, lead time exceeded).
The system shall enable configuration of business rules on requisition fields to kick off review workflows before releasing a requisition for purchase (e.g., send workflow item to engineering for materials requiring drawings).

4. Direct-Specific Invoice & Settlement

The system shall support evaluated receipt settlement (ERS / self-billing), generating supplier payments based on goods receipt without requiring a supplier invoice.
The system shall capture freight, duty, customs, insurance, and other landed cost components at the line level, allocate them to inventory cost, and apply Incoterm-driven logic to determine which cost components are buyer-borne versus supplier-borne for a given PO.
The system shall support retroactive price adjustments (price changes effective for prior receipts) with appropriate inventory and AP adjustments.
The system shall support consignment settlement (invoice or self-billing on consumption rather than receipt).
The system shall support subcontract settlement, recognizing both the supplier's service charge and the value of components consumed during subcontracted processing, with appropriate inventory and AP entries for both elements.
The system shall support invoice posting in advance of goods receipt (for prepayments, milestone-based services, or supplier billing conventions), holding the invoice for matching against future receipt with appropriate accrual handling and clear audit trail of the timing.
The system shall produce period-end goods-receipt / invoice-receipt (GR/IR) reconciliation, accruing for goods received but not yet invoiced at period close and reversing in the following period, with full visibility of the GR/IR balance per supplier, PO, and item.

5. Direct-Specific Supplier Management

The system shall manage quality agreements, technical drawings, and material certifications per item-supplier combination, with version control.
The system shall distinguish between manufacturer and distributor relationships, supporting buy-from-distributor / approved-by-manufacturer models.
The system shall enforce supplier qualification status at the item or category level, preventing PO issuance to a supplier and/or goods receipt for items or categories where qualification is missing, expired, or revoked.
The system shall track and enforce dual or multi-source policies for designated critical components, warning when volume concentration with a single source exceeds defined thresholds or when a backup source has not been used within a defined recency window, in order to keep alternate sources operationally viable.
The system shall support supplier scorecards that include direct-relevant metrics (PPM defect rate, on-time-in-full, certificate of analysis compliance) alongside indirect metrics.
(For everything else there’s integration with Third-Party Risk Management solutions)

What This List Tells You About Vendor Fit

The requirements above are the litmus test for whether a P2P platform can genuinely serve direct and MRO buyers… Or whether it can only service indirect spend well.

“Pure-play, indirect-native” platforms will fail most of Section 3 (MRP & Replenishment) hard, regardless of how well-marketed they are. Their architecture wasn't designed to deeply integrate with processes run in another system of record…

ERP-native P2P modules tend to handle these direct and MRO requirements fluently but feel clunky for the indirect core requirements (particularly around intake, guided buying, and conversational interfaces).

Therefore, the P2P vendors worth shortlisting when you’re a manufacturer, distributor, and/or MRO-heavy operator are the ones that score competitively on both the core P2P requirements AND the direct and MRO requirements above.

They exist, but they're rarer than vendor marketing suggests. The way to find them is to score honestly, score by demo, and refuse to accept "we'll figure it out in implementation" as an answer to any of the requirements above.

A Word on Completeness

That's 46 direct and MRO requirements!

Combined with the core P2P list, well over 170. Honestly? We probably still missed a bunch. Direct and MRO procurement has corners I haven't worked in, and every plant, distribution center, and storeroom has its own quirks. We could keep adding to this list forever.

But here's the takeaway I want you to leave with: a complete list might make you feel good, but it won't increase your chances of success in your P2P transformation. Completeness is a comfort, not a strategy.

Go ahead. Build your RFP with the requirements that genuinely matter to your operation. Score them honestly. Make vendors prove them in demo (against your real data, with a scripted scenario that includes at least one inventory-controlled item with lot capture, one MRP-generated requisition, and one consignment receipt).

But more than anything else, find the best partner for you… The vendor whose product, roadmap, services capability, and cultural fit match your reality.

A requirements list is a starting point, not the answer. Don't confuse the map for the territory.

Haven't read the Core piece yet? Start with The P2P Master Functional Requirements List.

👀 In Case You Missed It…
The Last 3 Newsletters:

1/ The Master Procure-to-Pay (P2P) Functional Requirements List for Indirect Purchasing
2/ ProcureTech Unpacked Conference Summary
3/ One Year at Pure Procurement: Insights and Lessons from a Rookie

2 other ways we can help this week:

Not sure if your KPI set is actually credible? Procurement teams can end up tracking too much, too little, or the wrong things entirely. Going back to the CAPS study gives you a stronger foundation, with 90 metrics practitioners considered most important for purchasing effectiveness, so you can validate what you measure and spot what may be missing.
Grab it here.
Get more from your SAP investment. AI-powered intake and orchestration can help close the gap between what your ERP can do and what your process actually needs. This ebook, developed with Tonkean, looks at how to reduce manual work, streamline P2P flows, and create better coordination across your procurement tech stack.
Grab it here.

See you next week {{FIRST_NAME|readers}},

— The Pure Procurement Newsletter Team

P.S. Please rate today’s newsletter.
Your feedback shapes the content of this newsletter.

The Master Procure-to-Pay (P2P) Functional Requirements List for Indirect Purchasing

Joël Collin-Demers — Mon, 04 May 2026 01:28:01 +0000

Most procure-to-pay solution RFPs include a "functional requirements" tab that runs to 400+ rows. And most of those rows are useless…😅

Here's the problem: nine times out of ten, those requirements were copy-pasted from a Gartner Bill of Materials, a consultant's template, or, let's be honest, the vendor's own marketing site. Then someone added "must" or "should" in the priority column and called it a day.

The result? Every vendor scores 95%+. The selection comes down to "vibes." And six months into implementation, you discover the system can technically do what you asked for, just not in any way a human would actually want to use.

This article fixes that. Below you'll find a P2P master functional requirements list organized the way a practitioner actually thinks about source-to-pay, not the way an analyst does. But before the list, we need to cover two things nobody talks about:

What makes a P2P functional requirement good in the first place?
(because a great list scored against badly-written requirements is worse than no list at all).
Whether you're an indirect-only buyer or a direct + MRO buyer?
(because that single distinction reshapes half your requirements list, and almost no published list out there even acknowledges it.)

This article is the Core requirements list — the requirements that apply to every P2P deployment regardless of business type. If you run inventory, MRP, or material masters, you'll need the Core list plus the Direct & MRO Extension companion piece.

Let’s dig in.

Why Most Procurement Teams Get This Spectacularly Wrong
What Actually Makes a Good Functional Requirement (And Why Yours Probably Aren't)
The 5 Tests Every P2P Functional Requirement Must …
- The "Shall + Verb + Object + Condition" Template
- Functional vs. Non-Functional: Stop Mixing Them
Indirect-Only vs. Direct + Indirect: The Question Nobody Asks First
Why You Want a Single P2P System (Unless You Have a Real Reason Not To)
Core P2P Functional Requirements (Both Contexts)
A Note on AI & Non-Functional Requirements
A Word on Completeness
What's Next

Why Most Procurement Teams Get P2P Requirements Spectacularly Wrong

The software engineering world has an entire discipline, requirements engineering, built around frameworks like SMART, INVEST, and EARS. There are textbooks. There are certifications. There are 30-year-old IEEE standards.

Procure-to-Pay sourcing has… a spreadsheet someone got from their last consulting engagement.

This isn't a knock on procurement teams. It's a structural issue. Most procurement professionals were never trained to write software requirements, because it was never their job. It became their job around 2015 when source-to-pay suites stopped being IT projects and started being procurement projects. We inherited the responsibility without inheriting the playbook.

Here's the kicker: badly-written requirements aren't just an academic problem. Industry research has consistently shown that ambiguous requirements drive a huge portion of project rework and defects. In a P2P context, that translates directly into go-live delays, scope creep, change orders from your SI, and eventually, shelfware.

So before you touch the list below, ensure you know how to write a good requirement.

What Actually Makes a Good Functional Requirement (And Why Yours Probably Aren't)

A functional requirement is a statement that describes a specific behavior or function the system must perform. That's it. It's "what the system does," not "how it does it" and not "how well it does it."

That distinction matters more than it sounds. The moment you write "the system should be fast and easy to use," you've stopped writing a functional requirement and started writing a wish.

The 5 Tests Every P2P Functional Requirement Must Pass

Every requirement in your master list should pass all five of these tests. If it fails even one, rewrite it.

Specific. It describes one behavior in one sentence. If your requirement contains the word "and" or two "shalls," you have two requirements pretending to be one. Split them.
Testable. A vendor (or an implementation team) should be able to demonstrate the requirement is met or not met in a script, a demo, or a report. "The system shall be user-friendly" is not testable. "The system shall allow a requester to submit a non-catalog requisition in five clicks or fewer" is.
Unambiguous. Two readers in different rooms should interpret it the same way. Eliminate weasel words: typically, generally, where appropriate, as needed, robust, seamless, intuitive. Every one of these is a vendor escape hatch.
Implementation-agnostic. A functional requirement says what the system does, not how. "The system shall use SAP BTP to handle three-way matching" is not a functional requirement, it's a design constraint. Save those for a separate section.
Atomic. One requirement = one unit of value. If a requirement is so big you'd struggle to score it on a 0-5 scale, break it down.

The "Shall + Verb + Object + Condition" Template

When in doubt, use this structure. It's the equivalent of the SMART framework, adapted for P2P:

[Actor] shall [verb] [object] [under what condition / with what constraint].

Examples:

❌ Bad: "The system should support purchase orders."
✅ Good: "The system shall allow a buyer to create, edit, and dispatch a purchase order against an existing requisition in fewer than three screens."
❌ Bad: "Robust three-way matching capabilities."
✅ Good: "The system shall automatically match an invoice to a PO and a goods receipt where the unit price variance is ≤ [X%] and the quantity variance is ≤ [Y%], and shall route any non-matching invoice to a configurable exception queue."
❌ Bad: "User-friendly mobile experience."
✅ Good: "The system shall allow an approver to approve, reject, or request more information on a requisition from a mobile device without requiring a separate native app installation."

Notice what good requirements do: they tell the vendor exactly what to demonstrate, give your evaluators something concrete to score, and, most importantly, give your future implementation team a contract to hold the vendor to.

Functional vs. Non-Functional: Stop Mixing Them

A common mistake, even in published RFP templates, is jamming non-functional requirements into the functional list. They're different categories and should be scored separately:

Functional requirements = what the system does. (Create a PO. Match an invoice. Onboard a supplier.)
Non-functional requirements = how the system behaves. (Performance, scalability, uptime, data residency, security certifications, accessibility.)
Technical/integration requirements = how the system connects. (API standards, data formats, supported ERPs, SSO providers.)
Commercial requirements / Pricing = how the system is bought. (Pricing model, contract terms, implementation services.)

Mix these up and your scoring matrix becomes convoluted. Keep them in separate tabs of your RFP. This list is functional only.

Indirect-Only vs. Direct + Indirect: The Question Nobody Asks First

Here's the question that should be answered on page one of every P2P RFP, and almost never is:

Are you buying only indirect goods and services, or are you also buying direct and inventory-managed MRO?

Skip this question and you'll do one of two things.

You'll either over-buy a heavy “direct-procurement-capable” suite to handle a fleet of office supply requisitions, or, far more common,
You'll buy a slick “indirect-only” solution that collapses the moment a manufacturing plant tries to receive a lot-controlled raw material against a scheduling agreement.

A Quick Note on What "Direct" and "Indirect" Actually Mean Here

Before going further, a clarification: because "direct" and "indirect" mean different things depending on who's talking and in which context… Conflating them is one of the fastest ways to mis-scope a P2P solution RFP.

The finance definition. In accounting and FP&A, direct means anything that flows into Cost of Goods Sold (COGS): the materials, components, and services that end up in the cost of a product or service you sell. Indirect means everything else: overhead, SG&A, OpEx. This is the lens your CFO uses when discussing margin.
The ProcureTech / systems definition. In the context of P2P platforms, direct means buying that runs on inventory management, MRP-driven replenishment, and item master records. Indirect means transactional buying without any of those mechanics: buy it, receive it, expense it, done.

The two definitions overlap heavily but they aren't the same thing, and the gaps matter:

A factory's preventive maintenance contract is OpEx (indirect by finance), but if the replacement spare parts flow through a CMMS-linked storeroom with item masters and min/max replenishment, those parts are direct by systems definition and need the Extension requirements below.
A spot-buy purchase of a raw material with no item master and no inventory tracking is COGS (direct by finance), but by systems definition, you wouldn’t need a “direct” P2P system to buy this (no inventory, no material, no MRP). This requirement lives entirely inside the Core requirements.
Marketing agency fees are SG&A (indirect by finance) and indirect by systems definition. Easy. Aligned on both axes.
Production raw materials with item masters, MRP, and lot-controlled receipt are COGS (direct by finance) and inventory-driven (“direct”) by systems definition. Also aligned.

The simple rule: when this article says "direct" or "indirect," it means the systems definition, because that's what actually drives which requirements your P2P platform needs to support. Your CFO's definition matters for reporting and analytics; the systems definition matters for architecture and RFP scoping.

The three-test definition below operationalizes this.

The Three-Test Definition

The dividing line is concrete, not vibes. You're an indirect-only buyer if none of the following are true:

You hold goods in inventory and need to manage on-hand stock levels (storage locations, bins, lots, batches, serial numbers).
You run MRP (or any equivalent replenishment-planning logic) that automatically generates purchase requisitions from forecast or production demand.
You maintain item master records (material masters) that govern how a SKU is bought, stored, costed, and consumed across business processes.

If any one of those three is true for any portion of your spend, you're a direct + indirect buyer. That includes most manufacturers, distributors, retailers, hospitals, mines, utilities, oil & gas operators, and food producers. It also includes a lot of services-led organizations that quietly run MRO storerooms — facilities operations, IT spare parts depots, lab consumables.

Critically, this isn't an "industry" question. It's a process question. A SaaS company with a single bonded warehouse for branded merch is still indirect-only. A consulting firm that runs a parts inventory for its rental laptop fleet is, surprise, partially direct.

Note on MRO specifically: if your MRO spend is purely transactional (someone needs a replacement light bulb, no inventory record, no material master) it stays indirect. If your MRO spend runs through a CMMS-linked storeroom with on-hand inventory, item masters, and replenishment rules, it sits squarely in the direct extension — covered in the companion piece.

Why You Want a Single P2P System (Unless You Have a Real Reason Not To)

Here's where most teams go wrong: once they identify themselves as direct + indirect, they default to assuming they need two P2P systems. One for "the manufacturing side" running through the ERP. One for "the indirect side" running through a separate procurement suite. Two supplier masters. Two invoice processing flows. Two spend reports that never tie out.

For most organizations, this is a poor architecture choice, and one that's usually made on autopilot rather than on purpose.

The whole point of a P2P platform is consolidation. One supplier record. One invoice intake. One spend cube. One AP team. The moment you split it by goods type without a deliberate reason, you reintroduce every fragmentation problem the platform was supposed to solve.

Your CFO can't see total spend by supplier. Your AP team has to learn two systems. Your supplier sends two invoices to two different addresses for two different POs from the same buyer.

That said, there are legitimate reasons to run two P2P systems. The test is whether the separation is structural or strategic and durable, not just convenient for the next 18 months. Real reasons include:

Structurally separate business entities. Direct and indirect procurement are run by genuinely different legal entities or business units that don't share suppliers, AP, or financial reporting (e.g., a holding company with independent operating companies on different ERPs).
Durable functional separation. Direct procurement reports into operations or supply chain, indirect reports into finance or shared services, and there is no realistic path or appetite to converge them, for governance, regulatory, or political reasons that won't change.
Strategic divergence in capability needs. One side genuinely requires capabilities the other doesn't, and a single platform cannot serve both well even with configuration.
M&A and post-merger reality. You've inherited two P2P systems through acquisition and the integration cost outweighs the benefit on a defensible time horizon.

If one of those applies to you, a two-system (or more…) architecture is a legitimate choice, and the requirements list below still works, you just apply it twice with different scoping.

If none of those apply, and for most organizations, none do, the right principle is this: aim to have one P2P system that handles all your buying, direct, indirect, services, and MRO, even if it means accepting trade-offs in how each is supported.

Then, work on optimizing the user experience for different types of purchasing around the P2P system (e.g. intake, mobile experience, etc.).

That principle is what makes the requirements list below work. The Core section covers what every P2P system must do, regardless of context. The Extension covered in the companion piece covers the additional requirements that kick in when direct/MRO is in scope. Both sections describe the same system, not two separate platforms.

This is also why some “indirect-only” native platforms (no matter how well-marketed) are non-starters for direct + indirect buyers, and why some “ERP-native” P2P modules feel clunky for pure indirect users. The single-system principle forces you to weigh those trade-offs explicitly rather than sweeping them under a rug labeled "we'll figure it out in implementation."

How to Use This P2P Master Functional Requirements List

A meta-question first, because it deserves one: is an RFP-led, requirements-scored selection process even the right way to buy a procurement system?

There's a legitimate debate here.

RFPs reward vendors with the biggest/best proposal-writing teams, not the best products.

They tend to score table-stakes capability the same as genuine differentiation. They privilege the present over the trajectory, what the platform does today over where it's going. And they create the illusion of objectivity in a decision that's ultimately about partnership, vision, and fit.

Some of the best ProcureTech buying decisions of the last decade have been made by buyers who skipped the RFP entirely, ran structured discovery with a shortlist, and bought based on demonstrated capability and trust.

That's a real conversation, and one worth having before you go down this path.

But, assuming you've decided that an RFP-led selection is the right approach for your organization (whether for governance reasons, risk-aversion reasons, regulatory reasons, or just because that's how procurement decisions get made at your company), then you owe it to yourself, your stakeholders, and the vendors to do it properly.

A badly-run RFP isn't more rigorous than no RFP, it's just slower and more expensive while producing the same vibes-based decision.

The list below assumes you've made the choice to run an RFP and are committed to doing it well.

A few rules of engagement before you dive in:

Don't copy-paste the whole thing. A 400-row RFP is a sign you haven't done your homework. Pick the 80–120 requirements that actually matter for your scope, and cut the rest.
Confirm your context first. If you're indirect-only, use the Core list. Done. If you're direct + indirect, use the Core list plus the Extension. Don't cherry-pick from the Extension, those requirements are interdependent.
Tier them: Must / Should / Could. Use the MoSCoW method. If everything is a "must-have," you've prioritized nothing.
Add the conditions and thresholds. Most requirements below are written generically. Your real RFP needs to specify your tolerances, your match thresholds, your approval limits, your supported currencies, your costing method.
Score by demo, not by self-assessment. Vendors will tend towards checking "Yes" on everything (that’s just the nature of the beast in a prisoner’s dilemma). The only meaningful evaluation is watching them perform the requirement live, against a scripted scenario.

Now the list.

Core P2P Functional Requirements (Both Contexts)

This list applies to every P2P deployment, indirect-only or direct + indirect. It's organized by lifecycle stage rather than by software module, because modern P2P platforms blur module boundaries, and your users care about the journey, not the architecture diagram.

1. Catalog & Content Management

The system shall support hosted catalogs (loaded into the platform), punchout catalogs (OCI/cXML to supplier sites), and free-text non-catalog requests.
The system shall allow buyers to load, version, and expire price lists at the item level.
The system shall enforce contract pricing automatically when a catalog item is added to a requisition.
The system shall capture and surface vendor minimum order quantities (MOQ) at the item, item-supplier, or supplier-order level, displaying the MOQ to the requester at requisition time and warning or preventing requisition submission below the defined minimum based on configurable rules.
The system shall support catalog prices stored in supplier-native currency and displayed to requesters in their local or cost-center currency, with FX conversion applied at requisition time using a configurable rate source.
The system shall carry currency through the full lifecycle (transmitting POs in supplier currency and posting accounting entries in company currency) with FX gain/loss handled at invoice posting.
The system shall restrict visibility of catalogs, catalog sections, suppliers, and individual items based on user attributes including geography, legal entity, company code, cost center, plant, business unit, and role.
The system shall support both inclusion-based and exclusion-based visibility rules (e.g., "only US employees see this catalog" vs. "all employees except contractors see this catalog") with full audit logging of rule changes.
The system shall support catalog browsing by category, supplier, commodity code, and free-text fuzzy search.

Note: If the P2P system doesn’t handle this directly, you can ask for inclusion of a partner solution to the bid to enable these requirements.

2. Requisitioning & Intake

The system shall provide a single intake experience that routes any request ( goods, services, contracts, supplier setup, payment requests) to the appropriate downstream workflow.
The system shall support multiple requisition types (e.g., standard goods, services, capex, blanket, sample, prepayment, intercompany) that map to distinct business scenarios and serve as a key dimension in configuring subsequent business rules (including approval routing, mandatory fields, PO type generation, receipt requirements, and match tolerances).
The system shall support requisition initiation through a web portal interface accessible on desktop and mobile browsers, with full functional parity for catalog, non-catalog, and services requests.
The system shall support requisition initiation through email submission, parsing the message body and attachments for structured intent (item, supplier, value, ship-to) and resolving the sender to an authenticated requester before submission.
The system shall support requisition initiation through enterprise instant messaging platforms (e.g., Microsoft Teams, Slack) without requiring the requester to leave the messaging app to complete the submission for routine requests.
The system shall support guided buying, presenting requesters with the preferred channel for a given commodity (catalog, contracted supplier, RFx, Free Text, P-card, etc.).
The system shall maintain a unified requester identity and audit trail across all intake channels, and shall gracefully fall back to a richer channel (e.g., web portal) when a channel cannot handle the requisition's complexity, with the requester's progress preserved.
The system shall allow requesters to submit a requisition without procurement training, in fewer than [X] minutes for a catalog item.
The system shall support “on-behalf-of” (proxy) requisitioning, allowing a designated requester (e.g., an executive assistant, project coordinator) to raise a requisition on behalf of another user, with full audit logging of the proxy relationship and the actual requester carried through the lifecycle.
The system shall allow requesters to save a requisition in progress and resume it later without data loss, including across browser sessions and devices.
The system shall require requesters to specify a ship-to / deliver-to address per requisition or per line, validated against allowed locations for the user, the supplier, and the item.
The system shall support requisition templates, favorites, and reorder-from-history capabilities to accelerate repeat purchases for frequent buyers.
The system shall support a multi-supplier shopping cart, allowing a single requisition to contain items from multiple suppliers, with automatic downstream splitting into the appropriate number of POs.
The system shall enforce category-, value-, or commodity-driven mandatory fields on requisitions (e.g., SOW required for consulting engagements, project code required for capex, regulatory justification required for controlled substances).
The system shall support coding requisition lines to project / WBS structures alongside cost center and GL coding, with project budget validation where applicable.
The system shall support split-line accounting, enabling a single line to be assigned to multiple different accounting objects based on %.
The system shall distinguish between Capex and Opex requisitions, applying different approval routing, capturing asset-tracking attributes for capex, and integrating to fixed-asset accounting for Capex transactions.
The system shall detect potential duplicate requisitions at submission, based on item, supplier, requester, value, and recent activity patterns, and present the candidate duplicates to the requester before final submission.
The system shall require requesters of non-catalog items to search created catalog items first, present preferred suppliers for the relevant commodity, and only allow a "new supplier request" workflow when no approved supplier exists.
The system shall support split accounting at the line and header level (multiple cost centers, GLs, or projects per requisition).
The system shall validate budget availability against the requester's cost center at requisition submission and warn or block based on configurable rules.
The system shall allow attachments (drawings, scopes of work, quotes) to be added at the requisition or line level and carried forward through the lifecycle.
The system shall allow users to flag requisitions as “urgent” either explicitly or via desired delivery date thresholds.

3. Approval Workflow

Note: This is the section where most P2P platforms quietly fail their buyers' governance teams. Most vendors handle the basics (e.g. value-based routing, parallel/sequential approvers, mobile approval) well enough. Where they break down is at the level of cumulative spend and fragmentation: the requester who splits a $50K purchase into six $9K requisitions to stay under their approval limit, or the cumulative supplier spend across the org that quietly crosses the contract-required threshold without any single requisition triggering an approval. If your P2P platform only evaluates approval rules against the value of the requisition in front of you, you have a governance hole big enough to drive a maverick-spend pattern through. Score this section accordingly…

The system shall route requisitions for approval based on configurable rules including dollar amount, commodity, cost center, project, supplier, and one-time-spend thresholds.
The system shall route approvals based on cumulative spend (YTD, rolling 12 months, or contract-period) with the same supplier, category, or requester (not solely on the value of the current requisition) with thresholds configurable per dimension.
The system shall detect potential requisition fragmentation patterns (same requester, same supplier, same category, or same item split across multiple recent requisitions that cumulatively cross an approval threshold) and route flagged requisitions through a defined fragmentation-review workflow.
The system shall route requisitions that violate specific policy rules (e.g. sole-source above a threshold, use of a non-preferred supplier where a preferred supplier exists, category-specific value caps, missing required documentation) through a separate out-of-policy approval path, with mandatory capture of the policy-violation reason.
The system shall support parallel and sequential approvals within the same workflow.
The system shall support an emergency / expedited approval path with elevated authority and a defined post-event review workflow.
The system shall support delegation of authority for absent approvers, with audit logging of every delegation event.
The system shall apply configurable approval SLAs and auto-escalate approvals not actioned within the defined SLA to the next approver, the approver's manager, or a designated approval expediter, with audit logging of every escalation.
The system shall support bulk approval of routine requisitions under configurable value, category, and scope thresholds, with full audit logging of each individually-approved requisition.
The system shall prevent a requester from approving their own requisition regardless of role, authority level, or approval-chain configuration.
The system shall re-trigger appropriate approvers when a requisition is materially edited after partial approval, with the definition of "material" configurable (e.g., supplier change, value increase exceeding [X%] or [Y absolute], commodity change, cost center change).
The system shall allow an approver to approve, reject, or request more information from a mobile device, including via email.
The system shall provide approvers with the line-level context required to make a decision (item details, vendor, GL, attachments, prior spend with vendor) without leaving the approval screen.
The system shall capture and retain approval and rejection rationale (free-text comments) at every approval step and surface that history on the requisition, PO, and invoice.
The system shall reroute pending approvals automatically when an approver's role, organization, or employment status changes.

4. Purchase Order Management

Note: PO management is where the work shifts from the requester to the buyer. Across most enterprises, POs are created and managed by a central buying team (not by the requesters who initiated the underlying need). The requirements below are written with that operational reality in mind: they describe the buyer's workbench, not the requester's intake form. A central buying team's leverage comes from two places: eliminating the routine work that doesn't need a human (auto-PO creation, auto-release against blankets) and giving the buyer real tooling for the exception work that does (discrepancy handling, version control, open-PO aging, supplier follow-up). Vendors that handle one of those well and the other badly are common. Score accordingly.

The system shall convert an approved requisition into one or more purchase orders, splitting by supplier and shipping address as required.
The system shall consolidate multiple approved requisitions destined for the same supplier into a single PO where commercially appropriate, configurable by supplier, category, or buyer preference.
The system shall enforce vendor minimum order quantities (MOQ) at PO creation (including line-level item MOQ and supplier-level minimum order value or weight) applying enforcement at the moment POs are generated from requisitions, consolidated across requisitions, or released against blankets, with override capability and audit logging where business justification exists.
The system shall automatically create and transmit a PO from an approved requisition without buyer intervention when all defined business rules are satisfied (e.g., supplier on contract, item in catalog, value under threshold, ship-to validated, payment terms set, supplier flagged auto-PO-eligible).
The system shall automatically create a release against an existing open blanket PO when a requisition references that blanket and sufficient remaining balance is available, without requiring buyer intervention.
The system shall provide a configurable rules engine to define which conditions trigger auto-PO creation versus buyer review, including value thresholds, supplier categories, commodity codes, and explicit auto-PO eligibility flags at the supplier or contract level.
The system shall allow a buyer to intercept an auto-PO before transmission to the supplier when needed, with full audit logging of the intercept and any subsequent buyer-initiated changes.
The system shall support multiple PO types (e.g., standard, blanket, contract release, services, subcontract, consignment, stock transfer, intercompany) that map to distinct business scenarios and serve as a key dimension in configuring subsequent business rules — including supplier transmission channel, acknowledgment requirements, receipt configuration, match logic, settlement method, and accounting treatment.
The system shall provide blanket PO release management, including release against the remaining balance, real-time visibility of committed versus consumed value, prevention of over-release, and configurable handling of blanket expiry (auto-warn, auto-close, or carry remaining balance to a successor blanket).
The system shall create a financial commitment (encumbrance) at the moment of PO issue, release the commitment as goods are received and invoiced, and reconcile any residual commitment at PO close.
The system shall assign each PO to an explicit buyer/owner separate from the requester based on configurable business rules, support reassignment with audit logging, and handle buyer out-of-office routing.
The system shall maintain full version control of POs across multiple revisions, with version numbers, supplier-facing supersession messaging on each revised transmission, and complete version history available for audit.
The system shall transmit POs to suppliers via configurable channels: cXML, EDI, email PDF, supplier portal, and API.
The system shall capture payment terms on every PO (e.g., Net 30, Net 60, 2/10 Net 30, end-of-month variants), defaulting from the contract, supplier master, or category in a defined precedence, allowing override with audit logging, and transmitting the payment terms to the supplier in the PO.
The system shall issue POs in the supplier's transaction currency, capture the buyer commitment in the company's reporting currency at the FX rate of issue, and manage FX exposure on long-lead-time POs where receipt and invoice may occur at materially different rates.
The system shall assign each PO to defined organizational structure elements (including legal entity / company code, plant or site, business unit, profit center, and cost center owner) with these assignments driving accounting treatment, reporting visibility, segregation of duties, and entitlement controls.
The system shall default organizational structure assignments from the requisition, requester, or buying entity in a defined precedence hierarchy, allow override with audit logging, and validate that the resulting combination is permitted (e.g., the supplier is approved for that legal entity and plant and that the requester has appropriate permissions to order for this entity and plant).
The system shall capture an ordering unit of measure on every PO line, support conversion to the supplier's pricing UoM where they differ (e.g., ordering by case, pricing per each), and transmit the agreed ordering UoM and quantity to the supplier in the PO.
The system shall allow requesters, buyers, and other authorized internal users to add notes against a PO, with each note explicitly tagged at posting time as either supplier-visible or internal-only.
The system shall transmit supplier-visible notes to the supplier through the PO communication channel (portal, email, EDI, or API) and allow the supplier to reply, with replies threading back to the conversation visible to internal users.
The system shall thread all notes against the underlying PO through the lifecycle (visible at requisition, PO, receipt, and invoice stages), maintain author, timestamp, and visibility scope on every note, and log any subsequent edits.
The system shall provide an open-PO workbench view aged by promised delivery date, surface overdue POs for buyer follow-up, and generate automated supplier reminders for POs approaching or past their promised delivery date on a configurable schedule.
The system shall support PO change orders with full audit history, including the original and revised values, the requester, and the approver of the change.
The system shall attach standard terms and conditions to every PO automatically, with override hierarchy supporting supplier-specific and contract-specific T&Cs, full version control of T&C templates, and audit trail of which version applied to each PO.
The system shall link a PO to one or more active upstream contracts at creation, automatically identifying applicable contracts based on the supplier, commodity, buying entity, and ship-to combination, and inheriting contract pricing, payment terms, Incoterms, and T&Cs onto the PO.
The system shall enforce contract terms on linked POs, preventing issuance at terms that violate the contract (unit price exceeding contracted price, payment terms shorter than agreed, quantity exceeding contract limits, ship-to outside permitted locations) without an explicit override and audit-logged justification.
The system shall track PO consumption against value-based contracts (commitments, minimum spends, ceilings, tiered pricing thresholds) in real time, with visibility of committed versus remaining contract value and configurable warnings or blocks as consumption approaches defined thresholds.
The system shall warn buyers when issuing POs against contracts approaching expiry, prevent issuance against expired contracts (or route them through an out-of-policy approval path), and propagate in-flight contract changes (price updates, term extensions) to open POs where applicable.
The system shall support drop-ship and alternate ship-to addresses (customer locations, third-party logistics providers, contract manufacturers, alternate company sites) with validation against the supplier's allowed ship-to list and clean transmission of the alternate address to the supplier.
The system shall capture an Incoterm (per the active ICC Incoterms standard, currently Incoterms 2020) and named place on every PO involving the physical movement of goods, validating against the standard's allowed values and preventing free-text entry.
The system shall default Incoterms and named place from the supplier master, contract, or item master with a defined precedence hierarchy, allow override at the PO level with audit logging, and transmit the Incoterm and named place to the supplier in the agreed PO transmission format.
The system shall allow buyers to close, cancel, or short-close POs with appropriate approvals and accounting impact.

5. Receipt & Confirmation

The system shall capture supplier PO acknowledgement (confirmation that the supplier has received and accepted the terms of the PO), including promised delivery date, promised quantity, ordering unit of measure and price through the same channels used for PO transmission (portal, EDI, cXML, email, API).
The system shall flag PO confirmation discrepancies vs. requested terms, route them to the buyer for review, and require explicit acceptance or rejection of the supplier's proposed terms before the PO is considered confirmed.
The system shall support goods receipt against a PO at the line and quantity level, including partial and over-receipts, with configurable tolerances and limits based (% of line quantity and/or amount or absolute quantity and/or amount).
The system shall configure goods receipt as optional or mandatory by purchase/document type, supplier, commodity, or value threshold.
The system shall capture receipt-time data including receiver identity, date, and supporting attachments (e.g. Bill of Lading).
The system shall flag and prevent receipt of items not on a valid PO (or route them through a defined exception process).
The system shall enable requesters to set up “pick up notifications” on their orders to support centralized receiving
The system shall support return merchandise authorization (RMA) initiation against an existing PO and goods receipt, with structured reason coding (damaged, wrong item, defective, over-shipped, no-longer-needed) and supporting attachments (photos, inspection reports).
The system shall route RMAs through a defined approval workflow involving the original requester, the buyer, and (where applicable) quality or warehouse personnel.
The system shall link RMAs to supplier credit memos or debit memos in the AP flow, with automatic netting against open payable balances.

6. Services Procurement & Delivery

Services procurement is where most P2P platforms reveal their bias. Vendors that came up serving manufacturing buyers treat services as "goods receipt with a timesheet pdf attached." Vendors that came up serving professional services firms treat goods as "a service order with a part number." Neither is right… Services have their own functional requirements, and they're often where 50%+ of indirect spend actually flows. A vendor that fails here will struggle with consulting, IT services, contractor management, marketing agency spend, and facilities services (i.e., a huge portion of the spend you actually care about).

This section contains end-to-end P2P requirements that need to be added to the above specifically for services.

The system shall support service procurement under two distinct commercial models: fixed-price (deliverables-based) and time & materials (consumption-based), with the appropriate downstream workflow for each.
The system shall capture a structured scope of work (SOW) at the requisition or order level, including deliverables, milestones, acceptance criteria, planned acceptance dates and start/end dates for fixed-price engagements.
The system shall capture service specifications, technical requirements, SLAs, KPIs, and hourly rates by resource role for time & materials engagements.
The system shall track service delivery progress against defined milestones, with milestone-based release of payment liability for fixed-price engagements.
The system shall support service order change orders and scope modifications with full audit history and re-approval routing where the change exceeds defined thresholds.
The system shall notify requesters of upcoming planned “receipt” dates for the two different order types (periodic timesheet entry for time & material and milestone dates for fixed price), as configured in initial requisition/order.
The system shall support service receipt via timesheet, milestone, or service entry sheet.
The system shall integrate with external timesheet systems (or provide a native timesheet capability) to capture consumed hours by resource against an open T&M service order.
The system shall validate timesheet data against the service order (including approved resource roles, rates, and remaining budget) before allowing approval.
The system shall route timesheets through a configurable approval workflow, including approval by the service requester or designated milestone owner.
The system shall report consumed hours, rates, and burn rate by resource, by service order, and across orders for a given supplier or category.

7. Invoice Capture & Matching (for both goods and services)

The system shall capture supplier invoices via supplier portal, email, EDI, e-invoicing networks (PEPPOL, etc.), and OCR/IDP from PDFs.
The system shall support supplier-initiated invoice submission through a supplier portal with pre-validation (PO existence check, item-PO match, tax calculation check, duplicate check) before the invoice enters the AP queue, returning errors to the supplier for correction rather than creating downstream exceptions.
The system shall extract invoice header and line data from unstructured documents and present it for review with confidence scores.
The system shall capture and validate extended header data on every invoice (including invoice type, payment terms, early payment discount terms, withholding tax, freight and handling charges, supplier reference numbers, remittance instructions, and payment reference) validating critical fields (payment terms, currency, tax codes) against the referenced PO or contract.
The system shall detect duplicate invoices across all capture channels using configurable match logic on supplier, invoice number, invoice date, amount, and PO reference (including fuzzy matching to handle minor variations in invoice number formatting), and block duplicates from posting with a defined review workflow.
The system shall use AI or heuristic matching to suggest the most likely PO match for invoices arriving without a clear PO reference, based on supplier, amount, date, line items, and historical patterns.
The system shall provide configurable confidence score thresholds where automatic invoice processing is enabled.
The system shall perform two-way matching (PO ↔ invoice) and three-way matching (PO ↔ receipt ↔ invoice) configurable by supplier, commodity, and value or based on purchase order type settings.
The system shall support line-level matching including many-to-many relationships (one invoice line matched to multiple PO lines for consolidated invoicing, multiple invoice lines matched to one PO line for partial deliveries), with separate quantity and unit price tolerance applied at the line level.
The system shall apply tolerances at the line and header level for unit price, quantity, and total amount, configurable per order type, supplier and/or commodity code.
The system shall handle invoices in currencies different from the underlying PO currency, applying configurable FX rate sources (rate of invoice date, rate of receipt date, contract-fixed rate) and posting FX gain/loss appropriately.
The system shall support evaluated receipt settlement (ERS / self-billing) for indirect spend categories where ERS is appropriate (subscription services, recurring SaaS, utilities, telecom), generating supplier payments based on consumption or schedule without requiring a supplier invoice.
The system shall support recurring invoice automation for predictable, schedule-based charges (subscriptions, leases, utilities, maintenance contracts), auto-generating and auto-posting invoices on a configurable schedule based on contract terms, with periodic human review checkpoints and exception flagging when actual usage deviates from the recurring pattern.
The system shall ingest supplier statements (paper, PDF, or electronic) listing the supplier's open invoices, reconcile them against AP records, and flag discrepancies (missing invoices, paid invoices the supplier still shows open, disputed amounts, mismatched balances) for AP follow-up.
The system shall handle non-PO invoices through a separate, defined coding and approval workflow.
The system shall capture of cost center, GL account, commodity code at a minimum during coding of non-PO invoices.
The system shall support split-line accounting of non-PO invoices and PO-based invoices (based on purchase order accounting settings).
The system shall calculate or call an external service to calculate indirect taxes (VAT, GST, sales tax, use tax, withholding) at the line level.
The system shall support country-specific e-invoicing mandates (e.g., Italy SDI, Mexico CFDI, India IRN, France's reform) without bolt-on tooling.
The system shall support credit memos, debit memos, and prepayment invoices with automatic netting against payable balances.
The system shall produce tax-compliant invoice and credit note documents per the requirements of the supplier's and buyer's jurisdictions.

8. Exception Handling & Resolution

The system shall route every PO-based invoice exception (price mismatch, quantity mismatch, missing PO, missing receipt, duplicate, blocked supplier) into a queue with a defined owner and SLA.
The system shall surface the root cause of the exception in plain language, not as an error code.
The system shall allow an exception handler to communicate with the requester, approver, or supplier from inside the platform, with the conversation logged against the invoice.
The system shall measure exception aging and surface aged exceptions on dashboards.
The system shall integrate with [your payment system].

10. Supplier Management

The system shall support the creation of supplier master records with all fields required to support requirements herein.
The system shall enable maintenance of supplier hierarchy (parent/child, sites, remit-to addresses, ordering addresses, etc.)
(For everything else, there’s an SRM system/module!)

A Note on AI & Non-Functional Requirements

You'll notice this list doesn't include AI-specific functional requirements. That's deliberate.

Most of what you'd ask a vendor about their AI (which models they use, how they govern agentic behavior, how they integrate to your processes, how they can be utilized to automate certain workflow tasks, whether your data trains their model) isn't functional. It describes properties of the AI, not outcomes you’re looking for. Those belong in your non-functional requirements tab, your security questionnaire, or your vendor due diligence.

But here's the wrinkle: non-functional AI properties increasingly determine functional outcomes. "The system shall extract invoice header and line data from unstructured documents" looks identical on paper whether the vendor uses a 2018 OCR engine or a 2026 vision-language model. However, the functional outcome is wildly different.

The non-functional choice is now the functional differentiator. Ask the functional questions in your RFP, but make sure your demo reveals the underlying AI quality (and do the AI-specific due diligence separately). If you're new to the AI question, 10 AI Subdomains That Actually Matter in Procurement is a good place to start.

A Word on Completeness

You've probably noticed there are a lot of requirements in this article. 141 of them if I counted correctly… And honestly, I probably missed a bunch. I could keep adding to this list forever. Day-to-day Procure-to-Pay complexity is mind boggling… (That’s probably why I’m still in this field after 15 years 😅)

But here's the takeaway I want you to leave with: a complete list might make you feel good, but it won't increase your chances of success in your P2P transformation. Completeness is a comfort, not a strategy.

Go ahead. Run your RFP with the requirements that genuinely matter to your context. Score them honestly. Make vendors prove them in demo. But more than anything else, find the best partner for you… The vendor whose product, roadmap, services capability, and cultural fit match your reality.

A requirements list is a starting point, not the answer. Don't confuse the map for the territory.

What's Next

If your buying scope is limited to indirect goods and services (no inventory, no MRP, no material masters) the Core list above is your complete requirements playbook. Pick the 80–120 that matter, tier them, and run your selection.

If you run inventory-managed direct or MRO buying alongside indirect, the Core list is necessary but not sufficient. The requirements that govern material master integration, MRP-driven replenishment, lot and serial tracking, landed cost allocation, and direct-specific supplier management are covered in the upcoming companion piece: P2P Requirements for Manufacturers, Distributors, and MRO-Heavy Operations.

Both pieces describe the same P2P platform (not two separate systems).

ProcureTech Unpacked Conference Summary

Joël Collin-Demers — Mon, 27 Apr 2026 01:30:43 +0000

A rchive | Upgrade to Premium | Sponsor

"Oh ok, so all procurement platform vendors have reached parity and we can just pick the one with the best price?"

I had just walked off stage after making the case for "The Great Convergence" and that was the first question I got. Then I got it again. And again.

Three times in 20 minutes. Same question. Same misconception.

I'll get to my answer in tonight's note because it’s important (spoiler: God no)!

But FIRST, the 2026 ProcureTech Cup results you've been waiting for!

🏆 ProcureTech Solution Discovery Stream: Top 5

Twenty-four vendors. 1 week of community voting on LinkedIn.

The goal? Help you discover new ProcureTech solutions.

Here's where it landed (~1000 votes total):

Kyyte — Intake & Orchestration
Fairmarkit — Sourcing
Sievo — Spend Analytics
Vertice — E2E Procurement Platform
1. (They’ve got an interesting webinar planned this week!)
Consource — Specialized Consulting Procurement solution

My “discovery of the year”: Qolabra (SRM solution) who went all out and made a video for the event!

Full standings (all 24 vendors) in tonight's note.

🎓 ProcureTech Educator of the Year: 3-Way Tie

Conference attendees voted on the best educational vendor session after our inaugural conference last Friday. The result?

A three-way tie between:

SpendHQ (Making Sense of Spend Analytics solutions)
Fairmarkit (Making Sense of Sourcing solutions)
Pactum (Making Sense of Specialized procurement solutions)

👏👏👏

(I had not planned for this outcome 😅)

This prize wasn’t about having the flashiest demos… It was about highlighting the vendors that did the best job as “educators” during the conference!

🎤 Favorite Non-Vendor Session: 2-Way Tie

(I swear I didn’t plan this!! 😂 I didn’t even vote in any stream!)

Tom Mills (The Elevated Importance of Soft Skills in the Era of AI)
- While you can’t see a recording of his talk unless you have a ticket, you can see Tom in action in an upcoming webinar here.
Brajan Gatys (Build vs. Buy Workshop — Building an AI Agent Live).

One session was deeply human. One session was deeply technical.

The fact that both won tells you everything about where this industry's head is at right now.

Congratulations to all the winners!

(And a big thank you to KonnectHouse for partnering with us on this novel event concept)

Last week was a very intense week for us at Pure Procurement. But based on the feedback received so far, it was well worth it!

Three half-days. 16 sessions. 3 keynotes. 10 vendor-led “Making sense of” sessions. 3 workshops. And a whole lot more than I can fit in this intro! 100% virtual.

We’ll definitely be back next year.

Tonight's full note has every session takeaway, the complete Discovery Stream standings, and a proper answer to the question that won’t stop ringing in my ears.

Onwards!

📰 In this week’s edition:

📄 Podcast: AI-Powered Category Management (sponsored)
🌙 "The Great Convergence"… and the Question I Need to Address
📢 This week’s “Must Reads”
📋 3 procurement jobs that caught our eye

Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.

2026 ProcureTech Unpacked Conference Summary

I opened ProcureTech Unpacked with a keynote called "The Great Convergence."

The main thesis? It's no longer useful to ask whether you should buy a Source-to-Pay suite or an Intake & Orchestration platform. In the past few years, S2P suites have bolted on I&O functionality. I&O players have been filling out their offerings in an attempt to become your end-to-end procurement platform provider.

I chose those words carefully. In an attempt.

To make the case, I analyzed publicly available vendor press releases. Two slides told the whole story:

S2P Suites providers releasing I&O capabilities

Intake & Orchestration “first” providers releasing “S2P module-like” functionality.

These two slides generated more questions than the rest of the keynote combined.

The most common? "So all vendors have reached parity and we can just pick the cheapest one?"

No. Press releases are marketing documents!! Two modules can share the same name and deliver WILDLY different business outcomes.

My point was that you can now start evaluating all End-to-End Procurement Platform vendors apples-to-apples…

You can stop asking whether you need a S2P Suite OR an Intake & Orchestration solution… They now all CLAIM to do it all.

To help you see these differences for yourself, I'll be publishing two assets over the coming weeks:

Procure-to-Pay (P2P) Master Requirements List
Supplier Relationship Management (SRM) Master Requirements List

Why P2P and SRM?

After 15+ years implementing S2P technology, these are the two hardest functional areas to get right… And the best proof that "same name" never means "same capability."

Stay tuned.

Solution Discovery Stream Results

You voted on LinkedIn this week. Here's where it landed.

Twenty-four ProcureTech vendors participated in the Discovery Stream. Attendees voted for the solutions that impressed them most. Here are the final standings:

Rank	Company	Category	Votes
1	Kyyte	Intake & Orchestration	208
2	Fairmarkit	Sourcing	110
3	Sievo	Spend Analytics	92
4	Vertice	E2E Procurement Platform	79
5	Consource	Other — Specialized	67
6	Keelvar	Sourcing	64
7	Market Dojo	E2E Procurement Platform	61
8	Kodiak Hub	SRM	42
9	Mercanis	E2E Procurement Platform	41
10	ProcureVue	Spend Analytics	34
11	SpendHQ	Spend Analytics	33
12	Supplier.io	Other — Specialized	30
13	Qolabra	SRM	30
14	BeNeering	Intake & Orchestration	27
15	ConvergentIS	E2E Procurement Platform	27
16	Matchory	Other — Specialized	26
17	Procurence Meercat	E2E Procurement Platform	20
18	Axiom	Other — Specialized	19
19	Graphite Connect	SRM	18
20	Axya	E2E Procurement Platform	15
21	Samification	Other — Specialized	13
22	Focal Point	E2E Procurement Platform	6
23	Zip	E2E Procurement Platform	5
24	Pactum AI	Other — Specialized	4

Congrats to Kyyte for the top spot! Make sure you check out vendor websites by clicking above for the vendors you don’t know!

2026 ProcureTech “Educator of the Year”

10 vendors led “Making Sense of…” session for their respective software categories.

Conference attendees voted via the end of conference survey for their “favorite educator” of the vent.

We ended up with a three-way tie!

SpendHQ (Making Sense of Spend Analytics)
Fairmarkit (Making Sense of Sourcing solutions)
Pactum (Making Sense of Specialized procurement solutions)

These are the 3 vendors attendees said taught them the most. Not the flashiest demos. Not the slides with the most client logos. The ones who showed up, shared real insight, and made the audience smarter.

That's the bar. And these three cleared it.

Congratulations! I hope to be able to let you hoist the ProcureTech Cup soon!!

Favorite Non-Vendor Sessions

Two-way tie based on end of conference survey votes:

Tom Mills (The Elevated Importance of Soft Skills in the Era of AI)
Brajan Gatys (Build vs. Buy Workshop — Building an AI Agent Live).

What I love about this result: the audience simultaneously craved deeply human content (how do we stay relevant and choiceful as AI takes over more tasks?) and the deeply technical content (show me how this actually gets built, live, right now).

That tension (human judgment vs. technical capability) was the undercurrent of the entire conference.

The Sharpest Moment From Every Session

Thirteen sessions. One sharp take from each. Here's what hit hardest:

SpendHQ — Making Sense of Spend Analytics

Without a solid spend taxonomy, everything downstream falls apart. Don't just default to UNSPSC. A custom taxonomy is worth the effort. And don't conflate who buys something with what is bought.

Fairmarkit — Making Sense of Sourcing

The future of sourcing is adaptive. You shouldn't be locked into a rigid, linear flow (RFI → RFQ → RFP → Auction). You should be able to change strategy mid-flight based on context — and your system should follow.

Keelvar — Making Sense of Sourcing

60–70% of addressable spend is never competitively sourced in most organizations. AI in sourcing is about closing that gap and increasing impact.

ConvergentIS — Making Sense of End-to-End Procurement Platforms

End-to-end platform providers should be selling you outcomes, not software licenses. How they price tells you how they see themselves.

Market Dojo — Making Sense of eAuctions

Don't hide behind eAuctions by limiting supplier communication. If anything, you need to be more communicative to get great results from this tool.

BeNeering — Making Sense of Intake & Orchestration

The hard part of I&O isn't intake or orchestration. It's understanding that these tools are the piping that leads to sourcing and purchasing channels. Without robust channels on the other end, I&O alone won't deliver.

Trust Your Supplier — Making Sense of SRM

An SRM platform without proper stakeholder management and governance is just an expensive vendor database.

Graphite — Making Sense of SRM

The organizations getting the best results from supplier management aren't faster because they work harder. They're faster because their data is better — and their processes make it better automatically over time.

Pactum — Making Sense of Specialized Procurement Solutions

Specialized platforms shouldn't just provide technology. They should deliver procurement best practices adapted to your context. The goal isn't replacing human behavior… It's amplifying and scaling the best of it.

Axiom — Making Sense of Tail Spend Management

“Old guard” P2P systems and catalog management platforms were built for your top suppliers. They were never designed for the plumber, the emergency print job, or the one-off training provider. Rethinking catalog and supplier content management is how you solve the tail spend problem.

Tom Mills — Soft Skills in the Era of AI

In the era of AI, procurement needs to be the conscience of our organizations. We need to be choiceful about what — and how much — we outsource to AI if we want to keep our competitive advantages.

Tanya Wade — Bias, Hallucinations and Liability

LLMs are trained to tell users they're absolutely right. This reinforces biases and creates real liability. "AI hygiene" isn't optional for organizations that want to stay intellectually honest.

Brajan Gatys — Build vs. Buy Workshop

Building your own AI agents can be powerful, cost-effective… and dangerous. Without careful deployment and maintenance, they become the equivalent of that critical macro-ridden Excel file nobody wants to touch.

Of course, there was a lot more great content than just the above at ProcureTech Unpacked 2026. For me, the industry breakout groups were the most impactful part of the event.

Thanks again for everyone who made time to attend.

See you all next year!

P.S. If you have a ticket, you have 30 days to watch recordings and download conference assets :)

👀 In Case You Missed It…
The Last 3 Newsletters:

1/ One Year at Pure Procurement: Insights and Lessons from a Rookie
2/ The Agentic Procurement Team Playbook
3/ Confessions from an Intake & Orchestration RFP

2 other ways we can help this week:

Why most procurement teams do not have a software problem. They have a clarity problem. In this conversation, our consulting principal breaks down why digital procurement still needs mentorship, how teams should think about the 600+ ProcureTech solutions on the market, and why the goal is not to buy more tools, but to build the right capabilities in the right order.
Watch the replay.
Stop comparing apples to oranges. Most ProcureTech evaluations break down early because teams compare suites, point solutions, and hybrids as if they solve the same problem. This framework gives you a sharper way to read the market, structure your thinking, and build a technology stack around fit, integration, and business outcomes instead of vendor noise.
Grab it here.

See you next week {{FIRST_NAME|readers}},

— The Pure Procurement Newsletter Team

P.S. Please rate today’s newsletter.
Your feedback shapes the content of this newsletter.

One Year at Pure Procurement: Insights and Lessons from a Rookie

Joël Collin-Demers — Mon, 20 Apr 2026 01:00:00 +0000

A rchive | Upgrade to Premium | Sponsor

Hi {{FIRST_NAME|readers}},

If you've been paying attention to the ProcureTech market, there's a feeling out there…

A feeling that things are changing…

It feels like we've truly entered a new era of end-to-end procurement platforms (and not just because of AI's October 2022 ChatGPT moment). The enterprise is always slow to change, but there's clearly something happening.

That was the core thesis of my presentation to procurement pros at Zip Forward Europe in London this week. And I brought the receipts from 12+ vendors to back up the claim! 🧾

If you want a copy of my slides, just reply to this email and I'll send them over.

Now. Three things happening this week:

1/ Wednesday at 9am ET, our inaugural virtual conference, ProcureTech Unpacked, goes live in collaboration with KonnectHouse.

10 software vendors will be discussing and demoing the "art of the possible" across all the main ProcureTech software categories. We've got a full house and everything is coming together nicely. If you managed to snag a ticket, very excited to see you there. We've got surprises planned. 🎆

2/ Tomorrow at 9am ET, the 2026 ProcureTech Cup "Discovery Stream" launches on my LinkedIn profile.

For those of you who didn't get into Unpacked this year, we didn't want you on the sidelines. A new simplified format this year: 25 brands. Open voting, all week.

The ProcureTech brand with the most votes by Friday at 5pm ET wins the Solution Discovery stream. Come make your voice heard.

3/ And tonight? It's Miller time. 🍺

With all of that going on this week, I gave Miller Cordeiro, our Head of Growth, the keys to the newsletter🔑. He’s been bringing the power of the ‘stache to our industry, and he's got some thoughts on what he's learned. 🥸

What do you think his main takeaway is after a year working with me? (It may or may not have something to do with maple syrup.) 😅

Onwards!

📰 In this week’s edition:

📄 AI Contract Ochestration Guide (sponsored)
🌙 One Year at Pure Procurement: Insights and Lessons from a Rookie
📢 This week’s “Must Reads”
📋 3 procurement jobs that caught our eye

Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.

One Year at Pure Procurement: Insights and Lessons from a Rookie

by Miller Cordeiro

A Year of Transformation

When I joined Pure Procurement as Head of Growth a year ago, I thought I understood what digital transformation in procurement meant. Nearly twelve months later, I’ve realized I was in way over my head.

Working alongside Joël and so many other incredible practitioners has shown me just how outdated my perception of procurement really was.

Honestly, the last thing I associated with the function before working at Pure Procurement was software or cutting‑edge technology. But after a year of learning and discovery, I’ve walked away with lessons I’ll carry forward with confidence.

The most important of them? Business transformation is barely about technology. It’s about clarity, relationships, and resilience.

One of the clearest examples of this came when I realized just how much time and effort is required to align stakeholders before any tool can truly make a difference. Without that alignment, most if not all digital transformation initiatives are doomed to fail.

Key Lesson: Stakeholder Alignment Comes First

A key lesson that has stuck with me as a recurring theme in every digital transformation initiative is that stakeholder alignment must always come first. This is no easy feat. Aligning stakeholders requires considerable time and effort, which is precisely why change management is such an important part of not only procurement but all business functions.

Procurement technology can be powerful and a true game changer for any business, but without clarity and buy‑in across the organization, even the best solutions stall. This insight reshaped how I approach everything from procurement to business to growth initiatives — start with people, not platforms.

The Growth Playbook: Three Lessons Learned

1. Clarity Before Technology

Procurement succeeds when requirements are precise and expectations are aligned. Whether drafting an RFP or evaluating a ProcureTech solution, clarity upfront saves months of rework downstream. My first year taught me that growth and progress is accelerated when we invest in defining the problem before chasing the solution.

2. Build Relationships to Drive Adoption

Tools don’t transform organizations, people do. Building strong cross‑functional relationships is the secret sauce of a truly successful initiative. Procurement leaders must act as connectors, ensuring that technology adoption is supported by trust and collaboration. Without collaboration and open communication, even the simplest goals become nearly impossible to achieve.

3. Cut Through Hype, Focus on Reality

AI, orchestration, and automation currently dominate conversations in the space, but separating hype from reality is essential to ensure success. Focus on solving your core problem, not chasing shiny features…

Progress comes from pragmatic wins that build momentum, not from promises that overreach. And it’s crucial to remember that not every problem requires the same solution, just because something is considered “best of breed” or “best in the market” doesn’t mean it’s the best solution for you and your organization.

Sometimes the answer may be as simple as doing a better job leveraging your current systems and software. The key is simple: find the solution that truly fits your needs and objectives. This will save you money, energy, and, most importantly, time.

Looking Ahead

As I move into year two, I’m excited to see how procurement continues to evolve. The industry is shifting from transactional efficiency to strategic enablement, and Pure Procurement wants to be at the forefront of that change. My role in growth is to ensure that more practitioners in the space have access to the actionable insights, education, and resources they need to succeed and grow as professionals.

Procurement transformation is not a sprint; it’s a repeat game with no finish line.

And after one year, my playbook is clear: start with clarity, invest in relationships, and stay grounded in reality. That’s how we grow — in procurement, and in life.

What lessons did you learn this year?

👀 In Case You Missed It…
The Last 3 Newsletters:

1/ The Agentic Procurement Team Playbook
2/ Confessions from an Intake & Orchestration RFP
3/ The Repeat Game: Why Procurement Always Negotiates at a Disadvantage

2 other ways we can help this week:

Change management is where ProcureTech projects live or die. In the following webinar, we discussed why technology alone never delivers ROI, what good change management actually looks like, and battle-tested tactics to drive adoption before and after go-live.
Watch the replay.
Want to cut through the AI noise? Most vendors say they “use AI.” Very few tell you which type, where it fits, or what it should actually do in procurement. This poster helps you sort signal from spin by breaking down the AI subdomains that matter, where they apply, and where they don’t.
Grab the free poster.

See you next week {{FIRST_NAME|readers}},

— The Pure Procurement Newsletter Team

P.S. Please rate today’s newsletter.
Your feedback shapes the content of this newsletter.

The Agentic Procurement Team Playbook

Joël Collin-Demers — Mon, 13 Apr 2026 01:04:40 +0000

Introduction
What is Agentic AI in Procurement?
The Core Challenge
Do You Know Your Business Rules?
How to Use This Guide
System Design Concepts
The Agentic Team Maturity Model
The Teams Winning with AI Aren't the Ones with the Best Tools
The Bottom Line

Introduction

The vendor pitches all sound the same: "Our AI agent will revolutionize your sourcing." "Autonomous procurement is here." "Deploy agentic AI and watch efficiency soar."

Here's what they don't tell you: you can't deploy "agentic" anything if your organization isn't built for autonomy.

Everyone wants an F1 car. The AI vendors promise you an F1 car. But if your team doesn't have the pit crew, the track knowledge, or the racing strategy, you're going to crash an expensive piece of machinery into a wall.

When the operating model is right, that same car becomes a force multiplier: cycle times shrink, tail spend stops eating your team alive, and your best people get time back for strategy instead of approvals and follow-ups.

This guide is designed for CPOs who are evaluating agentic AI technology, whether you're considering buying a platform or building your own capability. It won't tell you exactly how to build these systems. Building autonomous procurement systems is genuinely complex, and any guide that suggests otherwise is oversimplifying.

What it will do is give you the five system design concepts you need to understand deeply before you sign a contract, make a build decision, or hand your team a mandate.

Think of this as a readiness assessment and a vendor conversation framework. Use it to locate where your organization stands today, and to ask better questions of the technology partners who want to help you get there.

What is Agentic AI in Procurement?

Agentic AI refers to systems that can perceive their environment, make decisions, take actions, and learn from outcomes with minimal human intervention. Unlike generative AI (which creates content) or predictive AI (which forecasts outcomes), agentic AI executes workflows autonomously.

For procurement, this means an AI agent could:

Evaluate supplier quotes and award business based on predefined criteria
Monitor contract compliance and trigger renegotiations when thresholds are breached
Route purchase requests through dynamic approval workflows based on real-time risk scoring

Sounds powerful. And it is, when the right foundations are in place.

The Core Challenge

These AI agents need business rules to follow, systems to access, processes to execute, and feedback loops to improve. If your procurement function doesn't have those foundations in place, the agent has nothing reliable to work with.

The difference between a failed AI implementation and a successful one usually isn't the technology. It's whether the organization had the design discipline to give the technology something real to work with.

Do You Know Your Business Rules?

Consider a concrete scenario. You've deployed an agentic AI tool to handle low-value, low-complexity sourcing events autonomously. A request comes in for office furniture: $25,000, standard specifications, needed in 90 days.

Should the AI agent:

Send an RFQ to three pre-approved suppliers?
Negotiate directly with the incumbent based on historical pricing?
Route to a human buyer because furniture involves installation dependencies?
Automatically award to the lowest bidder if quotes are within 5% of budget?

If you can't answer that question systematically, with a documented business rule, your agent can't answer it systematically either. Agents rely on either hard rules (explicitly defined logic) or statistical models (inference from patterns). Without the former, you're accepting unknown outcomes of the latter at scale.

If your team can't answer these questions consistently before deploying an AI agent, you're probably not ready. The good news: the path to readiness isn't as long as it looks. It comes down to five system design concepts.

How to Use This Guide

The five sections that follow are not a step-by-step build guide. They are system design concepts, the domains where autonomous procurement systems succeed or fail, regardless of whether you're buying a platform or building one internally.

For each concept, ask two questions:

If we're buying: does our vendor have a mature, proven approach to this? How configurable is it? Who owns it post-deployment?
If we're building: do we have the internal capability to design, govern, and continuously improve this component?

Use the maturity model at the end to assess where your organization stands across all five.

System Design Concepts

✅SYSTEM DESIGN CONCEPT #1

Policy as the Rulebook

Agentic AI operates on logic. That logic has to come from somewhere. In procurement, it comes from your policy and business rules.

Most teams discover when they start implementing AI agents that their procurement policy is either nonexistent, outdated, or so vague that humans interpret it differently depending on who you ask. That's a problem whether you're buying or building, because the agent's interpretation of ambiguity probably won't match yours.

If your policy says "strategic sourcing required for purchases over $50,000" but doesn't define what "strategic sourcing" means, the agent will make its own interpretation. It won't be stuck. It'll take action. And you may not agree with that action.

The 3 Policy Elements Every Agentic System Needs

1. Decision Thresholds and Escalation Triggers

When does the agent act independently, and when does it hand off to a human? This goes beyond dollar thresholds. Well-designed systems account for:

Risk exposure: Is this spend category regulated or mission-critical? Are decisions reversible?
Complexity: Does the purchase require custom specifications? Are multiple stakeholders involved?
Urgency: Is this routine replenishment or an emergency buy?

A well-documented threshold policy looks like: "Purchases under $10,000 with pre-approved suppliers and standard terms → autonomous. Purchases under $10,000 with new suppliers or non-standard payment terms → human review."

Questions to Ask a Vendor

How does your platform encode and enforce these thresholds? Can procurement teams configure them directly, or does every change require technical resources?

2. Approved Actions vs. Human-Required Interventions

What can the agent actually do? Can it send RFQs? Award contracts? Negotiate payment terms? Add new suppliers to the approved vendor list? Each of these carries different risk profiles and requires clear boundaries.

Without a documented authority matrix, agents make decisions that create compliance risk, generate stakeholder friction, and erode trust. The question to ask a vendor: what is the out-of-the-box authority model, and how is it governed?

3. Risk Tolerance Parameters by Category

Not all sourcing carries equal risk. Mature systems define autonomy levels by spend category:

High autonomy. Tail spend (office supplies, low-value services):
Medium autonomy. Agent can run RFQs and score bids; human approves final award. IT software and SaaS:
Low autonomy. Agent supports analysis; human decides. Direct materials or mission-critical services:

If this level of policy clarity doesn't exist yet, it's worth knowing: your human buyers are likely making inconsistent decisions too. An agentic system just forces you to confront that reality and resolve it.

✅SYSTEM DESIGN CONCEPT #2

System Ownership and Configuration Governance

Traditional procurement systems were configured once and left alone. IT owned them, maintained them, and occasionally upgraded them. Procurement submitted tickets for changes.

Agentic AI requires a different model. Market conditions change. Supplier performance shifts. New risks emerge. If procurement has to wait months for IT to update the agent's decision logic, the agent becomes a liability, not an asset.

The Design Question: Who Owns What?

The core design decision is where configuration ownership sits. In well-functioning agentic procurement environments, the split tends to look like this:

IT retains ownership of:

Infrastructure and hosting
Security and access controls
System integrations (ERP, P2P, CLM)
Major version upgrades and disaster recovery

Procurement must own:

Agent configuration and business rules
Workflow design and approval routing
Category-specific decision logic
Agent performance monitoring and tuning
Response when the agent makes incorrect decisions

In short: if it affects how procurement makes decisions or executes work, procurement needs to control it, even if IT enables it through infrastructure.

This requires a capability shift. Someone in the procurement function needs to understand both the business logic of procurement and the technical details of system configuration. This "translation layer" role, often a Digital Procurement Lead or Procurement Excellence function, is critical for sustainable agentic AI.

Questions to Ask a Vendor

How much can procurement configure directly, without IT involvement?
Is there a sandbox environment where changes can be tested before going live?
What does the shared governance model look like between vendor, IT, and procurement?
What happens when the agent makes a decision that needs to be corrected? Who has the access and capability to fix it?

✅SYSTEM DESIGN CONCEPT #3

Process Design and Exception Handling

Agentic AI can handle ambiguity, that's what makes it compelling compared to rigid automation tools. But if you want specific outcomes, you need to provide guardrails. You need to define the menu of acceptable actions.

Most procurement processes aren't as well-documented as teams believe. Processes evolve organically. Someone creates a workaround for an edge case. A new stakeholder gets added to approvals because of a compliance incident. A one-off payment term exception becomes the informal standard. None of it gets documented. It lives in tribal knowledge, email chains, and institutional memory.

When you start implementing an AI agent, you discover there are no "standard" sourcing business rules, there are 47 variations, most of which contradict each other.

What Good Process Design Looks Like

Well-designed agentic systems require process documentation that goes beyond the happy path. The design concepts that matter:

Decision point mapping

Every fork in the process (where a different condition leads to a different action) needs to be explicit. Not "it depends," but documented logic for what it depends on.

Exception handling design

What percentage of transactions follow the standard process? For those that don't, why not? Mature systems have explicit exception paths rather than relying on human judgment to catch what the agent misses.

Stakeholder process ownership

Who owns each process end-to-end? Who has authority to change it? How do changes get communicated? Without clear ownership, process improvements stall and agent behavior drifts from business intent.

A Concrete Example: Negotiation Decision Tree

Consider an agent handling negotiations for low-value software renewals (under $50,000 annual spend). A well-designed decision tree might look like:

On receipt of renewal quote:

Quote within 5% of prior year → auto-approve
Quote 5–15% higher → agent negotiates for 10% discount using historical pricing data
Quote >15% higher → escalate to human buyer

If vendor declines discount:

Can agent propose a multi-year deal to unlock volume pricing?
Can agent solicit competitive quotes from alternatives?
If no alternatives exist → escalate to category manager

On approval routing:

Final price within budget and <$50K → auto-approve, issue PO
Final price exceeds budget → route to stakeholder for funding approval
Non-standard payment terms proposed → route to finance

This level of specificity is required for the agent to operate reliably. Without it, the agent either makes incorrect decisions, escalates everything to humans (defeating the purpose), or operates inconsistently, which is worse than either alternative.

Questions to Ask a Vendor

Do you provide process templates and decision tree frameworks, or does the customer need to build all of this from scratch? What implementation support is included to help design these flows?

✅SYSTEM DESIGN CONCEPT #4

Configuration Management and Release Discipline

Agentic procurement environments are not static. Market conditions change. Business rules evolve. What worked six months ago may need adjustment today. How a system manages these changes, safely, traceably, and without breaking existing workflows, is a critical design question.

This is the procurement equivalent of how software teams manage code releases: test in a non-production environment, deploy in controlled increments, monitor for issues, and maintain the ability to roll back.

The Core Design Requirements

Change testing before production: Can new agent logic be validated in a sandbox before it affects live transactions?
Version tracking: Is there a record of what changed, when, and why? Can you revert to a prior configuration if something breaks?
Stakeholder communication: When agent behavior changes, how are the people who interact with it informed? Without visibility, trust erodes.
Monitoring post-deployment: How does the system surface when the agent starts behaving unexpectedly after a change?

A Practical Example

Suppose an agent has been successfully handling negotiations for a raw material category for six months. Then geopolitical events cause supply disruption and price spikes. The existing negotiation logic, optimized for a stable market, is now wrong.

A well-designed system enables you to:

Update negotiation parameters to reflect the new market reality
Test the updated logic against historical transaction data before going live
Deploy the change with monitoring to catch unexpected behavior
Document the rationale so the change is traceable

Questions to Ask a Vendor

What does your change management infrastructure look like? Who can make configuration changes, and with what level of oversight? How are changes communicated to end users?

✅SYSTEM DESIGN CONCEPT #5

Adoption and Stakeholder Trust

You can have the most sophisticated agentic system in the market. If stakeholders don't trust it, they'll route around it. Buyers will manually override decisions. Requesters will email procurement directly instead of using self-service workflows. Finance will demand approvals be reinstated.

Adoption is not a rollout problem. It's a trust problem. And trust is built through consistent outcomes, visible improvements, and ongoing communication, not through a launch announcement.

The Stakeholder Experience Design Questions

How the system handles stakeholder experience is often the difference between an AI investment that pays off and one that stalls at 20% utilization. The design concepts that matter:

Transparency of agent decisions

Can stakeholders see why the agent made a particular sourcing decision?

Explainability is not just a compliance requirement, it's a trust requirement. Opaque decisions generate override behavior.

Feedback loops

How does stakeholder feedback (a buyer who disagrees with a decision, a requester who encountered an error) get captured and incorporated into system improvement? Systems that don't close this loop become disconnected from the business they serve.

Communication cadence

When the system is updated or improved, how is that communicated? The difference between a change that builds trust and one that surprises stakeholders often comes down to a well-written update that says: "We heard your feedback. Here's what changed. Here's what it means for you."

Self-service viability

Many CPOs want to push more sourcing work to requesters. But requesters won't use self-service tools if they don't trust the outcomes. Consistent agent performance, faster approvals, competitive pricing, clean transactions, is what builds the confidence that makes self-service scale.

Case Example: Large-Scale Adoption

One of the world's largest telecommunications companies deployed agentic AI across hundreds of business units, covering both high-volume tactical RFQs and complex strategic RFPs. The challenge was fragmented execution: each business unit ran sourcing independently with inconsistent processes, and some teams had never run a formal RFP.

What drove adoption to 700+ active users and an NPS that significantly outperformed procurement technology benchmarks was not the technology alone. It was three design decisions:

Trust through transparency: Users could see why the agent made sourcing decisions. Central teams maintained oversight while empowering business units. Real-time reporting showed results at enterprise scale.
Speed and intuitiveness: Business units became more autonomous, reducing reliance on central teams. AI handled routine work; humans focused on strategy and relationships.
Continuous improvement: The vendor expanded agentic capabilities over time, faster scope of work creation, autonomous negotiations, scenario-driven decision support, while maintaining workflow stability.

The result: nearly 200% increase in supplier responses year-over-year, and an estimated $100M in annual savings. Not because users were forced to adopt the system. Because it consistently delivered better outcomes than manual processes.

Questions to Ask a Vendor

What does your adoption support model look like? What's your customer NPS? Can you share adoption rates across your customer base, not just your best case studies?

The Agentic Team Maturity Model

Before evaluating vendors or scoping a build effort, it helps to locate your organization on the maturity curve. Not every process needs to reach the highest level, the goal is to match autonomy level to risk, complexity, and strategic importance.

Level 1 — Assisted (Human Does, AI Suggests)

AI provides recommendations: suggested suppliers, pricing benchmarks, risk flags
Humans make all decisions and execute all actions
No autonomous workflows

Level 2 — Augmented (AI Does, Human Approves)

AI executes workflows but requires human approval at key decision points
Example: agent drafts RFQ and selects suppliers, but buyer approves before sending
Partial automation with human oversight

Level 3 — Autonomous (AI Does, Human Monitors)

AI executes end-to-end workflows for defined scenarios or spend categories
Humans monitor performance and intervene only on escalations
Example: agent handles all RFQs under $25K with pre-approved suppliers

Level 4 — Adaptive (AI Does and Improves)

AI executes workflows and learns from outcomes to optimize over time
Agent adjusts negotiation tactics based on supplier response patterns
Agent surfaces proposed logic changes based on market conditions
Humans focus on strategy and governance; agent handles execution

The real skill, whether you're buying or building, is knowing which processes belong at which level, and designing the system accordingly. A tail spend RFQ process might appropriately run at Level 3. A direct materials negotiation for a mission-critical component probably stays at Level 2 indefinitely.

The Teams Winning with AI Aren't the Ones with the Best Tools

Software vendors are going to keep pitching you agentic AI tools. Some are genuinely good. Many will overpromise and underdeliver. The teams getting real value from these investments share something in common: they paired adaptive technology with the organizational discipline to make it safe, repeatable, and scalable.

They have clear procurement policies that define when AI agents can operate autonomously and when humans need to intervene. They have governance models that allow procurement to configure and tune agent behavior without months of IT delays. They have process documentation detailed enough to actually automate. They have configuration management that lets them improve agent performance without breaking existing workflows. And they have adoption practices that turn skeptical stakeholders into champions by improving the user experience and communicating those improvements consistently.

That's the agentic procurement function. Not software alone, and not process alone, the combination of adaptive technology and the organizational design to govern, tune, and trust it.

So before you sign a contract with an AI vendor, or hand your team a mandate to build, ask the five questions this guide has outlined. The answers will tell you more about your readiness, and your vendor's readiness, than any product demo.

The Bottom Line

Agentic AI is only as good as the operating model behind it.

If your procurement policy is vague, your process logic lives in tribal knowledge, and procurement cannot govern how the system behaves, then autonomy will not create control. It will scale inconsistency faster.

The teams getting real value from agentic AI are not the ones buying the flashiest tools. They are the ones with clear business rules, clear ownership, well-designed exception paths, and the ability to tune the system as conditions change.

Get that right, and agentic AI becomes a force multiplier. Get it wrong, and you have simply automated confusion.

Download the ebook

Watch the Webinar

👀 In Case You Missed It…
The Last 3 Pure Procurement Newsletters:

1/ Confessions from an Intake & Orchestration RFP
2/ The Repeat Game: Why Procurement Always Negotiates at a Disadvantage
3/ How to Predict Your ProcureTech Timeline (Without a Crystal Ball)

Need Help Building Your Digital Procurement Roadmap?
Watch our webinar replay on what AI-powered sourcing can do today and where it's headed. No vendor pitch — just a practical walkthrough with live demos. Watch the replay.
Serious about understanding the ProcureTech market?
The 2025 ProcureTech Cup Almanac pulls the field into one place, with participating company profiles, solution categories, HQ locations, and demo links so you can explore the landscape without piecing it together vendor by vendor. Grab it here.

— The Pure Procurement Newsletter Team

P.S. Please rate today’s newsletter.
Your feedback shapes the content of this newsletter.

Confessions from an Intake & Orchestration RFP

Joël Collin-Demers — Mon, 06 Apr 2026 01:00:00 +0000

A rchive | Upgrade to Premium | Sponsor

Hi {{FIRST_NAME|readers}},

Big week around here. Two things before we get to tonight's guest post.

1/ beehiiv just named us one of their 30 favorite B2B newsletters to follow in 2026.

Our newsletter has never won an award. We've never been on a "best of" list. We just show up every Sunday night and try to write the most useful article possible.

Apparently someone noticed because... There’s 75k+ newsletters on beehiiv…🏆

Help us celebrate!

2/ We dropped a 15-minute mockumentary about what we're building this year.

Because if you're going to announce your roadmap, you might as well make fun of yourself in the process…

Fair warning: things escalate quickly…🥶❄️

Now, tonight's main course.

I've been following Michelle Cleary's sharp writing for a while now and finally asked if she'd guest post on the newsletter.

She just went through a full Intake & Orchestration RFP and came back with war stories, receipts, and advice for both sides of the table (including one CFO move that got a vendor permanently blacklisted).

I thought it was a great story to share with procurement pros and software vendors alike. Let me know how you like it with a quick reply.

This year, we're making a conscious effort to find the next great ProcureTech voices. People in the trenches making tech work with stories worth telling.

If that's you, we want to hear from you.

Onwards!

📰 In this week’s edition:

📄 Procurement Maturity Framework (sponsored)
🌙 Confessions from an Intake & Orchestration RFP
📢 This week’s “Must Reads”
🏆 The Road to the ProcureTech Cup: Episode 24
📋 3 procurement jobs that caught our eye

Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.

Confessions from an Intake & Orchestration RFP

by Michelle Cleary

If you're like me, it seems like the only thing more buzzwordy in the procurement world than AI these days is Intake and Orchestration.

Admittedly, two years ago this wasn't even remotely on my radar, and certainly wasn't an area I could convince anyone in procurement or finance leadership to fund. However, it is absolutely top of mind these days and something I think is actually worth all the chatter it's getting.

There is clearly a desire within procurement to elevate the function, embrace technology and AI, and improve workflows to allow us all to operate more efficiently and effectively.

The power of intake and orchestration tools is becoming well-known across procurement functions, hence the emergence of so many vendors in this space. It's also quite refreshing to see companies prioritizing procurement and actually providing funding to explore tools like this — finally!

What Are Intake & Orchestration Solutions for Procurement?

But let's back up a minute, because not everyone is up to speed on what Intake and Orchestration even is or the potential value it holds. This came up recently in a call with a colleague who kept hearing about how many procurement teams were deploying I&O solutions but wasn't sold on the value proposition.

As someone who just recently went through a lengthy I&O RFP and as a born skeptic, I can candidly say there is definitely value here, without question. At a high level, I&O is a fancy way of saying "we need a better front door for procurement (requests for sourcing, NDAs, access to catalogs, access to contracts, etc.) than just using email", and we also need a better way of managing a request’s lifecycle across stakeholders and systems.

Think about it: how much time do you spend scrolling through emails trying to find a request or track down the latest update? A proper I&O tool not only provides one singular front door to users but also enables stakeholders to see the status of requests in real time.

There are a ton of other modules and efficiencies these tools provide, but this alone should be enough to pique your interest, and hopefully open the door to a funding conversation with your CFO. Obtaining senior leadership backing (and funding!) is critical to secure before you begin the RFP process.

Anyone who has asked for a budget knows it’s not easy, you have to build a strong business case to support why you need the funds. Focus on tangible synergies or bottom line savings that the company will realize by investing in the technology – this can take on various forms such as:

Reducing the size of your tech stack to run more efficiently
Better cross collaboration between teams (IT/Legal/Procurement/TPRM)
Quicker processing of basic tasks like vendor onboarding, invoice processing (possibly allowing for headcount reduction or removal of outsourced contractors).

While you’re asking for the funding to pursue a tool, make sure to obtain a senior level sponsor for the project – this is almost as important as the funding!

Having someone from your C Suite sponsor your RFP adds a level of validity (which is sad that you need!) but it helps to ensure that those required to leverage the tool you procure know that the directive is coming from the very top. I&O tools are extremely cross functional in nature, so it’s a good idea to ensure you have the support of leadership not only within the procurement function but also in legal, IT and Risk.

Procurement Intake & Orchestration: The Complete Guide (2026)

If you’d like to dive deeper into what Intake & Orchestration actually is, when you need it, and the 15 enterprise vendors fighting for your budget, this guide will help!

So before we dive into I&O, I should probably elaborate on why I’m qualified to speak on this topic. Like most procurement folks, I have a bit of an untraditional path into procurement. Having spent the first 10 years of my career in traditional supply chain and ops role, I eventually went into a commercial marketing role which had a very close tie to procurement and I began to see the value of being very good friends with my procurement team and how they really were the gatekeepers to a lot of things moving forward within the organization.

Since then, I’ve spent my time both as a procurement consultant and a marketing procurement professional across large global brands, helping to build and shape the future of procurement within the organization. I’ve built this function from the ground up and know first hand the power of creating a strong procurement department.

Advice for Software Vendors Pitching I&O Tools

The first thing every vendor needs to know about pitching their I&O tool is this: you are pitching to procurement people. We live to poke holes and pressure-test vendors, it's our bread and butter. So you better come with your A game. You're never going to pull the wool over the eyes of a strong procurement person, so my honest advice is to ditch the gimmicky sales tactics that might work with marketing teams and be prepared to talk details.

We live in the weeds, you need to be ready to go there with us. There is a misnomer that exists out there about what a procurement person does somewhere along the way we’ve been labeled as Buyers; when in reality a procurement team consists of a lot more than just Buyers. Typically the folks you will engage with during an RFP process will be more strategic category management procurement professionals, who’ve spent a while honing true subject matter expertise; whether within a specific category or as an expert in procurement transformation.

Many procurement professionals who are category experts have actually sat on the other side of the fence (ex. I’ve been in Marketing roles so I understand the needs of Marketing a lot more intricately which allows me to be more successful as a Marketing Procurement professional).

You may also get some on the team who are ex-consultants in procurement, coming from the Big Four firms (or some smaller ancillary organizations); team members from this background are definitely going to be prone to digging deep on change management, implementation, and full workflow.

In short, it’s critical that you understand the dynamics of the team you’re pitching to understanding the backgrounds, skill sets and personalities of the decision making team will help you to properly tailor your pitch and demo.

In the same vein, I cannot stress enough the importance of understanding what your potential client is actually looking for, and only pitching to that need. I see this all the time with marketing vendors: if I'm running a pitch for a new PR Agency, do not try to sell me on your other services; it's a major red flag and a turnoff.

Thoroughly read the brief and ask questions prior to your pitch so you can demo the solutions that address what we're actually trying to solve. There was a lot of functionality I saw during my RFP that was extremely cool, but mostly nothing we were ready for, looking for, or could afford.

Finally, make sure you have someone with real procurement knowledge as a key part of your pitch team. We love nerding out with like-minded procurement geeks, and having a solution presented by someone who has experienced the same issues we're trying to fix goes a long way. We can spot a phony a mile away, so don't try to fake it.

Common Mistakes Made in I&O Pitching

In our RFP, I can candidly say we were presented with the full spectrum of options, from highly established, well-known providers to virtual unknowns. As a total nerd, this was exciting, as it allowed us to truly make the most informed decision for our needs.

I cannot stress enough how much value I place on running a proper RFP for this type of
work, it is critically important to see what's out there, because this is definitely not a
shallow pool of one or two providers like it was a few years ago. When I run RFPs for my marketing stakeholders, I usually have an unwritten rule to invite 5-6 agencies or vendors, for the following reasons:

1 will usually bail
1-2 will usually be a hard no within the first 5 minutes
2-3 will be really strong

This rule has proven right time and time again, and this RFP was no exception. Seeing a wide range of offerings also meant seeing a healthy mix of mistakes and triumphs across pitches:

Mistake #1 is one I'm still shocked to see in every single RFP I run: not being able to solve for the business need. This goes back to properly understanding the brief. If, upon reading it, you determine you don't have the solution that meets the need, politely decline to participate. There is absolutely nothing wrong with having the self-awareness to acknowledge you're not the right fit; it's far better than making a group of people sit through a disastrous pitch.

Actual Real Life Example: It was obvious within 7 minutes of their pitch that one of the vendors did not have anything close to an I&O tool; we actually felt second hand embarrassment for the poor person who had to spend the next 90 minutes pitching us. When we gave them the feedback, they said “yea we know we don’t really have this functionality”, infuriating!

They should have declined to participate instead of wasting everyone’s time.

Mistake #2 is not following the RFP directions, sounds obvious, right? It's not. A good brief will give you clear instructions on timing, point of contact, and deliverable dates. Going outside those rules of engagement immediately sours the vibe. Don't overreach to senior leaders to get a leg up; don't be late on deliverables. Your behavior during the pitch process gives us a window into what you'd be like as a partner (even if the delivery
teams are different…), make sure it's a good one.

Actual Real Life Example: one participant in our RFP had their CFO reach out directly to our CFO at the onset of the RFP and offer to provide a discount if we agreed to cancel the RFP. Our CFO never responded and instead forwarded it to us and said “do not hire them.”

Mistake #3 is overselling and upselling. Similar to Mistake #1, it comes back to understanding what we need. Focusing too much on upselling things we don't need leaves a bad taste in everyone's mouth.

Actual Real Life Example: our brief clearly stated that we were not looking to replace our P2P tool; however, one participant pitched and priced us for not only I&O but also a full end to end P2P. When we pushed back on this, they actually refused to price us on only I&O (they were one of the first ones we pushed out of the process)

Mistake #4, which likely won't come as a shock, is pricing. I try hard not to make my RFPs purely price-focused, finding the right partner matters more, but price is obviously a big factor, and it goes both ways. Coming in with a completely outrageous price is an immediate red flag and, depending on how far off it is, can be a total deal-killer. If you're 3x my budget, I'm probably not going to bother negotiating. Conversely, coming in too low raises eyebrows about your company's legitimacy and staying power.

Pricing is always a balancing act, avoid the extremes on both ends.

Actual Real Life Example: We were very clear on the term and number of users we were looking to procure the tool for; however we had a vendor who refused to price to our needs and instead used their own pricing model which resulted in such an absurdly astronomical price we didn’t even negotiate it, we simply told them they were far too high.

They immediately came back and reduced it by 40%… which made us even more turned off.

Mistake #5 is not understanding the market. There are a lot of players in this space now, many offering very strong tools at vastly different price points. Humility goes a long way when you're not the only fish in the pond. As buyers, we have plenty of viable options, as a supplier, you should understand the market landscape and adjust your approach accordingly.

Actual Real Life Example: We invited one of the market leaders to participate in our RFP and it was clear from the onset that there was a high level of ego in play, both in the way they presented themselves and they way they priced. They absolutely failed to realize that there were plenty of other options out there, their ego lost them this business.

Best Practices Seen in I&O Pitching

On the flip side, I saw some really impressive things during the pitch process that I'd encourage all vendors to replicate, behaviors that won the business or placed vendors as a strong #2 or #3:

Best practice #1 was partnership. This may surprise you, as it's often the most underestimated part of an RFP, but it's frequently the most important. I've said many times that RFPs are like speed dating: we're checking if you're fit-for-purpose, but we're also making sure we actually like you and can work with you. Our winner meshed perfectly with our team from the start. We felt they would be an amazing collaborative partner and that we could grow with them. Never underestimate how important team chemistry is even if it’s not an explicit requirement in the RFP.

Actual Real Life Example: there were two vendors with who we had a strong connection. This went a long way with our team. At the end of the day though, our #2 choice had an absolutely disastrous key member that unfortunately soured us completely on them. It gave us pause and made us wonder: “If they were hired, would others be as much of a mess?”

Best practice #2 was having a good balance of AI features. Some vendors went so heavy on AI that we weren't sure we'd ever actually work with a human, a massive concern that ruled some out. We were transparent upfront about our company's limited AI maturity, and those who listened were able to showcase their AI capabilities while also reassuring us that a strong human element remained central to the experience.

Actual Real Life Example: Our strong #3 choice was in a pretty good position but lost for 2 very specific reasons… One of those was AI. We were pretty clear that our company was not mature in AI but they didn’t listen and went SO heavy into complex AI functionality that we began to question if the tool was actually any good or if it this was an AI shadow game. It also made us feel like they didn’t listen to our needs and culture.

Best practice #3 was references. I experienced a real roller coaster with reference checks during this process. Please make sure you give good references. We were on the fence between our #1 and #2 choice, and the reference checks literally made our decision for us. I'm still genuinely puzzled by some of the references we were given, and I feel bad knowing they cost those vendors the deal.

Actual Real Life Example: The second reason our #3 choice lost is because of their references. They gave us a handful of references to call, none of whom are even actively using the tool. Some had been trying to go live for over a year. It was incredibly odd and made us wonder if the company was still in a start up mode and not actually live yet.

Best practice #4 goes back to a key theme: focusing on solving the business problem. Our two strongest options clearly understood our core issues and built their demos around helping us address them. They didn't try to upsell us or push us in a different direction, and it made for much smoother conversations rooted in a shared goal. They didn't feel salesy, they felt like true partners.

Actual Real Life Example: Our winner truly felt the most like a partner. They had a strong understanding of procurement, took the time to understand our challenges and explained how their team and their tech could help us do our jobs more efficiently. In addition, they just felt like genuinely nice people to work with.

What Procurement Teams Need to Know to Select the Right Partner

Procurement People: I'm glad I went through this thorough RFP process, it's genuinely made me something of a subject matter expert on I&O. Every client is different, so the solution we chose may not be right for you, but that's entirely the point of an RFP. There are several very strong tools out there right now, so it's critical that you educate yourself on the options in the market, not only from a functional perspective but from a cost perspective.

Economics 101: when there's more supply, you as the buyer have more leverage on price. Even if you ultimately choose the most expensive option, make sure that decision is the result of due diligence and market analysis. Be clear and concise on why you're looking for an I&O tool so vendors can pitch to you on how they specifically meet that need.

Also, ensure you have a robust and transparent scorecard for properly evaluating vendors throughout the RFP process; this is an excellent way to ensure you have real time feedback and that your decision is based on robust data from all stakeholders vs, just the opinions of a select few.

I also encourage putting this evaluation criteria within your brief so that the vendors also know how they are being assessed; it sets you up for strong pitches and demos. In the RFP I ran, our evaluation criteria included the following:

Fit-for-Purpose: Can this tool solve all or most of the issues we are looking to address?
Implementation: Can this vendor also support the implementation of their tool or do we need to source an implementation partner? What does the cost and timing of implementation look like?
Integration: Does this tool have the ability to integrate / interface with all of the systems we need it to? If not, can they easily build to make it work?
Team Chemistry: Is this a vendor and team we feel we can and want to work with? Did they feel like collaborative partners?
References: What insights did we gain from the reference checks we did?
Price: How does the price align with our budget? Do we feel it is a fair pricing model or is there concern over potential hidden costs / true ups?

What I&O Vendors Need to Know to Win More Deals

Vendors: Do your homework. Understand your client, read their brief carefully, don't assume you know what they need, ask and tailor your pitch accordingly, not what you think they need. Remember, you are pitching to procurement people, so you need to know your stuff. Leave the fluff behind.

Insights into the Outcome: In our case, after a quick but robust RFP process, we selected our winner pretty easily, they had been our number one choice throughout the process. They were ahead of our #2 choice by a fair margin.

We wound up going with a fairly new player in the space which I think shocked even us because we had never even heard of them prior to beginning the RFP; however, there were some very clear reasons why they were unquestionably the winner:

Their tool checked all the boxes for what we were looking for and had a very easy and visually pleasing UX/UI. It was very easy to use.
They didn’t try to upsell at all. They spent maybe 4 minutes max explaining their expanded modules and functionality but that was the end of it. There was no belabored upsell – they focused on solving our core needs.
We really vibed with the team. Everyone on our side, from legal to finance to IT all agreed that the chemistry was the best with this group. We felt we could grow and innovate with them and that they would be a strong and collaborative partner.
Their references were incredibly strong and validated what we had felt in all of our meetings with them.
Their price was very attractive, we didn’t even negotiate it, but rather asked to be part of future innovation and beta testing for projects down the road.

It's exciting to see the evolution in this space and the ongoing innovation to address the unique needs of procurement teams. It's strange for procurement to finally be center stage, and I'm absolutely here for it.

👀 In Case You Missed It…
The Last 3 Newsletters:

1/ The Repeat Game: Why Procurement Always Negotiates at a Disadvantage
2/ How to Predict Your ProcureTech Timeline (Without a Crystal Ball)
3/ The Most Important Requirement That’s Not in your RFP

2 other ways we can help this week:

New to Digital Procurement? Start Here. We're opening up free access to our Digital Procurement 101 video course until May 6th. No fluff. Just the foundational knowledge you need to navigate procurement technology with confidence. If you enjoy it, please leave a 5-star review. It helps!
Grab your free access.
ProcureTech Unpacked (our inaugural 100% virtual conference) is happening April 22–24, 2026. Three half-days built around two things: making you at least one industry friend who's as serious about procurement transformation as you are, and walking away knowing how to navigate the ProcureTech market without getting played by vendor marketing. That's it. No fluff.
Get your tickets.

See you next week {{FIRST_NAME|readers}},

— The Pure Procurement Newsletter Team

P.S. Please rate today’s newsletter.
Your feedback shapes the content of this newsletter.

The Repeat Game: Why Procurement Always Negotiates at a Disadvantage

Joël Collin-Demers — Mon, 30 Mar 2026 01:21:47 +0000

A rchive | Upgrade to Premium | Sponsor

Hi {{FIRST_NAME|readers}},

Two events worth flagging before we get to tonight's note.

ProcureTech Unpacked (April 22-24): 100% Virtual. This is right around the corner.
Three half-days, solution deep-dives, peer breakouts, and a format designed to make you smarter about the ProcureTech market (not sold to). If your organization is turning to you for answers on digital procurement, this event is specifically designed for you.
If you haven't grabbed your spot yet, there's still time.

Apply for a Spot

Zip Forward (April 16th): London, UK. I'll be speaking on the executive track about “The Great Convergence” in procurement technology and what it means for your procurement technology roadmap.

If you’re thinking about making procurement technology investments in the near future and want to avoid mistakes, I think you’ll find this session worthwhile.

If you're in-person, come say hi. Would love to meet some of you face to face. If you’re not, I’ll try to get you the replay 😉

Learn More

Now. Something a bit different tonight.

A few weeks ago we ran a Q&A with Debadatta Dash on next-gen SAP Ariba. You loved it. Like, really loved it. So we're doing it again!

This time I sat down with Eldar Tuvey, Co-Founder and CEO of Vertice. Two cybersecurity exits totaling $600M+. And a very different lens on procurement than most founders in the space.

I wanted to understand what makes him tick, how he sees the market, and what he knows about software pricing that most procurement teams don't.

Let us know how you enjoy this one.

Onwards!

📰 In this week’s edition:

📄 Best Intake-to-Procure Software 2026 - Analyst Report (sponsored)
🌙 The Repeat Game: Procurement’s Disadvantage
📢 This week’s “Must Reads”
🏆 The Road to the ProcureTech Cup: Episode 23
📋 3 procurement jobs that caught our eye

Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.

Q&A with Vertice CEO: Eldar Tuvey

A conversation about data moats, guaranteed savings, and why the procurement team is always at a disadvantage in the repeat game.

Eldar Tuvey is the Co-Founder and CEO of Vertice, the intelligent procurement platform processing $30B+ in direct and indirect spend across 30+ countries, with benchmarking data on 16,000+ vendors. Before Vertice, Eldar co-founded ScanSafe (acquired by Cisco, $200M) and Wandera (acquired by Jamf, $400M).

We recently sat down with him to get his take on the company, his journey and his thoughts on the ProcureTech market at large.

“I'm not proud of it, but we knew that some of our customers were paying five times more than another customer for the same thing…”
Edlar Tuvey

Q: You built two successful cybersecurity companies: ScanSafe and Wandera and exited both for a combined $600M+. You were deep inside the world of selling enterprise software. How does someone go from a cybersecurity company exit to building a procurement platform? Make this make sense…

Eldar: Honestly, I wanted to solve a problem I had running those two businesses... We grew very fast. We were selling a lot of software, but we were also buying a lot of software.

And we saw that just buying software, renewing it, trying to negotiate new purchases, it was such a drag. So difficult, so slow, and every single time there were increased costs because of more usage, more modules, more capabilities that we needed.

We also saw a huge variance in what we were paying compared to other founders I would talk to. It seemed like a broken process.

But the biggest thing? It was a drag on innovation and productivity. These wasted cycles, spending months trying to buy a new CRM or another tool, stopped us from moving fast. You want your best people building the company, not negotiating with vendors and running RFPs and testing software for months.

Q: And I’m guessing you had a unique vantage point because you were also selling software to thousands of customers? Could you see the pricing disparity from the vendor side too?

Eldar: Exactly. And I'm not proud of it, but we knew that some of our customers were paying five times more than another customer for the same thing. Because software's marginal cost is zero (or has been, until the AI age), the pricing swings are enormous.

Buy in Australian dollars? Cheaper. Come at the end of a quarter? The sales rep might discount more. Pay upfront? Different discount again. Sometimes you're a better negotiator, sometimes you're not, sometimes the sales rep is better, sometimes they're not.

All of these things lead to huge variations. There's sometimes a 10x difference between what customers pay for the exact same product.

Q: Ah so Vertice was born out of that frustration… So where this is all going from your vantage point...? What do you see the role of procurement morphing into over the next three to five years?

Eldar: I don't think teams will necessarily shrink much, but the skill sets will shift. I think procurement will rely more on outside parties for expertise, data sources, AI, and specialist agents for running certain functions.

Department heads and procurement leaders will need to really understand the latest technologies… have an in-depth view of their position on AI. What is good AI? How should they think about it? They need to identify automation opportunities, implement them across the department, and train people to get the most out of it.

And critically, procurement is going to need to leverage; insights exactly at the point of decision-making. Not in a report they read three weeks later… At the moment they're doing the approval, taking the next step.

Lastly, procurement leaders are going to need to be able to talk about business and technology. Understand their business intimately, but also understand technology intimately.

Q: You just mentioned data… Vertice has $3.4 billion (probably more by now) in negotiated spend data. What does that change in terms of what you're able to do, especially in the age of AI?

Eldar: AI functionality is something we've invested in very significantly over the last 24 months. It really helps us bring our proprietary data from all these negotiations together for customers.

Not just for software purchases… Software, hardware, telecommunications, and other indirect spend categories that our customers put on the platform, we see all of it. And then there's a network effect. Each new customer basically gets to share in that data (anonymized and private, obviously), so they understand where they rank relative to their peers.

AI is going to be super helpful in providing pricing intelligence, recommending actions, benchmarking against your peer group. It really helps you scale procurement judgment, by giving you insights exactly when you need them.

Now, I think Gen AI is a little bit overhyped right now… AI is never going to take over all of procurement responsibilities. But procurement-specific data and training is essential. The crux is the store of the data. You can't just run everything on generic AI, someone still needs to identify the demand. What does this organization actually need in terms of new tools, agencies, contractors?

Q: And that's a key distinction! An LLM sitting on top of publicly available internet data is going to give you an average answer; a reversion to the mean... But a finely-tuned LLM sitting on a proprietary dataset of 100,000+ actual negotiations... That’s something else entirely, right?

Eldar: We've done something like 100,000 different negotiations for our customers. We've got millions of data points on all of those. What works well, what doesn't. How long they take. Who the best person is to deal with. How many steps there are, how long between tasks, how long to get an approval.

We know everything about those negotiations. All the emails sent back and forth, all the Slack messages, all the Zoom transcripts. And we use that data, that knowledge gathered through trial and error over many years, to train our AI tools. So our customers essentially touch a button and have access to all of that insight for their own negotiations.

Interesting… There seems to have been market validation for this too? 13x revenue growth over two years. #2 on the Sunday Times 100 Tech 2026. What's been the biggest surprise in that growth journey? What’s been harder than expected?

Eldar: Great question. I've built two relatively successful businesses before. Both exited, one to Cisco, one to Jamf… I've never seen anything like it in terms of product-market fit. It's been spot-on from the moment we started.

We're solving a problem that everyone has. I've never gone to a customer who said "Oh no, everything's perfect. I don't need you." Perhaps they want to do it themselves. Perhaps they use a competitor. But I've never met a customer who says they don't have a problem.

In terms of what's working, we have a great team, and you add AI on top and you get 5x productivity.

What's harder than expected? Competition has never been fiercer. A lot of new entrants, well-funded, which makes the competition intense. But that keeps you on your toes.

And finding talent is hard. We're growing so fast that we continuously need to grow the team, specifically procurement specialists who understand vendors intimately. That's a scarce resource.

Q: Let's talk competitive advantage. You've mentioned data, team quality, the vendor touch points. Does Vertice have another unfair advantage?

Eldar: Yes, and as you mention, a few things come together.

First, the data. We have something like 16,000 vendors in our database with live pricing benchmarks and negotiation playbooks for each one.

Our AI tools are trained on all of this real-world procurement, tens of thousands of contracts, something like a million human-to-human email and call interactions. All updated in real time.

Second, the visibility we have into a customer's entire tech stack. Their complete indirect procurement spend, usage, duplications, risk from vendors. That total understanding of their processes and inefficiencies gives us a real edge.

Third, and this is the one I'm most proud of, predictive pricing. Not just historical benchmarks, but forecasting what a customer can expect to pay. We've seen so much data that we can forecast very accurately where their spend is going to go. If a customer knows where their spend will be in the next 12 months or three years, they can adjust accordingly. See it sooner, act faster, make better decisions.

And all of it is supported by our specialist procurement experts. We still believe in humans. AI tools cut out manual work, automate tasks, speed things up, and can make connections across your entire spend that a human might miss. But the human relationship with customers, that's still critical.

Q: And then there's the “repeat game”, right? When a customer is dealing with Salesforce, they do it once a year, maybe once every three years. You're dealing with Salesforce how often?

Eldar: Twenty to thirty times a week. We understand exactly how they work. They understand how we work. It makes the process so much easier.

The customer is always at a disadvantage because of the repeat game. They're doing it once every three years. We're doing it constantly.

Q: And am I mistaken or in certain engagements, you actually guarantee savings? That's pretty bold in an industry full of empty promises. How does that work?

Eldar: Because we can forecast so accurately, we can offer customers a multiple of our fee in guaranteed savings. We give them a 3x, 4x ROI on what they're paying us.

CFOs and CPOs know they're going to generate hard ROI with a minimum guarantee, and they're confident to proceed. We've not really ever had to rebate a customer because we just over-deliver.

We sell outcomes, not aspirations. Everyone's been talking about how AI needs to price on outcomes and not on seats… That's what we've been doing for four years. We guarantee savings, and if we don't deliver, they get their money back.

When you're selling to procurement and finance, that's what builds confidence in my opinion.

Q: Shifting to a question our newsletter audience might have... A lot of CPOs and procurement leaders are reading this and evaluating tools. What questions should they be asking vendors that most people don't think to ask?

Eldar: Three things.

First: adoption. How will they ensure business users and procurement users actually adopt the tool? Because they're different user groups... Understanding adoption is key.

Second: integrations. What native integrations do they have? Slack, Teams, SSO, ERPs, which tools in your existing stack can they actually connect with? That's absolutely critical.

Third: innovation roadmaps. Are these guys going to be there for me as the market changes? I've been around the block and I've never seen the market move this quickly. You need belief that your vendor is going to be able to cope with the changes, that they'll innovate, that they've historically delivered on their roadmap. If they've done it in the past, you can assume they'll continue.

Q: On integration specifically, every customer is a "world first" in the sense that they all have different system combinations, different configurations, custom field usage. How does Vertice handle that complexity?

Eldar: Out of the box, we have a huge number of integrations: ERP systems, CLM, ticketing systems, HRIS. We have open APIs for syncing data across all these systems and flexible data mapping. We have an integration layer that scales with our customers and orchestrates across all of these disconnected systems.

For a younger company establishing itself, being able to work with the existing tools that customers have is crucial. We've not come across a customer yet who's told us about a system that we can't integrate with in some way.

Q: Do you need a systems integrator (SI) to deploy Vertice?

Eldar: Absolutely not. We have an onboarding team to support customers, but most of them just get going by themselves after a bit of training. It's super intuitive. And if they need help, we're there.

Q: Coming back up for air from the weeds, what's the biggest misconception that even experienced procurement professionals still get wrong about deploying or leveraging technology?

Eldar: It's about making end users' lives easier. Making the team more efficient and insight-led so they can make better decisions.

But in terms of misconceptions, I think process and policy alone don't deliver the value. You need relationships and softer skills where you can really build those relationships with your preferred vendors and actually deliver a better result.

For most of our customers, it's all about growth. They want to grow fast, and procurement is absolutely strategic in enabling them to have the best tools with the right capabilities to build their businesses.

So in my mind, it's not just about enabling process. It's also about enabling relationships.

Q: To that end, you’ve redesigned the intake process in your tool recently, haven’t you? Can you talk about that?

Eldar: One of the key things we did is make our intake form available on a simple URL. Most of our customers promote it to all employees, anyone can start a procurement request.

The intake itself is dynamic. It doesn't ask unnecessary questions. It can be conversational with AI. It's available in Slack and Teams. We're trying to make ourselves absolutely accessible, be the front door, but make it super easy.

And we put insights directly into the intake. If you're asking to buy a license for something that already exists, we tell you. If there's a better alternative, we tell you. We show you how often we see it, whether you have budget, everything we know, right at the beginning of the process, not at the end.

Q: Which could potentially bypass the procurement process entirely, right? "We already have licenses for your need. Just use that!”

Eldar: Exactly. It's all conditional routing. If we've already got it, it doesn't go to procurement. Below a certain spend level, doesn't go to procurement. Low risk (we give risk scores for all vendors), doesn't need the same review. But it’s all according to your own business rules.

We embed all of the insights at the beginning of the process and at the relevant points across the whole workflow. Better decisions made, better outcomes delivered.

Q: Finally, what would you tell folks who have a traditional procurement background, who’ve done their CIPS or other certifications, and have stayed in their lane with “procurement domain expertise”, what's the move now?

Eldar: Get up the learning curve. There's an explosion in procurement tech happening right now. So many new entrants, so much innovation. I've never seen the ecosystem this active. It's definitely gathering steam, and my advice to everyone is: it's time to layer in digital expertise. The people who do will be the ones leading the function in three years.

Q: So to “bite into the fruit of technology”, if you haven't already 😅
Eldar, thanks for sharing your thoughts with our newsletter readers.

Eldar: Thanks for having me!

Readers subscribed to Pure Procurement Premium can view the original video leading to the above Q&A article. Curious? Maybe it’s time to upgrade (or Login)!

👀 In Case You Missed It…
The Last 3 Newsletters:

1/ How to Predict Your ProcureTech Timeline (Without a Crystal Ball)
2/ The Most Important Requirement That’s Not in your RFP
3/ What Is a Conference Room Pilot (CRP) in Procurement Technology?

2 other ways we can help this week:

Want to cut through the AI noise? Most vendors say they “use AI.” Very few tell you which type, where it fits, or what it should actually do in procurement. This free poster helps you sort signal from spin by breaking down the AI subdomains that matter, where they apply, and where they don’t.
Grab the free poster.
ProcureTech Unpacked (our inaugural 100% virtual conference) is happening April 22–24, 2026. Three half-days built around two things: making you at least one industry friend who's as serious about procurement transformation as you are, and walking away knowing how to navigate the ProcureTech market without getting played by vendor marketing. That's it. No fluff. 60% sold out.

Get your tickets.

See you next week {{FIRST_NAME|readers}},

— The Pure Procurement Newsletter Team

P.S. Please rate today’s newsletter.
Your feedback shapes the content of this newsletter.

How to Predict Your ProcureTech Timeline (Without a Crystal Ball)

Joël Collin-Demers — Mon, 23 Mar 2026 01:12:43 +0000

A rchive | Upgrade to Premium | Sponsor

Hi {{FIRST_NAME|readers}},

Something different this week.

We've been working on an authoritative deep dive into the 5 foundational capabilities you need before you deploy AI in procurement.

It's a big piece… 😅

So we're giving you three ways to consume it:

🎥 Live Video. Join me and the Fairmarkit team this Wednesday (March 25th, 11am ET) for a 45-minute executive conversation. Reserve your spot here.
📖 All at once. The full long-form article drops in the next few weeks.
📬🍎 In “5 bites”. One foundation per day over 5 days. This is the experiment. Reply and let us know if you want in. Click this link and we’ll send you Part 1 tomorrow!

A big thank you to Fairmarkit for being open to trying that third format with us. Content partners who let you try weird stuff are the best kind.

Now. Part two.

Speaking of doing the hard work before you deploy... (Foundations!)

Tonight's Sunday Night Note is about that 6-month implementation timeline in your business case.

It's not a forecast. It's a wish… 🧞‍♂️🌈

And a Nobel Prize-winning researcher with 16,000 projects can prove it.

Onwards!

📰 In this week’s edition:

🎥 Before You Deploy AI: The 5 Capabilities You Need (sponsored)
🌙 How to Predict Your ProcureTech Timeline
📢 This week’s “Must Reads”
🏆 The Road to the ProcureTech Cup: Episode 22
📋 3 procurement jobs that caught our eye

Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.

How to Predict Your ProcureTech Timeline

"We'll have it fully deployed in 6 months."

I've heard this sentence hundreds of times. From vendors. From system integrators. From internal project leads who genuinely believe it.

And almost every single time, it's wrong.

Not because people are liars. Not because they're incompetent. But because of something far more insidious: they're building their estimate from the bottom up.

They look at their project. Their team. Their requirements. They map out the tasks, assign durations, add a little buffer (maybe 15%, if they're "conservative"), and arrive at a number that feels reasonable.

Then reality happens:

The data migration takes three times longer than planned.
The change management that was supposed to be "straightforward" turns into a 9-month organizational therapy session.
That integration with your ERP? Nobody mentioned it would require a custom middleware layer.

Six months becomes twelve. Twelve becomes eighteen. And somewhere around month fourteen, everyone pretends the original timeline never existed.

Here's the thing: there's a better way to estimate your ProcureTech projects. And it doesn't require a crystal ball. It requires a history book.

The Planning Fallacy Is Eating Your Projects Alive

Oxford professor Bent Flyvbjerg has spent decades studying why projects fail. His database covers more than 16,000 projects across 136 countries. The findings are brutal.

Only 8.5% of major projects come in on budget AND on time.

Want to add "delivered the promised benefits" to that criteria? That drops to 0.5%.

Half a percent.

For IT projects specifically, the picture is equally grim. McKinsey and the University of Oxford found that 66% of enterprise software projects over $15M experience cost overruns. The average large IT project exceeds its budget by 45% while delivering 56% less value than predicted. And one in six IT projects is a genuine "black swan," with cost overruns averaging 200%.

These aren't obscure academic data points. This is the exposed reality of how projects actually perform versus how we think they'll perform.

Flyvbjerg calls this the "planning fallacy" (a term originally coined by Nobel laureate Daniel Kahneman). It's the systematic tendency to underestimate costs, timelines, and risks while overestimating benefits. And it affects virtually everyone, from governments building high-speed rail to procurement teams deploying a new sourcing platform.

The kicker? The planning fallacy isn't about stupidity. It's about perspective.

The Inside View vs. The Outside View

Here's what happens when you plan a ProcureTech project the "normal" way:

You sit down with your team. You list the tasks. You estimate durations. You factor in the things you know about your specific situation (your data quality, your team's bandwidth, your stakeholder landscape). You build a bottom-up plan.

This is what Kahneman and Flyvbjerg call the "inside view."

It feels rigorous. It feels detailed. It feels like the responsible thing to do.

And it's almost always wrong.

Why? Because the inside view treats your project as unique. It focuses entirely on the specifics of this deployment, this team, this organization. It ignores the exposed base rate of how similar projects have actually performed in the real world.

It's like estimating how long your kitchen renovation will take by carefully planning every step, while ignoring the fact that most kitchen renovations go over schedule.

The "outside view" (or Reference Class Forecasting) flips this on its head.

Instead of starting from the inside out, you start from the outside in:

Step 1: Identify a “reference class”. Find a set of past projects comparable to yours. Deploying a new S2P suite? Look at other S2P deployments. Implementing an Intake & Orchestration platform? Find organizations that have already done it.
Step 2: Gather actual outcome data. Not what those projects were planned to cost or take. What they actually cost. How long they actually took. What benefits they actually delivered (ideally directly from someone who has no incentive to modify the numbers…)
Step 3: Position your project within that distribution. Use the statistical reality of those outcomes to anchor your estimate (instead of bottom up planning). Then adjust for your specific circumstances, but only at the margins.

"But Our Project Is Different..."

I can already hear the objections. This feels way too easy…

"Our situation is unique."
"We have a great implementation partner."
"We've done thorough requirements gathering."
"Our vendor has a proven methodology."

Every single project team says this. And Flyvbjerg's database of 16,000+ projects tells us that virtually every single one of them is wrong.

Your project is not as unique as you think. That's not a criticism. It's a statistical fact.

The S2P deployment you're planning? Hundreds of organizations have done it before you. The data migration challenges you'll face? They've been faced (and usually underestimated) before. The change management hurdles? They're predictable, because they follow patterns.

The organizations that get this right aren't the ones with the best plans. They're the ones that take the “outside view” seriously, before they ever build the “inside view”.

What This Looks Like for ProcureTech

Let’s make this practical.

Imagine you're building a business case for a new procurement platform. Your vendor says implementation will take 6 months. Your SI partner agrees. Your internal team maps out the workstreams and lands on 7 months (because they're being "realistic").

Now apply reference class forecasting:

You research (or ask around) how long similar deployments have actually taken at comparable organizations. Not the vendor's best-case reference customer. Not the case study on their website. The actual, unvarnished reality across a meaningful sample (not a single reference call).

You'll probably find that the real distribution looks something like this: the fastest deployments took 8-9 months. The median was 12-14 months. And a meaningful chunk (let's call it 20-30%) took 18+ months.

Your 7-month estimate? It's not at the optimistic end of the distribution. It's off the distribution entirely.

Now you have a choice. You can ignore this data and proceed with the inside view. Or you can anchor your business case to reality.

The teams that anchor to reality don't just get better estimates. They make better decisions. They budget for adequate change management. They phase their rollouts more intelligently. They set expectations with leadership that are actually achievable.

And when the inevitable surprises happen (because they will), they have contingency built in rather than scrambling to explain why everything is behind.

Think Slow, Act Fast

Another core principle pairs perfectly with reference class forecasting: "Think slow, act fast."

Most ProcureTech projects do the opposite. They rush through planning (because everyone's excited, the vendor is eager, and the CFO wants ROI yesterday) and then slog through execution as reality catches up.

The teams that win spend more time upfront. They gather reference class data. They run experiments. They pilot. They de-risk before they commit.

Then, once they start building, they move fast because they've already answered the hard questions.

I've written before about the Pixar parallel: “you build the story before you animate.”

In ProcureTech terms, you prove the concept before you deploy the platform. Reference Class Forecasting is how you pressure-test your story against what's actually happened to everyone else who tried to tell the same one.

Where to Find Your Reference Class

This is where it gets tricky for procurement, because our industry isn't great at sharing real implementation data. Vendor case studies are marketing materials (sorry, not sorry). Analyst reports give ranges but rarely expose the full distribution. Conference presentations cherry-pick success stories with people willing to share them.

So where do you look?

Your own organization's history. How did your last technology deployment actually perform against its original business case? What about a suite for sales (Salesforce), IT (ServiceNow), or another business function? If you've never gone back to check, that's a problem worth fixing.
Peer networks. Talk to procurement leaders off the record who have deployed similar platforms. Not "how did it go?" But "what was your original timeline, and what was the actual timeline?" You'd be surprised how candid people are when you ask the right question.
Implementation partners. A good SI will have data on dozens of comparable deployments. Ask them not for the best case, but for the distribution. If they can't (or won't) share it, that tells you something.
Industry benchmarks. Just ensure you’re looking into the data gathering method… People have a tendency to remember better stats than what happened in reality when surveys are in play…

As with anything, you need to consider how the data was gathered, who’s presenting the data and what their inherent biases and incentives are… This will color the analysis.

The Prisoner's Dilemma in Your RFP

Here's something else nobody talks about: the process you use to gather planning data is structurally designed to give you bad planning data.

Think about what happens during an RFP or vendor evaluation. You ask three vendors and two SIs for implementation timelines and cost estimates. Each one knows they're being compared against the others. Each one knows that whoever comes in with the lowest cost and shortest timeline typically has the best shot at winning.

This is a textbook Prisoner's Dilemma.

Every vendor and SI is incentivized to give you their best-case scenario, not their realistic one. Because if Vendor A says "12 months" and Vendor B says "8 months" (for the same scope), Vendor B wins the conversation. Even if Vendor A was being honest and Vendor B was being... optimistic.

Nobody wants to be the one who says "this will actually take 18 months and cost twice what the other guys quoted." Even if that's the truth. Especially if that's the truth.

This is called "strategic misrepresentation": deliberately understating costs and timelines to get a project approved. It's not always malicious. Sometimes vendors genuinely believe their best-case numbers… But the competitive structure of an RFP makes the problem worse, because it rewards the most aggressive estimate, not the most accurate one.

And here's the uncomfortable part: sometimes you want the best-case numbers too.

Because a business case that says "18 months and $1.2M" doesn't get approved. A business case that says "9 months and $600K" does. You know the real number is probably somewhere north of the vendor's estimate, but if you put the realistic figure in front of your CFO, the project dies before it starts. So you take the optimistic number, add a modest buffer, and tell yourself you'll "manage it tightly."

The vendor is incentivized to understate. You're incentivized to let them. And now everyone is building a plan anchored to a number that nobody actually believes.

This is the planning fallacy and strategic misrepresentation working together, and it's the single biggest reason ProcureTech projects blow up their timelines and budgets. Not because anyone lied. Because the system made honesty expensive.

So what do you do?

Recognize when the Prisoner's Dilemma is present. Any setting where vendors or SIs are competing for your business is a setting where their planning data is structurally biased toward optimism. That doesn't mean their estimates are useless. It means you should treat them as floor estimates, not expected outcomes.
Gather your reference class data in settings where the dilemma doesn't exist. Peer conversations, user group discussions, post-implementation retrospectives, independent research. These are contexts where people have no incentive to shade the numbers. The procurement leader who deployed the same platform two years ago and is telling you over coffee that it took 14 months instead of the promised 8? That's your reference class talking. Listen to it.
Ask vendors the right question. Instead of "how long will this take?", try "across your last 20 deployments of similar scope, what was the range of timelines from fastest to slowest?" If they only want to talk about the fastest one, you have your answer.

The Bottom Line

Reference class forecasting isn't pessimism. It's realism.

And it works. The method was so effective that the UK Government officially adopted it as mandatory guidance for major transport projects through the Department for Transport. The American Planning Association endorsed it, recommending that planners should never rely solely on conventional “bottom up” forecasting.

Multiple studies across infrastructure, energy, and IT have confirmed that projects using reference class forecasting produce significantly more accurate cost and schedule estimates than those relying on traditional bottom-up planning alone.

It doesn't mean every project will fail. It means your estimate should reflect how projects like yours have actually performed, not how you hope yours will perform.

The math is simple: if you anchor your plans to the inside view, you're betting against decades of empirical evidence. If you anchor to the outside view, you're giving yourself a fighting chance.

Next time someone tells you their ProcureTech deployment will take 6 months, ask one question:

"Can you show us how long your last 10 comparable deployments took? Not the 10 best ones. The last 10…"

If things start to get dicey, 6 months isn’t an estimate… It's a (MS Project backed) wish. 😅

👀 In Case You Missed It…
The Last 3 Newsletters:

1/ The Most Important Requirement That’s Not in your RFP
2/ What Is a Conference Room Pilot (CRP) in Procurement Technology?
3/ The Pixar Method for Procurement Transformation

2 other ways we can help this week:

A Skeptic’s Take on AI in Procurement. Our consulting principal recently took the stage at Zip Forward: LLM market overview, vendor motivations, and a framework to chart your own path… Without the hype. Watch the replay.
ProcureTech Unpacked (our inaugural 100% virtual conference) is happening April 22–24, 2026. Three half-days built around two things: making you at least one industry friend who's as serious about procurement transformation as you are, and walking away knowing how to navigate the ProcureTech market without getting played by vendor marketing. That's it. No fluff. 60% sold out.

Get your tickets.

See you next week {{FIRST_NAME|readers}},

— The Pure Procurement Newsletter Team

P.S. Please rate today’s newsletter.
Your feedback shapes the content of this newsletter.

The Most Important Requirement That’s Not in your RFP

Joël Collin-Demers — Mon, 16 Mar 2026 01:00:00 +0000

A rchive | Upgrade to Premium | Sponsor

Hi {{FIRST_NAME|readers}},

Quick riddle this week before we dive in:

How do you pay thousands of "tail spend" suppliers at scale without:

Creating supplier records for each one in your ERP
PCards,
Buying everything on Amazon,
Or…
Asking employees to run expenses through Expense Reports

Every procurement team I've worked with has some version of this headache.

You've got hundreds (sometimes thousands) of low-value, one-time or infrequent suppliers (Your “Tail Spend”). Each one technically needs a vendor code, bank details, tax information, compliance checks...

For a strategic supplier worth millions a year, that onboarding effort makes sense.

For a $500 one-time purchase? It's a bazooka to kill a fly. 😅

The answer to this riddle?

You stop trying to onboard them all…

Instead, you let a partner handle the onboarding, the buying and the payment on your behalf. You have one supplier record in your ERP. Thousands of suppliers paid behind the scenes. Your finance team doesn't touch any of it.

Our friends at Axiom are launching MarketPay, which does exactly this.

It connects the full tail spend process (buying through payment) end-to-end, integrated directly with your ERP. One supplier record on your side. Thousands of suppliers paid on theirs.

If tail spend gives you nightmares, this is worth a look if only to understand the concept.

Now, onto tonight's main event. A story about how a thorough vendor evaluation process (e.g. RFP)can (and will) still miss something critical... So what are you to do?

The answer tonight.

Onwards!

📰 In this week’s edition:

🌙 A 2,000+ Requirement RFP Won’t Protect You from This...
📢 This week’s “Must Reads”
🏆 The Road to the ProcureTech Cup: Episode 21
📋 3 procurement jobs that caught our eye

Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.

A 2,000+ Requirement RFP Won’t Protect You from This...

We were weeks away from go-live. Everything was on track.

The functional requirements? Check. Non-functional requirements? Done. The business case? Approved. IT had signed off on privacy assessments, cybersecurity reviews, architecture discussions, the whole nine yards. We followed the playbook. Best practice requirement lists, stakeholder reviews, the works.

Then, in a routine testing conversation with the vendor during deployment, someone asked a simple question:

"How do we connect this to our centralized identity access management (IAM) system?"

Silence.

😬

For the non-technical folks: Identity and Access Management (IAM) is basically how a company controls who gets access to what software without losing their minds…

Think of it as the master keychain for your company’s entire technology stack. Someone joins the company as a category manager? One click and they get access to every system they need, from your ERP to your sourcing tool to your HR system. Someone leaves? One click, access revoked everywhere.

It's the kind of thing you don't think about until it's not there.

And this vendor? They didn't have it.

No centralized IAM support. None. Zero.

Now, for this particular client, that was a massive deal. They manage security and access centrally through an automated process. Their user access management team is tiny by design, because they don't need to manually provision accounts across 200+ applications. The system does it for them.

Without IAM integration, that elegant, automated process suddenly has a manual hole in it. For one application, sure, you can live with it. But the precedent it sets? The operational debt it creates? That's how "small gaps" become big problems over time.

Here's the thing though. This requirement wasn't buried in some obscure corner of the IT architecture document that nobody reads. IAM is pretty standard stuff. It just... slipped through the cracks of a stakeholder-laden procurement process where everyone assumed someone else had covered it.

And that's the point.

You can run the most rigorous, best-practice-driven vendor selection process in the world, and there will still ALWAYS be gaps.

There are easily 2,000 potential functionality requirements for any serious ProcureTech deployment. Your RFP might cover 500 of them. Maybe 800 if you're really thorough. But somewhere in the remaining 1,200, there's a little thing waiting to become a big thing at the worst possible time.

Which brings me to what actually matters...

In that moment, what I know to be true became painfully clear: a vendor's "ability to deliver" and "openness to co-innovate" are what make or break projects.

When we flagged the IAM gap, the vendor didn't flinch. No finger-pointing. No "well, it wasn't in the contract." No escalation theater.

Instead, they said something beautiful:

Issue resolved. Project saved. Relationship strengthened.

Now, I don't want you to imagine the alternative... but I'm going to make you anyway.😅

Escalation meetings. Finger-pointing about "what was in scope." Legal teams getting involved. Project delays. A steering committee that starts questioning the entire initiative. Three months later, a "failed project" that was actually 95% successful but got torpedoed by a login button.

All of this, for 1 of 2,000 potential functionality gaps that could have slipped through anyone's process.

So how do you protect yourself from this possibility?

Not with more requirements. You'll never catch them all…

You protect yourself by picking the right partner.

And that starts way before go-live.

The Big Fish, Small Pond Problem

Here's something most people don't factor into their vendor evaluation: your relative importance in the vendor's client portfolio.

In our story, the vendor prioritized the fix because this client mattered to them. They weren't account #4,782 in a sea of enterprise logos. They were a meaningful relationship that the vendor was invested in.

That dynamic isn't accidental. It's strategic.

If you're a mid-market company deploying a platform built for Fortune 50 enterprises, you might get a great tool, but when something breaks (or is missing), you're in line behind 200 other clients with bigger contracts and louder voices.

On the flip side, if you're one of the larger accounts for a growing vendor, you're not just a customer. You're a design partner. Your feedback shapes the roadmap. Your gaps get prioritized. Your calls get returned.

Sometimes the "objectively better" platform is the wrong choice, because you'll never have the leverage to get what you need from it.

This doesn't mean you should always pick the small vendor. But it does mean you should understand where you'll sit in the pecking order, and what that means when (not if) you need something that isn't on the roadmap today.

The Reference Calls Nobody Does Right

"Can you provide three client references?"

Every RFP asks this. Every vendor hand-picks their three happiest customers. You schedule the calls, hear glowing reviews, check the box, and move on.

That's not a reference check. That's a testimonial reel.

If you want reference calls that actually protect you, you need to change what you ask, and who you ask about.

First, stop asking references to confirm the vendor is good. Start asking them to describe how the vendor behaves when things get messy. Here are a few questions that have saved me over the years:

"Tell me about a time something went wrong during implementation. What happened, and how did the vendor respond?"
"Have you ever discovered a functionality gap after go-live? How was it handled?"
"How easy is it to get something onto their product roadmap? Do you have a direct line to product management, or does everything go through your account rep into a black hole?"
"Is there a customer advisory board? A roadmap review? Or do you find out about changes when the release notes hit your inbox?"

These questions tell you more about your future experience than any demo ever will.

Second (and this is the one most people miss entirely): don't just check references at the vendor level. Ask vendors who will actually be staffed on your project (assuming you can respect your start date commitments 😅), and then check references on those specific people by name.

The vendor might have an A-team that closes deals and shows up for implementation kickoffs. But the people doing the day-to-day configuration, the testing, the training? Those are the people who determine whether your project succeeds or fails.

Ask for their names. Then ask the vendor's other clients: "Have you worked with [name]? What was that experience like?"

You'd be surprised how many vendors have never been asked this. And you'd be even more surprised by how much the answers vary depending on who gets assigned to your project.

The Question That Actually Matters

When it comes down to it, picking software vendors isn't about who has "the best" tool on a feature comparison spreadsheet. ProcureTech success is about partnering with a team of humans who will have your back, be flexible (within reason), and get you to the business outcomes you're actually after.

Features can be compared in a demo. Roadmaps can be shared in a presentation. But the willingness to say "let's figure this out together" instead of "that's not our problem"?

That only shows up when things go sideways.

And things always go sideways.

So next time you're evaluating ProcureTech vendors, sure, run the RFP. Check the boxes. Score the requirements.

But then ask yourself the question that actually matters: When we inevitably discover something we forgot to ask about, what will this vendor do?

That answer is worth more than every line item on your evaluation scorecard combined.

👀 In Case You Missed It…
The Last 3 Newsletters:

1/ What Is a Conference Room Pilot (CRP) in Procurement Technology?
2/ The Pixar Method for Procurement Transformation
3/ Next-Gen SAP Ariba: An Insider's View from the Beta Program

3 other ways we can help this week:

You have a question for Joël? He’s hosting a free Ask Me Anything session on Vertice’s WhatsApp community this Wednesday, March 18th 2026 at 12pm ET. You have ProcureTech questions, want to know his favorite color or how to build a birdhouse? Everything is fair game. Join the discussion here.
Want to cut through the AI noise? Most vendors say they “use AI.” Very few tell you which type, where it fits, or what it should actually do in procurement. This free poster helps you sort signal from spin by breaking down the AI subdomains that matter, where they apply, and where they don’t. Grab the free poster.
Need a cleaner way to get buy-in for ProcureTech investments? A roadmap only works if people outside procurement can actually understand it. This template helps you turn a complex ProcureTech plan into a one-page story executives, IT partners, and stakeholders can follow without getting lost in the weeds. Grab it here.

See you next week {{FIRST_NAME|readers}},

— The Pure Procurement Newsletter Team

P.S. Please rate today’s newsletter.
Your feedback shapes the content of this newsletter.

What Is a Conference Room Pilot (CRP) in Procurement Technology?

Joël Collin-Demers — Mon, 09 Mar 2026 01:15:49 +0000

The Conference Room Pilot (CRP): A How-To

Most project teams that blow their system go-live have one thing in common: they skipped the dress rehearsal.

They tested modules in isolation. They signed off on demo scenarios they believed looked like their actual processes. They trusted that everything would "come together" once they were live. It didn't. The Conference Room Pilot (CRP) exists precisely to prevent that. And almost nobody does it well (if at all…).

Most of what's been written about Conference Room Pilots treats them as a narrow, software-centric exercise. Show up, click through the system, tick a box, move on. That framing misses the entire point.

A well-executed CRP isn't primarily about the software. It's about stress-testing your processes, people, and assumptions… together, in real time, before any of it touches production. This matters whether you're a CPO signing off on a $1M Source-to-Pay Suite Go-Live or a procurement manager trying to keep a new intake process from falling apart on day one.

The Conference Room Pilot (CRP): A How-To
What Is a Conference Room Pilot (CRP)?
- The Classic Definition… And Why It's Too Narrow
The Real Value of a CRP Has Nothing to Do With Sof …
- Process Simulation Over System Demonstration
When to Run a Conference Room Pilot
What a CRP Actually Looks Like
- A CRP in Practice: New Supplier Onboarding
- What You're Actually Testing
The 6 Things a CRP Will Expose (Before It's Too La …
Are You Ready to Run a CRP? The CRP Readiness Chec …
Who Needs to Be in the Room
- The CRP Facilitator Role
CRP vs. UAT: Stop Confusing These
A Note for Procurement Leaders: What the CPO Needs …
The Bottom Line

What Is a Conference Room Pilot (CRP)?

A Conference Room Pilot (CRP) is a structured simulation exercise where key stakeholders walk through end-to-end business processes (step by step, in real time) to validate that a new system, process design, or workflow change will actually function as intended in the real world.

The classic definition focuses on software: you configure a demo environment, gather your end-users, and run your core business processes through the new system before committing to go-live. The goal is to validate that the application does what it's supposed to do before you're fully committed to it.

That definition isn't wrong. It's just incomplete.

The Classic Definition… And Why It's Too Narrow

The conventional framing positions CRP as a testing activity; something you do to check whether the software works. Most ERP and Source-to-Pay Suite implementation methodologies treat it as a checkpoint between system design and user acceptance testing (UAT).

But here's what that framing misses: the value of a CRP isn't the software validation (the “pilot” part). It's the conference room…

When you gather a requester, category manager, a finance approver, a purchase order processor, an accounts payable clerk and an IT system owner in the same room and walk through a single purchase order from requisition to payment, things surface that no requirements document, no workshop, and no demo ever would. Assumptions get challenged. Handoffs break down. People realize they had completely different mental models of "how this is supposed to work."

That's the real return on a CRP. And critically, you don't need a configured software environment to get it.

The Real Value of a CRP Has Nothing to Do With Software

Let's be direct: the insight-generating mechanism of a conference room pilot is not the software. It's the simulation. It's what happens when real actors perform real activities, in sequence, together… And you see where the process will actually break.

A CRP is your procurement transformation fire drill.

Process Simulation Over System Demonstration

The distinguishing feature of a CRP (versus a vendor demo, a UAT session, or a training workshop) is that it simulates the process flow, not just the technology.

That means:

Real actors perform the activities they will own post-go-live
Information handoffs between roles are explicitly executed (not assumed)
Edge cases and exceptions are deliberately introduced, not avoided
Process breaks (moments where the simulation stalls because nobody knows what to do next) are treated as findings, not failures

This distinction matters enormously. A vendor demo is choreographed to show the system at its best. A UAT is a scripted validation of pre-agreed requirements. A CRP is a stress test of your operating model, with or without a system in the room.

When to Run a Conference Room Pilot

Here's the short answer: any time you are thinking about changing a cross-functional business process, a CRP belongs in your toolkit. Full stop.

It doesn't matter whether the trigger is a new software implementation, a process redesign initiative, a policy rollout, or an internal operating model change. If the process touches more than one team (if information crosses a departmental boundary, if an approval chain involves multiple functions, if the output of one team's activity becomes the input for another's), then you have a cross-functional process. And cross-functional processes are exactly where the most dangerous assumptions live.

The reason is straightforward: no single stakeholder group owns the full picture. Procurement understands the sourcing and purchasing steps. Finance owns the payment and accrual logic. The business understands what they actually need and when. Legal knows what the contract requires. IT knows what the system can and can't do. None of them, in isolation, can validate that the end-to-end process works. That validation only happens when all of them are in the room at the same time, walking through it together.

A CRP is how you create that moment deliberately, before it matters.

You can use this tool at different steps in the transformation lifecycle:

A CRP run during a Source-to-Pay vendor selection looks different from one run mid-implementation (which looks different again from one run to validate a new internal intake workflow with no software in sight).

But the objective is identical in every case: validate that the new end-to-end process design actually works, and that every stakeholder group involved genuinely understands their role within it.

Those are two distinct things, and both matter. A process can be logically sound on paper and still collapse in practice because the people running it have different mental models of what each step actually requires. The CRP tests both simultaneously… And it's the only exercise that does.

What a CRP Actually Looks Like

Let’s use procurement processes as an example.

First, a scoping point that most guides get wrong: you don't run a CRP for "procurement." You run one for a specific process (or a specific subprocess) that is changing. The scope of your CRP should match exactly the scope of the change you're making.

Redesigning how new suppliers get onboarded? That's your CRP scope. Changing how contract renewals get initiated and approved? That's a CRP. Rolling out a new exception handling workflow for invoice disputes? Run a CRP for that, and only that. You're not trying to simulate the entire Source-to-Pay lifecycle in a single session. You're stress-testing the specific process that is actually changing, with the specific people it affects.

That framing matters because it keeps CRPs tractable. A focused two-hour session on a well-scoped subprocess will surface more useful findings than a bloated full-day exercise that tries to cover everything and ends up validating nothing properly.

A CRP in Practice: New Supplier Onboarding

Let's make it concrete with a subprocess that touches multiple functions and carries real operational risk: new supplier onboarding.

Your organization is changing how suppliers get set up: new data requirements, a revised risk screening step, a different approval chain before a supplier can receive a purchase order. You run a CRP before the new process goes live.

You block a half-day. You bring in the people who will actually execute each step. You start at the process trigger and don't skip anything.

The trigger: A category manager wants to engage a new IT services supplier. What kicks off onboarding? Who sends the request, to whom, and in what form?
Information collection: What does procurement ask the supplier to provide? Who chases missing information? What happens if the supplier is slow to respond? Does the process stall, or is there an escalation path?
Risk screening: Who runs the screening check? Procurement, legal, compliance, or a combination? What does "approved" actually mean here, and who has the authority to sign off on a borderline result?
Financial and banking setup: Who captures supplier banking details? Who in Finance validates them? At what point in the process does this happen? What prevents a PO being raised before it's complete?
System setup: Who creates the supplier record in the ERP or ProcureTech system? What data fields are mandatory? What happens if a field is missing or incorrect?
Handoff to operational use: How does the category manager know the supplier is live and ready to transact? What does that notification look like, and from whom does it come?

Walk through that sequence with your category manager, your procurement operations lead, your Finance AP contact, your compliance officer, and your IT system owner (all in the same room, all executing their actual steps in real time).

You will find gaps. You will find the step that three people thought someone else owned. You will find the data field that nobody is responsible for collecting. You will find the approval that everyone assumed was someone else's call.

That's the CRP doing its job.

What You're Actually Testing

The process steps are almost a vehicle. What you're really validating is:

Role clarity: Does everyone know what they are responsible for at each step? Not in theory, but when it's actually in front of them?
Information completeness: Is the data available when it's needed, in the format it's needed, collected by the person who is supposed to collect it?
Handoff integrity: When procurement passes to finance, or compliance to IT, does the handoff have a named owner on both sides? Or does it land in a void?
Exception resilience: When something goes wrong (a supplier fails a screening check, a banking detail doesn't match, an approver is unavailable) does the process handle it, or does it silently stall?

The 6 Things a CRP Will Expose (Before It's Too Late)

Across every procurement CRP (software-backed or not), the same categories of problems tend to surface. If you're tempted to skip the exercise, consider that this is precisely what you're choosing to discover in production instead:

Orphaned steps. Activities that exist in the process design but have no owner in practice. Someone assumed "procurement" would handle it. Procurement assumed Finance would. Nobody owns it.
Data gaps. Information that a downstream step requires that nobody upstream is collecting. A supplier bank account that Accounts Payable needs but Procurement never asks for. A commodity code that the spend analytics tool requires but the PO template doesn't capture.
Approval bottlenecks. Chains that look reasonable on an org chart but create 10-day delays when three approvers are simultaneously in budget review season, on leave, or simply haven't been onboarded to the new system.
Integration failures. Moments where the ProcureTech system needs to talk to an ERP, a contract repository, or a supplier portal and the handoff is broken, duplicated, or quietly manual.
Misaligned mental models. This is the big one. People who have been in the same process design workshops for three months turn out to have fundamentally different understandings of what "approval" means, what "receipt confirmation" requires, or when a three-way match exception gets escalated versus accepted.
Training gaps. Not system training, but process training. Who knows what they're supposed to do, and who is performing the step for the first time during the CRP itself?

Are You Ready to Run a CRP? The CRP Readiness Checklist

A CRP that surfaces nothing is almost always a CRP that was run too carefully. The instinct is to prepare meticulously, smooth out the rough edges, and present a polished run-through. That instinct is exactly wrong.

The goal is to find the breaks. Design the session to find them. Use this checklist to make sure you're set up to do exactly that.

✅ Before the Session

Scope and scenarios

Processes “in scope” for this CRP are clearly defined (e.g. Procure-to-Pay, Supplier Onboarding, Contract Renewal)
At least 3-5 realistic end-to-end scenarios have been scripted (including the happy path and at least 2 exception scenarios)
Scenarios are based on real transaction types your team handles, not fictional clean-room examples
Each scenario specifies the starting trigger (e.g. "Marketing submits a requisition for a new agency retainer, $45K, no existing preferred supplier")

Data and environment

Required master data is pre-loaded: supplier records, item/service catalogues, cost centers, commodity codes, contract templates
If software is in scope, a dedicated sandbox/test environment is configured and accessible to all participants
If no software is in scope, physical or digital process artefacts are prepared (forms, templates, approval emails, intake sheets)

Participants

All process owners confirmed and available for the full session (not delegates or observers)
Business stakeholders who initiate or receive outputs from the process are included
Finance, IT, and Legal representatives are confirmed where the process touches their domains
A dedicated facilitator has been assigned (not the project manager or the system implementer)
A note-taker or findings logger is assigned separately from the facilitator

Logistics and ground rules

Session ground rules are documented and will be shared at the start: participants execute as they would in real life, not as they think they should for the exercise
A findings log template is prepared with columns for: finding type, process step, description, severity, owner
Participants know the session purpose: this is a simulation, not a training session or a demonstration

✅ In the Room

Running the simulation

The process is executed single-stream: one person acts at a time while others observe, question, comment
Every assumption is named explicitly: "I'm assuming the supplier is already approved" is logged as a finding if that assumption isn't guaranteed in real life
Issues are logged, not fixed on the fly: the session keeps moving
The facilitator is not rescuing participants when they get stuck; hesitation and confusion are data points
Real data is used wherever possible; sanitized or fictional test data masks real-world issues

Exception testing

At least one scenario includes a missing or incomplete information scenario (e.g. requisition submitted without a cost center)
At least one scenario includes an approval chain exception (e.g. primary approver is unavailable; spend is above delegated authority)
At least one scenario includes a supplier-side exception (e.g. invoice disputes, partial delivery, supplier not yet in the system)
Edge cases specific to your organization have been identified in advance and are introduced deliberately

Findings capture

Every process break, question, workaround, and disagreement is logged in real time
Findings are categorized as: process design issue / data issue / system/configuration issue / role clarity issue / training gap
Severity is assessed on the spot: show-stopper / significant / minor

✅ After the Session

Findings consolidation

All findings are consolidated into a single log within 24 hours of the session
Findings are prioritized: which must be resolved before go-live, which can be addressed in a later phase, which are accepted risks
Each finding has a clear owner and target resolution date
Process design, system configuration, and training plans are updated to reflect findings

Decision and next steps

Go/No-go decision for the next implementation phase is formally documented based on CRP findings
Any process area where the simulation surfaced major breaks has a scheduled re-run CRP before go-live
Stakeholders are debriefed on key findings, particularly those at leadership level who weren't in the room

That checklist covers a full software-backed CRP. For a process-only simulation, simply ignore the system/environment items… Everything else applies directly.

Who Needs to Be in the Room

This is non-negotiable. The CRP only works if the right people are present… Not substitutes, not observers, not "I'll catch up on the notes afterwards."

Operations: the people who will own each step post-go-live, not their managers
Business stakeholders: the internal customers of procurement who initiate requests or receive outputs from the process
System/technical lead: to field configuration questions and log system-level findings (if software is in scope)
Process/Function subject matter expert: to anchor the process design and facilitate decisions when breaks occur
Finance representative: for any process that touches payment, accruals, or cost center allocation
IT/integration lead: if the process crosses system boundaries

What you don't need is an audience. Observers slow the simulation and introduce social dynamics that make people less likely to surface real problems. Keep the room tight and the mandate clear.

The CRP Facilitator Role

The facilitator is the most critical role in the room and the most underestimated one on the project plan.

Their job is not to present the system or explain the process. Their job is to run the simulation without rescuing it. When a participant gets stuck, the facilitator doesn't solve the problem… They document it and keep the session moving. When an assumption surfaces, the facilitator names it explicitly: "That's an assumption. Let's flag it."

A good facilitator treats every hesitation, every question, and every workaround as a data point. A bad facilitator treats them as interruptions to manage. The difference between these two approaches is often the difference between a CRP that generates 30 actionable findings and one that generates three politely vague observations.

CRP vs. UAT: Stop Confusing These

This distinction matters, and it's worth being blunt about it because the two are routinely conflated (with real consequences for project sequencing and quality).

User Acceptance Testing (UAT) is a formal quality assurance activity. It executes pre-scripted test cases against defined acceptance criteria. Its purpose is to confirm that the system meets the agreed requirements. Pass or fail. It is conducted by the QA team, with business sign-off, against a completed system build.

A Conference Room Pilot is not a testing process. It's a validation process. You're not checking whether the system passes a test… You're discovering whether the process, the system, and the people work together as a coherent operating model. There is no pass or fail. There are only findings.

	CRP	UAT
Purpose	Validate process design and stakeholder alignment	Confirm system meets agreed requirements
Scripts	Scenario-based, realistic, includes exceptions	Formal test cases with expected outcomes
Pass/Fail?	No. Findings are classified, not graded	Yes
Who runs it?	Business operations and stakeholders	QA team, with business sign-off
When?	Before design is locked; mid-implementation	Pre-go-live, post-build
Software required?	No	Yes
Primary output	Findings log, process design updates	Test result sign-off

Running a rigorous CRP makes UAT dramatically smoother. Teams that skip the CRP often spend their UAT cycles discovering fundamental process design issues when Brenda from AP starts asking tough questions… Which is exactly the wrong time to find them, because you've lost the flexibility to fix them properly without delaying go-live or accumulating change requests.

A Note for Procurement Leaders: What the CPO Needs to Understand About CRP

If you're leading the procurement function rather than running the implementation, here's what you actually need to know (and what to watch out for).

CRP is a governance tool, not just a project activity. It's the mechanism that tells you, before you're committed, whether your operating model is coherent. A CRP that surfaces 40 findings isn't a project failure. It's risk management working exactly as intended.
The temptation to cut CRP under time pressure is almost universal… And almost always wrong. Project timelines get compressed, budgets tighten, and the CRP is one of the first "optional" activities to get deprioritized. The irony is that skipping it typically creates more timeline pressure, because the issues it would have surfaced migrate into go-live support, rework, and escalations that are far more expensive to resolve after the fact.
What to ask your implementation team: Don't just ask whether a CRP is planned. Ask what process streams are in scope, who specifically has been confirmed as participants, and what exception scenarios are on the script. If the answers are vague, the CRP is a box-tick, not a validation exercise.
The "no software" CRP is underused at the leadership level. Before committing to a major process redesign (a new operating model for category management, a revised governance structure for supplier risk, etc.), a lightweight CRP with your senior stakeholders costs you a day and potentially saves you a quarter of painful adoption problems.

The Bottom Line

A conference room pilot is not a demo. It's not a test. And it's definitely not an optional nice-to-have that you sacrifice when the project timeline gets uncomfortable.

It's the one moment in your procurement implementation where the whole operating model (people, process, and technology, when applicable), runs together at full speed before it matters. Skip it, and you're betting that every assumption your team made over six months of design workshops was correct. That's a bet you'll almost certainly lose.

And remember: the software is optional. The simulation is not.

Any time you're changing how procurement operates (new intake process, new approval framework, new supplier onboarding workflow, new category management model), the CRP logic applies. Sit the right people in the room. Walk the process. Find the breaks before they find you.

👀 In Case You Missed It…
The Last 3 Pure Procurement Newsletters:

1/ The Pixar Method for Procurement Transformation
2/ Build vs. Buy in Procurement Technology: The AI Edition
3/ Next-Gen SAP Ariba: An Insider's View from the Beta Program

Need Help Building Your Digital Procurement Roadmap?
Watch our webinar replay on what AI-powered sourcing can do today and where it's headed. No vendor pitch — just a practical walkthrough with live demos. Watch the replay.
Serious about understanding the ProcureTech market?
The 2025 ProcureTech Cup Almanac pulls the field into one place, with participating company profiles, solution categories, HQ locations, and demo links so you can explore the landscape without piecing it together vendor by vendor. Grab it here.

— Joël Collin-Demers

P.S. Please rate today’s newsletter.
Your feedback shapes the content of this newsletter.

The Pixar Method for Procurement Transformation

Joël Collin-Demers — Mon, 02 Mar 2026 02:01:27 +0000

A rchive | Upgrade to Premium | Sponsor

The go-live party was on a Friday.

Balloons. Cake. A VP who flew in from headquarters to shake hands and take photos. Eighteen months of work, $2.4M in consulting fees, and a project team that hadn't slept properly since Q3.

By Monday, the tickets were already coming in.

"The approval workflow doesn't match how we actually work." "Suppliers can't figure out the portal." "Nobody told us we had to re-enter all our contracts."

By Wednesday, the VP had stopped replying to emails.

I've heard this horror story more times than I'd like to admit. And every single time, the post-mortem says the same thing: "We should have tested this with users earlier."

Which is a polite way of saying: we built the wrong thing.

Quick question before we get into today's note:

I’ll share results next week.

But today? I want to show you why this keeps happening…

And why the answer has been hiding in your favorite Pixar movies the whole time…

Just because “anyone can cook”, doesn’t mean they should (yet)! 😅

Onwards!

📰 In this week’s edition:

📄 Meet MarketPay: The Future of Tail Spend Payments (sponsored)
🌙 The Pixar Method for Procurement Transformation
📢 This week’s “Must Reads”
🏆 The Road to the ProcureTech Cup: Episode 19
📋 3 procurement jobs that caught our eye

Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.

What Pixar Can Teach You About Procurement Transformation

A French rat wants to cook at the finest restaurant in Paris.

That's the idea behind Ratatouille. Six words. Not a requirements document. Not a configuration spec. Not a business case with 47 appendices.

Six words.

Pixar turned that idea into a masterpiece in eight years. Eight years of writing, drawing, scrapping, rewriting, screening, arguing, and starting over.

And here's the thing that should shake every procurement transformation leader reading this:

They didn't animate a single frame until the last 9 months.

The Way Most Procurement Transformations Are Run

You know the drill.

An executive sponsor gets fired up after a conference. A compelling vendor demo. A competitor's case study. Something clicks.

Next thing you know, there's an RFP. Then a contract. Then a kickoff call where someone shares a project plan that reads like a construction schedule.

Design. Build. Test. Deploy. Train. Go-live.

You're animating on day one.

And six to eighteen months later, the beautiful thing you built doesn't match the world you're actually living in. Stakeholders didn't adopt it. The business requirements you documented in month two are already stale. Users found workarounds. You're $1M in and you're... somewhere between "close to go-live" and "we need to revisit the scope."

Sound familiar?

We know it does. Because 80%+ of digital transformation initiatives fail. Not because the technology didn't work. Because we treated a fundamentally human problem like a templated construction project.

What Pixar Actually Does

Pete Docter, the director behind Up, Inside Out, and Monsters, Inc., had a realization early in his career.

He'd assumed creativity worked the way legends described it. That the greats just... knew.

"I figured that people like Walt Disney would be like, lying in bed, and suddenly shout 'Dumbo!' The whole thing would be in their head, and they could tell you the story from beginning to end."
Pete Docter

Then he started making movies.

"It starts as a gray blob," he said.

Not a vision. Not a blueprint. A gray blob.

What Pixar discovered (and what they turned into a repeatable system) is that great things don't come out fully formed. They get iterated into existence. Tested against reality. Broken down and rebuilt. Again. And again. And again.

Here's how the Pixar process actually works:

The Idea. Six words or less. A French rat loves to cook. Not a 150-page functional requirements document.
The 12-Page Outline. No animation. No wireframes. Just: Where are we? What's going on? What happens? The rough bones of the story. Written by humans, for humans.
The Brain Trust. Directors, writers, artists, and executives read the outline and come back with honest feedback. Questions, criticisms, concerns. No sacred cows.
The Script. 120 pages. The director takes the feedback, or leaves it. Nobody can force changes. The director is in charge with only one rule: it has to get better.
The Storyboards. The director and a team of five to eight artists turn the entire script into hand-drawn panels. Each panel covers about two seconds of film. A 90-minute movie requires 2,700 drawings. They string them together with recorded dialogue and rough sound effects. It's called a "reel" (a rough simulation of the movie).
The Audience. Pixar employees (many with no direct involvement in the film) watch the reel. Their faces are watched as closely as the screen. Reactions are tracked, discomfort is noted, and the moments where attention drifts are catalogued. "You can really feel when you have the audience and when you don't," noted Docter. "Without anybody saying anything."
The Rewrite. The script gets substantially reworked. New storyboards. New voice recordings. New reel. Another audience. More feedback.
Repeat. A typical Pixar movie goes through this cycle eight times. The gap between version one and two is "usually huge." Two to three is "pretty big." By version seven or eight, the changes are surgical.
Only then does the real animation begin. After about eight rounds of exhaustive, audience-tested, painfully honest iteration animation starts with state-of-the-art computers, on a story that has already proven it works. The actual animation? The last 9 months of an 8-year process in the case of Ratatouille.

Why? Becauce it costs virtually nothing to iterate while in planning phases… But its ulta-expensive to change the story when animation has started…

Why Is Procurement Transformation Ignoring Human Behavior?

Humans are thinkerers but we often forget it in professional settings.

(Yes, that's a made-up word. Stick with it.)

In most cases, we think we already understand. We're absolutely convinced we know what "good" looks like before we've tested it against reality. We write requirements like we're scripting the final movie, and then we hire a vendor to animate it, on budget, on a deadline.

And then we wonder why the audience (your stakeholders) doesn't show up…

Humans are catastrophically bad at getting things right the first time. Even smart ones. Even experienced ones. Even with AI.

The most costly line item in any failed procurement transformation isn't the software license. It's the late-stage discovery that “the story” doesn't work, when you've already spent $1M animating it.

The Parallel Approach for Procurement

What if you ran your next ProcureTech initiative like a Pixar movie?

Step 1: Start with the idea, not the RFP. What's the six-word version of the transformation you're trying to deliver? "Stakeholders can spend without procurement’s direct involvement." "Suppliers onboard in hours, not months." If you can't say it simply, you haven't understood it yet.
Step 2: Write the outline, not the requirements doc. Where are we today? What's broken? What would "better" actually look like (step-by-step process) for the people doing the work, not the people approving the budget? Keep it to a few pages.
Attend conferences, discuss with peers, consult with vendors and consultants, read ProcureTech newsletters, watch the weekly ProcureTech Cup show. Your outline should be informed by the “art of the possible.”
Step 3: Build your brain trust. This isn't your steering committee. This is a small, honest, cross-functional group (AP, sourcing, a category manager, an IT business partner, a skeptical stakeholder) who will tell you when the story doesn't work. Give them permission to be brutal. No sacred cows… (“Maybe it would make more sense if we changed the org structure and RACI? 😦🫣🫢”)
Step 4: Prototype the experience before you configure anything. Storyboard it. Run “Conference Room Pilots”. Make clickable mockups on Figma. A Miro board walkthrough. Show people what using this thing will actually feel like. Let them react. Watch their faces. "You can really feel when you have the audience and when you don't."
This can be done with a specific piece of tech in mind (e.g. jointly with a vendor) or without.
Step 5: Iterate on the story before you “animate it”. Rewrite. Repeat. Do this until the changes become small. Bonus: as you’re cycling through different stakeholder groups, you’re also starting your change management activities (“Here’s why we’re doing this. We want your feedback. We haven’t built anything and what you say will shape where we go.”)
Step 6: Only then do you configure, build, and deploy. Now you're “animating” a proven story. Your vendor is working from a storyboard that's been stress-tested eight times, not a first-draft requirements document written by someone who'd never used the system.
If you did this without a software vendor partner, you’ll need to go through a few more “prototype iterations” with them to get on the same page based on their platform design/constraints. Do it.

Note: As for the RFP, you either run it with partnership criteria at step 3 to include a given vendor in your brain trust and design with a platform in mind. Or, you do it before Step 6, going to ask the market to realize your vision. Both are possible but carry different tradeoffs.

The first option reduces the risk of designing something that needs to be built from scratch, leverages vendor experiste around the “art of the possible” but “locks you in” to a vendor early on.

The second option allows for maximal possibilities but heavily relies on your internal team’s comprehension of the “art of the possible”. You can alleviate this by hiring talent or a consultant that’s already done something similar to what you’re trying to accomplish.

Loosely stated, this process is what we call the Procurement Innovation Garage approach.

Related Reading: How to Setup a Procurement Innovation Garage

Discover how to create a Procurement Innovation Garage to overcome the 80% failure rate of traditional projects. Learn why continuous experimentation beats assumption-based planning and how to build a team that delivers real procurement technology results.

The Reason We Don't Do This

It feels slow.

It feels like we're not "making progress."

Every day you spend planning and experimenting feels like a day you could have spent building and deploying. Leadership wants to see a Gantt chart with milestones. Vendors want to start the clock on the SOW. Your team wants to feel like something is happening.

But here's what's actually slow: an 18-month implementation that ends with a system nobody uses, followed by a re-implementation 24 months later.

Pixar's iterative process (the one that feels slow) is actually what makes Up make you cry in the first four minutes. It's what makes Wall-E work without dialogue. It's what turns a gray blob into something people actually care about and engage with.

Your procurement transformation deserves the same respect.

The story has to work before you animate it.

That’s the only way you get “to infinity and beyond.”

P.S. I first stumbled upon the Pixar story in How Big Things Get Done by Bent Flyvbjerg and Dan Gardner. I highly recommend this book. It's one of the best books I've read on why ambitious projects succeed or fail, and the procurement parallels are everywhere.

👀 In Case You Missed It…
The Last 3 Newsletters:

1/ Next-Gen SAP Ariba: An Insider's View from the Beta Program
2/ The AI Agent Nobody's Building in ProcureTech...
3/ Gartner Just Confirmed One of Our 2026 Predictions

2 other ways we can help this week:

A Skeptic’s Take on AI in Procurement. Our consulting principal recently took the stage at Zip Forward: LLM market overview, vendor motivations, and a framework to chart your own path… Without the hype. Watch the replay.
ProcureTech Unpacked (our inaugural 100% virtual conference) is happening April 22–24, 2026. Three half-days built around two things: making you at least one industry friend who's as serious about procurement transformation as you are, and walking away knowing how to navigate the ProcureTech market without getting played by vendor marketing. That's it. No fluff. Get your tickets.

See you next week {{FIRST_NAME|readers}},

— The Pure Procurement Newsletter Team

P.S. Please rate today’s newsletter.
Your feedback shapes the content of this newsletter.

Next-Gen SAP Ariba: An Insider's View from the Beta Program

Joël Collin-Demers — Mon, 16 Feb 2026 02:05:12 +0000

A rchive | Upgrade to Premium | Sponsor

Hi {{FIRST_NAME|readers}},

Quick update before we get to tonight's note.

Last week, I mentioned ProcureTech Unpacked (our first 100% virtual conference happening April 22-24) for the first time.

One-third of the spots sold out within a week.

So far, we've got industry peer groups forming in:

Pharma/healthcare
Manufacturing
SaaS
Financial services/banking

The format is simple: solution deep-dives and peer breakouts with people in your industry navigating the same digital procurement challenges you are.

No vendor pitches. No sales. Just education and connections.

If you want to upskill yourself or your team on digital procurement on fast forward ( and make contacts with peers doing the same thing), this is for you.

Spots are intentionally limited to create an intimate, impactful experience.

Answer a few questions if you’re interested in learning more (no commitment).

I’ll get back to you with the details.

Raise your hand

Now, onto tonight's main course...

A delicious Q&A with someone in the Next-Gen Ariba beta program. Beans will be spilt. 🫘

Onwards!

📰 In this week’s edition:

📄 Market Intelligence Report: AI in the Enterprise (sponsored)
🌙 Q&A with SAP Procurement Insider: Debadatta Dash
🏆 The Road to the ProcureTech Cup: Episode 17
📋 3 procurement jobs that caught our eye

Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.

Q&A with SAP Procurement Insider: Debadatta Dash

Debadatta Dash is currently a Technology Platform Leader, Source-to-Pay at a major global enterprise. He’s been driving Source-to-Pay transformation with organizations within the SAP ecosystem for 15+ years, making Ariba, Fieldglass, Concur, ECC and S4/HANA work together to support procurement processes in complex global organizations.

SAP's Procurement Product Family:
🔑Ariba: SAP's cloud-based procurement suite covering intake, sourcing, contracts, buying, invoicing, and supplier management. The platform most of this interview focuses on.

🔑 Fieldglass: SAP's solution for managing external workforce and services procurement (contingent labor, SOW-based engagements).

🔑 Concur: SAP's travel and expense management platform.
🔑 ECC (ERP Central Component): SAP's legacy on-premise ERP system that many organizations still run today (and *can* be hosted in the cloud).

🔑 S/4HANA: SAP's next-generation ERP, designed as the cloud-ready successor to ECC with a simplified data model and real-time analytics.
Note: These boxes will break down any technical terms in this article to ensure everyone can follow along.

Debadatta is one of those rare people who lives at the intersection of procurement domain knowledge and deep technical SAP expertise. (IYKYK - This is a combination that is hard to find. 👀)

Debadatta and I had very similar early careers in SAP and procurement. But where I eventually went wider (covering the full ProcureTech landscape across vendors and categories) he kept going deeper into the SAP ecosystem. That's why I have enormous respect for his perspective on SAP procurement solutions past, present, and future.

He's also a prolific educator on LinkedIn and YouTube, has completed 37+ openSAP courses, and has been selected for SAP's Early Adopter Care program for Joule in Ariba. He's currently beta testing next-gen Ariba's contract management module.

In short: when Debadatta talks about what's coming, I listen. I thought you would find our most recent conversation valuable if you’re curious about what the historic market leader in ProcureTech is up to…

(Earlier this year, I asked whether SAP Ariba was still "King of the Hill". This Q&A is arguably the clearest answer yet.)

Let's get into it.

#1 - The Big Picture

Joël: You're constantly immersed in the SAP procurement space. You attend events, implement solutions, talk to professionals across industries. What are you seeing right now that procurement leaders need to pay attention to, SAP or otherwise?

Debadatta: There are many things. I'll highlight three.

First, the unprecedented speed of innovation.

The pace of innovation in B2B digital procurement right now is both staggering and humbling.

Take SAP as an example. Early in 2025, I highlighted the historically long "gestation period" between SAP product announcements and actual releases in a LinkedIn post. We exchanged views on that post at the time.

Fast forward to now and I stand corrected on many fronts.

SAP announced its proprietary LLM at Sapphire in May 2025 (SAP’s own yearly conference). The first version of SAP RPT-1 is already publicly available. Joule for Ariba early adopters was completed in September 2025. More than 30 sourcing and procurement use cases were released before end of 2025. Next-gen Ariba was announced in October 2025, and beta testing with customers is already underway.

🔑 SAP RPT-1 (Relational Pretrained Transformer): SAP's proprietary large language model, purpose-built for enterprise data. Unlike general-purpose LLMs like GPT or Claude, RPT-1 is designed specifically to understand the relational structure of business data within SAP systems.
🔑 Joule: SAP's AI co-pilot, built natively on BTP. Think of it as an AI assistant embedded directly into your SAP applications that can pull data, execute tasks, and navigate you to the right screens through conversational prompts.
🔑 Next-Gen Ariba: SAP's complete rebuild of the Ariba procurement suite. Rather than patching the existing 25-year-old platform, SAP is rewriting Ariba from scratch with a modern architecture, redesigned user experience, and AI baked in from the ground up. First release is scheduled for February 2026.
We covered the Next-Gen Ariba announcement when it dropped last fall, arguing that SAP Ariba has effectively killed the legacy Source-to-Pay Suite.
SAP had effectively killed the legacy source-to-pay suite. Debadatta's view from inside the beta program is the clearest confirmation yet.

This level of agility from SAP is unprecedented in my 15 years as a practitioner and observer in this ecosystem.

Beyond SAP, the momentum is equally strong. Look at Coupa's two moves in 2025 alone in category management and the buyer-supplier network space.

And Joël, you as a hyperactive digital procurement analyst and community builder have a frontline view of the SMB procurement tech space more than anyone else. That space is buzzing with startups and agentic AI innovations almost every day! We see it in your newsletter.

Second, looking inward and sensing business direction.

In a world where external choices seem endless, sustainable decisions can only come from looking inward.

The cornerstone is deep business understanding and alignment with both short-term priorities and long-term strategic direction. It's not enough to know how your organization operates today. As leaders, building a deep sense of anticipation and digital literacy around how the organization will transform over the next 18-24 months is crucial.

Is the company entering new markets, or consolidating its existing footprint? Will the focus be on differentiated, research-driven product portfolios, or on partnerships, mergers, acquisitions, and operational standardization?

For large enterprises, the reality is often a blend of all these strategies, requiring leadership to strike a delicate balance in attention and capital allocation. This balancing act is essential to ensure that technology investments and procurement decisions align seamlessly with the organization's evolving business objectives.

Third, best-in-class business and IT collaboration.

Organizations aiming for integrated, end-to-end business processes with minimal disruption cannot afford an ungoverned approach to technology assessment, deployment, and usage/operations.

The starting point must be a unified strategy with IT. Don’t simple engage IT in later stages… Involve them early in the your thinking and decision-making processes. Share business requirements upfront to evaluate whether existing technology can meet the need. If gaps exist, conduct joint market research and enable IT to perform technical vetting before onboarding new solutions.

This is not a one-off interaction. It must be a genuine team sport.

#2 - Clean Core: What It Actually Means

Joël: We keep hearing about "clean core" as an SAP guiding principle. What does that actually mean in practice? How are companies balancing it with their real business needs?

Debadatta: You used the appropriate term: guiding principle. Clean core is a non-technical concept in ERP governance. A mindset shift more than anything else.

🔑 Clean Core: An ERP governance philosophy that calls for keeping your core ERP system free from unnecessary customizations (custom code) as you transition to the cloud. Think of it as "don't mess with the engine". Rather, extend capabilities through approved side-channels instead.

I often describe this as the contrast between the aspirational state and the practical state. The aspirational state represents the ideal vision: where ERP systems operate with seamless integration, agility, and intelligence. In reality, most organizations function within the practical state, managing day-to-day ERP operations with inherent complexities and constraints. Bridging this gap is a progressive journey, requiring deliberate steps toward modernization, simplification, and innovation.

At its heart, clean core calls for avoiding unnecessary customizations. When customization becomes unavoidable, refrain from altering the core ABAP code. Instead, leverage in-app extensions (such as CDS views within S/4HANA) or adopt side-by-side extensions using SAP BTP capabilities.

🔑 ABAP Code: The core programming language SAP uses to build its ERP applications. Modifying ABAP code is like tinkering with the engine of your car… It might work today but creates nightmares during your next upgrade and grows your application support costs because it’s the first thing that ends up breaking… And isn’t supported by standard SAP support because YOU built it.
🔑 CDS Views (Core Data Services): A way to create custom data models and reports on top of the core ERP without modifying its underlying code.
🔑 SAP BTP (Business Technology Platform): SAP's cloud-based platform that acts as the foundation layer connecting all SAP applications. Think of it as the operating system on which Ariba, S/4HANA, SuccessFactors, and all future SAP innovations run.
Both CDS Views and BTP are tools to extend ERP functionality. Think of it as building ramps outside to connect different floors rather than renovating the inside of the building.

However, enabling this guiding principles in practice comes with responsibility. As business users witness the power to create new applications through BTP, there is a real risk of accumulating technical debt at an alarming pace if governance is not enforced rigorously.

Remember: systems like ECC and S/4HANA have evolved over three decades, offering extensive built-in functionality. For example, there is no need to develop a custom three-way match cockpit (PO–Receipt–Invoice) in BTP. The core ERP natively provides this capability… But if you don’t know that, you might be tempted to build it again outside the ERP… And nothing will stop you.

🔑 Three-Way Match: The process of matching a purchase order, goods receipt, and supplier invoice to verify accuracy before payment. It's one of the most fundamental procurement controls. If your ERP can't do this natively, you have bigger problems.

The mantra should be: maximize native ERP capabilities first. Only consider extensions when the business requirement exceeds the scope of the core system. And don't hesitate to explore non-SAP platforms or technologies if SAP ecosystem extensions introduce excessive complexity or technical debt.

The foundational pillars of a clean core strategy are clean data and clean business operations. From a governance perspective, tolerance for deviations in these areas should be little to none. I've seen a few customers starting their cloud-ERP journey with zero legacy data migration… A straight up clean slate. A bold step indeed.

Based on my own observations of organizations that have matured in their clean-core cloud ERP journey over the past three to five years, a typical governance committee ends up with roughly these numbers:

50–60% of requirements are approved because they align well with the clean core framework
30–40% of enhancements are approved with the understanding that they introduce some technical debt, which must be periodically cleansed
Up to 10% of requirements are rejected, with the expectation that they will be revisited during future upgrades

#3 - SAP BTP: The Glue Holding It All Together

Joël: Your answer illustrates why SAP BTP (Business Technology Platform) has gotten more attention in recent years. How should procurement professionals be thinking about this? What's actually possible today?

Debadatta: SAP BTP is the bedrock upon which the entire SAP application portfolio rests. It acts as the unifying layer that is supposed to seamlessly connect every element of SAP's offering:

Data Governance Layer: Business Data Cloud as the data governance layer
Digital Core: S/4HANA Cloud ERP as the transactional backbone
Line-of-Business Applications: Ariba, Fieldglass, Concur for Spend Management, IBP for Supply Chain Planning, SuccessFactors for HCM, and more
AI Capabilities: AI and emerging agentic AI innovations

SAP BTP as visualized by SAP

In essence, BTP is the glue that binds SAP's suite into a coherent, integrated story. It is the vehicle that brings the clean core concept to life.

If clean core represents the vision of a painter, BTP is the paintbrush that turns that vision into reality.

The BTP bet seems to have paid off. Today, the BTP PaaS tops the chart in terms of buzzwords in the SAP ecosystem, and BTP services are some of the most in-demand skillsets in ERP hiring. Customers are leveraging BTP to unlock solutions and innovations that were not possible within SAP's offering just a few years ago.

🔑 PaaS (Platform-as-a-Service): A cloud computing model where SAP provides the platform (servers, tools, development environment) and you build or extend applications on top of it. You don't manage the infrastructure. SAP does.
BUT, you get to design, build and govern your own applications. Hence why this is not considered a SaaS (Software-as-a-Service). Although, you *can* also download pre-packed apps onto BTP from the SAP Store…

Beyond foundational services, BTP delivers five major capability areas:

Application & Product Development. SAP Build, Build Work Zone, Mobile Services, DevOps, Business Application Studio
Enterprise-Grade Business Automation . SAP Build Process Automation, SAP Task Center
Integration Across SAP and Non-SAP Landscapes. SAP Integration Suite, Event Mesh
Data & Analytics. SAP Analytics Cloud, SAP Datasphere
Data & Artificial Intelligence. SAP AI Core, SAP AI Launchpad, Translation Hub

These are all tools built on SAP BTP.

#4 - Joule: Hype vs. Reality

Joël: There's a lot of buzz around Joule, SAP's AI assistant. What does it actually do for procurement users day-to-day? Is it living up to the hype?

Debadatta: First, it's essential to underscore that Joule is currently available exclusively for SAP's cloud product portfolio: S/4HANA Cloud editions, Ariba, Concur, SuccessFactors, etc.

From a technical perspective, Joule is architected ground-up on SAP BTP, making BTP and several BTP-based capabilities mandatory prerequisites for activation and use.

I have had the privilege of being part of a select cohort of SAP ERP experts inducted into the Early Adopter Care program for Joule for Ariba in Q3 2025. Leading Joule implementation for the Ariba suite has been a standout experience. Its capabilities are impressive and evolving rapidly.

Out of the promised four types of Joule skills, we already see released use cases for three:

Informational skills: Joule pulls information or instructions from standard SAP documentation directly within the chat interface.
Transactional skills: Joule performs actions within the chat interface (retrieving data, approving tasks, sending reminders, etc.)
Navigational skills: Joule takes the user directly to a specific screen or application area to perform a task manually.

Some concrete Ariba buying examples of what Joule can do today:

Get status of a Purchase Requisition. Displays the status of a specific PR
Show recent purchase requisitions. Displays the last 10 PRs you created
Show approvers of a PR. Identifies the immediate approver
Show shipping details. Retrieves shipping information for a PR
View requisition. Takes you directly to the specific requisition screen

As of today, there are 34 Joule prompts dedicated to Ariba sourcing and procurement, with new prompts added in every release.

Looking ahead, Joule will serve as the launchpad for agentic AI use cases with simple text-based prompts. Sourcing event creation agents and bid analysis agents are scheduled for rollout in 2026.

SAP has also announced an early version of Joule Studio, which will provide lifecycle management for custom Joule agents, empowering customers to tailor AI-driven experiences to their unique business needs.

This is an exciting phase for SAP ERP professionals.

#5 - Next-Gen Ariba: The Big Rewrite

Joël: SAP recently announced they're "replatforming" Ariba on SAP BTP (“Next-Gen Ariba”). What does this mean for companies currently on “Current-Gen” Ariba 😅?

Debadatta: As a seasoned practitioner in the SAP procurement space, the October 2025 announcement from SAP regarding Next-Gen SAP Ariba feels like a watershed moment for the company.

As someone who is part of the beta testing group for the upcoming contract management module, I can confirm that the earliest version of the next-gen contract solution is significantly cleaner, more intuitive, and better aligned with modern UX expectations.

If SAP sustains this level of quality across next-gen buying, sourcing, and supplier management, the Ariba portfolio by late 2026 to early 2027 will represent a substantial leap forward.

What customers need to know about Next-Gen Ariba architecture:

Next-gen Ariba capabilities will be built on SAP BTP, with prerequisites similar to those for Joule. The enablement process will follow a structured approach including application provisioning via the SAP for Me portal, BTP setup jointly by SAP and customers, and SAP Cloud Identity Services for authentication.

Here's the big one: SAP has confirmed that there will be a single master data layer cutting across applications (S/4HANA, Ariba, etc.). Many of the data validation errors in integrated flows are going away (e.g. CLID, Supplier sync across SLP-MDG-S/4HANA, Sourcing integration between S/4HANA and Ariba) . That will be a massive improvement in itself.

🔑 Single Master Data Layer: Instead of each SAP application maintaining its own version of supplier records (which inevitably drift apart), Next-Gen Ariba promises one unified data layer shared across all applications. If you've ever dealt with supplier data sync nightmares between ECC, S/4HANA and Ariba, you know why this matters.

In addition to migrating Ariba's buyer-side applications to BTP, SAP announced during Sapphire 2025 that SAP Business Network (formerly Ariba Network) will also transition to BTP. While this announcement received limited attention, its long-term impact will be significant.

Release timeline and transition strategy:

SAP plans to release the initial version of next-gen Ariba in February 2026 (right now!). This first iteration will not achieve full functional parity with the current generation. SAP will progressively enhance capabilities through quarterly releases in May, August, and November 2026, moving closer to the existing scope.

Key considerations for customers:

Transition Program: SAP will support migration in waves, reaching out when readiness criteria are met. The big question that remains is… How easy will migration be?
Readiness Factors: Adoption will depend on current Ariba landscape, licensing, and BTP preparedness
Joule Integration: Embedded within next-gen Ariba, with advanced agentic AI features offered as premium bundles
Licensing: While Next-Gen Ariba will not require new licensing, premium AI capabilities may incur additional costs due to higher SAP AI credit consumption

SAP's strategic direction for procurement is clear: enhanced user experience, data consistency across platforms, and AI-driven innovation through expanded Joule use cases.

#6 - Where SAP Is Still Dropping the Ball

Joël: Where is SAP missing the boat in procurement? What are the gaps between what they're promising and what companies can execute today?

Debadatta: There are multiple areas of improvement. I'll highlight three that stand out for me.

1. Supplier Onboarding and Enablement Challenges

Current SAP Business Network onboarding and enablement processes are complex, often frustrating both suppliers and buyer enablement teams.

What needs to improve: if a supplier faces login issues (say, three failed attempts), the homepage should display their admin contact or open an Ariba support window. Guided in-app assistance for suppliers (e.g. step-by-step handholding in responding to sourcing events or completing qualification questionnaires) would go a long way.

One of the other issues I see is that many suppliers with standard (free) accounts don't even know their SAP Business Network account exists. They don't need to. These accounts are often auto-created when buyers send POs or payment confirmations. While these actions don't affect supplier experience directly, they lead to confusion later (e.g. suppliers receive system downtime or certificate update emails that have nothing to do with them).

Legacy Supplier Portals: 6 Critical Questions for Modern Supplier Onboarding

We covered what “Next Gen” Supplier Portals need to look like back in January. Have a look to dive deeper into this topic.

2. SAP Ariba Buyer Support Services

Despite 13 years post-acquisition, SAP and Ariba still operate in silos in some customer experience areas, undermining end-to-end product positioning.

Coordination among incident management, product management, and engineering teams is fragmented, causing delays. Delays with engineering teams on product bugs continue for weeks, or months at times.

Customers need faster, more seamless issue handovers among SAP support teams… Especially for integration issues (S/4HANA-Ariba, Ariba-MDG, VIM-SAP Business Network).

🔑 MDG: SAP’s Master Data Governance tool for vendor master records, material masters (inventoried items) and customer master records.
🔑 VIM: OpenText Vendor Invoice Management application (add-on to core accounts payable functionality).

3. Product Rollout Delays

Historically, SAP has had long gaps between capability announcements and deployment, frustrating customers. Example: Spend Control Tower, announced in 2023 as an enhanced Ariba Spend Analysis solution, remains limited even in late 2025… Especially for customers using custom taxonomy over UNSPSC. New SAP Analytics Cloud-based dashboards lack intuitiveness and offer minimal customization options.

#7 - Making It Practical: Agile Implementation

Joël: Companies take more agile and iterative approaches to cloud adoption instead of waiting for massive end-to-end migrations. What does this look like in practice for procurement?

Debadatta: Individual SAP Procurement transformation projects can adopt a more agile-like approach without disrupting other workstreams.

Guided Buying aligns well with agile delivery. Begin with a single category as a proof of concept (e.g. create landing pages, integrate catalogs, preferred suppliers, and forms, then test and deploy). After a successful pilot, expand iteratively by category. Similarly, SAP's new Ariba Category Management, along with sourcing, contract, and supplier management deployments, can follow this model.

Running a pilot with one category manager or buyer and showcasing results can build cross-functional momentum.

While a textbook agile approach may not suit large-scale, multi-workstream S/4HANA transformations, a modular or phased strategy with short milestones for individual teams is feasible. SAP Activate methodology offers a reference framework adapt and tailor phases as needed rather than applying them rigidly.

SAP Activate Metholodogy

#8 - The Takeaway: What to Do in the Next 6–12 Months

Joël: If you're a procurement leader tied into to the SAP ecosystem at a mid-to-large enterprise, what should you be doing in the next 6–12 months?

Debadatta: I would focus on improving the aspects that will be largely constant and always relevant over the next 12 months and longer in this hyper-evolving world.

First and always, data hygiene processes. You can’t do much without good data.

Second, operational discipline. This goes hand-in-hand with process optimization and standardization. If the team or function has system adoption goals, I would be championing that cause and leading by example.

Third, intentional development of a digitalization roadmap in partnership with IT and the teams that report to me. SAP will be a good fit for some of it. It won’t for other parts of it. You need to be scouting the ProcureTech market to know where to draw that line. Reading your newsletter certainly helps ME do that 😅

Finally, I would be raising the bar on what it means to "hire for the future" for all open positions.

Joël: Thanks so much for agreeing to chat with me Debadatta. Great insights here.

Our Consulting Principal’s Take

This conversation reinforced what we outlined in our analysis last fall, as well as one of our core 2026 ProcureTech predictions:

SAP is betting big on this “replatforming effort” and so the SAP procurement ecosystem is moving faster than it has in years.
However, there’s still lots of complexity to understand and navigate for procurement pros, most notably:
- What’s the migration path from legacy Ariba to Next-Gen Ariba? If it’s not dead simple to migrate from the legacy platform to the new one, you’ll have procurement organizations “running for the RFP hills”!
Given SAP is positioning Next Gen Ariba as a “standalone procurement apps/data/AI platform”, should we expect SAP to compete in environments where SAP is not the back end ERP system? (Given the underlying requirement for BTP, I am skeptical but happy to be proven wrong).

According to SAP’s target release dates, rubber will be hitting the road very shortly.

We’ll see whether this new platform really is a game changer or if it was yet again smoke and mirrors… (I’ve being called hopelessly naïve often in my life… 😅)

For the whole ProcureTech industry’s sake, I hope it’s a good one. SAP isn’t going anywhere in the short term and so I’d much rather procurement have great products available from them than the alternative.

Time will tell…

👀 In Case You Missed It…
The Last 3 Newsletters:

1/ The AI Agent Nobody's Building in ProcureTech...
2/ Gartner Just Confirmed One of Our 2026 Predictions
3/ Procurement Intake & Orchestration: Complete Guide (2026)

2 other ways we can help this week:

Get your team aligned on the basics. Download our free Procurement Function Overview poster. It’s a visual map of the entire procurement function on one page. Bonus: all of our content is built on this model, so it's the foundation for everything we publish. Teams that read together transform togethers. Grab the free poster.

Curious about AI in sourcing? Watch our webinar replay on what AI-powered sourcing can do today and where it's headed. No vendor pitch — just a practical walkthrough with live demos. Watch the replay.

See you next week {{FIRST_NAME|readers}},

— The Pure Procurement Newsletter Team

P.S. Please rate today’s newsletter.
Your feedback shapes the content of this newsletter.

The AI Agent Nobody's Building in ProcureTech...

Joël Collin-Demers — Mon, 09 Feb 2026 02:01:05 +0000

A rchive | Upgrade to Premium | Sponsor

Hi {{FIRST_NAME|readers}},

Two things before I reveal the AI Agent that's almost certainly not on your radar…

#1:
After 12+ months of saying the same thing at the bottom of every newsletter, we had a realization… If it's worth repeating every single week, it's probably not worth saying at all.

So we're mixing it up. Starting today, the footer gets rotating content that actually deserves your attention. Finally, a reason to scroll all the way down.

#2:
Most procurement tech events follow the same tired script. Vendor booths. Feature demos. Polished case studies. You leave inspired by what's possible... but clueless about how to make it work in your company.

Our first ever conference, ProcureTech Unpacked (April 22-24) flips that script.

Yes, you'll see what the market offers. But you'll also get the frameworks to build the business case, structure the roadmap, design the governance, and lead the change management that turns "possible" into "done."

Here's what you get:

3 half-days, 100% virtual. No travel, no lost productivity.
9 solution deep-dives from category leaders competing to educate, not sell.
Intimate peer breakouts with practitioners facing your exact challenges.
You decide the winner. Vendors compete for "Best ProcureTech Educator of the Year"… which keeps them honest.

Take this 2-minute survey to learn more. No commitment. But space is limited by design, and it's first-come, first-served. We'll personally reach out to everyone who raises their hand to make sure it's the right fit.

Alright, now for today's main event...

Onwards!

📰 In this week’s edition:

🎥 Tail Spend Automation : Case Study Webinar
🌙 The AI Agent Nobody's Building in ProcureTech...
🏆 The Road to the ProcureTech Cup: Episode 16
📋 5 procurement jobs that caught our eye

Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.

The AI Agent Nobody's Building in ProcureTech...

Anyone who's ever tried to administer a shared drive or MS Teams site with 20 colleagues knows the truth…

It's a warzone.

Nobody takes the time to establish naming conventions or a decent folder structure. Nobody documents usage rules. Plus, the shared drive doesn't enforce any of them anyway. And then? Old colleagues leave. New ones arrive. Nobody trains the new people on how to use the shared drive, let alone how it's administered (if it ever was)…

But very quickly, your beautifully organized digital workspace becomes a flaming dumpster of files…

Hypothetically… Maybe you spend a weekend building out a pristine SharePoint site. Naming conventions. Folder structure. A "READ ME FIRST" file that precisely zero people will read.

Then folders like "Sophie's Files" and "Jerry's Contracts" start popping up at the root level. So you sit down with each of them, calmly explaining why they can't do that. And they politely nod and say yes to get you out of their office, but you can tell they don't see the slow motion trainwreck occurring in front of their eyes.

Within a month, everyone has their own personal folder on the shared drive. Within three months, nobody can find anything. Within six, people are emailing files to each other because, and I quote, "the shared drive is a mess."

Hypothetically.

I'm not bitter, you're bitter.

I just love to write… Fiction.

Now, you'd think we'd all have learned this lesson by now. But the same thing happens with every new system too if you're not careful.

A shiny new procurement platform gets implemented. Configurations get designed. Workflows get built. Approval matrices get set up. And the thinking behind why it was all designed that way?

Nowhere to be found…

I’ll let you in on a dirty little secret of system implementations:

The first thing to get cut is when timelines get tight?

DOCUMENTATION.

Every. Single. Time.

I've been in situations where I onboard a project a year or two after initial implementation and the first thing I have to do is reverse engineer the thinking of the team who set it up. Why is this approval threshold set at $10K? Why does this workflow skip category managers for IT spend? Why is there a separate process for this one business unit?

Nobody knows. The person who designed it left two years ago. The documentation is a half-finished Confluence page with a "Draft" watermark that was last edited in 2022.

I know writing is hard and most people hate to do it… But dang!

I'm not bitter, you're bitter.

Now here's where it gets really interesting… and really dangerous.

In the world of AI and workflow automation, the problem above doesn't just persist. It accelerates.

Because now we're not just configuring static approval workflows. We're building AI agents. We're designing automated processes that make decisions. We're creating interconnected systems that talk to each other.

And the questions that matter become exponentially more important:

Why is the business process designed this way?
What are we optimizing for?
What's the context?
What constraints were considered?
What trade-offs were made?

These are all things that are absolutely critical to understand when deciding whether to create new “Agents” and workflows or to modify existing ones. Ideally, you want to build a holistic, all-encompassing, coherent workflow and AI agent architecture.

You want a well-designed house. Not the Winchester Mansion…

The Winchester Mystery House

That's what your ProcureTech architecture ends up looking like without documentation and governance. And it's what your AI agent ecosystem will look like if we keep building the way we always have.

So here's my question:

Why aren't we using our newfound Generative and Agentic AI capabilities to solve this exact problem?

Where is the Solution Architecture AI Agent?

An AI agent purpose-built to support solution administrators when they're creating new workflows, designing other agents, configuring approval matrices, or modifying existing processes. One that:

Captures the rationale behind every configuration decision, automatically
Surfaces existing context before you make changes ("Here's why this was set up this way, and here's what depends on it")
Evaluates new designs holistically, considering the entire architecture instead of just solving the immediate problem at hand
Onboards new administrators by explaining the "why" behind the "what", without requiring a two-week archaeological dig through Confluence and shared drives

I want an AI agent that ensures my team is crafting our procurement systems while considering the whole, not just patching the latest fire.

Think of it as an “architectural review board that never sleeps, never forgets, and never leaves the company”.

If someone is working on an agent like this, I haven't seen it.

(Seriously, get in touch…)

I've seen AI agents for sourcing. For contract analysis. For spend classification. For supplier risk monitoring.

But the foundational layer (the one that governs how all of this is designed and maintained) is still a human-dependent, documentation-optional, institutional-knowledge-in-someone's-head process.

And then we collectively wonder why 80%+ of digital transformation initiatives fail.

We're still smoking ourselves to the grave. Just with a nicer pipe.

If there's something out there I'm not aware of, reply to this email and let me know.

I'd love to be wrong on this one.

📊Quick Reader Poll…

👀 In Case You Missed It…
The Last 3 Newsletters:

1/ Gartner Just Confirmed One of Our 2026 Predictions
2/ Procurement Intake & Orchestration: Complete Guide (2026)
3/ The Legacy Supplier Portal Is Obsolete

2 other ways we can help this week:

New to Digital Procurement? Start Here.

We're opening up free access to our Digital Procurement 101 video course until February 14th. No fluff. Just the foundational knowledge you need to navigate procurement technology with confidence. Grab your free access.
Tired of Outdated Procurement Policies?

Check out our revamped procurement policy template, built from the ground up for digitally-minded procurement teams. One buyer: "Wow. An easy ROI if you compare it to the salary and time of the person needing to draft it all from zero." Save yourself weeks of work. ($499)

See you next week {{FIRST_NAME|readers}},

— The Pure Procurement Newsletter Team

P.S. Please rate today’s newsletter.
Your feedback shapes the content of this newsletter.

Pure Procurement

What Is a Source-to-Pay Suite?

The Short Answer

How the Market Defines It

Why the Term Gets Used Loosely

The Core Modules of an S2P Suite

1. Spend Analysis

2. Sourcing

3. Contract Lifecycle Management (CLM)

4. Supplier Management

5. Procurement / Requisitioning

6. Purchase Order Management

7. Invoice Management

8. Payments

S2P vs. P2P: What's the Difference

What an S2P Suite Is Not

Why Organizations Move to S2P Suites

Where AI Actually Shows Up in S2P Today

How to Measure Whether It's Working

How to Evaluate a S2P Suite

Can You Implement an S2P Suite in Phases?

The Bottom Line

Supplier Risk Management 101: What It Actually Takes to Build a Program That Works

Table of Contents

Supplier Risk Management 101: What It Actually Takes to Build a Program That Works

What Is Supplier Risk Management, and What Is It Not?

Risk Doesn't Live in One Place, It Lives at Three Levels

Supplier Level

Contract Level

Engagement / Transaction Level

The Risk Dimensions Practitioners Actually Use

The Hardest Part of Supplier Risk Management (It's Not the Technology)

The Supplier Risk Lifecycle, Once You've Done the Hard Part

Pre-Signature: Due Diligence

Post-Signature: Ongoing Monitoring

Offboarding

How Your Industry and Geography Shape Your Program

Where Technology Fits, and Where It Doesn't

Building a Program That Produces Results, Not Just Checkboxes

What to Take Away

2 other ways we can help this week:

What is Procurement Intake & Orchestration? Definition & Examples

What is Procurement Intake & Orchestration?

Procurement Intake Management: The Front Door

Procurement Orchestration: The Coordination Layer

Why Do Companies Need Intake & Orchestration?

When Do You Actually Need I&O?

5 Signs You Need I&O

4 Signs You DON'T Need I&O

The I&O Vendor Landscape

Go Deeper: The Complete I&O Guide

Frequently Asked Questions

What is the difference between intake and orchestration?

What is a procurement intake process?

What is the difference between intake orchestration and S2P suites?

Do I need intake orchestration if I have Coupa or SAP Ariba?

What does procurement orchestration software cost?

How long does it take to implement intake and orchestration?

Related Reading

Do You Need a Contract Lifecycle Management (CLM) Tool?

Table of Contents

Do You Need a Contract Lifecycle Management (CLM) Tool?

The Question Isn't "Do We Need CLM?", It's "Have We Fixed the Basics?"

What Is Contract Lifecycle Management (CLM)?

The Foundation Problem Nobody in the CLM Industry Wants to Talk About

Here's the five-step progression that actually matches where most procurement teams are starting from:

Step 1: Set Up a Central Repository

Step 2: Assign a Single Owner for Contract Data Quality

Step 3: Build the Process Discipline to Actually Use It

Steps 4 and 5: Integration and AI Query Layer

Step 4: Integration into your sourcing and contracting workflow

Step 5: Plug in your corporate LLM

What That Foundation Actually Gets You

The 20% Where a Dedicated CLM Platform Earns Its Place

How to Know Which Side of the Line You're On

CLM Platforms Worth Evaluating (If You Actually Need One)

The Bottom Line

2 other ways we can help this week:

Foundational Procurement System by Industry: ERP vs S2P Suite

The Two Principles That Should Drive Every Architecture Decision