SAP SE (SAP) Earnings Call Transcript & Summary

Okay. Good morning, everybody. I'll start off day 2 of our conference here in San Francisco. Thank you very much for joining us. My name is Adam Wood. I look after European software and payments research here at Morgan Stanley. It's a great pleasure to have Muhammad Alam with us. Muhammad, thank you very much for joining us. Muhammad is Executive Board Member at SAP responsible for Product and Engineering. So thank you.

Thank you for having me.

Alam, trying to get these out the way as quickly as possible, a few disclaimers. So for important disclosures, please see the Morgan Stanley research disclosure website at www.morganstanley.com/researchdisclosures. If you have any questions, please reach out to your Morgan Stanley representative. On the SAP side, during this fireside chat, SAP will make forward-looking statements, which are predictions, projections or other statements about future events. These statements are based on current expectations, forecasts and assumptions that are subject to risks and uncertainties that could cause actual results and outcomes to materially differ. Additional information regarding these risks and uncertainties may be found in SAP's filings with the Securities and Exchange Commission, including but not limited to the risk factors of SAP's 2025 Annual Report on Form 20-F. So with those out of the way, we can get on to more interesting things, hopefully.

So maybe just to start off with, there's been some recent news on your side that you're not going to be renewing your contract with SAP next year when it expires. I wonder if you'd be able to elaborate just a little bit on what the reasoning was behind that.

Yes. I mean, I think not to go into too much detail, but there's a few things going on, on the personal side, for me, which made it a little bit hard for me to commit today a contract extension. And German governance requires, once a contract is coming up for renewal, that, a year in advance, you have those discussions. So I just wasn't at a place personally to be able to commit to that. And we thought it was still, from a transparency perspective, the right thing to communicate both to our colleagues as well as externally too. But I mean, listen, the way I look at this, we still have more than a year left in the contract. And a year, as you all know now in today's environment is a lot of time to make some pretty rising impact. So that's what we're focused on, both at SAP internally as well as for our customers.

Well, best of luck for the next 12 months, and, yes, looking forward to seeing the impact that comes through. I was at a dinner last night, and I think we were all asked big theme and the thing we wanted to get out of the conference. I think half of the room said, "How do we understand the moats for incumbent application software vendors?" So that was where I wanted to start off with, the kind of elephants in the room of how you protect what you have already and your moats. So how much risk do you think incumbent software vendors are from GenAI disruption? And what do you think SAP's biggest moats are?

Yes. I mean I think, listen, I mean, let's start with GenAI does pose significant -- has significant impact on existing software vendors. I think that's clear. Nobody is debating that. I think the thing that I feel like we lose in that discussion is not all SaaS vendors, not all applications are created equal, nor do they play the same role within a customer's environment. So while it is true that a certain class of SaaS applications are going to be a lot more prone to risk, disruption, transformation, I think there is a class of SaaS applications, and from an SAP perspective, we deeply believe we play in that class that are extremely mission-critical for an organization to operate. When you think about financial management, when you talk about general ledger, you talk about treasury, you talk about GL, AP, AR. And then you get into the supply chain side where you really run your shop floor or your logistics environment and things like that, that's a different class of applications. At least in my mind, sort of the moral equivalent, the way I think about it is, listen, there's a class of apps -- if you think about maybe even Windows, for example, right? It's an application at the end of the day. But it's sort of the OS of what consumers use every day on a device. SAP is very much like the operating system of a business. There's certainly a set of apps that are built on top of it. A lot of our partners do that, a lot of integrations exist, if you will. But it's hard to go take out the OS, if you will. While you could go build an OS with GenAI, are you going to go now start writing your own OS to be able to run your own devices? That's not necessarily true. But apps on top of it, sure, and customer applications, those lend themselves a little bit better to be able to go do. And then from an SAP perspective, while, listen, even in the class of applications we work in, there's phenomenal opportunity to create incremental value that now is possible with GenAI, that wasn't possible before, and that's what we're focused on. We do believe that the risk of disruption is different. And this is where I think the conversation that's happening today out there, is, hey, all SaaS apps are treated similarly, and that's what the initial reaction. But we fundamentally, when we speak with customers, when we look at our portfolio, the reality seems very different.

That brings me really nicely into the next question, which is this idea of there's a set of applications that already exists, the operating system that you talked about. But then there's this amazing white space that this new capability and technology opens up. Maybe first of all, how difficult would it be to replicate that operating system that you talked about? And then what advantage does the operating system give you as you think about moving into the white space and automating things that couldn't be automated previously?

