Service and dormant accounts counted as Documentum consumers

Some of the largest line items in a Documentum finding are not people at all. Service accounts that run integrations and dormant accounts that no one has used in a year are routinely counted as billable consumers, and each one carries a full price tag until you prove otherwise.

When OpenText measures Documentum consumption, it counts what authenticates against the repository. A batch job, an integration identity, and a long departed employee all leave records in the same account tables and access logs as an active person. The vendor count does not draw the distinction for you. If you do not separate non human and unused identities yourself, they are priced exactly like working users.

Why service accounts end up in the consumer count

Documentum rarely operates in isolation. It connects to enterprise applications, archives, capture pipelines, and reporting tools, and each integration authenticates through an account. Those service accounts are designed to run unattended and often hold broad rights so the integration does not break. To an audit script that counts authenticated principals, a service account looks identical to a human consumer, and a broadly privileged one can even look like a power user.

The defensible position is that a service account is infrastructure, not a consumer. It does not represent a person consuming content for their own purposes. It represents a system performing a function on behalf of users who are already licensed. Counting both the integration identity and the people it serves charges twice for the same activity. We develop this argument in detail in our note on whether OpenText can count service accounts as Documentum users.

Dormant accounts are entitlement, not use

The second category is the dormant account: an identity that exists in the repository and could authenticate, but has not done so for the audit period. These accounts arise naturally. People leave, projects end, departments reorganize, and deprovisioning lags behind. The account object lingers, and the audit count treats it as a live consumer.

A dormant account is an entitlement on paper. It is not measured consumption. When authentication telemetry shows no activity across the relevant window, the account should not carry a paid license for that period. Dormancy is one of the cleanest removals available because it rests on the vendor own log data rather than on interpretation. We rely on this evidence base when reducing a Documentum finding with usage evidence.

How the two categories inflate the same finding

Service accounts and dormant accounts attack the count from opposite directions but add to the same inflated total. Service accounts add identities that were never people. Dormant accounts add people who were no longer using the system. Together they can account for a substantial fraction of a raw Documentum count, which is why a finding built from the union of all account sources tends to overstate genuine consumption so heavily.

The count is the multiplier in the remedy. OpenText prices a shortfall at then current list, adds back maintenance and support, adds first year maintenance on the newly deemed licenses, and reimburses the costs of running the audit. Every spurious account flows through all of those layers. Remove it once at the count and you remove it from every stacked charge at the same time.

How we separate the population under the four Rs

Respond. In the seven day notice window we secure a single controlled channel and prevent a raw account export from becoming the agreed baseline before it has been classified. The vendor right to copy records is real, but the classification of those records is ours to lead.

Reconstruct. We build the effective license position independently. We tag every account as human or non human, map service accounts to the integrations they serve, and overlay authentication logs to mark dormancy across the audit period. The result is a population of distinct, active, authorized human consumers, which is the only population the metric is meant to charge for. The mechanics of the vendor side of this are covered in how OpenText measures Documentum in a self assessment script.

Rebut. Each service account and each dormant account is removed with evidence: an integration owner, a system of record, or a log that shows no authentication. The vendor must accept the removal or contest its own data.

Resolve. With the count corrected, we settle on buyer terms and, where it helps, convert forward into an OpenPass agreement that defines the consumer metric so the same ambiguity cannot reappear at the next renewal.

A pattern drawn from a real engagement

In our anonymised insurance matter, case file E-01, a Documentum seat finding opened at $7.2M. A meaningful share of the counted population turned out to be service and dormant accounts rather than working users. Once those were disqualified and the remaining identities reconciled, the matter settled at $1.6M, a 78 percent reduction. The system was unchanged. The count was simply corrected to the people who actually used it.

A practical way to separate the population

Separating real consumers from service and dormant accounts is methodical work, and it rewards a disciplined sequence. The first pass is classification by nature: every account is tagged as human or non human. Service identities, batch jobs, connectors, and generic system accounts go in the non human bucket, each mapped to the integration or function it performs and to the system that owns it. This alone removes a category that should never have carried a consumer license.

The second pass is classification by activity. Authentication telemetry across the full audit period is overlaid on the remaining human accounts. Accounts with no logins in the window are marked dormant and pulled out as entitlement on paper rather than measured use. Where deprovisioning has lagged, leaver records and directory status corroborate the dormancy, so the removal rests on more than the absence of a log line.

The third pass is reconciliation. The surviving human, active accounts are matched against the directory to collapse duplicates, so that a single person who holds several account objects is counted once. What remains after these three passes is the population the metric is actually meant to charge for: distinct, active, authorized human consumers. Everything removed along the way is supported by evidence the vendor cannot easily dispute, because most of it comes from the vendor own logs and the organization own directory.

The discipline pays off twice. It produces a defensible count for the current audit, and it leaves the organization with a clean map of its Documentum population that makes the next audit far less painful. An estate that knows exactly which of its accounts are people, which are machines, and which are dormant is an estate that does not get surprised by a raw extract.

Where to go next

For the wider context of how OpenText assembles and stacks a finding, read our complete OpenText audit defense playbook for 2026, and for the product specific traps see our ECM and Documentum audit defense track. If you are already counting accounts under audit pressure, open a case and we will classify the population before it is priced.