>
Journal · Licensing Metrics

Concurrent user licensing and its audit risks.

User based metrics feel intuitive, which is exactly why they are misread. An authorized user licence counts every named person with access, a concurrent licence counts only the peak using it at once, and the two are not interchangeable. Most user findings come from counting the wrong population, not from real over use.

Authorized versus concurrent

The first distinction decides everything. An authorized user licence is assigned to a named individual and covers that person whether they log in daily or never. A concurrent user licence covers the maximum number of users accessing the software at the same moment, so a pool of one hundred occasional users might need only twenty concurrent licences. Confuse the two, or let an authorized entitlement be measured as if every provisioned account were active, and the count balloons past entitlement on paper alone.

Where the count inflates

User counts almost always drift upward, and rarely because of genuine new demand:

An auditor reading the access directory at face value counts all of these. A buyer side review strips them out, and the defensible number is often well below the raw provisioned total.

The concurrency evidence question

For concurrent licences the live argument is peak usage. IBM may assume the authorized population equals demand unless you can show actual concurrency from access logs or session data. Demonstrating that peak simultaneous use sits far below the provisioned headcount is the difference between licensing the whole directory and licensing the real peak. That evidence has to come from your own systems, and it has to be assembled before the audit fixes a number, not after.

Building the user position

The defensible position has three parts: the correct metric definition for each product, a cleaned user list with non human and stale accounts removed, and, for concurrent metrics, concurrency evidence from logs. Reconcile that against entitlement and the gap, if any, is real rather than an artefact of an uncleaned directory. More often, the cleanup alone closes most of the apparent finding.

What this means under audit

User findings are usually counting problems. Confirm whether each product is authorized or concurrent, clean the user list of departed, duplicate and non human accounts, and for concurrent metrics bring concurrency evidence from your own logs. The provisioned directory is not the licence count, and the difference is yours to prove before IBM counts every account as a user.

What is the difference between authorized and concurrent user licensing?
An authorized user licence covers each named individual with access, whether or not they use the software. A concurrent licence covers the maximum number using it at the same time. The two count very differently and are not interchangeable.
Why do user counts inflate under audit?
Inactive accounts, service and test accounts, duplicates and departed staff often remain provisioned. If they are counted as authorized users, the total climbs above entitlement even though no real person is using the seat.

User count above your entitlement?

Our PVU Reconciliation engagement covers user based metrics too, cleaning the account list, confirming authorized against concurrent, and assembling concurrency evidence so the count you defend reflects real use. We mobilize within 48 hours of your audit notice.

See PVU Reconciliation →
Related reading

The IBM Audit Brief

Audit triggers, ILMT pitfalls, and settlement tactics for IBM software buyers.

IBM Audit

Independent, buyer side IBM software audit defense and negotiation. Not affiliated with IBM Corporation.

Services
Audit DefenseAudit NegotiationILMT RemediationSub-Capacity Defense
Products
WebSphereDb2CognosCloud Pak
Company
AboutContactJournalWhite Papers
Independent. Not affiliated with IBM Corporation.Buyer Side · Est. 2019