Yes. And again, a very good question. So let's decompose sort of this class of applications and why they're different. That's sort of the crux of the question, right? And if you think about the things that makes this class of applications different is sort of 50 years of logic and business processes that are embedded, not just in the horizontal domains that we talked about, which is finance, HCM, spend, supply chain and so forth. But it's the deep industry capabilities in oil and gas and what we've done in manufacturing and what we do in media and others, if you will. Now that collective knowledge as well as the data that around it, the semantic understanding of it, the business process definition of it, sort of creates -- and not just that, right? For us as an enterprise player, because our history is we run some of the most mission-critical, largest organizations across industry, the level of sort of enterprise readiness, the governance, the security and the privacy and the fact that we're localized in so many countries around the world, creates this moat, this barrier of entry to say "Hey, I'm going to go build something and put on top of it." Now that's one aspect of it, right? So there isn't necessarily an immediate threat to say, hey, somebody is going to go build maybe a GL system, localize it around the world and be able to sort of comply with all the statutory. I mean that even exists in parts of our portfolio like Concur. I know there's been some discussions that say, "Hey, is Concur more prone to disruption?" But if you look at Concur and you decompose that business, it's expense management. And expense management may sound simple to the layperson, but there is a phenomenal amount of statutory requirements around the world that we spend a significant amount of our R&D investment, keeping up to date on a very regular basis. For sure, you can go create a forms-over-data application that allows you to capture expenses, but who's going to go do the compliance to the statutory requirements? Who's going to maintain that over time? Who's going to make sure all of that is integrated across your core OS for it to work? And that's why even if you sort of look back over the last 1.5 decades, there, from an expense management perspective, you think if it's that's easy, the space will be pretty proliferated. But it's not. Because even there, it's a moat from an enterprise perspective, from a localization perspective. Now that said, that's more of a barrier-to-entry moat. The question is there is now an opportunity to create tremendous value on top of it. And that is what we're deeply, deeply focused on. The thing that makes me sad, honestly, for the first question you asked me, is this is a once-in-a-lifetime sort of, to me, in a tech space, in a business application space, opportunity to create some phenomenal impact and value for customers and, hence, value back for SAP and our shareholders. And we're deeply, deeply focused on that. But if you think about sort of the opportunity that exists on top of it, certainly, automation is one big one. There's intelligence that sort of requires that data context, that process context, that context graph to be able to come with automation, to be able to sort of create autonomous experiences as well. And as you would expect, what we're working on Sapphire for us is around the corner, right? And I'm sure everybody would expect, like what we have coming up is one of our most ambitious launches in terms of now taking the opportunity and what's possible with GenAI and AI in general, putting it on top of the sort of core OS of applications that are unlike any others with its enterprise readiness, localization breadth, industry depth, and creating value, which is what our customers are looking for. And again, I like analogies a bit so I'll also sort of give another analogy here, which is if you think about autonomous applications in some ways, right? Autonomous not just meaning automation, but autonomous has a significance of intelligence that's baked into it, as well as being able to do things that, frankly, maybe humans weren't able to go do, because now you can do that at scale across a massive amount of data that's very hard for humans to go do. But if you think about sort of this autonomous -- concept of an autonomous business application, it's not very similar to, take autonomous self-driving cars, right? In sort of that core mission-critical set of applications, can you really go by autonomous software to put on a nonautonomous vehicle, and feel like, "Listen, this is perfect, I'm just going to go make my own car autonomous and drive it around the town." It just doesn't work like that. There's a level of seamlessness in the app, data, agent, think experiences, that really creates phenomenal value that's very hard to plumb on top. Can you do it in certain business case -- business processes? Yes. But then you have to also be aware of the TCO impact to the customer on the other side. Because what the customer is then doing is saying, listen, for this core area, this -- think of it as the OS of the business, I'm going to go pick something else, a PaaS provider, which everybody, and their brothers today, is building an agentic PaaS platform, right, that somebody can go plumb on top of whatever exists underneath. But you take on the cost of understanding the data model, which is very hard to go do, doing the integration, figuring out does the context exist, and then taking the risk of the decision and the recommendation that came out to your financial management, to your supply chain processes, to your spend, which are pretty -- you need to be very deterministic. You can't be probabilistic like you can be maybe in some of the front-office business processes, right, in lead opportunity and so forth. You have to be very deterministic here because a simple error could be pretty costly for the organization. You really build, add to the iceberg that exists for organization in terms of maintenance costs, integration and things like that, which, in some cases, even preventing application of the agentic layer. But again, to summarize, to me, I think this app, data, agentic experience that sort of creates that value seamlessly with the core OS, the systems of mission-critical applications that exist underneath, not just creates value that's unparalleled by just PaaS providers that you can hook into your environment, but it also leads to more deterministic outcomes. Because we feed it, I think you talked about the moats, and we can go a bit deeper into it, the moats that we have, which is deep process understanding, the data that we have, the data model, the SAP Knowledge Graph and so forth, that we're sort of building into as a post-trained model to work with what you can find off the shelf. And those 2 together then sort of create that value that we believe is very unparalleled. And I think the confidence that we have, again, I think the debate is raging out there in terms of what does that mean for SaaS applications. For us, what we're focused on, again, as you would expect to hear a bunch of things coming out of Sapphire, the proof is going to be in the pudding. And I think the feedback that we're getting from customers is, hey, listen, I want to go run an autonomous finance organization or an autonomous supply chain or autonomous spend. There's a level of credibility connectedness that comes to make sure that the whole vehicle is autonomous. Not that you buy a layer on top of it and say, "Hey, I'm going to put it on my 1990 BMW with this new software that's there and I'm just going to sit back and let it drive me home." You could do that, but there's a lot of risks doing that.

