How Documentum named user counts inflate an audit finding

A Documentum compliance finding almost always begins with one number: the count of named users the vendor believes are entitled to access the repository. That number is rarely the number that should appear on an invoice, and the gap between the two is where most of a finding lives.

When OpenText audits Documentum, the headline charge is built by multiplying a user count by a list price and then stacking back maintenance and audit costs on top. The user count is the multiplier that drives everything else, so a count that is inflated by even a few hundred accounts can move a finding by millions. Understanding exactly how that count is assembled is the first step toward taking it apart.

What OpenText measures when it counts Documentum named users

The Documentum named user metric ties a license to a specific, identifiable person who is authorized to access the content repository. In principle that is a clean definition. In practice the count that arrives in a finding is drawn from the directory and the repository, not from a curated list of authorized humans. OpenText typically pulls every account object in the repository, every entry in the connected directory group that grants access, and every login record it can reach, then treats the union of those sources as the population of named users.

This is where the inflation starts. A directory group provisioned for convenience may grant repository access to a whole department that never opens Documentum. A migration may have left thousands of legacy account rows in place. Test identities, generic accounts, and integration logins all sit in the same tables as real people. The vendor counts what it finds and prices it at full list, and the burden of proving that an account is not a billable user shifts to you.

The four ways a named user count overstates reality

Stale and duplicate accounts

Documentum estates that have run for a decade accumulate account objects that no longer map to active people. Leavers, role changes, and repeated migrations leave duplicate identities for the same individual across repositories. Each duplicate is counted as a separate named user unless you can demonstrate the overlap with directory evidence.

Non human and service accounts

Service accounts, batch jobs, and integration identities authenticate against the repository exactly as a person would, so they appear in the same logs. They are not human users and should not carry a named user license, but they are routinely swept into the count. We treat these separately in our analysis of service and dormant accounts counted as Documentum consumers.

Read only and incidental access

Many accounts can technically reach the repository but only consume content in a limited way. Whether such access maps to a full named user or a lighter consumer right depends on the entitlement language, not on the vendor default. The boundary is the subject of our note on read only users and the consumer definition.

Dormant entitlement

An account that exists but has not authenticated in months is an entitlement on paper, not a measured use. Login telemetry frequently shows that a large share of the counted population never touched Documentum during the audit period. Dormancy is one of the most persuasive grounds for removing a line from the count.

How we reduce the count under the four Rs

Our method applies four operations to a Documentum named user finding, and each one attacks the multiplier directly.

Respond. OpenText gives seven days notice before an audit and the right to copy relevant records. In that window we take over first contact, agree a single controlled channel, and make sure no raw account export leaves the building before it has been reviewed. The seven day notice clock starts immediately, and an unmanaged export in week one becomes the vendor baseline for the rest of the engagement.

Reconstruct. Before any vendor measurement script runs, we build the effective license position independently. We reconcile account objects against the directory, collapse duplicates, separate non human identities, and overlay authentication telemetry so the count reflects distinct authorized humans who actually used the system. This reconstruction, described further in how to document Documentum named users for a rebuttal, becomes the evidence base for everything that follows.

Rebut. We challenge the finding line by line: every duplicate, every service account, every dormant identity, every account whose access type does not match the metric definition. Each removal is supported by directory and log evidence, not by assertion, so the vendor has to accept it or argue against its own data.

Resolve. Once the defensible count is established, we settle on the buyer terms and, where it serves you, convert the position forward into a clean OpenPass agreement with audit protections and a defined user metric written in.

What this looks like in practice

In our anonymised insurance engagement, case file E-01, an OpenText Documentum finding opened at $7.2M, driven largely by a named user count built from raw repository and directory data. After we disqualified service and dormant accounts and reconciled duplicates against the directory, the count fell sharply and the matter settled at $1.6M, a reduction of 78 percent. The product had not changed and usage had not changed. Only the count was corrected to reflect reality.

That pattern recurs because the opening number is built for negotiation, not for accuracy. A finding priced at full list assumes you will accept the raw count. The moment the count is rebuilt from evidence, the stacked remedy of list price, back maintenance, and audit cost recovery falls with it.

What OpenText can and cannot demand from the count

Buyers often assume the audit count is authoritative because it comes from their own systems. It is not. OpenText is entitled to seven days notice and to copy records relevant to the audit, but that right to copy data is not a right to define what the data means. The interpretation of an account export, the classification of each identity, and the decision about which accounts meet the named user definition are all open to challenge. The vendor presents a reading of the data. You are entitled to present a better one.

This matters because the count hardens early. Whatever figure is exchanged in the first weeks tends to become the anchor for the rest of the negotiation. If a raw extract leaves your organization before it has been reviewed, that extract becomes the vendor baseline, and every later correction has to fight upstream against a number that is already on the table. The single most valuable thing you can do in the notice window is make sure no count is conceded before it has been reconstructed from evidence.

It also matters because the burden of proof is practical rather than legal. The vendor will not remove an account because you assert it is dormant or non human. It will remove an account when you show the directory record, the integration owner, or the authentication log that proves the point. A named user defense is therefore an exercise in evidence, not argument, and the organization that arrives with reconciled data is in a far stronger position than the one that arrives with objections alone.

Where to go next

If you want the full picture of how a Documentum finding is assembled and dismantled, start with our complete OpenText audit defense playbook for 2026 and then read our ECM and Documentum audit defense track for the product specific traps. If a notice has already landed, you can open a case through the contact form and we will take over the named user analysis before the count hardens.