The Cognos user role matrix and license counting.
Cognos is licensed by what users can do, not simply how many there are. Roles map to different license tiers, and the role matrix decides the count. When an audit reads the role assignments incorrectly, it counts heavyweight licenses for users who only ever consume content, and that gap is where the negotiation lives.
Why roles, not headcount, drive the count
Cognos separates users by capability. A user who only opens and views reports sits in a lighter tier than a user who authors reports, builds data modules, or administers the environment. The license you owe depends on the highest capability a user is actually assigned, so the count is a function of the role matrix rather than the raw number of accounts. This is what makes Cognos counting contestable: the same population of users can produce very different totals depending on how their roles are read.
How the matrix gets misread
The errors are consistent across audits:
- Capability inferred from group membership. A user placed in an authoring group for convenience, who never authors anything, can be counted at the authoring tier rather than the consumer tier they actually occupy.
- Inactive and disabled accounts counted. Accounts left in the directory after staff turnover inflate the count if they are not filtered against genuine active use.
- Administrative and service accounts counted as users. Non human accounts and a small number of administrators can be swept into a consumer or author tally where they do not belong.
- Role overlap double counted. A user who appears in more than one role can be counted once per role rather than once at their highest capability.
Building the defensible role matrix
The defense is to reconstruct the matrix from what users can actually do and actually use, not from how the directory happens to be structured. That means mapping every account to its genuine highest capability, removing inactive and non human accounts, resolving role overlaps to a single tier per user, and matching the resulting population to entitlements. The aim is a count that reflects real capability, which is almost always lower than the count an audit produces from raw group membership. On an enterprise estate running Cognos and Maximo, mapping actual user counts to entitlements removed the excess license claim and cut $2.8M of over deployment at renewal.
A Cognos finding rests on how the role matrix is read. Confirm each user's genuine highest capability, strip inactive and non human accounts, and resolve role overlaps before accepting the count. Heavyweight licenses counted for users who only consume content are the most common, and most negotiable, Cognos over count.
Was your Cognos count built from roles or from groups?
Our Audit Negotiation engagement rebuilds the Cognos role matrix from genuine capability, challenges the tier assigned to each user, and maps the corrected population to entitlements so the settlement reflects who actually does what.
See Audit Negotiation →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.