What Is SAP STAR and Why It Matters in 2026

SAP STAR (System and Tracking Analysis for Resource Usage) is an activity-based measurement tool that has become central to SAP's audit and licensing strategy in S/4HANA and cloud environments. Unlike older assignment-based approaches, STAR monitors actual system activity to classify users and determine licence requirements. For enterprise buyers, STAR represents both opportunity and risk: it can reveal unused licences, but it can also be weaponised to justify aggressive licence upgrading during audits.

In 2026, STAR measurement is not optional. SAP has embedded STAR data collection into every S/4HANA system and mandates STAR runs as part of the audit discovery process. Contract language increasingly requires STAR measurement before initial licence entitlement calculations, and RISE with SAP contracts place specific STAR obligations on customers. This guide explains how STAR works, what it measures, where the measurement goes wrong, and how to build defensible positions against STAR-based audit overreach.

STAR vs USMM: The Fundamental Difference

The distinction between STAR and USMM (User Synchronisation and Measurement Management) is critical. USMM is a consolidation and assignment-based measurement tool: it synchronises user data from source systems, consolidates users across the landscape, and measures licence requirements based on assigned roles and authorisations. USMM asks: "What roles did this user get assigned?" The answer determines licence classification.

STAR, by contrast, is activity-based. It tracks what users actually did in a defined measurement period (typically rolling 12 months) and classifies them based on transaction usage, not assignment. STAR asks: "What transactions did this user actually execute?" A user assigned a single Functional licence role might still be classified as a Professional user if their activity log shows high-value transactions reserved for Professional users.

This difference is not semantic. In a USMM measurement, you can defend a user's classification by arguing they were assigned incorrectly or that assigned roles included unintended transactions. In a STAR measurement, your only defence is to argue the activity data itself is flawed, unsupported, or includes activities outside the user's actual job function. STAR shifts burden of proof: instead of defending role assignment decisions, you must defend against 12 months of logged activity.

How STAR Collects Data: The Measurement Agent

Every S/4HANA system includes a native STAR measurement agent. This agent is installed by default and runs continuously. It logs transaction execution events, capturing which transactions users execute, when those executions occur, and in some cases what data fields were accessed or modified.

The STAR measurement window is rolling 12 months. SAP's position is that any transaction executed within the 12 months preceding a measurement date is relevant to licence classification. This creates a material risk: a user who executes a single high-value transaction once in 12 months can be classified at a Professional level, even if they are a part-time occasional user of that functionality.

STAR data is collected at transaction granularity. Some transactions are "Professional" or "Expert" tier (requiring Professional or Expert User CAL equivalents), while others are "Functional" tier (available to Functional Users at lower cost). The measurement agent captures transaction execution frequency, but from a licensing perspective, frequency is often irrelevant — a single execution of a Professional transaction can trigger Professional licence classification.

Enterprise customers should understand that STAR measurement runs are not one-time events. STAR data accumulates continuously. If you have not cleaned up your user base or decommissioned old roles before STAR measurement, the tool will capture 12 months of historical activity, which can include activities from departed users, test activities, or one-off project work that inflates licence requirements.

Licence Classification Under STAR: Professional, Functional, and Productivity Users

SAP's STAR-based licence classification map has three primary tiers: Professional User, Functional User, and Productivity User. Each tier maps to specific transaction access and carries different cost implications. Under STAR measurement, users are not assigned to a tier — they are classified into a tier based on the highest-value transaction they executed within the 12-month window.

Professional User classification is the most expensive tier. A user is classified as Professional if they execute any transaction reserved for Professional access. These include most modification, creation, and configuration transactions across finance, HR, supply chain, and analytics modules. A single professional transaction execution during the 12-month period can lock a user into Professional classification, regardless of frequency.

Functional User classification sits in the middle. Functional Users can execute defined, limited sets of transactions — typically transaction variants that restrict data ranges, master data access, or modification capability. A Functional User classification is much more cost-effective than Professional, but still more expensive than Productivity.

Productivity User classification is the lowest tier and applies to read-only users or users limited to portal-based access. A user classified as Productivity has dramatically lower per-seat cost.