It's not a car that you would want to get into yourself.

Yes, yes.

No, it makes sense. You've already alluded to this, but I mean, I think that this is a big investor concern, that it's not that we actually replace the systems of record underneath, but rather the user interface shifts to probably a chat-based LLM interface sits above it. There's more interaction there and maybe more value gets created. For people that are running multiple systems of record, investors start to think, well, that could make sense. How do you think about that risk? How much do you want to collaborate with those companies to enable data access? And how -- the value of the intelligence that you have in the system, how much do you protect that rather than wanting to collaborate?

Yes. I mean it's a loaded question, so let me see. If I forget one part of it, remind me. But the first part you asked is the interaction layer -- yes, the agentic experience interaction layer. Because I do -- I think one of the things we also believe is, for the first time in sort of a long time, the shape of the stack is changing because there's a new layer now on top, which is this agentic experiences layer that sits on top of everything below. And then arguably, everything below becomes more platform, more commoditized and the value shifts up, if you will, both in what it creates for customers and the organizations that can charge premium for it as well. And that's really where the interaction layer happens. We used to sit at the top as an application layer, I would say. I mean we're still there. The world hasn't completely changed yet. But we see the signs that it's changing. So for us, again, it's not that, as you said, the lower layers are going away, like the application data, the PaaS and the IaaS. They're not going anywhere. They're still there from that perspective. The question is, for this new layer to work, how does the most value get created? And we believe, again, this agentic layer, the application that needs to exist, because that's where data gets created, that's where action gets taken, that's where compliance happens, that's where statutory requirements happen, if you will, particularly, again, for the class of apps that SAP is in. If you take a small single-lane application that just maybe does an HCM or does some front-office applications, that's a -- I think that's a fundamentally different landscape. I mean we stood on stage -- it was last Sapphire, and talked about, listen, we believe that the best-of-breeds will struggle in this world. But where SAP's moat exists even in this sort of new-stack layer, if you will, is the application layer becomes, again, a platform, if you think about this, right, because value shifts up. And from an application platform perspective, what organizations are telling us, this sort of sweet message to say, "Hey, at this platform layer, we need finance, spend, sourcing, supply chain, HCM, CX to work sort of seamlessly across." So SaaS becomes effectively a new platform. And we're one of the very few, you can count on one hand with maybe a couple of fingers, that can sort of go across that breadth of the business processes to provide that SaaS platform to power the experiences on top of it end-to-end. Because if you pick and choose in that SaaS platform 6 different providers, guess what, you have to build the integrations, you have to make sense of the data model yourself. You have to necessarily push the data somewhere else to be able to connect to. And that's resonating with customers because that also allows them to melt the iceberg, right, the complexity and the TCO that they maintain. Now that said, it's clear to me, certainly as a product leader into SAP, that we have to have a play in the agentic layer as well. We want to make sure that when somebody comes to Joule, they can ask a question about finance or supply chain and spend, from the same pane and get the right answer back through the SAP Knowledge Graph, through the sort of fine-tune model that we talked about, to get the most best response. And then the agentic experience is, again, leveraging that moat, encompassing in that agentic layer for us, sort of creates autonomous experiences. That's very hard to build as a PaaS story on top of it, right? So that's what we're working on really unlocking, working with customers and unlocking for our customers as well. And sort of this redefinition of the applications, these core applications, as agentic experiences, is, as you would imagine, something that we're working very, very aggressively on. And you'll hear a lot more about that too from a product innovation perspective. But through this, what we don't aspire to become is to say, listen, we're just going to now play in this SaaS as a platform layer. We do want to play in this agentic layer. But we'll, of course, be compliant with A2A, that if you have other things, as you come understand the SAP data, you come through our agentic layer, if you will. And it then creates this sort of stickiness for SAP's agentic layer through everything else that happens in the organization. Because while we're mission-critical, we're, in 99 out of 100 cases, not the only application that exists. There's some deep industry stuff, if you take oil and gas, upstream, downstream. If you take pharma, there's other things that happened as well. There are some industries we're actually pretty complete, like discrete manufacturing, it can mostly run on all SAP and things like that as well. But it allows that level of interoperability, if you will, on the moat that we have.

