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:
- Departed staff whose accounts were never deprovisioned but still hold access.
- Service, system and test accounts counted as if they were human users.
- Duplicates, where one person holds two accounts across systems and is counted twice.
- Dormant access, where a user was granted a role years ago and has never used it.
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.
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.
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 →The IBM Audit Brief
Audit triggers, ILMT pitfalls, and settlement tactics for IBM software buyers.
Independent, buyer side IBM software audit defense and negotiation. Not affiliated with IBM Corporation.