Technical users are the connective tissue of an SAP landscape: the RFC accounts that connect satellite systems, the batch users that schedule period-end jobs, the interface users that move IDocs between SAP and the rest of the application portfolio, and the integration users that authenticate the API layer. None of them are human. None of them should consume a paid Named-User Licence. In practice, a striking proportion of them do, because the original account creation predates any defined licence-type policy and no subsequent review re-classified them. The cleanup is one of the cheapest pieces of SAP license optimization work we do, and one of the most consistently productive.
What the licence catalogue says
SAP’s licence-type catalogue includes a category called Test Users (sometimes labelled differently across contract vintages) and, separately, an explicit category for system / RFC users. The catalogue treats these categories as outside the priced Named-User pool. The licence consequence is straightforward: a properly tagged technical account does not count toward the Professional, Limited Professional, or Employee licence quantities the contract specifies. An improperly tagged technical account — one carrying a Professional User type in SU01 — counts, and at the highest tariff in the contract.
The catalogue mechanism is the SAP user type field in SU01. The values relevant to the licence position are Dialog (D), System (B), Communication (C), Service (S), and Reference (L). Only Dialog users are candidates for Named-User classification under USMM. The other four are excluded by design. The problem is that the user type field is set at account creation and rarely revisited, and the licence-type field (a separate field in SU01) is set independently. The two can drift, and they do.
How the drift happens
The drift arises from three patterns. First, accounts created for human users who later moved into purely technical roles (a developer who became a basis administrator and now only runs background jobs). Second, accounts created originally as technical accounts but with Dialog user type because the administrator was uncertain which user type the integration tool required. Third, integration accounts created during projects under time pressure with no review at project close, where the original technical scope expanded over time into something that looks like a service account but still authenticates as a Dialog user.
In every case the symptom is the same: an account with no recent SU3 interactive logon, no terminal IP address attached to its history, and behaviour patterns consistent with a programmatic actor rather than a human. The cleanup question is whether the account’s function justifies a Dialog user type or whether the function would be better served by re-typing the account as System, Communication, or Service.
The three-step identification routine
The identification routine is fast. Step one: pull SU01 with the user type field, the licence-type field, the last logon date, and the role-collection assignment for every account. Step two: filter the population to Dialog users with no SU3 interactive logon in the trailing twelve months. Step three: cross-reference the filtered population against the integration topology — the SM59 RFC destinations, the API gateway authentication log, and the batch scheduling system — to identify accounts whose only activity is programmatic.
The output is a candidate cleanup list. In a typical mid-market estate of 4,000 to 8,000 named users the candidate list contains 80 to 250 accounts. The remediation is a re-type from Dialog to the appropriate technical user type, combined with a documented business justification per account. The licence-position impact is the reduction in priced Named-User count corresponding to the re-typed accounts.
Why the cross-reference matters
The cross-reference is what makes the cleanup audit-defensible. A re-type without documented programmatic activity is challengeable. A re-type supported by the SM59 entry, the batch job log, or the API gateway record is supportable on its merits. The override register that records the cleanup should reference the underlying evidence per account, in the same way the override register for the USMM run preparation records evidence per classification.
The remediation mechanics
Re-typing an SAP user from Dialog to System, Communication, or Service is a single transaction in SU01. The operational risk is mis-typing an account that is actually still used interactively by a human user, which would lock that user out of the system. The mitigation is a two-week observation window: change the licence-type field first (no operational impact) and observe whether any tickets arise around the affected accounts. If none arise, change the user type at the end of the window.
The remediation can be batched. A scripted approach using LSMW or a custom BDC programme can re-type two hundred accounts in a single run. The work is faster than the analysis that precedes it, and the operational impact is essentially nil when the observation window has been respected.
Eighty re-typed accounts in a four-thousand-user estate is a two per cent licence position improvement. Two hundred and forty is six. The cleanup compounds with role-collection mining and dormant user purges, and the cumulative effect frequently lands in the eight-to-fifteen per cent recovery range.
The USMM consequence
The USMM execution following the cleanup produces a submission with fewer Dialog users and correspondingly fewer Professional and Limited Professional classifications. The reduction flows directly to the licence-quantity position and through the LAW consolidation to the contractual baseline. If the cleanup precedes the measurement window, the measurement records the improved position as the natural state of the estate. If the cleanup occurs after the measurement window, the improved position must wait for the next cycle to be recognised, which is a year of unnecessary compliance carry. Sequence the cleanup ahead of the measurement.
The cleanup should also be reflected in the USMM and LAW advisory override register. The register entry records the original classification, the re-typed classification, and the evidence reference. The register becomes the audit-defence document for any subsequent challenge to the re-typed accounts.
Where S/4HANA changes the picture
The Full Use Equivalent (FUE) model in the S/4HANA contracts converts Named-User counts to FUE counts using contract-specific ratios. The cleanup recovery in the user-count dimension translates into FUE recovery at the applicable ratio. The dollar value depends on the conversion ratio in the specific contract, but the direction is the same: fewer Dialog users, fewer FUEs consumed, lower contractual baseline. The SAP S/4HANA topic page covers the FUE mechanics. The cleanup should be conducted before the S/4HANA migration rather than after, because the migration sets the FUE baseline and the baseline is sticky.
What goes wrong
The recurring failure mode is treating the cleanup as a one-time exercise. A single pass recovers the accumulated drift, but new drift begins immediately. The mitigation is a quarterly review that runs the same three-step routine against new and changed accounts since the previous review. The quarterly cadence keeps the technical-user position aligned with the licence catalogue between measurement cycles. The work is light once the routine is established — a half-day per quarter in most estates — and the recovery sustains.
The other failure mode is treating user-type changes as an IT-only matter and not synchronising them with the licence-type field or the override register. The two fields move together for audit-defence purposes, and the register entry is the durable record. The licence optimization handbook sets out the synchronised workflow in full.
The combined effect
Technical user cleanup rarely produces a headline number on its own. Combined with dormant user cleanup, role-collection mining, and named-user reclassification under transaction-history evidence — the four standard moves in the optimization pillar — the cumulative recovery is what produces the headline. See the dormant user cleanup playbook and the named-user reclassification routine for the adjacent moves, and the utility licence recovery case file for the pattern in practice.
— 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.
Where to start
Pull the SU01 extract with user type, licence type, and last logon date. The candidate list is visible within a day. The remediation follows the candidate list. The licence optimization service brief covers the full cleanup sequence and the cadence to sustain it.