You've alluded to this a few times, this idea of the data, the business context. That semantic business context, how much does that still matter? And the question I get is, can these models not come into the system and infer that structure themselves?

Yes. They can. I mean, I think they can. But again, the difference is: for which kind of application, right? You can even put an MCP server, for those that are familiar with how MCP server works, in front of what I call a single-lane, single-domain application. And it will do actually a pretty nice job in translating the natural language query that's coming in into what is the answer that needs to come back. But soon as the MCP server has more than x number of tools underneath it, the accuracy just goes haywire, you can't rely on it. And if you look at the SAP landscape, the SaaS platform across finance -- even within one of them, the complexity is so vast, the data model, the table, the entities, the extensions customers build is so massive that it just doesn't work with a simple MCP server that you can put on top of it and think, as you might read in some LinkedIn post, "Hey, this is sort of going to be amazing and game changing." Now listen, I say that, but this understanding of the context to me is one of our deepest moats. And it's very hard even for us as publishers of the software to sort of solve it in a way where the SAP Knowledge Graph, the SAP process graph, the context graph through the interactions and the behavior of the application, is available at scale for all the agents all the natural language interactions. We've been at this for now 1.5 years, is when we initially said, listen, we're actually getting pretty close to our SAP Knowledge Graph, and this is what we've solved for. And as hard as it is for us to go solve, this is where our confidence comes in, that at scale, to sort of solve for what S4 has, with Ariba, with our supply, it's a very hard thing to go do. And hence, that creates the moat. So you have the raw data, but it's the relationship of the data and the semantical richness on top of it and then how it's used in the processes, is what creates that moat. And that's what we're sort of building into fine-tune models that, of course, the agents and Joule works on top of it, to again address a very vast surface area of an enterprise that otherwise is not easily understandable. Now what you could do is take the raw data, put it somewhere. And customers do that today. But then by definition, A, you've taken a lot of burden because you don't have the semantical context. B, you also lose the permissions and the authorizations, right? Because as soon as you go put it into a Databricks or a Snowflake or an Azure or a Google Big Query, then all it is, is sort of flat data that doesn't have permissions and authorization, which is also very critical. All of a sudden, because of GenAI, you're not going to start sharing your payroll data with all of your employees, your financial data everywhere, your supply chain data at scale from that perspective. So we maintain that as well. So our partnerships, particularly with what we've done with Databricks, allows our customers to maintain the data gravity with the semantical richness within SAP Business Data Cloud, that we launched last year, to be able to then create scenarios that are far more powerful from that perspective.

So this is all about the difference between a point SaaS solution and then the breadth of complexity in solutions that you're delivering the compliance and governance that sits all around it, that really differentiates you from peers. Again, we move on to data, and that's obviously a big moat for you. You mentioned Business Data Cloud. Could you talk a little bit about how you think about how customers lever the data responsibly and how that works through Business Data Cloud, how you're managing those partnerships?

