How OpenText measures Documentum in a self assessment script

When OpenText asks you to run a self assessment script against your Documentum estate, the output is not a neutral inventory. It is the raw material of a compliance finding, and what it captures, how it interprets what it captures, and what it quietly leaves uncorrected all shape the number that follows.

A self assessment script is the most common way an OpenText Documentum measurement begins. Rather than send a team on site, the vendor provides a data collection tool or a set of queries and asks the licensee to run them and return the results. It looks cooperative and low effort, and for that reason it is easy to treat the request as a formality. It is not. The script defines what the audit will see, and because the OpenText EULA places compliance squarely on the licensee, whatever the output shows becomes the buyer's problem to explain. Understanding how the measurement works is the first step in keeping it from setting the finding unchallenged.

What a Documentum self assessment script collects

A Documentum self assessment typically queries the repository and the surrounding deployment for the facts that map to license metrics. In practice that means it counts the user accounts defined in each repository, identifies the repositories and Content Server instances in scope, captures the products and modules installed, and records deployment details such as the servers the software runs on. The output is a structured set of counts that the vendor then maps against your entitlements.

The difficulty is that a script counts what exists in the system, not what the business actually uses. It reads the user table, not the pattern of genuine activity. It reads the installed software, not whether a module is in production. It reads the repository definitions, not whether a repository is live or retired. The gap between what the data shows and what the estate truly is, is exactly where the finding inflates, and the script does nothing to close that gap on the buyer's behalf.

Where the script output inflates the finding

Every defined account is counted as a consumer

The script reads the user accounts in each repository and returns the total. It does not distinguish a daily user from a service account, a dormant login, or a test identity. All of them land in the count. This is the single largest source of Documentum overcharge, and we examine it in detail in how Documentum named user counts inflate an audit finding and in service and dormant accounts counted as Documentum consumers.

Installed software is read as licensed and in use

A module that was installed during an evaluation, or enabled by default, or left in place after a project ended, appears in the script output as present. The audit can treat presence as use. Separating genuinely deployed modules from incidental installs is a buyer side task that the script will not perform.

Repositories and servers are counted as they are found

The script enumerates repositories and Content Server instances without regard to whether each is production, non production, or retired. How those deployments should be counted is a question in its own right, addressed in Documentum server deployment counting in an OpenText audit, and the raw enumeration almost always overstates the chargeable estate.

Why running the script unprepared is the mistake

The script is convenient for the vendor precisely because it shifts the work, and the risk, to the buyer. When a licensee runs the collection and returns the output without first understanding what it contains, the audit receives a clean data set that it can take at face value. From that point the conversation is about explaining individual lines, after the headline number has already formed. The opening finding anchors the negotiation, and an anchor set by an unreviewed script is an anchor set by the vendor.

The far stronger position is to treat the script as input to a buyer side measurement rather than a substitute for one. The output should be reviewed, reconciled against entitlements, and corrected for the context the tool cannot capture, before it becomes the agreed basis of the finding. OpenText gives seven days notice before an audit and the right to copy relevant records, which is a narrow window, but it is enough to take control of how the measurement is run and how its results are presented.

Defending a script based measurement under the four Rs

Respond. In the seven day window we take over the channel and the data collection. Where a script is requested, we control how and when it runs, and we ensure its output goes through a buyer side review before it reaches the vendor as an agreed count.

Reconstruct. We rebuild the effective license position independently. We take the raw counts the script produces and reconcile them against entitlements, separating active users from service and dormant accounts, production repositories from non production and retired ones, and deployed modules from incidental installs. The reconstructed position, not the raw script output, is what we put forward.

Rebut. We challenge the finding line by line. Where the vendor relies on the script output to assert a count, we answer with the corrected figure and the evidence behind it. A count that rests on an unreviewed measurement is a weak claim, and we treat it as one.

Resolve. We settle on the corrected position and, where it serves you, convert forward into an OpenPass agreement that defines how future measurement will be conducted, so the next script does not start from the same inflated baseline.

An anonymised outcome

The financial stakes follow the standard remedy. 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 of the audit, so every line the script overstates 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, much of it achieved by taking the raw measurement apart and rebuilding the count on what the estate genuinely ran rather than what the collection captured. The script had produced a large number; the corrected position produced a defensible one.

Treat the measurement as the start, not the verdict

The lasting point is that a self assessment script is a beginning, not a conclusion. It generates a data set, and that data set has to be interpreted with the operational context only the buyer holds. A repository that is retired, an account that belongs to a batch process, a module that no one has opened in years, these are invisible to the script and decisive to the finding. The buyer who understands this runs the measurement on their own terms, reviews the output before anyone else sees it as final, and arrives at the negotiation with a position rather than a problem.

If OpenText has asked you to run a Documentum self assessment, the worst outcome is to return the results unexamined and let the script set the number. The better path is to put the output through a buyer side reconstruction first, so that what reaches the vendor reflects the genuine estate. To work through a measurement request before it hardens into a finding, read more on our ECM and Documentum audit defense track, and open a case if a script request has already arrived.

Where to go next

For the full method behind a Documentum finding, read our complete OpenText audit defense playbook for 2026. To prepare the records that let you correct the script output, read how to reconcile Documentum entitlements before an audit and what records does OpenText copy in a Documentum audit.