Communication users are the licence-economic backbone of the integrated SAP estate. They authenticate the RFC calls, the IDoc transmissions, the inbound queue handlers, the outbound proxy calls, and the BAPI invocations that move data between SAP and the surrounding system landscape. SAP’s contract architecture treats them as non-licence-bearing — up to a point. The point is the contractual definition: a communication user is non-licence-bearing only if its activity meets the description of system-to-system communication, with no direct or indirect human use behind the connection. A communication user that has been re-purposed to support a small set of administrators logging in to inspect interface activity, or to support a workflow that fans out to a human decision-maker behind the connection, no longer meets the definition. The classification is then defensible only on the original purpose, not on the operating reality, and the audit team is entitled to challenge the population. This article sets out the audit method that confirms the population is correctly classified, identifies the four common drift patterns, and supplies the documentation that survives the challenge. The work is part of our license-optimization programme.
What the contract says
The communication-user definition varies by contract vintage but the core elements are stable across the modern SAP licence contracts. A communication user is an account established for system-to-system data exchange, with no individual human assigned to the account, no use as a session-establishing user for human work, and a purpose limited to the integration scenarios documented in the contract. Older contracts may have softer definitions; newer contracts often have tighter ones. The first task in the audit is to identify the controlling definition in the buyer’s specific contract. The ECC topic page covers the typical contract patterns.
The four drift patterns
The communication-user population accumulates licence-bearing exposure through four drift patterns. Each is innocent in isolation and becomes a problem only when it persists undetected over multiple measurement cycles.
Pattern one: shared administrative access
An administrator needs to inspect interface activity. The administrator’s named account does not have the required authorisations because they belong to the communication user. Rather than building a separate administrative role, the practice that emerges is for administrators to log in to the SAP GUI using the communication user’s credentials. The communication user has, in effect, become a shared human-use account. The classification is no longer defensible.
Pattern two: workflow with human downstream
A workflow runs under the communication user’s authority. The workflow includes a decision step that requires human input from a downstream business user. The decision is captured outside SAP (in a workflow tool, a ticketing system, an email response) and the workflow proceeds under the communication user. The communication user has, in effect, become the licence carrier for the downstream human. The audit team will read it that way.
Pattern three: GUI logon flag drift
The communication user was created with the technically restrictive flag (no Dialog GUI logon), but over time, troubleshooting needs caused the flag to be loosened. The user can now log in via GUI. The classification is challengeable as soon as the flag changed. The flag history is recoverable from the change-document logs and is the first thing the audit team asks about.
Pattern four: chained authorisations
The communication user is the inbound authentication for an external system whose own authentication delegates to individual humans behind it. The chain is sometimes recorded in the integration design document, often not. The licence-bearing exposure may be substantial: every human behind the external system is, under the strict reading, a user of the SAP system through the communication-user proxy. Document the chain.
The audit method
The audit runs in three phases. Inventory, evidence, classification. The phases produce, in order, a complete list of the communication-user population, the supporting evidence for each, and a recommended classification or remediation for each.
Inventory
The inventory pulls every account in the user-master with the Communication user type (USR02 USTYP = ‘B’ in the classical configuration; the equivalent in newer configurations may differ). The pull should include accounts that are currently flagged as Communication and accounts that have been flagged at any point in the previous twelve months. The historical flag-change is recovered from the change-document audit. The output is the complete current population plus the historical drift set.
Evidence
For each communication user, the evidence step captures the integration purpose, the technical configuration (logon flag state, role assignments, password policy), and the activity profile (logon history, transaction-history if any, RFC inbound counts). The activity profile is the most discriminating piece of evidence: a communication user with consistent RFC activity and no GUI logon is in the defensible state; a communication user with sporadic GUI logon entries is in the indefensible state.
Classification or remediation
For each communication user, the population is sorted into three buckets. The compliant bucket — the population that meets the definition without remediation. The remediable bucket — the population that meets the definition once specific remediation is applied (closing the GUI logon flag, removing inappropriate role assignments, separating an administrative use into a different account). The non-compliant bucket — the population that does not meet the definition and must be re-classified as licence-bearing.
The compliant population is typically the largest of the three. The remediable population is typically the most economically valuable, because the remediation is fast and the licence release is immediate. The non-compliant population is typically the smallest and the most painful to address.
The documentation standard
The audit produces a communication-user register: per-account purpose, evidence references, classification, and remediation status. The register is one of the principal artefacts the SAP audit team will request during a measurement-driven engagement. Without it, the entire communication-user population is in scope for challenge; with it, only the specific accounts the auditor flags are in scope. The economics favour producing the register before it is requested. See the named-user licences pillar for the broader documentation frame and the named-user classification guide for the register template.
How often to run the audit
The communication-user audit should run annually, in the quarter before the formal USMM submission. The annual rhythm catches drift before it accumulates. Estates that have not run the audit in the previous twenty-four months typically find a population that is 8-15% non-compliant, with a further 20-30% in the remediable bucket. Estates that operate the annual rhythm typically find a population that is below 2% non-compliant and largely compliant in steady state. The measurement cycle calendar places the audit in the operating rhythm.
The cross-system view
In landscapes with multiple SAP systems, the communication-user audit must cover all systems and must reconcile the population across the systems. A single integration purpose is typically supported by a chain of communication users across the source, the middleware, and the target systems. A change to the classification on one system must propagate consistently to the others, or the LAW consolidation will surface an inconsistency that produces an audit conversation in its own right. The LAW consolidation pitfalls article covers the consolidation surface.
How it fits with the technical-user cleanup
The communication-user audit is related to but distinct from the technical-user cleanup. The cleanup converts Dialog users into the technically-appropriate System or Communication type. The audit confirms that the population already in the Communication type still meets the contractual definition. The two should run consecutively: the cleanup first (converts mis-typed users into Communication), the audit second (validates the now-larger Communication population). The case file at insurer named-user reclassification covers a combined sequence.
— 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
Begin with the change-document audit on the user-type field for every account currently flagged as Communication. The flag-change history is the fastest signal of where drift has occurred. The remediation work follows naturally from the change-document findings. The license-optimization service brief covers the full audit sequence and typical engagement timeline.