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 Monthly Update

SAP's procurement story is one of the most consequential in enterprise software…

And it is entering a new chapter.

It began in the early 1990s with SAP R/3, the ERP system that defined how large organizations managed purchasing for decades.

When SAP acquired Ariba in 2012 for $4.3 billion, it signaled that procurement's future would be cloud-based and networked, connecting buyers and suppliers across the internet rather than locking everything inside a single system.

But the years that followed revealed a growing tension. Ariba operated separately from SAP's core ERP systems, and connecting the two required significant technical effort. Customers felt that burden in their day-to-day experience: slow upgrades, complex integrations, and a fragmented landscape that made it harder to get full value from either platform.

As artificial intelligence began reshaping what enterprise software can do, a more fundamental question emerged:

SAP's answer, taking shape in 2026, is to rebuild Ariba from the ground up.

The next generation of SAP Ariba ("Next-Gen Ariba" as they are calling it) is being designed as an AI-native source-to-pay suite, built on SAP BTP, SAP's modern technology platform.

Why do this now? Well, SAP wants to deliver tighter integration with SAP's cloud ERP, a unified data foundation, and AI embedded directly into the user experience through SAP Joule, SAP's AI copilot… That's where the market is heading. That's what customers are demanding.

This is exactly why I decided to start this newsletter.

I've spent 12 years delivering SAP programs for large global enterprises as a consultant, and the last 4 years leading Source-to-Pay modernization initiatives in industry, driving procurement transformation from the ownership side. I have seen this landscape from multiple angles: value delivery, architecture, and what it actually costs to operate these systems over time.

This newsletter brings that practitioner perspective to an SAP procurement technology landscape that is changing faster than most organizations can track.

I don't just want to cover what is changing, but what it actually means for the people and teams who are responsible for making SAP work for their procurement teams.

If you run your procurement processes on SAP, Ariba, Fieldglass, or Concur, more change is coming your way than at any point in recent memory… Whether you are ready for it or not.

The organizations that will navigate this well are not necessarily the ones with the biggest budgets or the most technical resources. They are the ones that engage early, stay informed, and treat change as something to manage proactively rather than react to at the last minute.

Waiting for your system integrator or SAP account team to tell you what to do is a strategy, but it is rarely a good one. Nasty surprises and forced, last-minute projects are almost always the result of decisions made without enough context, too late in the process.

I started this newsletter to give you that context, ahead of time, from someone who has been on the inside of these programs. I hope you will join me on the journey.

The most significant architectural change is how applications and services are separated from one another, and how they are deployed using SAP BTP accounts.

If you understand this, everything else becomes clearer… Architecture decisions, license negotiations, support structures, etc.

The diagram below provides a visual representation of the next-generation SAP Ariba stack. At its core, it serves as an inventory of the applications and services that make up the overall solution. In the diagram:

When a customer requests provisioning of one or more applications based on their licensed entitlements, the subsequent steps are largely technical…

In the background, this involves selecting the appropriate applications and supporting services from the core solution inventory, deploying them into the relevant BTP accounts, and establishing the necessary integrations between them.

These integrations can take multiple forms, application-to-service or service-to-service, depending on how the solution components need to interact. APIs act as the backbone enabling this communication across the stack:

The most significant shift is the role of BTP account architecture within SAP-managed provisioning.

In the next-generation model, solutions will no longer be provisioned within customer-owned global accounts. Instead, each application and service will have its own global account.

When a customer requests provisioning, their tenant environments are created as customer-specific subaccounts within the global account owned by the respective application or service.

To illustrate: imagine CUSTOMER1 requests provisioning of next-gen Ariba Sourcing:

The supporting services include search and alert notifications (App Services B and C), SAP Cloud Identity as a foundational service, and an audit log as a landscape service. Each lives in its own global account, with customer-specific subaccounts created beneath them.

The BTP deployment of the above solution blueprint will look something like this:

When the same customer later adds Ariba Buying (App Y), which also uses search and alert notifications, only an additional app-specific customer subaccount is added under App Y's global account. It then connects to the existing customer subaccounts for Services B and C. No duplication of shared services.

The updated architecture would look like this:

This provisioning model gives SAP direct control over deployment speed and upgrade cadence.

Next-gen Ariba is a new environment built on BTP and entirely separate from the current-generation environment, which runs on a legacy Java stack. Key principles governing the transition:

SAP has made its bet, and it is not a subtle one. BTP is the foundation everything is being built on, and that is not changing. If your organization runs SAP and does not have BTP skills internally today, this is your signal to start closing that gap.

The challenge is that every SAP customer is going to arrive at the same realization at roughly the same time. And this is not just a procurement story. Finance, HR, supply chain, manufacturing: every SAP workload is moving in the same direction. Consultants with deep BTP expertise are already in demand across all of these domains, and that demand is only going to increase as migrations accelerate. Organizations that wait until they have a forced transition on their hands will be competing for the same scarce resources, at premium rates, under time pressure.

Getting ahead of the wave does not require a massive investment today. It might mean identifying one or two internal people to begin building BTP familiarity, engaging your SI partner now on their BTP practice depth, or simply making sure BTP readiness is on your roadmap conversations with SAP rather than something you discover you need when it is already urgent.

The architecture is changing whether you engage with it or not. The only variable is whether you are ready when it matters.

Disclosure: This article represents the understanding and views of the author at the time of writing. /n Procurement is an independent publication and is not affiliated with, endorsed by, or sponsored by SAP. Readers should independently validate all information provided before making any major business decisions. Use at your own risk.

Worth Repeating…

👀 From the Archives…

1/ SAP Ariba E-Auction Best Practices To Bring The Best Out of Your Suppliers
2/ Deconstructing the New Category Management Offering From SAP
3/ a16z on SAP: Right Thesis, Thin Evidence

Wrap Up