Cognos user reconciliation: a worked example.

The opening claim, and what it counts.

Imagine IBM's audit team pulls the Cognos namespace and reports four thousand provisioned accounts, then prices every one of them at the Analytics Explorer role, the authoring tier. The opening claim says you are several thousand entitlements short. That number is built from a raw export, not a reconciliation. The first move is to separate the accounts that represent real, active, correctly tiered users from the noise the export carries.

Step one: strip the accounts that should not count.

A raw Cognos export is rarely a clean user list. It carries disabled accounts, departed employees never deprovisioned, duplicate identities where one person has two logins, and service or system accounts that are not human users at all. Each of these inflates IBM's opening count. The reconciliation removes them against directory and HR records, leaving only the distinct, active individuals who genuinely hold access.

• Disabled and departed accounts removed against directory records
• Duplicate identities collapsed to one person, one entitlement
• Service and system accounts separated from human users
• Dormant accounts with no activity in the period flagged for removal

Step two: tier each user at the role they actually hold.

Once the list is clean, each remaining user is mapped to the capability the account truly carries. A user who only opens published reports is a Viewer, licensed far below an authoring Explorer. IBM's opening claim prices the population at the higher tier; the reconciliation proves how many are genuinely consumers. In the locked enterprise case, this Cognos and Maximo user reconciliation cut $2.8M of over-deployment by mapping actual usage to entitlements and removing the excess license claim at renewal.

What this means under audit.

The gap between four thousand authoring entitlements and the smaller count of correctly tiered, active users is the entire dispute. Under Contain, Reconcile, Challenge, Settle, the Reconcile step rebuilds the user list from clean records, and the Challenge step puts the rebuilt count in front of IBM with the directory evidence behind it. A worked reconciliation is what converts an inflated headcount into a defensible position that moves the settlement.