It is no longer just a licensing or audit risk.
It is a financial exposure.
The on-premise mindset no longer describes the current SAP reality.
SAP is no longer a software asset. It has become a portfolio of contracts, subscriptions, consumption models, and financial commitments.
Even though some organizations still approach SAP with the logic of the on-premise world—an IT decision, projects with a defined beginning and end, and relatively simple landscapes—that mindset is no longer sufficient.
Today, SAP is an increasingly broad and complex portfolio of interconnected, multi-year financial commitments. Purchasing products and signing contracts without active governance means accepting a financial exposure that can grow every quarter.
SAP licensing is no longer a periodic compliance exercise. It requires continuous visibility into contracts, subscriptions, consumption, and usage rights across the SAP landscape.
What many organizations perceive as a technical SAP transformation initiative is, in reality, a long-term financial commitment. Migration to S/4HANA, cloud adoption, BTP services, and AI capabilities introduce new contractual obligations, consumption risks, and cost structures that require continuous governance.
Our market presence positions us as one of the companies with the deepest intellectual capital in SAP contracting and contract governance. VOQUZ Labs are specialists in this field. We have gathered the most important information about SAP and the licensing process to equip organizations with the knowledge required to govern SAP costs, contracts, and consumption effectively.
For decades, SAP licensing operated (and for some still operates) under a CAPEX model: companies acquired perpetual licenses, which were accounted for as assets on the balance sheet, and paid around 22% of the license value annually to access maintenance and support. This percentage could vary depending on the type and level of support contracted.
Although this model appeared complex and financially costly, it guaranteed ownership: the company held the perpetual right to use the software, regardless of whether it maintained a commercial relationship with SAP (that is, an active maintenance and support contract).
Under the subscription model - the model SAP has actively tried to move all its customers toward - this logic changes fundamentally. There is no longer a purchase of an asset. The company contracts a temporary right of use for a defined period, typically three to five years, with renewals that are generally complex and often bring unplanned financial increases, within parameters, limits, and conditions defined almost unilaterally by SAP. If the contract is not renewed, access to the system and solutions ceases.
This comparison illustrates the shift from traditional SAP on-premise licensing to modern cloud subscription models. Under the CAPEX model, organizations purchased perpetual licenses, retained control of their infrastructure, and operated within a predictable audit framework. Under the OPEX model, SAP licensing becomes subscription-based, infrastructure is managed by SAP, and organizations must actively govern consumption, contracts, and financial exposure across services such as BTP, and Digital Access.
Moving from a CAPEX model to OPEX has direct implications for the user company’s financial statements. Perpetual licenses were treated as intangible financial assets and depreciated over time. They could also be relevant in M&A scenarios. Subscriptions are recurring expenses that immediately negatively affect the company’s EBITDA. Companies, especially CFOs, need to define how this cost will be allocated, reported, and forecasted. This dynamic is even more complex for consumption-based products such as BTP and AI, which introduce variability that did not exist under the fixed-price model.
More than an accounting change, we see this as a shift in how control must be exercised. In subscription contracts, when they are not properly negotiated with the support of firms that have VOQUZ-level expertise, SAP defines rigid terms of use, limits, and constraints on provisioned infrastructure, measurement rules, and renewal conditions that are often not fully clear. In other words, the customer operates within SAP-defined limits, and any deviation—such as excessive BTP consumption, improper user reclassification generating high FUE consumption, or the use of APIs and integrations not approved by SAP—can trigger additional charges, usually at list price, immediately and without prior negotiation.
The key takeaway is:
The transition to the subscription model does not simplify SAP licensing, even if the vendor’s messaging suggests otherwise. It transfers the financial risk to the customer, who now must govern variable consumption across multiple dimensions (FUEs, BTP, AI, Digital Access) without the predictability that the CAPEX model once provided. Moreover, even if SAP now provides additional consumption management tools such as SAM4U, BTP cockpit, and SAP for Me, these tools don’t provide the urgently needed financial reporting that reflects the customer’s actual costs, consolidated across all SAP platforms.
For years, SAP licensing was defined by four main pillars: named users (who accesses the system), engines (additional functionality for SAP solutions aimed at industries or lines of business with distinct metrics), databases (largely defined by HANA Enterprise and runtime models, with a fixed cost or a percentage of the contract), and Digital Access (licensing for interfaces between SAP and non-SAP systems). This model, once considered the “basic” structure, had its own complexity, but it was more mappable and manageable.
Today, that model no longer exists as a reference licensing structure (unless you are still only using SAP ECC or SAP S/4HANA on-premises). The current ecosystem requires organizations to manage multiple layers of cost, consumption, and risk simultaneously—most often through separate contracts, different metrics, restrictive contractual terms, and independent negotiation windows.
The graphic above illustrates why SAP licensing has become significantly more complex over the last few years. Modern SAP licensing extends far beyond user licenses and annual audits. Organizations must simultaneously govern Cloud ERP subscriptions, Full Use Equivalents (FUEs), SAP BTP consumption, Artificial Intelligence services, Business Data Cloud (BDC), Commit-to-Consume agreements (C2C), Digital Access, engine metrics, API policies, and other contractual licensing models. Understanding how these elements interact is essential for managing SAP costs, maintaining compliance, and reducing financial exposure.
Governing this set of contracts, metrics, and risks in parallel requires an approach that goes far beyond annual license measurement in preparation for an audit or negotiation with SAP. The mindset now must be one of continuous financial governance.
Migration to subscription models, often interpreted merely as a market trend, is much more than that: it is also a strategic and commercial priority for SAP, executed simultaneously on multiple fronts. Understanding these levers is essential so organizations can make decisions based on their own interests rather than on urgency created by the vendor.
In this landscape, and through our services supporting customers in negotiations, we have identified recurring trends and moves used to accelerate expansion into the new model, including:
SAP offers credits against the maintenance value paid on on-premise licenses for customers who migrate to the cloud subscription model. These credits were once as high as 90% for early adopters, later became 80% in 2023, and have been reduced annually. The implicit message is clear: wait too long and you lose value.
What SAP does not emphasize equally is that credit urgency should not be the only driver. A poorly sized migration costs far more than the potentially lost credit differential—especially considering that other benefits can often still be negotiated.
In the remaining on-premise contracts, audit results have increasingly been used as the starting point for migration conversations. A compliance gap—such as product sublicensing, misclassified users, use of unlicensed engines, or interfaces requiring Digital Access—turns the conversation about correcting those deficits into a proposed “cloud package” presented as a way to “solve everything” at once. The financial pressure of the audit finding creates artificial urgency to accept terms that have not been carefully evaluated.
A message that is not new, but has gained strength and become especially powerful in SAP’s positioning, is that artificial intelligence capabilities (Joule, autonomous agents, SAP Business AI Platform) are available exclusively or primarily in cloud models. Organizations that remain on-premise receive the implicit message that staying where they are means falling behind in innovation – This message was corrected by SAP in 2026. Once used as a commercial argument for customers to move to the cloud, from 2026 on, SAP AI is also available for SAP S/4HANA on-premises customers.
Although many consider this a legitimate product strategy, it deserves careful scrutiny because most of the AI capabilities announced are still on the roadmap or available only through early access. Buying access to the future at today’s list prices—without delivery guarantees and without an independent ROI analysis—is a risk many organizations are not quantifying. Along similar lines, we have seen products such as HANA Database experience price reductions of 55% just a few years after launch.
It is also important to note that the broad right to use these technologies is being affected by constant changes in SAP policies. This means that the use cases some companies expect to enable with these technologies may become a major unplanned financial impact. We have seen something similar before with what is now known as Digital Access.
Our recommendation here is simple:
Evaluate each migration driver separately. Credits, audits, and AI are valid arguments, but the decision to sign a three- to five-year contract with consequences extending for years beyond should be based on independent financial analysis, precise sizing, and a comparative business case with real TCO— not on urgency created by the vendor.
In a presentation at SAP Sapphire Orlando 2026, CEO Christian Klein outlined a vision that will shape SAP’s strategy for the coming years: the Autonomous Enterprise. The central idea is that AI agents, integrated directly into business processes (finance, supply chain, HR, procurement, and others), will make decisions and execute tasks autonomously, with a level of precision and compliance that generic LLMs cannot provide. This assumes that systems must not only maintain SAP-designed standard processes, but also have data of sufficient quality to support autonomous operations—an assumption that is quite contradictory to the situation of most current SAP customers.
During his speech, Klein was direct: “For our customers’ mission-critical processes, almost right is simply not enough.” This highlights how ambitious the idea is and suggests a level of AI advancement that has not yet been demonstrated in practice.
As initial steps to realize this vision, SAP launched the SAP Business AI Platform: a unified architecture that consolidates Business Technology Platform, Business Data Cloud, and AI Foundation under one umbrella as the technical foundation of this strategy. Joule becomes the “gateway to SAP,” with a layer of autonomous agents beneath it and the data platform as the underlying foundation.
The vision is technically ambitious and, in many respects, genuine and aligned with broader market trends among major technology companies. But it still raises practical questions that organizations must answer before aligning their own strategy with SAP’s proposed agenda:
The graphic above summarizes the commercial shift in modern SAP licensing. While many organizations approach SAP transformation as an IT initiative focused on S/4HANA migration, cloud adoption, SAP BTP, AI, and best practices, the underlying reality is different. Modern SAP licensing introduces long-term financial commitments through subscription models, bundled contracts, Full Use Equivalent (FUE) licensing, and consumption-based services. As a result, organizations face new challenges including reduced cost predictability, limited contractual flexibility, ongoing consumption risks, and increasing financial exposure. Understanding these commercial drivers is essential for building a sustainable SAP licensing strategy and avoiding unexpected long-term costs.
The ever-faster adoption of new technologies means that organizations without active financial governance over their SAP contracts will, in each new cycle, keep signing commitments without fully understanding what they already pay for—let alone what they will pay in the future. And the concept of the Autonomous Enterprise is a promise of continuous change, which only reinforces the need for continuous control, not merely isolated on-demand reviews.
In on-premise licensing, each user received a named user license type (in ECC contracts these were the familiar Professional, Limited, Employee, and others). In the cloud subscription model, that logic was replaced by FUE (Full Use Equivalent): a consolidated unit that not only aggregates all user license types into a single contractual pool, but also embeds a level of infrastructure sizing provisioned by SAP that often does not match the infrastructure customers were used to having—whether in number of instances, server types, disk space, or services such as DR and HA. Although this sounds like simplification, in practice it creates new risks related to conversions made without analyzing real usage, and to the fact that the conversion factor itself can generate additional financial implications.
The central question here is whether user optimization still makes sense, and the answer is yes. Both from the standpoint of how users actually use their access and from the standpoint of the authorizations they hold—the latter being even more critical—we find significant room to optimize costs, mitigate potential future risks, and even reduce current costs. The reality is that behind FUEs there is still an underlying classification (named user licensing assigned to users), and that classification should be monitored and adjusted as effectively as possible so that, after conversion calculations, the number of FUEs remains aligned with what was contracted.
SAP defines different user types for the Private Cloud environment, each with a distinct weight in the FUE calculation. Profiles vary according to the level of access to S/4HANA functionality. There are self-service users with low weighting, users with full functional access who receive a significantly higher weight, and specific categories for developers and for users who interact with systems exclusively through engines, without direct interface access, and who—if correctly identified—may not be counted in the total FUE requirement.
The graphic above summarizes the SAP Cloud user types used in the Full Use Equivalent (FUE) licensing model. It compares the available user categories, their FUE conversion ratios, and the corresponding license definitions. The examples shown include SAP S/4HANA Cloud Advanced Use (1.0 FUE), SAP S/4HANA Cloud Development Access (2.0 FUE), and SAP S/4HANA Cloud Self-Service Use (0.033 FUE), together with the SAP-defined usage rights for each user type.
The difference in weighting between an Advanced User (1.0 FUE) and a Self-Service User (0.033 FUE) is 30 times. In organizations with large populations of self-service users incorrectly classified as advanced users—which is more common than many assume—this difference translates into contractual costs far above necessary levels, often locked in for years.
In our projects, we have found substantial opportunities to reduce required or in-use FUEs through detailed analysis of user activities and authorizations that place them in a higher licensing category than they truly need. And do not assume this applies only to systems that are already implemented and operational. Optimization here is feasible and relevant in multiple contexts: before negotiating the migration contract, during implementation, after go-live, in renewal negotiations, and beyond. Governance should not occur only at isolated moments—it should be continuous.
Also keep in mind that SAP’s strategy for moving customers to the new licensing model (cloud subscription) has two main characteristics:
In both scenarios, customers are likely to contract far more licenses than they actually need. We have demonstrated this through many projects in which we support customers not only in negotiating their new contracts, but also in optimizing their entire licensing position before negotiations begin—allowing them to contract fewer licenses than SAP’s usual perspective would suggest.
Still speaking of what SAP measures but does not optimize, SAP provides documentation and measurement processes for its Private Cloud environments that ensure SAP’s own visibility into what customers consume. This process is automated, executed monthly, and consolidated in the SAP for Me portal, which means SAP has continuous and, in some respects, precise access to customer consumption without relying on shared files or self-declaration.
What this process does not do is optimize. SAP’s measurement tools identify what is assigned, not what is effectively used. They do not suggest reclassification to move a user into a more basic and appropriate license type, do not identify oversized profiles, and do not cross-check authorizations against actual usage behavior. Adjustments may be made when necessary, but always upward. Keep in mind that regardless of the quality of the commercial relationship between customer and SAP, a conservative classification (more FUEs than necessary) is commercially ideal for SAP, while for the customer it is an avoidable cost—unless independent tools and expertise are used to identify it.
Compliance is not the same as optimization:
Being compliant with an SAP contract means you are not underpaying. Being optimized means paying exactly what real usage justifies—no more, no less. The difference between those two states can represent millions of dollars in mid-size and large contracts. Reaching an optimized state requires independent analysis, specialized tools, and deep knowledge of contractual rules—not just execution of the measurement process recommended by the vendor.
We cover the three pillars of SAP Licenses (Product Selection, Deployment Options, License Models) in detail and describe how an in-depth understanding of their role in the SAP License contract is fundamental to understanding your effective license position, avoiding unnecessary software spending and ongoing maintenance costs and furthermore, eliminate shelf ware and maintain license compliance.
In on-premise contracts, SAP’s audit right is exercised at a known and contractually defined maximum frequency: once a year. This audit is generally executed with customer support, as the customer must run the measurements SAP requests and share them by submitting files. In this model, the customer clearly has greater control as well as the opportunity to review what was measured before sharing it and, even without deep knowledge of the contracts, still has the chance to make small adjustments. In other words, there was a predictable cycle that allowed preparation.
In cloud subscription contracts, that regime has changed radically. There is no fixed timing or prior notice for an audit. SAP performs automated and continuous system measurement through its portal, with real-time access to consumption of FUEs, engines, and services. In other words, the customer operates under permanent observation, and any deviation between what was contracted and what is actually being consumed can trigger additional charges or renegotiation at any time.
The graphic above illustrates how SAP compliance and license measurement have changed from periodic audits to continuous monitoring. Traditional on-premise environments were based on scheduled system measurements, internal review cycles, and formal SAP audits, giving organizations time to prepare, validate results, and negotiate findings. Modern SAP cloud licensing increasingly relies on automated consumption measurement, continuous monitoring, and direct access to usage data through SAP platforms. This shift reduces the time available to identify licensing issues, optimize consumption, and prepare for commercial discussions, making continuous SAP license governance an essential capability.
This regime change reinforces, more than any other argument, the need for continuous financial governance. There is no longer a window to “get the house in order” before an audit happens. Licensing must always be in order, and the customer must have visibility into its own consumption before SAP does.
One of the premises that led many companies to consider migration to the cloud was flexibility—the ability to scale resources according to demand. In adopting cloud infrastructure under contracts with providers such as Amazon, Microsoft, Google, and others, customers moved from local infrastructure to an environment of elastic resources that could scale up or down, paying for what they used and turning off what was no longer needed. That was the promise hyperscalers made in their native contracts, and it attracted many customers.
The reality in SAP Cloud contracts is different. By signing a Cloud ERP Private (RISE) contract, the customer commits to a fixed volume with initial growth-only flexibility, largely based on the contracted FUE volume, with the potential to add extra components to the contract—but not remove them. In other words, the infrastructure provisioned by SAP (and subcontracted, notably, from major market providers) is sized at signing, and resizing is a formal process that rarely follows the agility customers once had when dealing directly with hyperscalers.
Another significant infrastructure and landscape change is that the landscape moved from a relatively “simple” model to a multi-layer model. Where an SAP customer once operated a relatively predictable on-premise landscape, today the ecosystem is composed of multiple layers with different cost models:
The graphic above compares the main SAP cloud licensing models and the financial risks associated with each of them. It distinguishes between Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), and consumption-based licensing models. For each layer, the table summarizes the commercial model, typical SAP examples, and the corresponding financial risk, including over- and under-licensing, shelfware, credit overages, infrastructure sizing, and consumption-based cost exposure.
Governing this multi-layer model requires more than an annual report. It requires continuous visibility into each layer, early alerts, and the ability to react before overconsumption turns into list-price charges.
The Commit-to-Consume (C2C) model is the commercial structure that underpins BTP consumption (via BTPEA or CPEA) and also appears as an embedded component in broader contracts such as Cloud ERP Private. The logic is straightforward: the organization makes an upfront financial commitment, in the form of a credit pool, and consumes that pool over the contract period as it uses eligible platform services.
For the IT team, C2C offers agility: the company can allocate credits across different services in the BTP catalog without contracting each product individually. For the Board, however, C2C changes the organization’s risk profile by transferring to the customer the responsibility to forecast, monitor, and control consumption. Without active governance, the model creates one of two problems: wasted credits due to underconsumption, or financial exposure due to overconsumption billed at list price.
The risk of underconsumption is simple: unused credits expire at the end of the contractual period. There is no automatic rollover, no credit applied to future periods, and no reimbursement. The commitment was made, the payment was completed, and the value not consumed becomes pure cost with no return. At the opposite extreme, when consumption exceeds the committed pool, the additional services are billed at SAP list price, without the discounts originally negotiated and often without adequate advance warning. The practical result is that organizations that do not actively monitor their burn rate face end-of-period surprises in either direction.
The central difficulty is that the right commitment size is genuinely hard to calculate at signing. Integration volumes, message throughput, and the use of AI and automation services are highly variable metrics that depend on projects, initiatives, and architecture decisions that are often not yet defined when the contract is signed. SAP presents C2C as flexibility; in practice, it is a kind of flexibility that requires sophisticated forecasting capability so it does not turn into avoidable cost.
Cloud ERP Private contracts are often perceived as fixed-price. That perception is only partially correct. The contract typically includes a volume of BTP credits calculated on ACV (the total annual contract value), but that volume is far from unlimited, and the AI, automation, and advanced integration services that SAP actively promotes in the context of the Autonomous Enterprise are exactly the ones that consume the most credits. Organizations that adopt BTP extensions, build custom integrations, or deploy AI agents within the SAP ecosystem frequently exceed the pool included in the base contract without having planned for that additional cost.
The difference is not the technology, because SAP provides consumption dashboards in the platform. The difference is governance discipline: who has authority to activate services, how costs are allocated by business area, how frequently burn rate is reviewed against the available pool, and whether there is an established process to react before risk thresholds are crossed. Organizations that treat BTP as pure IT infrastructure without a defined financial owner tend to discover deviations only when the invoice arrives—and at that point, correction options are limited and expensive.
There is also a contractual dimension that is often overlooked: several of the mechanisms that reduce C2C risk are negotiable before signing, such as partial rollover of unused credits, price protection for overages, ramp-up of commitments over the contract years, and rights to convert credits into other SAP products. These terms do not appear in the standard contract. Entering the negotiation knowing they exist—and with projected consumption data to support the request—makes a real difference in the financial risk assumed.
Digital Access was introduced by SAP in 2018 in response to the exponential growth of non-SAP solutions connected to SAP systems. The logic was straightforward: companies could contract third-party solutions to support specific business processes without investing as much as they would with SAP. Interfaces were also adopted as a way to reduce the number of users who needed direct access to SAP systems (and therefore named user licenses), by making data available to them through other channels such as portals.
This licensing model was defined as covering nine predefined document types whose creation by non-SAP systems must be licensed: sales orders, purchase orders, invoices, service orders, and others. But make no mistake: the risk does not disappear with cloud migration. Audit settlements can still reach two to three times the customer’s original estimate when handled reactively.
In April 2026, SAP introduced a significant revision to its API policy. These changes have meaningful implications for the freedom organizations have to build integrations.
The graphic above summarizes how SAP is changing the rules for integrations, APIs, artificial intelligence, and data access. Modern SAP architectures increasingly require organizations to use SAP-approved APIs, Business Technology Platform (BTP), Business Data Cloud (BDC), Joule, and other supported services instead of custom or undocumented interfaces. At the same time, restrictions on direct data extraction and external data replication are becoming more relevant, particularly for AI, analytics, and data lake scenarios. Organizations should evaluate these architectural and contractual changes early, as they directly influence future integration strategies, data governance, and SAP licensing decisions.
SAP’s API policy repeats, at a higher level, the same logic as Digital Access: SAP does not restrict data ownership, but it does control how that data is accessed and operationalized. For organizations pursuing best-of-breed and best-value AI strategies, this represents a significant architectural constraint and a potential new audit vector.
Retail organizations operating with SAP’s retail data model are subject to a Digital Access structure that differs from the general rule, and understanding that distinction can represent a substantial cost difference. SAP states that purchase orders, sales orders, material documents, and invoice documents created using the Retail model are excluded from Digital Access counting. Some of these exceptions also apply to required FUEs, which represents a meaningful opportunity.
Although this is a relevant benefit, it is not automatic, and its correct application depends on specific technical configuration in the customer’s system. Without the appropriate configuration, Digital Access measurement includes documents that should be exempt, and the customer pays for an exposure that should not exist.
But be careful: this exception does not apply to all Digital Access licensing. Quality management, manufacturing, service & maintenance, financial, and time management documents remain subject to Digital Access even in retail environments.
Contracts are long, highly technical documents drafted by experienced legal and commercial teams on the vendor side. It is not uncommon for clauses that appear neutral—or even favorable to the customer—to contain restrictions, obligations, or interdependencies that only become visible months after signing, when room to maneuver has already narrowed. Our work in hundreds of negotiations allows us to identify recurring patterns that no public document or official SAP guide will describe clearly. Below are just a few examples among many others:
One of the commercial mechanisms widely used by SAP in migration negotiations is to grant credits against part of the maintenance value of the active on-premise contract. The proposal is presented as a benefit: the customer receives credits that can be applied to the new cloud contract, reducing the cost of transition. In practice, however, what is often not visible in the commercial proposal is that these credits come with restrictive usage rules: they may apply only to certain products, within certain time windows, and be conditioned on minimum subscription volumes in the new contract, among other requirements.
More importantly, by accepting the credits and signing a new contract, the customer often continues to have payment obligations under the previous contract for an overlap period. The result is that, for months, the organization pays for both contracts simultaneously. When measured against this duplicated cost, the credit received often does not represent the savings originally presented—especially when the transition period extends beyond the planned migration timeline. Identifying this overlap before signing and negotiating transition terms to eliminate or mitigate it is one of the most concrete ways we support our customers.
A pattern we increasingly observe involves customers who sign migration contracts for S/4HANA Cloud and, a few months later, receive additional contract proposals from SAP worth roughly 20% to 30% of the total already contracted. The situation is particularly delicate because, by signing the migration contract, the customer also accepts termination of the on-premise licensing at a future date. At that point, the negotiation position changes radically: the customer has already closed—or committed to close—the path back, and any additional need for product or capacity must be met within the ecosystem SAP offers, at the prices SAP sets.
This is a scenario that independent TCO analysis, conducted before signing, could have anticipated. The sizing contracted at the time of migration rarely captures the full scope of the organization’s real needs, especially in environments with a high degree of customization, many integrations, or users distributed across multiple entities. The pressure to decide quickly, combined with the complexity of contractual documents, causes scope gaps to become unplanned additional costs.
Our experience in SAP negotiations shows that the standard contract initially presented to the customer is not always the best contract available. Many clauses that help protect pricing, renewal terms, scalability conditions, exit rights, measurement definitions, product usage rules, and overuse conditions, among others, are negotiable—but only for those who know they exist, understand their financial impact, and enter negotiations with independent data and market benchmarks.
The difference between an SAP contract negotiated with specialized support and a contract accepted on SAP’s initial terms can represent a significant cost gap over a five-year cycle. More than the value alone, the difference lies in predictability: well-structured contracts reduce or even eliminate surprises, while contracts accepted without deep review almost always create them.
The aspects mentioned above are only some of many issues that make a major difference in negotiation up to contract signature. Other matters—such as how SAP treats past investments, termination terms for products during migration, referenced documents incorporated by contract, and offers of “free” products that create dependencies before they create cost—are areas that, through our extensive experience, we not only understand but address every day through projects and services that support our customers.
What we provide here is not a complete list, nor merely a set of isolated technical problems. It is a portrait of a structural transformation in the relationship between companies and one of their main software suppliers. SAP is deliberately and consistently changing its business model: from a seller of perpetual licenses to a subscription platform provider, with continuous monitoring, calibrated commercial incentives, and AI and data products available exclusively through its own ecosystems. Each of these moves is rational from SAP’s perspective and aligned with major market trends. Each of them also expands the financial exposure of organizations that do not actively govern their contracts.
The transition from CAPEX to OPEX is not just a change in how costs appear on the balance sheet. It is a change in who retains control. In the perpetual model, the company buys an asset and negotiates maintenance. In the subscription model, the company rents a service whose terms, limits, and consumption metrics are defined by the supplier and can therefore be altered at each renewal. When that supplier also monitors usage of every user license, engine metric, and consumed credit, the information asymmetry between SAP and the customer becomes a concrete cost factor.
The response to this scenario is not to resist the transformation:
The real response is to have better visibility into your own consumption than SAP has, before SAP needs to communicate a deviation.
It is to enter any contractual negotiation—whether migration, renewal, expansion, or audit—with independent data, real TCO analysis, and a financially grounded position. It is to treat SAP licensing not as a periodic compliance task, but as a continuous financial governance function integrated into the organization’s cost strategy.
That is the space in which VOQUZ Labs operates. Our experience spans hundreds of customer engagements at different stages: from organizations still running ECC and preparing for a migration decision, to companies already under Cloud ERP contracts that need to understand what they have signed and where the risks lie. We develop our own tools, maintain a market database on SAP pricing, and combine this with advisory expertise that recognizes contractual nuances not covered in public documents.
The clear conclusion we can draw from the market is that the pace of change will not slow down. Autonomous agents, the Business AI Platform, BDC, and other SAP products all come with their own pricing models and negotiation windows that favor those who decide early and with the right information. The organizations that navigate this complexity with clarity are the ones that transform their relationship with SAP from a source of financial exposure into a real competitive advantage.
If your organization is evaluating a migration, approaching a contract renewal, or simply trying to stay in control of your SAP costs, that is exactly the type of conversation you want to lead with VOQUZ Labs. Let us get in touch and show you, how we can help you maximizing your ERP’s ROI while staying in control of your costs.