The risk in STAR measurement is that users get classified at the highest tier their activity history shows, not the tier appropriate to their ongoing job function. A user who was a Professional in their first month, then spent 11 months as a Functional user, will still be classified Professional. A one-off project activity that required Professional access, executed once two years into an employee's tenure, can trigger Professional classification for the entire subsequent 12-month window.

The 12-Month Window Trap: Activity Classification Risk

The 12-month rolling measurement window creates a specific and defensible point of leverage in STAR audit disputes. SAP's measurement logic is: any transaction executed within the 12 months preceding measurement date is relevant. This means one-time, occasional, or project-specific activities that occurred 10 months ago can still drive licence classification today.

Enterprise teams should document the context of high-value transactions. If a user executed a Professional-tier transaction during an ERP implementation project or in response to a one-off business requirement, that transaction may not represent their ongoing, routine job function. Building an audit trail of user activities, along with business justification for what triggered each high-value transaction, is essential defence preparation.

In disputed STAR measurements, we regularly identify scenarios where the 12-month window included temporary assignments, consultant activities, or one-time projects. The business case for this activity may have ended. The user may have returned to a lower-tier role. But STAR still counts the activity as current. Challenging this requires documenting what changed after that activity occurred and presenting evidence that the user no longer requires that transaction access.

STAR in Hybrid Landscapes: STAR and USMM Together

Many enterprises still operate mixed ECC/S/4HANA landscapes. SAP's measurement approach differs between the two: USMM applies to ECC systems, while STAR applies to S/4HANA. This creates a hybrid measurement problem. When SAP consolidates licence requirements across the landscape, it runs STAR on S/4HANA, USMM on ECC, and then applies the highest classified position for each user across both systems.

A user might be correctly classified as Functional on ECC under USMM but escalated to Professional on S/4HANA under STAR due to activity during an early migration phase. When consolidated, that user becomes Professional across the entire landscape, even if their ongoing role on ECC is Functional.

The hybrid measurement trap is compounded by user consolidation logic. SAP consolidates users across systems by matching email addresses, employee IDs, or other identifiers. If the same user has multiple accounts across ECC and S/4HANA (e.g., one for legacy business unit operations, another for new product line), and if those accounts executed different activities, SAP's consolidation may combine them into a single "highest-tier" user classification across both systems.

Before any hybrid measurement, enterprise teams should verify which user accounts will be consolidated and what the highest-tier classification would be if those accounts are merged. Identifying and decommissioning duplicate accounts, or documenting why separate accounts should not be consolidated, is a critical pre-measurement activity in hybrid landscapes.

RISE with SAP and STAR: Contract-Mandated Measurement

RISE with SAP contracts include specific STAR measurement obligations. Unlike traditional audit scenarios, where measurement is triggered at SAP's discretion, RISE contracts often mandate regular STAR runs — sometimes quarterly, sometimes biannually — as part of ongoing compliance verification. SAP uses these runs to recalculate entitled licence quantities, and if actual usage exceeds entitlements, customers may be required to purchase additional capacity.

The RISE with SAP STAR provision creates permanent measurement exposure. Traditional SAP customers face measurement during audits, which occur periodically (commonly three to five year intervals). RISE customers face continuous, contractually mandated measurement. This means one-off activities, seasonal business variations, or temporary project access can trigger licence upgrades with little opportunity to remediate.

RISE contracts often include true-up provisions: if measured usage exceeds purchased capacity, the customer pays the difference. The "difference" is calculated against SAP's standard pricing for incremental users, which is significantly higher than the per-user cost embedded in a bulk RISE purchase. Managing STAR measurement exposure in RISE contracts requires active pre-measurement preparation and continuous activity monitoring between measurement windows.

See our RISE with SAP Advisory service page for details on pre-measurement and measurement-window strategies specific to cloud-based RISE deployments.

Common STAR-Based Overcharges and Measurement Anomalies

In our experience defending enterprise customers against STAR-based audit positions, several patterns emerge consistently:

Orphaned Accounts and Departed Employees: STAR captures activity from accounts that may no longer be active or from users who have departed the company. If a terminated employee's account was not promptly disabled, and that account had activity history within the 12-month window, STAR may still count it as requiring a licence. The measurement then credits the activity to a successor, inflating that user's classification.