Yes. I mean, I think when we launched a Business Data Cloud less than a year ago, initially with our partnership with Databricks and then we announced a partnership with Snowflake, Azure and Google as well. And for a first-year offering, it's actually been phenomenally successful. And no surprise to hopefully anybody here because data is the fuel that sort of powers the value that comes from AI. And the way we've sort of designed the architecture, it allows for 2 things, right? Clearly. One, we want to make sure that we bring to our customers best-in-class data engineering tools that we, at this point, don't feel like it's a battle we want to go win in, and organically build data engineering tools, because that market both become pretty mature and pretty commoditized. So we've brought those tools natively sort of embedded, in some cases, OEM, within Business Data Cloud, maintaining the data gravity, the semantical richness, and our customers can go use that to be able to sort of create value from it. So we're focusing on the things we add value on, which is harmonize data model across the applications, the connectedness, the Knowledge Graph of it, the semantical richness, partner on the things that have become commodity and data engineering, if you will, for 2 reasons, right? One, if you want to necessarily -- if you want to create value on top of that data through somebody else's AI tools, BDC is still the way to go do. So we become in that flow of value that gets created by anybody a customer may use. And by definition, that it gives us a level of both attach, stickiness with the value that we provide on top of that data, which hopefully as we just discussed a few minutes ago, is far different than sort of taking raw data out of the database somewhere else and trying to plumb on top of it. So there's value on top of it, and now we're in the flow of value that's being created theoretically by somebody else. The second part of it is because we now have that data available the way we do, bringing now some of the things we talked about earlier, you can help create agentic experiences and value on top of BDC with our AI platform that, again, covers majority, in some cases, of your core business processes with the right partnerships on top of our platform, where then we actually are the primary partners to create that interaction layer, that agentic layer, and hence, the value for the customer and premium value back to us and our stakeholders. So in both cases, this allows us to be part of the value chain. In one, of course, you can go do something, but there's BDC and there's other things. In the others, we're sort of core as the agentic layer, if you will. And again, what you'll find us do, and we talked about this at our SAP Connect event last fall and we've got some good customer examples for it, is what we can uniquely do then, that the PaaS agentic layers are not able to go do, is we can say, we will come up with out-of-the-box agents, right, that work in the seamless app data agentic experience, that you can extend if you have other tools, you need to add some pre/post-logic, because every customer is unique, but you can get to value far quicker in a lower TCO way than to say, "Hey, I'm going to buy this PaaS platform and then go figure all of that out," if you will. So that then also becomes, on top of the other moats that we've talked about, a value proposition for customers to say, "Hey, the leading provider of business applications is the one that understands my processes the best, industry horizontal, and my extensions, because we know extensions built on our platform can help create these agentic experience, and not just create, but use out-of-the-box AR agents, AP agents, spend agents, supply chain agents, and extend them to fit my need," is pretty phenomenal. Because while there's pressure, and I'm sure you guys know this, right, I think this is still very early innings for GenAI, right? And there's a lot of board pressure on CIOs and CEOs and CXOs to show value, like what have you done lately in GenAI? And there's a lot of organizations picking a bunch of different things, cobbling something together and say, "Hey, listen, here's value." But the lifetime TCO for that is pretty massive. What we're doing is saying, hey, we'll help you unlock agentic layer value out of the box with the right extension so you don't end up maintaining the burden of that till the end of time, if you will.

So just to make sure I understand properly on the Business Data Cloud, there's obviously going to be an environment, you talked about discrete manufacturing SAP can run pretty much end to end. I guess in that scenario, there will be less need for people to want to do Business Data Cloud. But where they're working with other systems of record, with other applications, would that be more where you could bring value and say, well, okay, yes, this is an environment now that's more heterogeneous, you can bring different data sets and then build on top of that? Is that the right way to think about it?

No, I mean, I think -- no. No. So if I give that perception, it's not that. Thanks for clarifying. The value of Business Data Cloud is there if you're an SAP shop in whichever form or fashion. Because what it does is it sort of brings the data, harmonize, with the semantical richness, with the authorizations and the permissions intact, with the SAP Knowledge Graph, that you can then go either build or consume the out-of-the-box agentic layer that we provide. Now what's different, and that's what BDC allows you to go do, is an industry like discrete manufacturing, most of the data would come from SAP, can come from SAP anyway, so it's sort of there. In oil and gas, the SAP data is there and you can zero copy-share with non-SAP data in a seamless fashion. So BDC allows you to be sort of that data layer and app data agents for all customers. In some cases, where there's a lot more data outside, you can do zero copy-share with some of the, again, the data engineering and data platform tooling that are out there with our partnership to bring it together.

That makes sense.

But it works on both flows, if you will.

Okay. We heard from one of the Business Data Cloud partners yesterday, and they talked about starting in the analytical, the OLAP world, adding OLTP, moving into transactions, talking about an application layer. So my question is how do you keep control of that environment from an SAP point of view? Because I imagine some of those partners might also have ambitions to start to build the applications, the agents on top of that. So how does SAP manage that as a partnership, potential competition with those partners?

