SAP USMM, LAW, SLAW and STAR explained. Four names, three tools, one field that sets the bill.

USMM measures one system, LAW consolidates all of them, SLAW is a transaction code into LAW, and STAR is an SAP service that maps roles to S/4HANA user types. Every named user count USMM and LAW report comes from field LIC_TYPE in table USR06.

What are USMM, LAW, SLAW and STAR, and how do they differ?

They are four names for three tools. USMM measures one SAP system. LAW consolidates the results from all your systems, and SLAW is only a transaction code that opens LAW. STAR is a service SAP delivers that maps your existing roles to S/4HANA user types.

None of the three measures digital access. That runs off a separate estimation report you install yourself, covered in our digital access measurement tools guide.

Every named user count that USMM and LAW report traces back to one field, LIC_TYPE in table USR06, which holds the license type recorded against each user ID. STAR works from roles instead.

USMM: one system, two lists

USMM runs on each system, covering the productive clients you select, and it produces two lists. The first is chargeable users by license type. The second is licensed engines, the packages SAP prices by a business metric. LAW adds consolidation and arithmetic on top of those two lists and nothing more.

The current program is USMM2, delivered through SAP_BASIS support packages such as 7.40 SP20 and 7.50 SP11, and it cannot be installed by note. The legacy program stays reachable through transaction USMM_OLD. Systems on different support packages can propose different user types for the same person, so check this before you compare results.

LAW, SLAW, SLAW2 and LICENSE_ADMIN

These are entry points into one tool. Each system sends its USMM result to a central LAW system as an XML file or over RFC. LAW then combines user IDs that belong to the same person and totals the consolidated count by license type.

The only commercially decisive step in that sequence is deduplication. A person with accounts in ECC, BW and a sandbox counts three times unless the matching rule collapses them into one. We cover how to set that rule further down.

STAR: a service with a person on the other side

STAR is delivered by SAP's Global License Auditing organization. It runs the Authorization Object Analyzer from SAP Note 3113382 against your existing roles and returns a proposed mapping from legacy ECC licenses to S/4HANA user types and FUE.

Two consequences follow, and both are commercial. STAR classifies on what a role permits, so a wide legacy role maps upward even if the person uses three transactions a month. And because STAR is a service, a named SAP employee owns the output, and the rule set behind it can be requested and contested.

Where does USMM get each user's license type?

From field LIC_TYPE in table USR06, and nowhere else. USMM reads that code for every user, totals the codes and prints the result. It does not look at what the person did. The classification is maintained on the license data tab in SU01, or in bulk through SU10, by whoever administers users.

In most systems we review, that field was set once, by whoever built the user creation template at go live. The template usually carried Professional, the cautious choice during a project. Few people outside Basis and security know the field, yet it is the multiplicand on the named user line of your SAP bill.

Why the Professional default survives for years

• Templates. New users are copied from a reference user that carries Professional.
• Automated provisioning. Active Directory or identity management feeds create users with a default type and never revisit it.
• Role changes. A person transfers from finance operations to an approval only job, and the license type stays where it was.
• Leavers. Accounts of people who left stay open and still count at their last classification.

Rule based classification in USMM2

In USMM2 you can define classification rules, maintained through LICENSE_ATTRIBUTES, that propose a type for each user from its roles. The proposal helps with scale, but it inherits the same weakness as STAR. Rules built on authorizations reward narrow roles and punish wide ones, so the rule set deserves the same scrutiny you would give a price list.

What does each SAP named user type cost?

The five named user types span a factor of 25 in list price, from Employee Self Service at the bottom to Professional near the top, with Developer above both. That spread is why classification decides more of the bill than any discount you negotiate afterward.

A worked reclassification

Say USMM returns 1,200 Professional users at $4,500, a $5,400,000 line. Usage evidence from the last twelve months shows that 300 of them only display and approve documents, which Limited Professional at $1,900 covers. You reclassify those 300 through SU10.

Reclassifying does not terminate a license, and $780,000 is list value, not a refund. What it does is remove 300 Professional units from the shortfall SAP is about to price, and lower the baseline for your next purchase. The support figure matters because it recurs in every year the contract runs.

How to prove what each user actually does

• RSUSR200. Lists users by last logon date. It finds dormant accounts and leavers that should be locked, the cheapest evidence in the whole exercise.
• ST03N. The workload monitor shows which transactions each user ran. This is the evidence that a user only displays and approves. Check the collector's retention settings early, because you need twelve months of history.
• SUIM. The user information system shows which roles and authorizations each user holds, which you need before any role remediation.
• SU10. Mass maintenance of user data, including the license type, once the evidence supports the change.

