A global insurance group rebuilt its SAP developer-user population against the contract definition, recovered $3.4M, and rewrote the role-mapping at source so the over-classification could not return.
Every result on this site is anonymised at the client’s request. Specific figures are real and verifiable through a confidentiality-protected reference call arranged on request.
The client is a global insurance group with seventeen thousand SAP users across the UK, continental Europe, and the Asia-Pacific region. The SAP estate had been in place for over a decade, supporting policy administration, claims, finance, and a SuccessFactors HXM footprint. The Developer licence pool stood at three hundred and twelve seats, with annual fees just over four million eight hundred thousand dollars after maintenance.
The engagement was triggered by an internal audit finding. The internal Audit and Risk function had observed that the Developer licence count had been growing each year, without a corresponding growth in the actual development team. The Chief Information Officer commissioned an external review of the user pool before the next USMM submission cycle, with explicit instruction to surface the over-classification and remediate it at source — not simply to reclassify users on paper.
At stake was an annual fee exposure of approximately four point eight million dollars on the Developer band specifically, plus the broader risk that an SAP-side measurement would carry the inflated baseline forward into the next renewal cycle.
The three hundred and twelve Developer licences had accumulated over six years through three mechanisms. The first was the original transport-system access requirement, applied broadly when the estate was built. The second was a role-mapping decision taken in 2019 that assigned the Developer band to any user with access to the ABAP Workbench, the Debugger, or the SE38 transaction — a definition the contract had never required. The third was a default applied by the SAM tooling whenever it detected a transport release or a development-class object change in the user’s activity log.
The contract definition of Developer was substantially narrower. It applied to users who created or modified development objects in a productive system, where the modification was made in the context of the user’s own work. Read-only access to the Workbench, transport release authority alone, debug authorities for production troubleshooting, and emergency-firefighter activations were each excluded by the contract clause in force.
Reading the contract definition against the actual transaction history surfaced the gap. Approximately one hundred and ninety users had been classified as Developers despite holding only the read or release authorities. A further forty-two had been classified on the basis of firefighter-style emergency authorities exercised fewer than four times in twelve months. The remaining seventy-eight matched the contract definition and were properly classified.
The work proceeded along four named tactics, run in parallel with the internal Audit and Risk function as the project owner and the SAM team as the operational partner.
Twelve months of transaction-history evidence was extracted from STAD, ST03N, and the change-document audit log. Each of the three hundred and twelve users was classified against the contract definition of a development action: creation or modification of a development object in a productive system, in the context of the user’s own work. The evidence rebuild reduced the validated count to ninety users.
The internal role-mapping was rewritten. The 2019 mapping that had assigned Developer to anyone with Workbench access was replaced with a granular mapping that distinguished read-only Workbench, transport release, debug, and active development authorities. The mapping change was deployed to the production role catalogue in week seven of the engagement, so that the next USMM run would produce a defensible count without manual reclassification.
The forty-two firefighter-style users were moved to a dedicated emergency-access role that produced a Professional classification by default, with elevated authorities triggered only through a logged session that returned the user to the lower band on session close. The reclassification both reduced the Developer count and improved the segregation-of-duties posture for the internal control framework.
A documentation pack was assembled for the next USMM submission, containing the contract clause, the role-mapping change record, the transaction-history evidence covering the twelve-month window, and the reconciliation between the prior baseline and the corrected count. The pack was designed to defend the corrected count if SAP requested clarification on the year-over-year reduction.
The Developer pool closed at ninety validated licences, against an opening count of three hundred and twelve. Annual fee recovery was approximately three point four million dollars on the Developer band, calculated against the contracted list price. The corrected count was carried into the next USMM submission and accepted without challenge, with the documentation pack referenced once during a clarification exchange.
Three durable outcomes were embedded in the remediation. The internal role-mapping was rewritten so the over-classification could not return at the next role-design iteration. The contract definition of Developer was footnoted into the SAM team’s standing classification procedure, so future role design would default to the contract-aligned mapping. And the firefighter remediation produced a segregation-of-duties improvement that fed into the internal control attestation cycle.
The matter closed ten weeks from engagement to signed remediation, ahead of the USMM submission deadline by approximately three weeks.
We were buying Developer licences for users who had never written a line of ABAP. The contract said one thing; the role mapping said another. The fix was at source.
Named-user and engine mix. We reclassify the user population against the contract definition, rewrite the role mapping at source, and embed the corrected classification in the SAM operating procedure.
Read the brief →Self-measurement preparation. We validate the USMM configuration, clean the user classifications against transaction evidence, and prepare the documentation pack that defends the submission.
Read the brief →The topic page on named-user bands, role mapping against the contract, and the seven categories SAP measurement applies.
The analyst paper on user classification against the contract definitions, with the eleven role-mapping mistakes that produce over-classification.
The reference article on the contract definition of a Developer, the role-mapping rewrite, and the firefighter reclassification.
A parallel reclassification matter at a manufacturer, with a similar gap between the contract definition and the operational role mapping.
A broader named-user cleanup matter, with the Professional and Limited Professional bands reclassified against transaction evidence.
The cluster index for thirty long-form articles on dormant cleanup, role rationalisation, developer reclassification, and engine remapping.
If the role mapping uses a different definition, the over-classification will re-emerge after every cleanup. Speak with a specialist about a source-level remediation. The first conversation is at no cost and under privilege.
Contact Us →Every Wednesday. Field reports from active matters, decoded SAP communications, and what to look for in the next audit cycle. Work email only.