SAP's EU Decision - Part Two - SAP has handed you a chisel. Here's how to use it

In part one we looked at four practices that made SAP perpetual estates immovable, and at the commitments the European Commission made binding on 9 July 2026 in case AT.40823. Reinstatement penalties capped. Landscape splits permitted. The initial term no longer restarting with every purchase. Defined grounds for shedding licences when the business changes.

Four locks removed. What that leaves you with is a set of options, and options are not savings. They pay out only if you are positioned to exercise them, and the positioning takes longer than most people expect.

One term carries over from part one and everything here depends on it. A commercial installation is a technical unit, not a functional one: SAP solutions and their licences on a landscape with at least one production and one corresponding non-production system, identified by its own installation number. Differentiation happens at that level and nowhere finer. That single fact shapes everything that follows.

SAP has published guidance on what separates cleanly. Hub scenarios such as Master Data Governance, Extended Warehouse Management and Central Finance. HCM where it runs as its own ERP installation. BW and the analytical estate. SRM, GTS, PI and PO. Regionally split ERP systems with their own complete configuration. Systems acquired through a transaction that were already fully operational when you bought them.

It has been equally clear about what it will not recommend splitting. Core ERP modules covering finance, manufacturing, sales, service and logistics. Industry add-ons such as IS-Oil and IS-Retail that depend on the core. And a third case that deserves more attention than it gets.

Any landscape running multiple ERP production systems off a single central development and test instance is not cleanly separable. That is exactly how a great many well-governed organisations have built, and for good reasons: one place to develop, one transport path, consistent code across the estate, considerably less infrastructure to license and run. In most respects it is the better design.

The difficulty is that a commercial installation requires its own production system and its own corresponding non-production system. Where several production systems share one development and quality chain, that condition is not met. The production systems cannot be separated on paper because they are not separated in practice. Splitting them means building independent development and quality landscapes, which is a genuine project with real cost, and it leaves you permanently running duplicated infrastructure you consolidated deliberately. The organisations that will find this hardest are frequently the ones that governed their landscape best, which is uncomfortable, but it is what the rules produce.

So what does the chisel actually take off? A dormant SRM installation. An ageing BW estate nobody has funded in years. A regional ERP inherited through an acquisition and never integrated. Large, distinct, self-contained blocks.

What it will not do is trim. It will not address two hundred over-classified Professional users inside a system you are keeping, because they are not separable from the installation they live in. It will not remove an engine licence you barely use. It will not touch a module that underdelivered, if that module runs inside your core.

That gives you a test to apply before building any business case. Weigh the annual saving on a given installation against the lead time to an effective date, the technical work to separate systems that are not already separate, any additional licences needed to make each installation viable alone, and the ongoing cost of running whatever you had to duplicate. Large blocks clear that comfortably. Small ones do not clear it at all, and a business case built on the assumption that this tool trims to consumption will not survive contact with SAP's split process.

SAP has published guidance on what separates cleanly. Hub scenarios such as Master Data Governance, Extended Warehouse Management and Central Finance. HCM where it runs as its own ERP installation. BW and the analytical estate. SRM, GTS, PI and PO. Regionally split ERP systems with their own complete configuration. Systems acquired through a transaction that were already fully operational when you bought them.

It has been equally clear about what it will not recommend splitting. Core ERP modules covering finance, manufacturing, sales, service and logistics. Industry add-ons such as IS-Oil and IS-Retail that depend on the core. And a third case that deserves more attention than it gets.

Any landscape running multiple ERP production systems off a single central development and test instance is not cleanly separable. That is exactly how a great many well-governed organisations have built, and for good reasons: one place to develop, one transport path, consistent code across the estate, considerably less infrastructure to license and run. In most respects it is the better design.

The difficulty is that a commercial installation requires its own production system and its own corresponding non-production system. Where several production systems share one development and quality chain, that condition is not met. The production systems cannot be separated on paper because they are not separated in practice. Splitting them means building independent development and quality landscapes, which is a genuine project with real cost, and it leaves you permanently running duplicated infrastructure you consolidated deliberately. The organisations that will find this hardest are frequently the ones that governed their landscape best, which is uncomfortable, but it is what the rules produce.

So what does the chisel actually take off? A dormant SRM installation. An ageing BW estate nobody has funded in years. A regional ERP inherited through an acquisition and never integrated. Large, distinct, self-contained blocks.

What it will not do is trim. It will not address two hundred over-classified Professional users inside a system you are keeping, because they are not separable from the installation they live in. It will not remove an engine licence you barely use. It will not touch a module that underdelivered, if that module runs inside your core.