How should you configure LAW so duplicate users count once?

Choose the matching rule at the combine users step before anything else runs, and clean the data it depends on before a single file is loaded. LAW also accepts criteria such as an account number or a customer defined grouping code, but most groups choose among these three, and each fails differently.

1. Identical user name. Reliable when provisioning gives every person the same ID in every system.
2. Identical email address. The fallback where IDs differ by system. It only works if the email field in the user master is filled consistently.
3. Last name plus first name. A last resort. It misses duplicates where names are spelled differently, and it merges two different people who share a name.

Duplicate identities inflated the LAW total in 1 in 2 of the system groups we reviewed, almost always because no rule had been chosen deliberately. Reconcile the user master and the email field first, so duplicates collapse upstream. Then record which rule you used and why, because SAP may ask.

How the job differs by size

A company with one ECC production system and one productive client barely needs LAW. The work is almost entirely classification, and a few hundred users can be reviewed line by line in a week. The risk is concentrated in the template default and in leavers.

A group running ECC, BW, CRM, several sandboxes and an HR system has the opposite problem. Deduplication and consolidation carry most of the risk, the central LAW system becomes a controlled asset, and classification has to run by rule because no team can review 20,000 users by hand. Both need the same sign off discipline described below.

What does the engine list in a USMM result tell SAP?

The engine list carries the larger single line items, and it is the half of the measurement most customers never read. For some engines, SAP ships a measurement program and USMM counts the metric for itself. For self declaration products there is no program, so USMM prints whatever number sits in the field, unvalidated.

Self declaration numbers

SAP reads a self declaration figure as a statement your company made under its own hand. In our reviews these figures were routinely inherited: typed in at go live and owned by someone who has since left. An unsourced number, rounded up to be safe, becomes a priced admission at list.

Give every self declaration number a named owner and a source document before the measurement leaves your network. The owner should be able to explain where the figure comes from in one sentence, and the document should be something an auditor could read.

Using the engine list to find shelfware

The engine list is also the cheapest place to find shelfware. An engine measuring zero against a paid line is the strongest termination evidence you will ever hold, because SAP's own program generated it. Read each engine line against your contract and flag every paid metric where the measured value is zero or far below the licensed quantity.

How does RISE with SAP change the measurement?

Under RISE and S/4HANA Cloud, named users stop setting the price and Full Use Equivalents take over. The ABAP stack still runs USMM and SLAW2, but the commercial metric is FUE, at ratios written into the Service Use Descriptions: 1 FUE for 1 advanced user, 5 core, 30 self service, and 0.5 developer.

An FUE cannot be divided between package types, so each line rounds upward on its own. A population that looks tidy on paper can still come out higher than a straight total suggests.

The same 300 people, converted to FUE

Take a population of 5,040 people classified on evidence: 900 advanced, 3,500 core, 600 self service and 40 developer. Then carry the same 300 misclassified users across as advanced instead of core.

Three hundred people cost 240 FUE, 14.1 percent of the contract. Unlike a perpetual overbuy, that cost recurs in every year of the subscription. RISE conversion tactics are in our RISE negotiation tactics for 2026.

Why accepting the STAR result and then fighting over price is the wrong order

The usual advice is to let SAP run STAR, take its mapping as the baseline and put the effort into the FUE rate. We disagree. A person with a wide legacy role and light actual use still comes out as advanced, and once that mapping sits in a quote, every discount applies to an inflated count.

Ask for the STAR rules in writing before you accept any output, and test them against ST03N and RSUSR200. Then narrow any role that is wider than the work before the mapping runs. This is the cheapest FUE reduction available, and it rarely gets scheduled, because security owns the roles and procurement owns the money.

Digital access still arrives under RISE

Digital access does not disappear under RISE. It arrives as a document block priced off the same estimation report, so filtering the raw count matters. On one system group, the raw 2,400,000 chargeable documents fell to 1,680,000 once two categories were removed:

• Documents created by a licensed SAP user. The person who started the process already holds a named user license.
• Internal document to document jobs. Follow on documents that SAP generated from documents already counted.

That is a 30 percent cut. At the $0.40 per document list reference, the priced value falls from $960,000 to $672,000, a $288,000 difference before any negotiation. SAP has since released revised versions of the estimation report, so check for the current note first.

