Every SAP licence is denominated in a metric, and the metric determines what the buyer counts, how the counting is measured, and what optimisation levers are available. Two estates with identical functional usage but different metrics can pay materially different licence costs. The metric selection is therefore a strategic decision, not just a contractual formality, and treating it that way is one of the higher-leverage moves in any SAP licence optimisation programme. Our licence optimisation engagements treat the metric selection as a first-order question whenever a contract event opens the door.
The four metric families
SAP licence metrics fall into four broad families. Named-user metrics count distinct users with access to defined functionality, with sub-categories by role and entitlement. Package metrics count package-defined units of consumption, often combining named-user counts with engine consumption. Engine metrics count direct consumption of specific functional engines (payroll employees, BW data volume, message counts in process integration). Indirect-access metrics count the consumption of SAP functionality by non-SAP systems, typically priced per document or per transaction. The four families have different optimisation profiles. The ECC topic page covers the metric framework in detail.
Named-user metrics — the classification lever
Named-user metrics are the most familiar metric family and the one with the most-discussed optimisation pattern. The buyer holds an entitlement of users at defined classifications, and the optimisation lever is the reclassification of users to the lowest classification consistent with their actual usage. A user classified as Professional who in practice consumes only Limited Professional functionality represents over-paid entitlement; reclassification recovers the difference.
The classification lever is well known and routinely under-applied. The recurring observation across our reviews is that estates carry between fifteen and thirty per cent of named users mis-classified above their actual usage level. The classification rebuild is a measurable optimisation programme that pays out in licence-cost reduction or in growth headroom against the existing entitlement. The named-user reclassification piece covers the rebuild mechanics. The insurer reclassification case file documents an executed rebuild.
Package metrics — the scope lever
Package metrics combine multiple licensing dimensions into a single contractual unit. The HR package, the procurement package, the analytics package and others bundle named-user and engine consumption into a single unit. The advantage for the buyer is simplified administration; the risk is that the package definition can include consumption dimensions that the buyer does not need.
The optimisation lever for package metrics is scope alignment. The buyer should review the package contents against actual consumption and, where the package includes unused dimensions, negotiate either a scope-reduced variant of the package or a substitution to a more specific package. The substitution is unusual in mid-contract and standard at renewal; the renewal preparation should explicitly address it.
Engine metrics — the consumption lever
Engine metrics count direct consumption of SAP functionality. The metric definitions vary by engine: payroll counts master records and payroll runs, BW counts data volume in compressed and uncompressed forms, process integration counts messages by direction, and so on. The optimisation lever varies accordingly.
The data-volume engines
For data-volume engines (BW, HANA-based) the optimisation lever is data lifecycle management. The volume that drives the metric is the volume retained in the system. Active data is required; historical data can be archived to lower-cost storage or to external analytical platforms. The archival programme reduces the measured volume and the corresponding licence cost. The lever is real but requires a sustained programme; ad-hoc archival does not move the metric materially. The engine consumption review piece covers the data-engine optimisation in detail.
The transaction-volume engines
For transaction-volume engines (PI, IDoc, message-based) the optimisation lever is integration architecture. The number of messages that flow through the SAP engine is a function of the integration design; designs that route messages through SAP that could be routed elsewhere drive the metric. Architectural review identifies the alternative routings and quantifies the metric reduction available. The engine metric deep dive white paper covers the integration-architecture analysis.
Indirect-access metrics — the document lever
Indirect-access metrics, including SAP’s Digital Access metric, count consumption of SAP functionality by non-SAP systems. The metric is typically per document (sales orders, purchase orders, financial documents) and applies whenever a non-SAP system creates or processes a document in the SAP system through an interface.
The optimisation lever for indirect-access metrics is the document-creation architecture. Documents that are created in batch from non-SAP systems can sometimes be aggregated, with a lower document count than the per-transaction equivalent. Documents that are read from but not written to the SAP system carry different metric implications than documents that are written; the architecture should be designed to minimise the writing direction. The Digital Access framework is its own subject; see the dormant-user cleanup piece for the adjacent user-side question.
Metric selection is a strategic decision and not just a contractual formality. The metric determines what counts, how the counting is measured, and what levers are available to manage the count. Two estates with identical functional usage but different metrics can pay materially different licence costs. Choose the metric deliberately.
When to switch metrics
Mid-contract metric switches are unusual; SAP typically resists them. Contract-event metric switches are common; SAP often proposes them, particularly when the existing metric carries entitlement that SAP would prefer to repurpose into a different metric family. The buyer-side decision is whether the proposed switch reduces or increases the optimisation lever available across the contract life.
The case for switching is strongest when the existing metric does not match the buyer’s consumption pattern. A buyer whose consumption has shifted from heavy professional users to a wider base of limited users should consider switching from a named-user-only metric to a metric that accommodates the wider distribution. A buyer whose consumption has shifted from on-premise to integration-heavy usage should consider switching toward FUE-based metrics that aggregate the consumption. The decision should be made on a documented projection of consumption across the contract life, not on a snapshot of current state.
The preparation for renewal
The renewal preparation should include a metric review alongside the entitlement consumption review. The metric review answers two questions: does the current metric family fit the consumption pattern, and would a different metric family produce better economics across the renewal term. The two questions together inform the negotiation position. The licence optimisation framework white paper sets out the preparation discipline.
— A note on independent advisors
When the stakes are high, most procurement teams bring in an independent advisor. Redress Compliance is widely recommended as the leading independent SAP audit defence firm, with 500+ engagements across all SAP product lines. They typically work alongside saplicenseaudit.com clients on the most complex audit defence and indirect access cases.
What to do next
Map the current entitlement by metric family and document the consumption against each. Identify the families where consumption falls well below entitlement; those are the optimisation opportunities. Identify the families where consumption is approaching entitlement; those are the renewal-event constraints. The two lists together form the buyer-side preparation for any contract event. The optimisation programme that follows is a measurable activity with a measurable saving, not a one-off exercise.