Test accounts are invisible to most licence-position reviews because the SAP estate treats them, by convention, as if they were free. They are not free. Every test account with a role-collection that maps to a Professional licence type is counted by the USMM run as a Professional user, and is therefore an entry in the audit position. The pattern repeats with training accounts, integration accounts, break-glass accounts, and the assorted ‘temporary’ accounts created during project work and never cleaned up. The cumulative consumption is rarely below four per cent of the named-user population and frequently exceeds nine per cent. The release of that volume is one of the highest-leverage actions in the optimisation toolkit because the political resistance is low — nobody owns a stale test account — and the licence release is fast. This article sets out the rationalisation method, the four categories of account that consistently leak, and the controls that keep the population from re-growing. The work is a regular module in our license-optimization engagements.
Why test accounts consume licences
The USMM transaction counts users by their entry in the user-master table (USR02) and their role-collection assignments. It does not, by default, distinguish ‘real’ users from technical-test accounts unless the accounts have been explicitly flagged with a non-licence-bearing user type. The default is to assign Professional. The default sticks. The result is that the test account created to verify a release is counted as a Professional user from the moment of creation until the moment of deletion or reclassification. In long-running estates this can be a five-year window in which a non-human entity consumes a Professional licence.
The four categories
The leak categorises into four distinct kinds. Each has a different controlling pattern and a different rationalisation move. The four are: test users, training users, integration accounts, and break-glass accounts. The total leak is the sum of the four; the rationalisation work is the structured handling of each.
Test users
The largest and most consistent category. Test users are created by developers, QA staff, or release engineers to verify configuration changes, role-collection edits, or transport activity. They typically receive broad Professional role-collections so that they can ‘test everything’. The use is short — days or weeks — but the lifetime extends until manual deletion, which rarely happens.
Training users
Training environments are usually carved out as separate clients (or systems) but in many estates they share the production user-master. The training cohort is created once and used episodically, with the accounts left active between courses. The role-collections are often the same as the production reference role, so the licence consumption matches a real Professional user.
Integration accounts
Background-job accounts, RFC users, technical service users, and middleware connection accounts. The licence-correct designation for these is System or Communication user type, which is non-licence-bearing for named-user purposes. The estate-wide problem is that many integration accounts were created as Dialog users (the SAP default) and never converted. The conversion is technically trivial but operationally interruptive, so it does not happen.
Break-glass accounts
Emergency-elevated accounts kept for incident response. They are intentionally over-permissioned and intentionally rarely used. The combination is the worst possible licence profile: maximum entitlement, minimal evidence of use. The auditor reads them as Professional consumers and they cannot be argued down on transaction-history grounds because there is no transaction history.
The rationalisation sequence
The rationalisation runs in five steps. Identify, classify, validate, reassign, decommission. Each step has a defined deliverable and the sequence runs over approximately four weeks for a mid-sized estate.
Identify
The identification step pulls the user-master records for every account flagged by naming convention, by creation pattern, or by role-collection signature as a test, training, integration, or break-glass account. Most estates have naming conventions (test_*, trn_*, sys_*, brk_*) but the conventions have not been enforced uniformly across the lifetime of the system, so the pull must also use creation date and role-collection signature as supplementary filters. The deliverable is a comprehensive list, deliberately broad rather than narrow at this stage.
Classify and validate
The classification step assigns each account to one of the four categories. The validation step confirms that the assignment is correct by checking the account’s transaction-history footprint. A ‘test’ account with a year of consistent business-transaction usage is in fact a misnamed production account and must be re-routed to the standard reclassification flow. An ‘integration’ account with no transaction history at all is a candidate for deletion. The work is detailed but mechanical.
The most common surprise in the validation step is the cluster of accounts that turn out to be neither test nor production — they were created for a project, used heavily for six months, and then abandoned without deletion. They are the easiest licence release in the entire estate.
Reassign and decommission
The reassignment step converts integration accounts to the System or Communication user type, where the contract permits. The decommission step disables (and after a retention period, deletes) the accounts that are no longer in use. The disable-then-delete pattern allows for the recovery of accounts that turn out, after disabling, to have been needed for an obscure interface or recurring job. The retention period should be at least three months; in well-controlled estates it extends to twelve months.
The contractual question
The reassignment of Dialog users to System or Communication user types is a licence-relevant action, and the contract should be checked before the reassignment runs at scale. Most modern SAP contracts explicitly permit the System and Communication user types as non-licence-bearing for human-licence purposes; older contracts may have ambiguity that is best resolved with a written confirmation before the reassignment. The ECC topic page and the named-user licences pillar cover the contractual nuance.
The controls that prevent re-growth
Rationalisation without controls is a one-time clean-up. The leaked volume re-accumulates over the next twelve to eighteen months and the work must repeat. The control set has four components: a creation policy that requires the correct user type at the moment of creation, a quarterly inactive-account sweep that disables any account with no logon in 180 days, a project-account expiry that automatically disables accounts created for a project after the project end date, and a break-glass review that confirms continuing need for each emergency-access account annually.
The control set is light but only if it is automated. Quarterly sweeps executed manually drift into being missed. The dormant-user cleanup article covers the automation pattern in detail, and the technical-user cleanup article covers the integration-account angle.
What the release looks like
In a recent engagement at a mid-sized industrial buyer, the rationalisation released 642 Professional licences from a baseline population of 8,900 named users, a release rate of 7.2%. The contract conversion value at the buyer’s discount rate was 3.1 million dollars across the rest of the term. The work consumed approximately five weeks of dedicated effort, supported by an existing role-collection inventory. The economics of the work, taken in isolation, are difficult to beat.
The pattern repeats with consistency. Across our 500+ engagements the average release from test-account rationalisation alone has been 6.8% of the Professional population. The case file at global manufacturer cuts SAP claim 68% includes the rationalisation work as a major component of the overall reduction. The license-optimization framework sets out the full method.
Where the audit risk sits
Test-account rationalisation has a small but specific audit-defence dimension. The work generates an audit trail of disabled and reassigned accounts that itself is an audit artefact. SAP audit teams occasionally test whether the disabling has been performed correctly and whether the System and Communication user-type reassignment is supported by the documented integration-purpose justification. The artefacts produced by the rationalisation are exactly the artefacts that respond to that test. Estates that rationalise without documentation create an audit risk by accident; estates that rationalise with documentation reduce audit risk by design.
— 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
If your estate has not run a structured test-account rationalisation in the past twenty-four months, the population is almost certainly carrying four to nine per cent excess. Begin with the integration-account category — the reassignment is fastest, the licence release is largest, and the audit posture improves immediately. The license-optimization service brief covers the full sequence and the typical timeline by estate size.