How to challenge a Documentum repository headcount

An audit usually opens a Documentum finding with a single big number: the count of user accounts in the repository. That headcount is the easiest figure to extract and the least likely to be correct. Knowing how to challenge it, account by account, is the heart of a Documentum defense.

A Documentum repository keeps a record of every account that has ever been provisioned against it, and a self assessment script can read that table in seconds. The number it returns is the repository headcount, and it tends to land in the audit finding as if it were the licensable user count. It is not. The headcount includes accounts that consume no license, accounts that belong to systems rather than people, accounts left behind by staff who departed years ago, and accounts that exist only to support integrations. Challenging the headcount means working through it line by line and removing everything that does not meet the licensed definition of a user. Because the OpenText EULA makes compliance the licensee's responsibility, that line by line work is the buyer's to perform, and it is where the largest reductions on a Documentum finding are found.

Why the raw headcount is not the licensable count

The gap between a repository headcount and a defensible user count exists because the repository was never designed as a license meter. It was designed to manage content and the people and processes that touch it, and it retains accounts long after they stop being relevant to licensing. A licensable user is, in general terms, a real person who accesses Documentum in a way the entitlement charges for. The headcount, by contrast, is every row in the account table. Between those two figures sit several categories of account that should never have reached the finding, and identifying them is the first move in any challenge.

The principle to hold to is that the burden of definition runs both ways. The audit asserts a number; the buyer is entitled to test every component of that number against the licensed definition of a user. An account that fails the definition is not a license shortfall, it is a line to remove, and the finding falls by the value of every line removed.

The categories to challenge first

Service and system accounts

Repositories run on accounts that belong to no person: batch jobs, scheduled tasks, system integrations, and administrative processes. These are not users in the licensed sense, and counting them inflates the headcount with identities that never sat at a keyboard. The full argument for disqualifying them is set out in service and dormant accounts counted as Documentum consumers and in can OpenText count service accounts as Documentum users.

Dormant and departed user accounts

Accounts belonging to people who left the business, changed roles, or simply stopped using Documentum often remain active in the repository because deprovisioning lags behind human resources. An account with no activity over the contract period is not a user consuming the software, and usage records establish that. This is the same evidence that reduces a finding in reducing a Documentum finding with usage evidence.

Duplicate and migrated identities

Mergers, migrations, and directory changes leave the same person represented by more than one account. Counting each identity separately inflates the headcount with people who are already counted. Reconciling identities against a single directory removes the duplication.

Read only and integration access

Not every account that touches the repository is a chargeable consumer. Accounts that only read, or that exist purely to carry data between systems, may fall outside the licensed user definition. The boundary is examined in Documentum read only users and the consumer definition and in how Documentum API and integration users are counted.

Working the challenge under the four Rs

Respond. OpenText gives seven days notice before an audit and the right to copy relevant records. In that window we take over the channel and ensure the repository extract is preserved as a working list to be challenged, not accepted as a finished count.

Reconstruct. We build the effective license position independently. We take the headcount apart against the account table, the directory, and the usage logs, classify every account, and assemble the population that genuinely meets the licensed user definition. The reconstructed count is built from evidence, not from the raw extract.

Rebut. We challenge the finding line by line. Each category, service accounts, dormant leavers, duplicates, read only and integration access, is removed with the evidence that supports it. The finding is reduced by the documented value of every disqualified line, and the remaining count is the one we are prepared to defend.

Resolve. We settle on the corrected count and, where it serves you, convert forward into an OpenPass agreement that records how users are defined and counted, so the next audit cannot rebuild the finding from the raw headcount.

An anonymised outcome

The reason a headcount challenge is so valuable is the standard remedy behind every Documentum finding. On noncompliance the licensee is deemed to have acquired licenses at then current list price, owes back maintenance and support, owes first year maintenance on the new licenses, and reimburses the cost OpenText incurs performing the audit, so every account wrongly left in the headcount multiplies through four charges. In our anonymised insurance engagement, case file E-01, a Documentum centred ECM finding fell from $7.2M to $1.6M, a 78 percent reduction, driven almost entirely by disqualifying service and dormant accounts from the repository headcount. The reduction was not a negotiation concession, it was the difference between the raw extract and the defensible count.

Treat the headcount as a draft, never a verdict

The lasting lesson is that a Documentum repository headcount is the opening position in a negotiation, not a measurement of what the business owes. The number is real in the sense that the accounts exist, but it is wrong as a license count because it includes everything the repository ever recorded. The buyer who treats it as a draft to be worked through, rather than a verdict to be paid, recovers the gap between the extract and the licensed definition, and that gap is usually the largest single component of the finding.

For a buyer, the practical step is to obtain the same repository extract the audit will use, classify every account against the licensed user definition, and assemble the supporting evidence before any number is conceded. To prepare that work, read how to reconcile Documentum entitlements before an audit, and to see how the challenge fits the wider defense, read our ECM and Documentum audit defense track. If a finding has been built on a raw repository headcount, open a case.

Where to go next

For the full method behind a Documentum finding, read our complete OpenText audit defense playbook for 2026. To see how the count is defended line by line once the categories are identified, read defending a Documentum seat overclaim line by line.