The indirect access model is covered in the complete digital access guide and the indirect access pillar.

What have we seen in SAP measurement reviews in 2024 and 2025?

Across 25 to 35 SAP measurement reviews in 2024 and 2025, the dispute was almost never about arithmetic. It was about who had the authority to decide the contents of one two character field, and the usual way companies handle the measurement gives that decision away.

• 20 to 40 percent named user overstatement. That is how far the named user line fell once users classified above their actual transaction profile were corrected, before any discount conversation opened.
• 1 in 2 inflated by duplicates. In half the system groups, one person holding several user IDs, with no consolidation rule chosen, inflated the LAW total.

Who should sign the measurement?

Most companies hand USMM to a Basis administrator as a recurring ticket. That person is careful and competent, and holds none of the three things that decide the outcome: the contract, the price list and the authority to reclassify anyone. So the administrator runs it as delivered, changes nothing that cannot be justified, and submits on time.

Every unexamined code in USR06 is thereby certified as correct by an organization that never looked at it. SAP's licensing auditors read the result as your own statement of position. After it is sent, every later discussion has you arguing against your own document.

The measurement is a document your company authors and signs, and SAP reads it that way.

Basis should keep the run. The classification decision belongs with whoever owns the SAP contract, with the price list beside the user list, and nothing leaves the network until that person has seen the delta priced. Where companies moved that decision, the argument with SAP changed from whether their number was wrong to whether their evidence was good enough.

Run USMM and LAW yourself first, fix the data and reconcile it to entitlement, and a formal audit loses most of its surprises. Our SAP audit defense guide sets out how to respond once one starts.

What will SAP say about your measurement, and how should you answer?

Expect a small set of lines from the account team and from license auditing. Each has a precise answer, and the answer is always evidence you prepared before the conversation.

• "The annual measurement is routine, just send the USMM results." Reply that you will submit by the date in the request letter, after your contract owner has reviewed classification and consolidation. Ask for the deadline in writing.
• "Your system reports these users as Professional." The system reports the LIC_TYPE value your administrators set. Send the ST03N evidence and the user type definitions from your contract, and ask SAP to identify any user whose activity exceeds the type you assigned.
• "We count every user ID unless you prove they are the same person." Provide the LAW combine users output, the matching rule you chose and the reconciliation list behind it.
• "The STAR rule set is standard." Ask for the rules in writing and a joint review of the results, and state which roles you are narrowing before the run.
• "Sign the shortfall this quarter and we will discount it." Correct the count first. A discount on an overstated shortfall still pays for users you do not need, and the inflated count becomes the baseline for your next renewal and its support fees.

Which contract terms should you ask for around measurement?

Ask for terms that fix the definitions and give you time to correct the data. SAP will not volunteer them, and each one is cheaper to win at renewal than during an audit.

1. User type definitions attached to the contract. Classification disputes turn on definitions, so the version that applies to you should be in the document you signed.
2. A correction window after submission. The right to correct a submitted measurement for data errors within an agreed period keeps one bad field from becoming a permanent admission.
3. Downward reclassification without penalty. Confirmation that moving a user to a lower type is allowed, and that the freed licenses can be reassigned.
4. STAR rules and output in writing. Both, with a joint review, before any FUE count enters an order form.
5. Digital access filtering rules. The exclusions for documents created by licensed users and for document to document processing, written into the order form.
6. FUE rebalancing. The right to change the mix of use types within your FUE total during the term.

When should each part of the measurement work happen?

Start twelve months before a renewal or the expected measurement date. Most of the evidence needs a year of history, and role remediation takes security teams months.

What to do next

1. Run USMM on every productive client. Check whether your SAP_BASIS level puts you on USMM2 or on the legacy program behind USMM_OLD, because systems on different support packages propose different types for the same user.
2. Export USR06 LIC_TYPE for every user and put the list band beside it. That spreadsheet is your argument. RSUSR200 and ST03N over twelve months supply the evidence for reclassifying to the actual profile.
3. Choose the LAW matching rule deliberately. Reconcile the user master and the email field before a single file is loaded, so duplicates collapse upstream.
4. Give every self declaration engine number an owner and a source document. Then read the engine list for paid lines measuring zero.
5. Move the classification signature to the contract owner. Keep the price list open during review, and remediate wide roles before STAR runs. Our SAP practice can run the review with you.

Frequently asked questions