System Administration and Maintenance Activities: System administrators often execute Professional-tier transactions for system maintenance, data cleanup, or troubleshooting. These transactions may not represent the administrator's ongoing job function. STAR counts them equally with business-driven activities. If an administrator executed emergency support transactions, they may be classified at Professional level despite most of their work being maintenance-oriented and non-billable.

Test and Development Activity: If test or development systems were not separated from production, or if development users' IDs were not isolated, their activities may bleed into production measurement. A developer testing a new module configuration might execute high-value transactions that trigger Professional classification in an actual measurement.

Batch and Background Processing: Some automated processes execute transactions through technical user accounts. If those accounts are classified as named users rather than service accounts, and if the background processing includes high-value transactions, the technical accounts can be classified at Professional level, inflating overall licence counts.

One-Time Project Access: If users were granted temporary access to specific transactions during an implementation or business initiative, and if that access was not revoked after the project ended, STAR will capture the activity even if the user no longer needs that access. The challenge is proving that project access has ended.

Challenging STAR Outputs: Evidence and Arguments

Disputing a STAR-based audit finding requires different evidence than challenging USMM results. Since STAR is activity-based, arguments about role assignment are secondary. The primary question is whether the measured activity is reliable and represents genuine ongoing licence requirements.

The strongest challenges to STAR measurement address data quality. Specifically: are there system records showing accounts were disabled after the measurement window? Are there IT service tickets or access provisioning logs documenting temporary project access that ended? Are there system administrator notes explaining why certain users executed high-value transactions? Building an audit trail of user lifecycle events — accounts created, access provisioned, projects ended, access revoked — provides evidence that STAR activity may not represent current entitlements.

The second line of defence is context. Even if activity data is accurate, that activity may not have been routine or ongoing. A user who executed a Professional transaction once in 12 months, during a specific business event or project, is not the same as a user who executes Professional transactions daily. Presenting business context — project end dates, one-time exceptions, role transitions — allows you to argue the activity doesn't justify Professional classification going forward.

The third approach is questioning classification methodology. SAP's transaction tier mappings (which transactions are Professional vs Functional) should be reviewed against your actual role requirements. If SAP has assigned a transaction to Professional tier that your business treats as Functional-level work, that classification assumption can be challenged. We have successfully argued that SAP's default transaction tier assignments are overly conservative for certain industries or use cases.

Documentation is everything. Before STAR measurement runs, begin collecting user lifecycle records, project documentation, access provisioning logs, and system change tickets. This creates a discoverable audit trail that contextualizes activity data and provides ammunition for disputing aggressive classifications.

Our Services

Independent SAP Licensing Advisory

Audit defence, contract negotiation, licence optimisation — all buyer-side, no SAP affiliation.

Explore All Services → Case Studies

Real Results for Enterprise Buyers

See how we've helped enterprises reduce SAP spend by 30-60% and win audit disputes.

Read Case Studies →

Conclusion: Treat STAR as a Starting Point, Not a Verdict

SAP STAR measurement is a powerful tool for understanding system usage, but in the context of audits and licence negotiations, it is also a powerful tool for inflating licence claims. STAR's activity-based approach, combined with its 12-month rolling window, creates measurement that systematically classifies users at their peak-activity tier rather than their sustained job function.

Successful STAR defence requires preparation. Before SAP runs STAR measurement on your systems, clean up inactive accounts, document the context of high-value activities, rationalise roles, and build an independent pre-measurement baseline. These steps allow you to understand your exposure and build counter-evidence before SAP's measurement runs.

When SAP presents STAR-based audit findings, treat the output as a starting point for negotiation, not a binding determination. Challenge the data quality, provide business context, and marshal evidence that activity history does not support the proposed licence classifications. STAR is defensible — if you are prepared.

For help preparing for STAR measurement, challenging STAR-based audit findings, or navigating measurement disputes in RISE contracts, see our SAP Audit Defence service and our SAP Audit Guide.

Part of SAP USMM & LAW Tools Series