Role mapping is the unglamorous middle layer of SAP compliance work. It sits below the headline negotiation and above the daily SAM grind, and it is the layer where the actual licence cost of a landscape is set. When an SAP audit team prices a population at Professional rates they are not doing it from a contractual judgement about each user. They are reading the classification field on the user master record, which was set by the role assignment, which was driven by an SAP-side or HR-driven workflow that nobody on the licensing side ever reviewed. The remediation is role-to-licence mapping — a defensible methodology that ties each role to the lowest contractually appropriate licence type, applied to the entire user master, with an evidence trail the auditor can read.
Why role mapping matters more than user classification
The user master classification field is the output. The role assignment is the input. Editing the output without remediating the input means the classifications drift back to the wrong values on the next provisioning cycle. Within six months a remediation that touched only the user master is undone by the SAP IDM or HCM workflow that re-provisions joiners and movers. The defensible methodology operates one layer up: it ties each role — or each composite role — to a target licence type, and that mapping becomes the rule that drives the user master classification on every provisioning event.
The compounding effect is significant. On a population of eight thousand users with three hundred roles in use, remediating the role mapping fixes the classification of every user assigned to those roles, prospectively, on every joiner from that day forward. Remediating only the user master fixes the snapshot once.
The contractual definitions: read these first
Every contract generation has its own definition of the licence buckets. ECC contracts from the early 2010s tend to have a richer Limited Professional definition than later contracts; S/4HANA contracts shifted significant transaction coverage out of Employee and into Limited Professional; RISE contracts often collapse the bucket structure entirely and re-express it as Full Use Equivalents. Before any role mapping work begins, the licensing team needs the contractual definitions in front of them in the version that applies to the audited period. Working from the current price list, or from a contract from a different generation, produces a mapping that the SAP audit team will reject and a remediation that does not hold.
The definitions to read are the named-user descriptions in the schedule, the use-rights restrictions in the master agreement, and any annex that defines what counts as “direct interaction” or “operational use” for the bucket. The SAP named user licences topic page walks through the bucket structure as it appears in current SAP contracts. The detail by contract generation is in the Named User Buckets guide.
Building the role inventory
The first concrete work is to extract the role inventory from the systems in scope. The extract is two things: the list of roles in use (typically 200 to 1,500 in a mid-market landscape, 1,500 to 5,000 in a large enterprise), and the role-to-user assignment matrix that shows which users hold which roles. The role inventory comes from PFCG and the assignment matrix from AGR_USERS and the related tables. Most landscapes have a long tail of unused or low-use roles. The first cleanup is to retire any role with zero assignments, then any composite role whose constituents are individually retired.
The three-layer mapping methodology
The methodology we apply runs in three layers. Each layer reduces the population assigned to higher buckets and leaves only the genuinely Professional users in the Professional count.
Layer one: transaction-code inventory per role
For each role, extract the transaction codes (and Fiori catalogues, on S/4HANA) that the role authorises. The output is a flat list of tcodes per role. The list is compared to a reference table of tcode-to-licence-bucket mappings derived from the SAP standard documentation and our contractual reading. Roles that authorise only reporting tcodes, employee self-service tcodes, and read-only display tcodes map to Employee or Self-Service. Roles that include operational transactions map to Limited Professional or Professional depending on which transactions are included.
Layer two: actual usage overlay
The tcode authorisation is the theoretical maximum. The actual usage is what the user has executed in the last twelve months, pulled from ST03N or the equivalent usage table. The overlay is the join: a user who is theoretically Professional under their role assignment but who has only executed display and reporting transactions for twelve months is misclassified. The remediation is to reassign to a lower-cost role or to argue the classification down at audit with the usage data as evidence.
Layer three: organisational context
Some roles cannot be classified from tcode and usage data alone. A role labelled FI-PowerUser may include both operational and read-only transactions, used in different ways by different users in different cost centres. The third layer is an organisational overlay — cost centre, business unit, employee type — that adds the context to make the final classification call. The output is a role inventory in which every role has a target licence bucket, a confidence level, and a documented basis.
The integration with provisioning
The mapping has no operational value if it does not flow into the provisioning system. The integration runs both directions. New roles, when created in PFCG, are tagged with their licence classification before they leave the development system. Existing role-to-user provisioning events read the classification and write the appropriate user master licence field. Most enterprise environments do this through SAP IDM, GRC Access Control, or a custom workflow in HCM. The licensing logic is added as a small extension. The discipline is the same one we describe in building a usable licence type inventory and in the operational programme described on the licence compliance assessment service page.
What an audit-ready output looks like
The deliverable of a role-mapping engagement is a binder of four artefacts. The role inventory with target licence bucket for each role. The role-to-user matrix with the licence bucket reconciled to each user. The evidence appendix with the tcode lists and usage data that support each classification call. The methodology note that describes the contractual basis. Together, this binder is the document the buyer can produce on day one of an audit. It moves the conversation from “here are 8,000 classifications, defend them individually” to “here is a methodology and an evidence trail; ask about specific exceptions.” The negotiation footing changes completely.
The numbers we see across engagements
The average Professional licence reduction from a first-pass role mapping across our engagements is between twenty-eight and forty-two per cent. The average Employee/Self-Service expansion is sixty to ninety per cent — users who were sitting in higher buckets because the classification was never reviewed are correctly placed in the lighter buckets the contract permits. The financial impact varies with the contract pricing, but for a population of eight thousand users with an average Professional list price of six thousand euros, a thirty-five-per-cent reduction in Professional count releases sixteen to seventeen million euros of licence value. The detail of one such engagement is in the global manufacturer case file.
The auditor reads the classification field. The classification field is driven by the role assignment. If the role mapping is not defensible, the audit position is not defensible. The work happens one layer above where most people look.
If you have a measurement transmission due, or a remediation programme that has stalled at the user master level, the priority is to lift the work back to the role layer. We work alongside in-house SAM and basis teams under engagement letter; the first conversation is at no cost. The licence optimisation service page describes how we structure the work, and the named user buckets explainer is the companion read.
— 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.