SAP Self-Declaration (STAR/SLAW): What to Share and What to Withhold

SAP's annual system measurement isn't a compliance check. It's a data collection exercise that feeds directly into SAP's commercial pipeline. Every user count, every engine metric, every system configuration detail you submit through the STAR (System Technical Assessment Report) or SLAW (SAP License Administration Workbench) process gets reviewed by SAP's Global License Auditing team — who share findings with SAP's account executives to build the case for why you need to purchase more. Understanding what the SAP STAR and SLAW self-declaration process actually is — and calibrating what you share accordingly — is one of the most commercially important decisions an enterprise IT team makes each year.

The SAP STAR and SLAW are SAP's primary self-declaration mechanisms. STAR is a questionnaire-driven assessment used for smaller or cloud-centric customers; SLAW is the full measurement tool used in larger on-premise or hybrid environments, closely related to the USMM measurement process. Both serve the same commercial purpose: giving SAP visibility into your licence consumption. Both deserve the same careful handling.

What STAR and SLAW Actually Are

SAP frames STAR and SLAW as customer-friendly self-service tools that allow you to manage your own licence compliance. That framing is commercially convenient for SAP, but it obscures what these tools are designed to do. They are intelligence-gathering instruments. The data they collect feeds into SAP's ELP (Effective License Position) process — the internal SAP calculation of how many licences you are contractually entitled to versus how many you are actually using. Any gap between those numbers is a commercial opportunity for SAP.

STAR: System Technical Assessment Report

STAR is typically requested by SAP account teams for customers transitioning to cloud, renewing agreements, or under review for compliance. It asks for information about your SAP landscape — which systems you run, how many users, which modules are active, and what third-party integrations exist. The information requested in a STAR goes beyond what is strictly necessary to verify contractual compliance. SAP uses landscape information to identify upsell opportunities (underused modules that SAP can sell you the "right" licences for) and integration data to identify potential indirect access exposure.

SLAW: SAP License Administration Workbench

SLAW is the more technically comprehensive tool. It aggregates measurement data across your SAP landscape in a format that SAP can directly compare against your licence entitlements from your Order Forms and BoM (Bill of Materials). The SLAW output is the primary input to a formal ELP calculation. Unlike STAR, which requires manual data entry, SLAW pulls data programmatically from your SAP systems — but the parameters it uses to classify users and count metrics are, by default, SAP's parameters, not necessarily the ones most favourable to you under your specific contract.

What to Share: The Minimum Required Scope

Your obligation under your SAP contract is to provide accurate information about systems and users within the contracted licence scope. Nothing more. The practical question is: what does that actually mean? Here is a structured framework that experienced SAP licence compliance advisors apply when reviewing what to include in a STAR or SLAW submission.

The 5 Most Costly Self-Declaration Mistakes

Across hundreds of STAR and SLAW reviews, the same patterns of costly mistakes appear repeatedly. These are the errors that generate the largest unintended compliance gaps.

1. Including Non-Production Systems

The single most common and costly mistake. Enterprise SAP landscapes typically contain 6-15 systems: production, development, QA, test, training, sandbox, and various project systems. When teams run SLAW across the full landscape without scoping it to production only, they dramatically inflate their user count — and create a self-declared compliance gap that SAP can invoice against. Every non-production system in your SLAW output needs to be removed or justified. Your contract's definition of "production system" governs this, not SAP's default tool configuration.

2. Submitting Without Cleaning Inactive Users

User databases accumulate ghost accounts over years — departed employees whose accounts weren't deactivated, service accounts created for projects long concluded, and duplicate user IDs from system migrations. SLAW counts every active user account, whether or not a real person is behind it. Before any submission, perform a user account cleanup: lock accounts for users who have not authenticated in 90+ days, remove service and batch user accounts from the measurement scope if your contract permits, and reconcile your HR system against your SAP user list.

3. Accepting SAP's Default User Classification Parameters

SLAW classifies users based on the highest-privilege role assigned to them. By default, it uses SAP's current classification rules. But your contract may define user types differently — particularly if it predates SAP's 2017 licence metric restructuring. If your Master Agreement describes "Professional" users differently from SAP's current standard, running SLAW with default parameters will over-classify users who should be Limited Professional or lower. Always configure SLAW parameters against your contractual definitions, not the tool's defaults. This is work that requires someone who has read and understood your specific contract — not just someone who knows how to run SLAW.

4. Including Third-Party Integration Data in STAR Responses

STAR questionnaires often include sections asking about third-party systems that integrate with SAP. This data has no bearing on your current licence compliance position, but it is extremely useful to SAP's commercial team for identifying potential indirect access exposure. If you describe an e-commerce platform, a CRM system, or a third-party portal that creates SAP documents without direct user interaction, you are handing SAP the evidence it needs to build a Digital Access claim. Decline to answer STAR questions about third-party integrations, citing that this falls outside the scope of your contractual measurement obligations.

5. Treating SLAW Output as Your Final Position

The SLAW output is a measurement dataset — not a compliance verdict. Enterprises that treat the first SLAW extract as their definitive position, and submit it to SAP without review or challenge, miss the opportunity to correct errors before SAP's team calculates the ELP. Run SLAW, review the output, identify anomalies, correct what can be corrected (inactive users, non-production systems, misclassified users), and only then submit. The SLAW output SAP receives should reflect your best, defensible view of your licence position — not the raw uncleaned first extract.

Understanding Your Contractual Obligations

What you are required to provide in a self-declaration is defined by your contract — specifically by the measurement and audit provisions in your Master Agreement and General Terms and Conditions. These provisions typically specify: how frequently measurements must be submitted, what scope of systems must be included, what data must be provided and in what format, and what the consequences of non-compliance with measurement obligations are.

Many enterprises assume they must submit whatever SAP requests in whatever format SAP specifies. This is incorrect. Your obligation is to meet your contractual measurement obligations — not to answer every question in a STAR questionnaire or to provide data beyond what your agreement requires. If SAP is requesting information that is not covered by your contractual measurement obligations, you are entitled to decline. Your SAP licensing advisor should review your specific contract provisions before any submission to identify precisely what you must provide and what you can legitimately decline to include.

For enterprises working through a full audit process rather than a routine self-declaration, our comprehensive SAP audit guide covers the complete measurement-to-settlement process, including the role that self-declaration data plays in formal audit proceedings.

After Submission: Managing SAP's Response

Once you have submitted your SLAW or STAR data, SAP's Global License Auditing team will produce an ELP. This document presents SAP's view of your compliance gap — the difference between what you are contracted for and what you have declared using. This ELP is not a bill. It is an opening negotiation position. How you respond to it determines your financial exposure.

Challenge the ELP immediately and in writing if you believe it contains errors. Request that SAP provide the methodology used to calculate each line item. Identify discrepancies between SAP's ELP and your own internal measurement. If your SLAW was cleaned and configured correctly before submission, you will already have a strong independent dataset to point to. The existence of your own independently validated measurement data significantly strengthens your negotiating position.

Never accept an ELP and begin purchasing licences to close the gap without first engaging an independent advisor. Many ELPs contain tens of millions in claims that dissolve under technical scrutiny. Our SAP licensing case studies document exactly how enterprises have used independent technical review to reduce their ELP exposure by 50% or more.