Foundational Procurement System by Industry: ERP vs S2P Suite

Archive | 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 😅

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:

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.

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.

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.

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.

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:

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?

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.

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:

Process gaps that create shadow systems or workarounds:

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:

UX / screen count:

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

Formal interfaces:

What you don't need:

Interface count:

3–4 formal, minimal shadow system pressure.

UX / screen count:

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.

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:

*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):

Interface count:

UX / screen count:

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.

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:

Formal interfaces — supporting:

Interface count:

UX / screen count:

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.

Let me put the four scenarios side by side:

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.