SAP licence harvesting and reclamation

Licence harvesting is the unglamorous discipline that quietly funds the rest of an SAP commercial programme. It is the routine reclamation of named-user seats that have been allocated to people who no longer use them, who have changed roles, who have left the organisation, or who were over-classified in the original assignment. Across the 500+ engagements we have measured, the harvestable pool is typically 15-22 per cent of the Professional and Limited Professional licence count, with another 5-12 per cent recoverable from Employee and ESS buckets. On a midsize estate with 12,000 named users at a blended licence cost of $2,400, that is between $4.3M and $6.4M of recoverable capacity sitting idle in the system. SAP’s audit team finds the same idle seats when the audit runs. The question is who gets there first.

What “harvesting” actually means

In SAP licence parlance, harvesting is the controlled return of an active named-user record to an inactive or downgraded state, with the licence type reassignment documented and the recovered seat returned to the available pool. It is not deletion of the user master. It is the licence-type re-classification of the user master — from Professional to Employee, from Limited Professional to ESS, from any active class to system-locked — that frees the underlying entitlement without compromising the user’s ability to be reactivated later.

The discipline matters because SAP’s audit measurement reads the active state of the user master at the moment USMM runs. A user who has not logged in for three years but is still classified as Professional is counted as a Professional user in the audit. Harvesting moves that user out of the count before the count happens.

The three sources of harvestable capacity

Harvestable capacity comes from three distinct sources, each with its own evidence pattern, its own re-classification rule, and its own approval path inside the buyer organisation. They are addressed in order, because the easier sources fund the political capital needed for the harder ones.

Source one: dormant users

A dormant user is one who has not logged in to an SAP system within a defined inactivity window. The standard window for SAP’s audit-defence community is 180 days, though we have seen engagements use 90 days for high-value Professional licences and 365 days for lower-cost classes. Dormancy is read from the last logon timestamp in USR02 across all SAP systems in the LAW consolidation. Users dormant beyond the window are candidates for system lock or downgrade.

The dormancy harvest is the easiest yield in the programme. It typically recovers 6-10 per cent of the active user count without any role re-mapping, and it can be run quarterly with a standing approval from the SAM steering group. The SAP usage analytics article describes the extract methodology in detail.

Source two: over-classified users

An over-classified user is one whose assigned licence type is richer than the role actually uses. A user with a Professional licence who only ever runs read-only transactions in a single module is the classic example. Over-classification is harder to evidence than dormancy because it requires a transaction-code analysis mapped against the SAP price list’s definition of each licence class. The mapping is described in our role mapping article.

The over-classification harvest yields 4-8 per cent of the user base in most estates, but the work is heavier. Each downgrade requires a transaction-code basis, a role-owner sign-off, and a re-assignment in SU01 or via the central user administration. The work is worth doing because the recovered Professional licences carry the highest unit cost in the estate.

Source three: organisational change residue

Organisational change residue is the accumulation of user records whose owners have changed roles, transferred to subsidiaries, or left the organisation, but whose SAP records have not been updated to reflect the change. Mergers, divestitures, and large transformation programmes leave the heaviest residue. A user who moved from one subsidiary to another two years ago may still be active in the original system landscape and counted in the audit. The residue harvest typically yields 3-5 per cent but requires HR-data cross-referencing that takes time.

The harvesting cadence

Harvesting is a cadence, not a project. The cadence we recommend has four elements. A monthly dormancy sweep that runs without manual approval against users beyond the 365-day inactivity window. A quarterly over-classification review that processes the top 200 candidates by potential value. An annual organisational-change reconciliation that runs before the audit measurement window. And a measurement-window freeze that suspends new licence assignments in the 60 days before USMM.

The cadence works because it surfaces capacity continuously rather than in a panicked pre-audit campaign. SAP’s audit team can read the SAP file note pattern that distinguishes a continuous-harvesting estate from a pre-audit-cleanup estate, and the continuous-harvesting estate is treated very differently. The SAP Named User Classification Guide white paper sets out the reading and the implications.

Evidence: what the harvest file note looks like

Every harvest action generates an evidence record. The record contains the user identifier, the previous licence class, the new licence class, the basis for the change (dormancy window, transaction-code analysis, organisational-change record), the approver, the date, and the system in which the change was made. The record is filed in the SAM evidence pack and survives the audit.

The evidence matters because SAP’s audit team will challenge any large-scale reclassification that happens close to the measurement window without a documented basis. A continuous-harvesting record with a clear evidence trail is treated as routine optimisation. An undocumented bulk reclassification in the week before USMM is treated as licence avoidance and challenged in the position paper. The pattern is the same one described in the insurer named-user reclassification case file.

What not to do during a harvest

Three errors recur in harvesting programmes and undo most of the yield. The first is wholesale deletion of dormant users. Deletion removes the evidence record alongside the user, and SAP’s audit team will read the gap. System-lock or downgrade, with the record intact, is the right action.

The second is harvesting without a transaction-code basis for downgrades. An over-classification downgrade without a documented basis is challenged in the audit, and the licence is reassigned to its previous class with the variance counted as compliance risk. The third is running the harvest inside the measurement window itself. SAP’s audit clause prohibits in-window reclassifications that materially change the measurement; the right discipline is to freeze reclassifications in the 60 days before USMM.

What harvesting unlocks at the contract table

A documented harvesting cadence does more than reduce the in-flight licence count. It changes the commercial position at the next renewal. The buyer that walks into a renewal with a documented 18 per cent reclaim track record over the previous twelve months has a measurable case for reducing the renewal seat count without giving up flexibility. The buyer that has never run a harvest is at the price list’s default reading of the estate, with no leverage. The SAP RISE topic page describes how the harvested capacity translates into RISE-conversion negotiations specifically.

Harvested capacity also reduces the surface area of any indirect-access exposure, because the count of Professional users that feed downstream integrations falls with the harvest. The exposure pattern is described in the indirect access pillar. The two disciplines — harvesting and indirect-access mapping — are typically run in parallel as part of the same compliance programme.

The self-service trap

Many estates have a self-service portal where managers can request new SAP user accounts for their teams. The portals usually default to Professional licence assignment because Professional is the safest classification from a permissions standpoint. The default is the single largest source of over-classification we see across our engagements. Every self-service request that defaults to Professional adds a downgrade candidate to the next harvest. The right intervention is to change the portal default to Employee or Limited Professional with a documented escalation path for Professional assignment.

If you have not run a structured harvest in the past twelve months, the priority is to size the dormant pool and the over-classification pool from a single USMM extract. The first conversation is at no cost. The SAP licence optimization service describes how we structure the engagement.