That gives you a test to apply before building any business case. Weigh the annual saving on a given installation against the lead time to an effective date, the technical work to separate systems that are not already separate, any additional licences needed to make each installation viable alone, and the ongoing cost of running whatever you had to duplicate. Large blocks clear that comfortably. Small ones do not clear it at all, and a business case built on the assumption that this tool trims to consumption will not survive contact with SAP's split process.

The commitments also make single metric contracts more widely available. SAP will respond in good faith where a customer with more than EUR 500,000 in cumulative net licence fees asks for one, calculating fees against a single agreed measure such as headcount, revenue or transaction volume, instead of a spread of user types and engines.

If you have ever spent a month reconciling Professional against Limited Professional against Employee Self Service, or arguing about an engine metric nobody can explain, the appeal is immediate. The administrative relief is real. So is the risk, and this is the part of the package we would want a client to think hardest about before requesting.

Start with whether it suits your direction at all. A single metric arrangement is a long-horizon instrument, and it rewards an organisation expecting to run a substantial on-premise estate for many years. If your roadmap has you materially into RISE or S/4HANA Cloud within a few years, you are engineering an elegant commercial structure for an estate you are in the process of leaving, and none of it carries across.

Then there is the metric itself, which is the entire decision. Choose well and you have a clean, predictable arrangement. Choose badly and you are worse off than if you had simply licensed what you needed.

We see this go wrong in a specific and expensive way. A customer takes a metric that delivers what looks like unlimited use, priced against something like revenue, within a defined band. It is genuinely attractive at signature and for the first few years. Then the business performs, revenue crosses the threshold at the top of the band, and the top-up becomes payable. The exposure lands on two fronts at once: the top-up itself, which for a large organisation can run into the millions, and the permanent increase to the maintenance base that follows it, uplifted annually thereafter. A metric tied to your prosperity charges you most in the middle of a good year, which is the hardest possible moment to justify a licensing conversation. In our view the right metric tracks your use of SAP rather than your success as a business, and has a trajectory you can actually forecast over five to ten years.

Three mechanics matter before you model anything.

SAP retains an annual audit right, and where the audit shows underutilisation it reduces the maintenance base rather than the licensed metric level, by up to twenty percent per annum. Note the asymmetry: the level you are licensed to only ever moves up, and a large underutilisation takes more than one cycle to work off.

Single metric contracts operate per commercial installation, so your installation structure has to be settled before the metric attaches. It attaches to whatever installations exist at the time.

And on exit, the flexing does not survive. The licences remain perpetual and the maintenance ends, but the measurement and adjustment process lives inside the arrangement you are terminating, so your entitlement crystallises at the level you had been trued up to and stops moving. Whether that entitlement is then expressed against the metric or against the enumerated product quantities underneath it depends entirely on how your order form is drafted, and the two produce materially different answers. Get the surviving entitlement stated expressly at signature, in the unit you would want to be measured in afterwards. It is a straightforward ask on the way in and a very difficult argument on the way out.

Nothing in this package sends anyone a cheque. Being positioned to use it means five things, all achievable, and most organisations have done none of them.

Know what you own against what you actually use. Not what the contract says you bought, which is a different question, but which licences are deployed and which are dormant. Almost every estate we look at carries material shelfware, and almost every organisation is surprised by where it sits.

Know how your estate maps to commercial installations. This is a technical question that never previously had a commercial consequence, so in most organisations nobody has asked it of the Basis team. Without that map you do not know which of your problems are addressable.

Know what each installation costs to support. This is harder than it sounds, because your maintenance invoice almost certainly presents cost against contracts and material numbers rather than installations. Producing a per-installation figure means allocating the maintenance base across the landscape yourself, and without it you cannot compare options, because you do not know the value of what you would be removing.

Know your initial term date, which is now fixed rather than moving, and which for many organisations has already passed.

And know your roadmap well enough to say which parts of the estate have a long on-premise future and which are heading to cloud, because that distinction changes the answer on almost every decision here.

Worth being straight about something. Four of those five were always available. SAP restricted what you could do about your estate. It never restricted your ability to understand it. The commitments have made that understanding far more valuable, but the reason most organisations cannot act quickly today is that the groundwork was never laid, and that part was always in the customer's gift.

Then there is timing, which people consistently underestimate. A split request is treated within six months, and takes effect on the next 1 January, 1 April, 1 July or 1 October following either SAP finishing the work or the end of that six month window, whichever comes first. A request lodged in March lands on 1 July if SAP moves promptly and 1 October if it runs the full window, and that is before you have decommissioned anything, moved any users, or stood up the infrastructure a split requires. Plan against the later date and treat the earlier one as upside.