Yes. And I think a simple way, and I actually found out that this person wasn't wearing a suit, so I probably should have followed his example and not dressed up here. To me, again, you have to go look at the nature of the partnership, right? So with Databricks, for instance, we have Databricks available within BDC. So that allows us the ability of those data engineering tooling with our data within the framework of the data gravity staying with SAP to build those agentic platform. Now if you have other data, you can sort of zero copy-share and build stuff. And same with Snowflake as well, to be able to go do. So our partnership sort of allows for leveraging the best of their platform within BDC for the value layer to be built. But if there's a massive amount of data that sits outside -- or if customers have already backed and put a lot of data out there, then you can zero copy the SAP data and BDC to that, but then keeps us into the flow of stuff. And then I think if you go back a few questions ago, I think the piece that, again, it's -- and I know that's not exactly what you're asking. The piece that -- where we feel like isn't necessarily going to be a reality in customers' environment is, because the data is there, somebody is going to start building applications on top of it in the class of applications we work in. Can they go build custom applications on some of those data platform partnerships? Yes. But then we also talked about the value of what comes out of the box, because there's deep context graph, there's the model that we're taking, there's Rapid one that we launched at TechEd last week that allows you to do data science but in the flow of the transactions. There's enough value proposition there to say, "Hey, what you build with BDC, with our agentic platform for the landscapes that we work in creates most value." But then, of course, there's always other things out there that those platforms can fill the gaps on.

Makes sense. You've actually given us some numbers around the total contract value of BDC. One of the things I'm interested in is, what's the time to value on those projects? How quickly can you go from signing a contract to getting people up and live and generating revenue with them?

So I think -- again, I don't -- Alexandra can sort of provide some of that offline. But more than half of our BDC customers are in usage today. So the time to value from BDC is very quick. It's not like your typical, think of it as an ERP implementation that says, hey, it's going to take x number of months for the value to show. And that's primarily because the way we've sort of built the product is, if you have the SAP landscape, the data products that we've built start feeding into BDC and then all the tooling is available for you to be able to sort of create value on top of it. And then we can also help you in your modernization journey for BW as well. So with both of those value propositions, we actually see a very healthy amount of usage and time to usage for BDC.

That's helpful. Maybe just to finish off with. I think one of the other things that's happened is we've kind of reduced software companies to just how they generate code. And if you can generate code more cheaply and more quickly, the value goes away. It seems to me that software companies are much more than the ability to generate code. But could you talk a little bit about how you think about that reduction in cost of producing code, how customers will be willing to pay for that in the future? So how does the structure of the industry change in terms of how you monetize going from seats to consumption? How do you think about all of that?

Yes. I mean I think it's an area we're spending a lot of time thinking through, what evolution that we may or may not need to make. I mean, I think if you look at the models that we have today, we have multiple models as well. We have a sort of significant part of value that's just embedded in the application for Joule-based that says, if you're running an SAP application, you can go interact and get value from it. Then there's a more premium capability that, per user per month, that says, hey, we wanted to give you predictability to say, hey, anything that we ship in this class, you can go try and use without having to feel like you need to add for this feature. The consumption is going to be this, and sort of come up with a complicated math. Because the reality is I think the ROI, just broadly speaking, in general, for some of these things are still to be really proven at scale. So what we don't want to go is get into this debate to say, to unlock this feature, it's this much consumption, so you need to show this. It's about, hey, here's a set of capabilities that's continuing to get better and you can sort of use and consume as much of it if you like. And then we have consumptive measures as well on top of it as well for scenarios that are deeply, deeply more consumptive, if you will. I think there are things around sort of now more outcome-based measures that we're looking at. We have usage-based metrics even today, not everything. And even our per user per month is user based -- usage-based as well, even in our core applications where, when you think about Ariba, we're talking about the spend that goes through as opposed to the number of users that are actually using the application. So I think as you would imagine, as the industry is, we're going to continue to see where things are going, and then evolve based on customer feedback on what we need to go do.

But the aim is to demonstrate the value before...

Clearly. I mean I think on the AI, I think we could, we at least believe at SAP, we both have the responsibility sort of running again these mission-critical applications to sort of prove and show the value. But then we have the ability to be able to sort of have the value show and then figure out, sort of based on feedback and discussion, what's the right business model in the fullness of time.

Perfect. Well, there's lots more we could discuss. We're bumping up against time. I want to thank you very much for joining us again.

Thank you for having me.

Thank you.

Thank you.