How to document Documentum named users for a rebuttal

A Documentum rebuttal is only as strong as the documentation behind it. Asserting that an account is dormant or a service identity changes nothing; proving it, with the right record attached to the right account, is what moves the finding. Knowing how to assemble that evidence is the difference between an argument and a reduction.

Once the categories in a Documentum finding are understood, the work shifts from analysis to evidence. The audit has produced a count, and the rebuttal must show, account by account, why the count is wrong. That is a documentation exercise. Every account proposed for removal needs a record that establishes its status: a usage log showing no activity, a directory entry marking a leaver, a system record identifying a service account, an entitlement showing read only access. A rebuttal without that backing is a claim the audit can decline; a rebuttal with it is a position the audit struggles to refuse. Because the OpenText EULA places compliance on the licensee, the burden of producing this documentation falls to the buyer, but that burden is also the buyer's leverage, because well documented evidence is what compels the finding down.

What a documented named user position contains

A defensible named user position is a structured record that ties each account in the repository extract to a classification and the evidence that supports it. For every account, the documentation establishes who or what it is, whether it meets the licensed definition of a named user, and, where it does not, the specific record that disqualifies it. The licensed unit is the named user as the entitlement defines it, and the documentation either confirms an account as a genuine named user or removes it with proof. The result is not a narrative but an evidence table: account, classification, supporting record, conclusion. That structure is what lets a rebuttal be reviewed line by line and accepted line by line.

The principle to hold to is that documentation converts assertion into evidence. The audit need not accept that an account is dormant simply because the buyer says so, but it has little ground to reject a usage log that shows no activity over the contract period. The quality of the rebuttal is the quality of the records attached to it.

The evidence each category requires

Dormant and departed accounts

These are documented with usage and activity records showing no meaningful access over the contract period, cross referenced against directory or human resources data marking the person as departed or reassigned. Usage evidence is the backbone here, as set out in reducing a Documentum finding with usage evidence.

Service and system accounts

These are documented with the system records, naming conventions, and configuration entries that identify the account as belonging to a process rather than a person. The classification argument is set out in service and dormant accounts counted as Documentum consumers.

Read only and duplicate identities

Read only access is documented with the permission records that show the account cannot perform chargeable actions, the boundary in Documentum read only users and the consumer definition. Duplicates are documented by mapping multiple accounts to a single directory identity, the reconciliation behind how to challenge a Documentum repository headcount.

Building the rebuttal documentation 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, the usage logs, and the directory data are preserved together, because the documentation can only be as complete as the records captured at the start.

Reconstruct. We build the effective license position independently, which is the documentation exercise itself. We classify every account, attach the supporting record to each, and assemble the evidence table that maps the raw extract to the defensible named user count. The reconstructed position is the documented rebuttal in finished form.

Rebut. We present the documentation line by line. Each account proposed for removal arrives with its record attached, so the audit reviews evidence rather than assertion. The finding falls by the documented value of every disqualified account, and the remaining count is the one the records support.

Resolve. We settle on the documented count and, where it serves you, convert forward into an OpenPass agreement that records how named users are defined and evidenced, so the next audit starts from an agreed basis rather than a raw extract.

An anonymised outcome

The reason documentation is decisive is the standard remedy behind the 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 that can be documented out of the count removes that fourfold charge. 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, and the reduction was built on documentation: usage logs and directory records that proved, account by account, which identities did not meet the named user definition. The argument did not win the reduction; the evidence did.

Document first, argue second

The lasting lesson is that a Documentum rebuttal is an evidentiary process, not a rhetorical one. The audit has the easier task, producing a count from a single extract, while the buyer must show why the count overstates, account by account, with proof. That asymmetry is real, but it is also the buyer's advantage, because the records that disqualify accounts, usage logs, directory data, system designations, permission entries, are in the buyer's own systems. A rebuttal that arrives as a documented evidence table, rather than a set of claims, is the one that brings the finding down to the defensible count.

For a buyer, the practical step is to assemble the supporting records, usage, directory, system, and permission data, alongside the repository extract, so each account can be classified with evidence attached. To prepare that material, read how to reconcile Documentum entitlements before an audit, and to see how documentation fits the wider defense, read our ECM and Documentum audit defense track. If you need to turn a Documentum finding into a documented rebuttal, 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 documented count is presented and contested, read defending a Documentum seat overclaim line by line.