The discipline runs both ways. It is not advisable to spend more than you need to on SAP support, and it is equally not advisable to compromise a larger SAP strategy to save modest amounts on maintenance. Dropping support on an installation you will convert in eighteen months, or fragmenting a landscape in ways that complicate a migration, buys you a line item and costs you a programme. The right question is not how much maintenance can be removed. It is what shape the estate needs to be in to serve where the organisation is going, and how much maintenance that shape happens to require.

While SAP loosens its grip on perpetual environments, the same thinking is absent from cloud and subscription. SAP has said so directly: the commitments concern on-premise maintenance and support, and the cloud portfolio is unaffected.

The reason that carve-out is hard to close is structural rather than a matter of goodwill. Every remedy in this package works because you own something. A perpetual licence survives the end of a support arrangement, which is precisely why splitting, terminating and reinstating are coherent ideas: there is an asset underneath that stays yours whatever happens to the support wrapped around it. In a subscription there is no surviving asset. When the term ends you have nothing, and there is nothing for equivalent remedies to attach to. The problem the Commission solved on-premise does not have the same shape in cloud, and the solution does not transfer.

Meanwhile the carve-out grows more significant every year. As more of your estate moves to RISE and S/4HANA Cloud, the share of your SAP spend covered by these protections shrinks. The commitments are binding for ten years, on a base that is contracting for most organisations across exactly that period. The Commission indicated it is alive to similar effects in cloud markets, which is worth something, but an indication is not a remedy, and changing these practices on-premise took a formal investigation, a preliminary assessment, a market test and a commitments decision. Nobody should plan on comparable cloud terms arriving soon.

Which is why the lesson from the perpetual estate is one to carry forward rather than bank. The constraints that made your perpetual agreement immovable were not exotic. They were ordinary commercial terms, reviewed properly by people answering a different question, and they became visible only when the organisation needed to change course. Your subscription agreements are being signed under exactly those conditions right now. Ask of them what nobody asked of the perpetual paper: not whether the contract is sound, but what it does when the plan does not hold.

That is also what makes this package strategic rather than transactional. The flexibility now available in your perpetual environment is what lets you approach a cloud decision without a compliance exposure or an unmanaged shelfware position sitting behind you in the negotiation. It is the difference between choosing to move and needing to. Used well it buys time, a clean baseline, and a credible alternative to moving on SAP's timetable, and those are worth considerably more at the table than anything you will save on a maintenance invoice.

So what should you do in practice?

Start your process with your map not with savings. Establish what you own against what you use, work out how the estate maps to commercial installations, allocate your maintenance base across them, and find your initial term date. Four questions, none of which requires SAP's permission, and together they tell you which of these options are genuinely available to you and which are theoretical. Most organisations we speak to cannot answer all four today, and until they can, every conversation about the commitments is speculation.

Then set that map against where the organisation is going. The same installation is a candidate for third party support if it has a long, stable, on-premise future, and a poor candidate if it is eighteen months from conversion. The same single metric contract is sound commercial engineering on one roadmap and an expensive mistake on another. No answer here is true independently of your strategy, which is why we would be cautious of anyone offering one.

Then negotiate the rest. Everything outside the defined grounds still requires a commercial conversation with SAP, and that conversation goes considerably better when you arrive with your estate understood, your dates known, your options modelled and a credible alternative in your back pocket. That is the difference between asking SAP for something and giving SAP a reason to agree.

This is the work Precipio does. We are an independent SAP strategy and licensing advisory, and we work with SAP customers in the New Zealand market, so the local context is familiar ground. We take no commissions from SAP and none from the integrators we might recommend, so the advice is shaped by the outcome you need and by nothing else. An advisor whose economics depend on the deal, or on the next one, has a structurally harder time pushing on the terms where the real difference is made. And we do not take over your responsibilities. We help you meet them, by connecting the dots across the estate, the roadmap and the commercial position, and by creating the conditions in which SAP agrees to things.

If this has landed close to home, the useful next step is to stay across it. Sign up to our insights on SAP licensing, commercial strategy and deployment, and tell us which areas you are focused on so we can send you the ones that matter. If you would rather talk it through against your own estate, get in touch and we will make the time.

SAP has handed you a tool, and for the first time in a very long while the room to use it. Understand your position, plan properly, and watch your commercial relationship with SAP become unrecognisable.