The single most common finding in an SAP licence audit is misclassified named users. The auditor opens the USMM extract, filters by license type, and starts looking for users whose role contents do not match the tier they have been assigned. Each upgrade between tiers can move a single seat by four to nine thousand dollars on the SAP price list, and a population of two hundred misclassified seats is a fifteen-to-two-million-dollar reopened finding before the negotiation even begins.
This guide explains the three core named user license types in the SAP rulebook — Professional, Functional (sometimes called Limited Professional in older agreements), and Limited Professional — what each one actually authorises, where the boundaries are, and how to defend a classification when SAP challenges it.
The three tiers, in plain English
SAP's commercial price list contains dozens of named user types, but in practice ninety per cent of the seat count in a typical estate sits in three categories. The structure has been broadly stable since the 2014 price-list refresh, though SAP introduced subtler boundary changes in 2020 and again in the 2024 RISE migration paths.
Professional User
The Professional User is SAP's broadest individual authorisation. It permits operational, system-administration, and management functions across the modules the contract covers. If a user can run a transaction that creates, posts, or releases a financial document, a sales order, a purchase order, a production order, an inventory movement that generates accounting, or any kind of master data record that drives downstream pricing or planning, that user is almost always a Professional. The price tier sits at the top of the user metric, typically $4,800 to $6,000 list per user depending on the contract vintage and any negotiated discount.
Functional / Limited Professional User
The middle tier is the most contested. SAP markets it as the license for users whose role is bounded to a specific business function — a controller who runs reports and posts journals in a single company code, a buyer who creates purchase requisitions but not commercial agreements, a warehouse supervisor who handles goods receipts but not master-data maintenance. The catch is that the contract definition is narrow: any cross-module activity, any creation of documents that drive a different module, can push the seat back into Professional territory. Price typically lands at $1,800 to $2,400 list.
Limited Professional / Employee Self-Service
The bottom tier covers users whose interaction with SAP is essentially read-only or restricted to their own personal records: time entry, expense submission, leave requests, payslip viewing, internal directory lookups. The SAP definition is unambiguous on what is allowed and what is not, and any attempt to use the tier for "occasional" operational users is a guaranteed audit finding. Price typically lands at $200 to $450 list.
Why the boundaries matter so much in 2026
Two structural changes have pushed user classification to the centre of SAP audit findings over the last eighteen months. The first is the broadening of audit-tool sophistication: USMM now extracts more granular transaction usage data, and SAP's License Administration Workbench (LAW) consolidates that data across system landscapes in a way that makes role-content analysis trivial for the auditor. The second is the shift of revenue pressure toward existing accounts in the run-up to the ECC end-of-mainstream-maintenance window. SAP's account teams are explicitly compensated for compliance-driven uplift, and named user reclassification is the lowest-friction lever they have.
The result is a defensible classification has to be more than a reasonable read of the contract. It has to be evidenced. That means role-content documentation, transaction-usage extracts that demonstrate what each user has actually done over a measurement period, and a written classification policy that the customer can produce when challenged.
Where the misclassification finding typically comes from
1. Operational users assigned as Limited Professional
The most expensive single category. A warehouse clerk who runs MIGO or MB1A to post goods movements has crossed the operational threshold and cannot sit as a Limited Professional. A field engineer with the Mobile Service licence who creates service notifications has the same exposure. We see this consistently in manufacturing and field-service estates, often because the original implementation team made a cost-driven judgement that has not been revisited in five or more years.
2. Functional users with cross-module authority
A Functional user who has been granted authorisations in even a single transaction that creates a posting in a module outside their nominal scope — for example, an HR business partner who can release a workflow that creates a payment proposal — falls back into Professional territory under the contract. Cross-module authority objects are subtle and often hide inside copied composite roles.
3. Service accounts treated as Limited Professional
Technical and integration accounts that perform RFC calls, batch jobs, or interface processing are not Limited Professional, even where there is no human behind them. The audit treatment depends on whether the activity is genuinely indirect under the indirect access framework, or whether SAP will require a Professional user assignment for the technical account. See our deeper analysis in the indirect access topic page.
4. Multi-system landscapes with inconsistent assignment
Where the same human has accounts in ECC, S/4HANA, BW, and Solution Manager, the LAW process consolidates the highest-tier classification observed across all of them. A user who is correctly Professional in production but mislabelled as Limited Professional in a sandbox can be repriced across the whole landscape if the consolidation rules are not configured to filter the sandbox out.
The defensible classification workflow
A defensible position is built from three artifacts, all of which need to exist before the next measurement window opens. Procurement teams who attempt to construct them inside an active audit are negotiating from a much weaker position than those who maintain them as part of standard licence hygiene.
The first artifact is a written classification policy that maps each business role, each composite role, and each common authorisation pattern to a contractual user type. The policy needs to reference the specific contract definitions in use, not the generic price-list descriptions, because the contract language is what governs in a dispute.
The second artifact is an authorisation-content extract for every active user, run from the SUIM transaction or an equivalent role-mining tool, that lists the transactions and authorisation objects each user can execute. This is the evidence that the classification matches reality. SAP's auditor will produce their own version of this extract; the defence is to produce yours first.
The third artifact is a transaction-usage extract showing what users have actually done over the measurement period. A user with the authorisation to run a Professional transaction but no usage history is a much easier classification defence than one whose actions have triggered the role-content boundary.
What to do before the next USMM run
The annual USMM measurement is the moment of truth for named user classification. Three concrete preparation steps should be in place every year:
- Run the SUSR_USERS_WITH_PROFILES or equivalent extract sixty days before submission, and reconcile every user whose authorisation footprint has changed.
- Decommission dormant accounts — any user who has not logged on in the last six months should be locked, reviewed, and either reclassified or deleted before USMM runs. Dormant Professional users are pure waste, and they distort the classification picture for auditors.
- Lock contractor and project-team accounts at the end of the engagement. We routinely find six- and seven-figure exposures from project-team users left active two years after go-live.
For a deeper view of the measurement process itself, see our SAP Audit Defence Playbook, which includes a full chapter on USMM preparation and a sample classification policy. For a real-world example of how a misclassification finding was reduced from $14M to $2.3M, see our global retailer reclassification case file.
The negotiation lever most teams miss
Even where SAP has a defensible reclassification finding, the price applied is negotiable. The auditor's opening position uses current list price multiplied by maintenance back-charges across the prior contract years. None of those numbers are fixed. We typically negotiate the unit price down to the customer's existing weighted-average discount tier, the back-charge window down to the current contract year only, and the maintenance multiplier down to the prospective basis. The cumulative effect on a six-figure finding is usually a forty to seventy per cent reduction without disputing the underlying classification.
This is the moment where independent advisory becomes valuable, because the customer's internal team is rarely positioned to challenge the auditor's pricing convention without the historical context of how similar findings have been settled.
Three questions to ask before the next contract renewal
Customers renewing or restructuring an SAP contract have a narrow window to address named user classification ahead of the next audit cycle. Three questions should be answered in writing before any renewal paperwork is signed.
First: what is the contractual definition of each named user type in the renewing contract, and how does it differ from the definitions in the expiring contract? SAP frequently restates definitions in renewal paperwork in ways that subtly broaden the Professional perimeter or narrow the Limited Professional perimeter. Customers who sign without comparing definitions can find their existing classification population pushed up a tier without any change in actual usage.
Second: does the renewal grandfather the existing user-type mix, or does it apply the new definitions retroactively to the existing user population? The answer drives the immediate post-signature compliance position. The negotiated position should always include a grandfathering provision that protects the existing population for at least the first two years of the new contract.
Third: what is the audit-rights clause for named user classification, and does it permit SAP to challenge classifications on a continuous basis, on an annual basis, or only at a defined audit cycle? The continuous-challenge position is the most expensive and the most negotiable.