SAP employee offboarding, end to end.

The single most preventable category of SAP licence waste is the persistence of named-user licences assigned to people who no longer work for the organisation. The pattern is universal: employees leave, the HR record is closed, the SAP user is left active for an extended window — sometimes by intention (to permit reactivation), sometimes by oversight, sometimes because the offboarding workflow does not include SAP. The active SAP user is counted against the named-user entitlement, and the entitlement may have been purchased at full list price. Across the matters we have worked, the offboarding-related waste typically runs between four and twelve per cent of the named-user pool, and in some estates substantially higher. The remediation is operational, not contractual: a disciplined offboarding process integrated with the SAP user lifecycle. This article describes the process.

The scope of offboarding

An SAP-aware offboarding process covers all departure types: permanent termination, retirement, internal transfer, contractor end-of-engagement, and long-term leave of absence. Each departure type has a distinct SAP treatment. A permanent termination should produce a deactivation. A retirement should produce a deactivation, often with retention of certain limited entitlements for pension-related access. An internal transfer should produce a re-classification of the user’s licence type, often a downgrade. A contractor end-of-engagement should produce a deactivation, with a defined re-activation path if the contractor returns. A long-term leave of absence should produce a suspension, with deactivation following the leave window. The methodology is in our dormant user purge article.

Step one — the trigger

The offboarding trigger is the HR record change. The HR system records the departure date, the departure type, and (where applicable) the next-employer or next-engagement information. The trigger is fired from the HR system into the SAP user lifecycle on the day the HR record is updated, not on the day the departure becomes effective. The lead time between trigger and effective date provides the window to schedule the SAP deactivation, run the data-protection actions, and capture any access required for the orderly transfer of the user’s in-flight work.

The integration requirement

The trigger requires an integration between the HR system and the SAP user lifecycle. The integration is often through SAP’s identity management (IdM), but it can equally be through an external IAM system (SailPoint, Saviynt, Microsoft Entra) that reads HR events and writes SAP user state. The integration must be reliable: a missed trigger produces a leftover user, and the leftover user is licence waste. The internal compliance program article covers the broader process architecture.

Step two — the handover

Between trigger and deactivation, the departing user’s in-flight work must be transferred. The in-flight work includes the documents in the user’s personal worklist, the approval flows assigned to the user, the workflow inbox, and any custom-developed objects (queries, reports, transformations) the user owns. The handover is operational and is conducted by the user’s manager or designated successor. The handover is documented so that the deactivation, when it occurs, does not orphan any business process.

Step three — the deactivation

The deactivation itself is a sequence of SAP-side actions. The user’s validity end-date in SU01 is set to the departure date. The user’s authorisation profile is cleared. The user’s licence assignment is removed from USMM. The user’s SSO assignment is removed from the identity provider. Each action is performed by the appropriate role — Basis for the SU01 update, the role administrator for the authorisation clearance, the licence administrator for the USMM update, the IAM team for the SSO removal — and each is recorded in the audit log. The licence harvesting article covers the related reclamation workflow.

Step four — the reclamation

The freed licence is reclaimed into the available pool. The reclamation is the operational counterpart to the deactivation: a deactivation that does not produce a reclamation has cleared the access but not recovered the entitlement, and the licence remains assigned in the entitlement table even though no user is consuming it. The reclamation requires a defined process: at a monthly cadence, the deactivated users are reconciled against the licence assignments, the orphaned assignments are cleared, and the freed entitlements are returned to the pool for re-allocation.

Step five — the retention case

In some cases, the user’s access is retained beyond the departure for specific, time-limited purposes: a finance close that includes the departing user’s pre-departure activity, a regulatory review that requires the user’s historical records to remain accessible, a transition window during which the successor needs the user’s context. The retention case is a structured exception: it is documented, time-limited, approved by a defined owner, and reviewed at a defined cadence. The retention should not be the default; it should be the documented exception. The licence optimization service page covers the related discipline.

Step six — the data-protection actions

The offboarding process must address the data-protection obligations. The departing user’s personally-identifiable information is governed by the data-retention policy, which may require deletion after a defined window. The user’s authorisation profile, however, may need to be retained for audit-defence purposes, in which case it is archived rather than deleted. The legal team owns the retention policy; the operational team executes the actions. The methodology is in our SAP SuccessFactors topic page, which covers the HR-data lifecycle for SAP-side records.

Step seven — the verification

At a monthly cadence, the offboarding process is verified: the HR-recorded departures of the prior month are reconciled against the SAP-side deactivations and reclamations. Any discrepancy — an HR departure without an SAP deactivation, an SAP deactivation without a reclamation — is investigated and remediated. The verification step ensures that the process does not drift, and it produces the documentary record that supports the audit defence in the event that the user inventory is challenged. The methodology is in our named user classification guide white paper.

The contractor sub-process

The contractor offboarding requires a slightly different treatment. Contractors typically have shorter engagement cycles, may have multiple engagement windows with the same organisation, and may be governed by procurement-side contracts rather than HR records. The contractor offboarding trigger should be the procurement-side engagement-end record, with the same downstream sequence (handover, deactivation, reclamation, verification) as the employee offboarding. The contractor-specific consideration is the re-activation path: a contractor who returns within a defined window should be re-activated against their prior user record rather than provisioned as a new user, which avoids unnecessary licence consumption.

The economic case

For a representative example, see our insurer named user case study, in which an offboarding remediation released 2,140 named-user licences from a base of 18,400 — an eleven-and-a-half per cent recovery that produced an annual maintenance saving in the high six figures and a future-purchase avoidance of materially more. The remediation was conducted over a four-week sprint, with the integrated HR-to-SAP trigger established as a permanent part of the operational landscape.

Across our $180M+ in client savings, the offboarding remediation has appeared as a contributing element in approximately sixty per cent of the matters that closed with material savings — the highest frequency of any single remediation. The reason is structural: offboarding waste accumulates in every organisation, and the discipline to address it is the single highest-frequency improvement opportunity in SAP licence management. The licence compliance assessment service page describes how the offboarding remediation is integrated into the broader engagement.