Managing SAP Package and Engine Licenses: Metrics and Cost Optimization
Beyond user licenses, SAP’s software pricing includes package or “engine” licenses – entitlements for specific functional components measured by business metrics (like employees, orders, revenue, or hardware size).
These engine licenses can be complex and costly if not managed properly, as usage can grow beyond licensed amounts.
This article targets enterprise CIOs, SAM professionals, and procurement teams. It clearly explains how SAP package/engine licenses work and offers strategies for monitoring usage and optimizing costs.
We’ll cover common metric examples, how to avoid over-licensing or compliance gaps, and ways to negotiate better terms for these module-based licenses.
What Are SAP Package/Engine Licenses?
SAP sells many software add-ons and vertical solutions as “package” licenses (engines). Unlike named user licenses (tied to individuals), engine licenses are tied to a specific usage metric.
You purchase the right to use a certain SAP component up to a defined quantity of that metric.
Here are typical examples to illustrate:
- SAP ERP Modules by Throughput: Some classic ERP functionalities beyond the base system are metered. For example, SAP Payroll might be licensed by the number of employees processed. If you have 5,000 employees, you’d need a Payroll engine license for 5,000 employees. Similarly, the SAP Sales and Distribution (SD) module could historically be licensed by a metric like gross revenue or number of sales orders per year (though in many cases, core SD is covered by user licenses; it depends on how SAP packaged your deal).
- Industry Solutions: SAP offers industry-specific engines, like SAP for Utilities (licensed per number of customers or meter points), SAP Oil & Gas components (often by barrel throughput or revenue), etc. These align with industry metrics. An engine license might say you can process up to X utility contracts or Y barrels of oil daily.
- Technical Engines (Database, etc.): The SAP HANA database is a common engine license. Using SAP’s in-memory HANA database under a runtime license is often licensed per memory volume (e.g., 64 GB increments) or CPU core. For instance, an SAP HANA, Limited Runtime Edition license might be sold as “64 GB of HANA memory” – if your actual database size or allocated memory exceeds that, you need additional licenses.
- SAP Digital Access (Document Licensing): Introduced to address indirect use, this engine counts documents created (like sales orders, invoices) by external systems. You might purchase, say, 100,000 Digital Access documents/year. If external systems generate more documents, you must true-up. This “digital document” license is effectively an engine replacing the need for numerous “indirect user” licenses.
- Cloud Platform & Others: Unlike traditional on-prem engines, even SAP cloud services have metric limits. For example, SAP Integration Suite (part of BTP) might be sold based on the number of API calls per month. These are analogous to engines: you buy a block of consumption and must monitor it.
Your contract includes a formal definition for each package. It specifies how the metric is measured (“an employee is defined as…”, “a sales order is defined as…”).
Staying compliant means ensuring your usage of that metric stays at or below the licensed quantity (or you procure additional licenses when it exceeds).
Read SAP Cloud Licensing Models (SuccessFactors, Ariba, Concur).
The Cost Pitfalls of Engine Licenses
Engine licenses present a few unique challenges in cost management and compliance:
- Growth of Metric = Higher Costs: These licenses are tied to business growth indicators. You can outgrow your license if your company grows (more employees, sales, and data). Unlike fixed user counts, these metrics can increase without anyone explicitly installing new software – it’s just organic business growth. This means unexpected cost spikes: e.g., a surge in sales orders could suddenly make you under-licensed for the Sales Orders engine. It’s crucial to align license capacity with business forecasts. A fast-growing business should budget for license expansions of engines accordingly.
- Difficult to Track: Some metrics are not straightforward to measure. Counting users or employees is one thing, but how do you continuously track “number of batch jobs executed” or “gross revenue processed in SAP”? Special SAP transactions or reports (sometimes custom) are often needed to check these. If you’re not regularly checking, you might assume you’re within bounds until an SAP audit runs specialized measurement scripts and finds you’re 30% over your licensed metric. It’s not uncommon for companies to be caught off-guard on an engine because they weren’t watching that specific metric (especially if it’s buried in technical detail).
- Shelfware Engines: On the flip side, some organizations purchase broad entitlements “just in case” that then remain underused. For example, licensing an engine for 10 million transactions per year while only 1 million are used – that’s over-licensing and means you overpaid upfront and pay excess maintenance yearly. This often happens when deals are made based on optimistic projections or to get a bulk discount. While it avoids compliance issues, it ties up the budget. Identifying such cases can allow you to negotiate reductions or drop maintenance to save costs.
- All-or-Nothing Usage: Engine licenses are typically not elastic. Technically, if you go 1% over your licensed metric, you’re non-compliant for that excess unless you buy more. There’s usually no concept of “bursting” or automatic incremental charges (unless you explicitly negotiated some pay-as-you-go). This binary nature means you must leave a safety buffer or risk crossing the line. But leaving too much buffer (overbuying) is wasteful – it’s a balancing act.
- Complex Metric Definitions: SAP’s definitions can be nuanced. For example, how exactly is “revenue” measured for a licensing metric? Is all sales revenue in the SAP system, or only certain orders? Definitions matter. If misunderstood, you might think you’re compliant when SAP’s definition actually counts more. A notorious area is employee counts: does “employee” include part-time workers, contractors in the system, and retirees with data in SAP? Usually, these details should be clarified to avoid disputes if they’re in the SAP system.
Best Practices for Engine License Management
To control costs and remain compliant with SAP package licenses, adopt these best practices:
- Inventory and Understand Your Engines: Start by compiling a list of all engine/package licenses in your SAP contract. For each, note the metric and the licensed quantity. Then, crucially, determine how to measure actual usage for that metric in your SAP system. Some can be checked via standard SAP admin reports (LAW can capture many engines, and specific measurement programs exist for certain components). For example, SAP provides a tcode USMM/LAW output that might list engines like “SAP ERP Human Capital Management: 5,000 employees licensed, X currently used”. In other cases, you might run specific reports (SAP Note often provides programs to measure things like documents). If unsure, work with SAP support to get the measurement methods. Knowledge is power – you can’t manage what you don’t measure.
- Set Internal Monitoring Alerts: If possible, set up internal alerts for the metrics. For instance, if you have an engine licensed by the number of employees, have HR inform IT when employee counts are nearing the licensed limit. Or if an engine is by sales orders, maybe a simple custom ABAP can count orders and warn if approaching the cap. Your basis team can monitor system size growth for technical metrics like CPU or memory (HANA). Proactive monitoring allows you to curb usage or start the process of expanding licenses in a controlled way.
- Include Metric Reviews in Change Processes: Many metric overruns happen after a big change, e.g., onboarding a newly acquired company’s employees into SAP (suddenly adding thousands of users to your HCM module), or a new product line doubling order volume. It’s critical to bake licensing checks into such projects. Before integrating a new business unit into SAP, ask, “Do we have enough licenses for this jump in employees or transactions?” Likewise, when upgrading hardware for SAP HANA, ask, “Will our HANA memory usage cross into a higher license bracket?” Early in project planning, involve your SAM or licensing team to evaluate the impact. This can prevent an after-the-fact scramble with SAP.
- Negotiate Scalable or Tiered Terms: There is room to negotiate beyond the static number when purchasing engine licenses. For example, you might negotiate a price per unit for additional capacity upfront. Suppose you license 1000 engines of something (say 1000 “documents”). Try to have the contract specify the price for the next 500 if needed. This way, if you grow, you know the cost and ideally lock in a discount rate. Some customers negotiate tiered pricing (the unit price decreases if they buy more). Another approach is a temporary use clause: can you average usage or have a short-term overflow allowance for seasonal spikes? SAP might not always agree, but it’s worth discussing if you have cyclical business.
- Avoid Over-Purchasing “Just in Case”: While a buffer is wise, huge overallocation isn’t. If SAP proposes you license double your current usage to be safe five years out, weigh the cost of paying now (and maintenance each year) vs. possibly paying a bit later but only if needed. It might be financially smarter to license what you need for 1-2 years and plan to true-up later, even if that true-up license is at a slightly higher unit cost. Don’t pay maintenance for years on excess capacity you’re not using. Many SAP engines can be procured relatively quickly if you exceed them so that you won’t be without options in an emergency – SAP will happily sell you more at that time. Keep some contingency, but be rational about growth projections.
- Periodically Revisit Usage vs. License: Just as with named users, set a schedule (maybe semi-annually or quarterly for fast-changing metrics) to compare actual usage to what you have licensed. If you find usage is consistently well below your entitlement, that’s an opportunity. You might decide to drop support on the unused portion to save costs. For example, you are licensed for 10,000 employees but only have 6,000. You could keep paying maintenance on all 10k (in case you grow), or perhaps trim your maintained count to 6,000 or 7,000 and stop paying on the rest (you’d still own rights to 10k on that older version, but if you needed to activate them later, you’d have to pay back-maintenance or re-license). This decision should factor in growth plans, but it’s a lever for cost savings if you’ve been well over-licensed.
Optimizing Costs in Engine License Agreements
When negotiating or renewing SAP agreements, consider these optimization tactics specific to engine licenses:
- Bundle Users and Engines in the Deal: SAP sales teams often have flexibility on engine pricing if you also make a significant user license purchase or renewal. Use that: for instance, if you’re buying a bunch of S/4HANA user licenses, you might simultaneously negotiate a deep discount on an engine like SAP Extended Warehouse Management. Bundling can hide the discount where you need it – SAP might be more willing to give 80% off an engine and 40% off users, depending on their sales strategy. Look at the total spend holistically and allocate your negotiation capital to the most expensive components.
- Get Clarity on Metrics and Audit Process: Insist that the contract documents how usage will be measured for each engine. Also, ask SAP account teams to walk you through how they will verify that metric during an audit. This sometimes brings out important details (like “Oh, we run program XY_Z, which counts line items in these tables…”). Knowing this, you could even replicate their approach to check yourself. Ideally, the contract should reference a SAP performance measurement or SAP note for measurement. Clear definitions reduce the chance of disputes. If something is vague, clarify it in writing (e.g., “revenue means revenue recognized in module SD for sold goods, excluding tax” or whatever nuance).
- Leverage Conversion & Decommissioning Credits: If you are transitioning from one SAP product to another (say, moving some on-prem modules to the cloud), you might have engine licenses that become redundant. In such cases, negotiate credits. For example, “We will drop the SAP CRM engine (licensed for 1000 users) as we move to the SAP C/4HANA cloud; SAP will credit us with some value for the new purchase.” Similarly, if you realize you don’t need an engine anymore (maybe you implemented a third-party solution), talk to SAP about a license exchange: SAP has programs (under their contract conversion policy) to let you swap one license for another of equal value, which can be a route to avoid waste.
- Third-Party Support as Leverage: For stable engines (not many changes or upgrades are needed), some companies consider third-party support (from companies like Rimini Street) to stop paying SAP maintenance. You keep using the license as-is, and the third party provides support at ~50% of SAP’s maintenance cost. This is usually considered for older engines, when you don’t plan to upgrade, or when SAP is sunsetting. While this is a big decision and means separating those licenses from SAP’s support umbrella, it can save costs. Even if you don’t go that route, knowing the option can be a negotiation point when discussing maintenance fees.
- Sunset Unused Engines: Review if you have engines on your books that have not been deployed. Sometimes companies buy licenses for future projects that never happen. If you find one, consider officially terminating that license (so it’s removed from support billing). There’s no benefit to holding a license for a product you will never use. Be mindful: once given up, you’d have to re-buy at full price if you want it later. But if it’s shelfware, freeing it can reduce complexity and cost.
Recommendations
- Tie Metrics to Business KPIs: Integrate license metric checks into business performance reviews. For instance, if HR reports a hiring spree or Finance reports revenue growth, trigger a check on related license consumption.
- Maintain a License Dashboard: Create a simple dashboard for each engine showing licensed quantity vs. current usage vs. % remaining. Update it quarterly and share it with IT leadership—this keeps awareness high and prevents surprises.
- Engage Module Owners: The people running the SAP modules (HR, sales, warehouse, etc.) should know their usage has a licensing implication. Work with them so they understand thresholds. For example, warehouse managers should know if doubling transaction volume could breach a license limit. When people are aware, they can sometimes help control or predict usage.
- Plan for Peaks: If your business has seasonal peaks (e.g., holiday sales surge), factor that in. Maybe your yearly average orders are fine, but a one-month spike could break the limit. See if your metric is measured on a peak or average basis and plan accordingly. Sometimes SAP engines consider peak concurrent usage (like maximum users at a time for some engines) – always clarify this and plan license counts based on peak if that’s the measure.
- Use Test/QA Systems Wisely: Engine licenses typically cover all use of the software in any environment (production, development, etc., since it’s tied to usage, not where it runs). But if you maintain separate test systems, avoid duplicating data that could inflate counts. For example, if you copy your production system to test, including all data, an audit might aggregate employees from both (depending on how the measurement is done). Usually, LAW has options to exclude test systems or count the unique union of users/objects, but be careful that non-prod systems don’t inadvertently double your measured usage.
- Document Usage Calculations: Keep spreadsheets or reports detailing how you calculate each engine’s current usage. When an audit or true-up happens, you can compare your figures to SAP’s. If there’s a discrepancy, documenting your calculation method helps resolve it or challenge SAP’s figures if needed.
- Negotiate “non-performance” clauses: If an engine’s usage declines (e.g., business shrinks or you optimize processes to use fewer transactions), try to negotiate that you can reduce license counts or get credits. SAP contracts rarely allow refunds, but if you have a cooperative account team, you might negotiate a swap or reduction at renewal for underused licenses. It never hurts to ask, especially if you’re buying something new simultaneously.
- Stay Aware of Indirect Impact: Recognize that engines can be affected by indirect usage, too. For example, if an external system suddenly starts pumping thousands of transactions into SAP, your document or user counts could spike. Ensure integration projects consider license impacts—e.g., if you connect a new e-commerce front end to SAP, remember that each order coming through counts toward your SD documents license. Mitigate by possibly using SAP’s digital access license for that scenario if it’s more cost-effective.
FAQ
Q1: What must I do if I licensed SAP Payroll for 5,000 employees and acquired a company with 1,000 more?
A1: You need to increase your SAP Payroll engine license to cover the additional 1,000 employees before processing them in SAP. That likely means procuring an additional license for those 1,000. Ideally, you contact SAP, tell them about the acquisition, and negotiate pricing for the increment. If the acquisition is mid-contract, SAP might give you a pro-rated price for the remainder of the year. The key is that you shouldn’t process those new employees in your SAP system without updating the license – doing so would be non-compliant. Also, consider timing: if the acquisition closes in October, maybe negotiate that the extra 1,000 are free for a few months and then added at renewal—SAP sometimes has flexibility to accommodate such events.
Q2: How does SAP measure “number of documents” or “revenue” for license purposes?
A2: SAP typically provides specific measurement tools or programs. For documents, SAP’s Digital Access adoption program includes an auditing tool (the “Digital Access Evaluation Tool”) that scans your system for document counts in the relevant categories (Sales Orders, Invoices, etc.). SAP might use specific tables (like the total of certain billing tables) in a given period for revenue. SAP’s Global License Auditing team often executes these during an audit. Some metrics are captured in LAW, but others might need manual steps. As a customer, you can ask SAP for the measurement guidelines or use the notes SAP has published. It might involve running specialized ABAP reports that output the count. Always verify the period – some metrics are based on peak concurrent values, others on annual totals, etc. The contract usually states if it’s “per year” or “at any time.”
Q3: Our SAP usage of the engine went down this year. Can we reduce the licensed level and save money?
A3: Directly reducing a perpetual license count isn’t straightforward – you already bought it. You can’t “sell it back” to SAP. However, you can choose not to pay maintenance on some of those licenses in the future, effectively shelving them. For example, if you licensed 10 engines and now only need 5, you could keep five on active maintenance (getting support and upgrade rights) and lapse maintenance on the other 5. You still own them (to use up to the software version when maintenance ended), but you’d be non-compliant if you started using them on a version released after your maintenance ended. This tactic saves maintenance fees. Another angle: at your next contract negotiation, see if SAP will allow an official reduction (especially if you’re buying something else – they might accept a give-back to make a new sale). Or, if on cloud, things are different – subscriptions can usually be reduced at renewal time.
Q4: Are SAP engine licenses one-time purchases or subscriptions?
A4: In the traditional on-prem model, engine licenses are one-time perpetual purchases (with optional annual maintenance fees). You pay upfront for the right to process 1 million something forever. In the cloud or newer consumption models (like BTP), engines are effectively subscriptions (e.g., you subscribe to a certain capacity per year). Many SAP engines now have cloud equivalents where you pay by usage per year. But if we’re talking classic engines in ECC or S/4HANA on-prem, it’s usually a perpetual license. You own it and only need to buy more if you exceed it (or if you want support, pay maintenance yearly). Always clarify with SAP which model you’re getting, as SAP pushes cloud, some offerings might only be available as a subscription now.
Q5: What is an example of an expensive SAP engine license to watch out for?
A5: One example is SAP HANA runtime licenses. If you run SAP Business Suite on HANA (not Full Use HANA, but runtime), you pay a percentage of your total SAP application value for the HANA database license. If you expand your SAP application licenses, your HANA license needs may increase correspondingly. Also, if you move to S/4HANA, HANA underpins it – the cost of HANA (either embedded in S/4 or separate) can be significant. Another is SAP Treasury or SAP IS-Oil engines – some industry ones can be very pricey per unit. SAP BusinessObjects BI suite historically had engines like cores for Analysis Processing – if you still use that, core count increases can be costly. Any engine tied to technical resources (cores, GB of memory) can rack up costs as you upgrade hardware. So, if you plan to double your server capacity, check if that impacts license counts for any SAP engine.
Q6: How does SAP handle engine license compliance during an audit?
A6: During an audit, SAP’s auditors will request that you run measurement programs. Many engines are measured via the LAW tool output (LAW consolidates user counts and certain package metrics). For specialized engines, auditors might send you specific scripts or have you execute certain transactions to capture current usage. For example, SAP Payroll might ask for a report on the number of active employee master records. They then compare these numbers to your entitlements. If you’re over, the audit report will state a compliance gap (e.g., you used 6,000 of X, licensed for 5,000, thus 1,000 unlicensed). They will then typically propose that you purchase the difference (1,000 units) plus possibly back-maintenance for the period of overuse (this can happen if they believe you exceeded for some time). The negotiation is similar to any audit resolution – you’d negotiate pricing for that shortfall, perhaps at less than list price if possible. It’s far better to catch it yourself and buy proactively than to do it in an audit scenario.
Q7: If we decide not to use a particular SAP module anymore, what steps should we take regarding its engine license?
A7: If you’re truly decommissioning an SAP module (say you’re switching off SAP CRM in favor of Salesforce, for instance), you have some options. You can drop maintenance for that module’s engine license at the next renewal, saving you money in the future. You keep the license (in case you ever reactivate the module at an older version), but if you know you won’t, it’s essentially shelfware. You might also inform SAP and see if they’ll do a license exchange or retirement: sometimes, as part of a broader deal, SAP might agree to cancel that license (so you stop paying maintenance immediately) if, for example, you commit to a new purchase elsewhere. You might bundle a removal clause if you have a direct ELA (enterprise license agreement) with SAP. Also, be sure to document that you are no longer using it (so if audited, you can show zero usage). Remove user access to that module, or technically uninstall it if possible, to avoid accidental use.
Q8: Can I transfer an engine license from one system to another or one company code to another?
A8: Engine licenses are enterprise-wide if the systems are within the same corporate license agreement. You don’t “assign” them to a specific server or module instance. So, if you have an engine for 1000 orders and deploy two SAP systems, it typically means that the total across both should not exceed 1000. You have the flexibility to use it where needed internally. You cannot split licenses outside your organization, though. For example, you can’t give 500 orders to a subsidiary that isn’t covered by your license agreement unless your contract allows that (usually, all affiliates are covered if listed). So within your organization’s SAP landscape, it’s a floating right. If you retire one system, the license doesn’t vanish – it can be used on another. Just track aggregate usage.
Q9: Are there tools to help manage engine license usage?
A9: Yes. Aside from SAP’s own measurement tools, some third-party SAM tools can track engine metrics. Snow Optimizer for SAP can monitor certain package measurements regularly. SAP Solution Manager can also be configured for some license analytics, and SAP has a tool called “SAP Licensing Audit Tool” or newer CLC (Cloud License Center) for some environments. However, engine metrics are so varied that not all can be automatically tracked easily.
Q10: What should we do if we suspect SAP’s metric definition doesn’t match our understanding?
A10: Clear it up immediately with SAP, in writing. If your SAP Order Form or license contract wording is ambiguous, email your SAP contract representative asking for clarification on the metric. You want a written response (even if email) that you can keep. For instance: “Our contract says ‘Procurement spend’ – does this include tax? Does it include inter-company purchases?” Getting answers helps avoid contentions later. You can sometimes negotiate an amendment if the definition seems unfair or too broad. For example, some customers negotiated that transactions (like inter-company orders) wouldn’t count toward the license. SAP might agree if it’s reasonable and not intended to be counted. Always best to handle this proactively – after an audit starts, SAP might stick to strict definitions. Also, SAP periodically updates its Software Use Rights document, providing standard definitions. Ensure you refer to the version applicable when you signed your contract (unless your contract auto-updates to new definitions, which some do). Licensing experts or lawyers can help interpret if it’s complex, but don’t be shy to ask SAP – explaining what you bought is part of their job.
Read about our SAP License Optimization Service.
