Can OpenText count service accounts as Documentum users

It is one of the most common questions a buyer asks during a Documentum audit: can OpenText really count our service accounts as licensed users? The accounts that run integrations and batch jobs show up in the audit population, and each one carries a full price unless you can establish that it is not a consumer.

The short answer is that an audit will count what authenticates against the repository, and service accounts authenticate. The longer and more useful answer is that authentication is not the same as consumption, and the named user metric is about authorized human consumers, not about every credential the system accepts. That gap is where service accounts come out of the finding.

Why service accounts appear in the count

Documentum sits at the center of a web of integrations. Enterprise applications push and pull content, capture pipelines feed documents in, archives draw documents out, and reporting tools read metadata. Every one of those connections authenticates through an account, usually a dedicated service identity with broad rights so the integration does not fail. To an audit script that counts authenticated principals, those service identities look exactly like people, and the broadly privileged ones can look like heavy users. The mechanics of how these identities surface are covered in how Documentum API and integration users are counted.

The argument against counting them

The named user metric grants the right of an identified individual to use the product. A service account is not an individual. It is infrastructure: a credential that lets one system act on behalf of another. The people whose work flows through that integration are the consumers, and they are already counted as named users in their own right. Counting the service account in addition charges twice for one stream of activity.

This is not a technicality. It follows directly from what the metric is meant to measure. The metric measures distinct authorized humans. A service account is neither distinct as a person nor human. It therefore falls outside the population the metric is designed to charge for, alongside the dormant accounts we examine in service and dormant accounts counted as Documentum consumers.

What the answer depends on

Like most audit questions, the precise outcome depends on the entitlement language and the facts. Some agreements address technical or system accounts directly. Others are silent, in which case the defensible reading is that an identity which is not a person cannot be a named user. What does not vary is the need for evidence. To remove a service account from the count you must be able to show what it is, what integration it serves, and that the humans it serves are themselves licensed. Building that evidence is the subject of how to document Documentum named users for a rebuttal.

How we remove them under the four Rs

Respond. In the seven day notice window we secure the channel so a raw account export does not become the agreed user count before service identities have been classified.

Reconstruct. We build the effective license position independently, tagging each account as human or non human and mapping every service account to the integration it serves and the system that owns it. The result separates infrastructure credentials from genuine consumers.

Rebut. We present each service account for removal with evidence: an integration, an owner, and the licensed humans behind it. The vendor must accept the removal or argue that a non human credential is somehow a named individual.

Resolve. We settle on the corrected count and, where it serves you, convert forward into an OpenPass agreement that defines the user metric so technical accounts are addressed explicitly and cannot be recounted next time.

What it is worth

Integration heavy Documentum estates can carry a surprising number of service accounts, and each one removed comes out of every stacked layer of the remedy: list price, back maintenance, first year maintenance, and audit cost recovery. In our anonymised insurance engagement, case file E-01, disqualifying service and dormant accounts was a significant part of moving the finding from $7.2M to $1.6M, a 78 percent reduction. The technique of supporting each removal with usage data is described in reducing a Documentum finding with usage evidence.

The double counting problem in plain terms

The strongest way to understand why service accounts should not be counted is to follow a single document through an integration. A person in an enterprise application creates a record, and the integration stores an associated document in Documentum on their behalf. That person is a licensed user in the enterprise application, and if they also use Documentum directly, they are a named user there too. The service account that carried the document between the systems is a third credential involved in one act of work by one person.

If the audit counts the service account as a Documentum user, the organization is paying for that single act of work twice over: once through the person who performed it and once through the credential that moved it. Scaled across thousands of documents and dozens of integrations, this double counting can add a large and entirely artificial layer to a finding. The service account is not consuming content for any purpose of its own. It is a pipe, and a pipe is not a person.

This framing also explains why the evidence required is straightforward. To remove a service account, you show three things: that the credential is non human, that it serves a specific integration, and that the people whose work flows through it are themselves licensed. Each of those facts is documented in ordinary systems of record, so the removal does not depend on interpretation. It depends on demonstrating that one act of work is being charged more than once.

The same logic extends to the related question of indirect and API driven access, where the activity attributed to an integration credential is really the activity of already licensed humans working through another system. Where the credential is infrastructure and the humans behind it are accounted for, counting the credential as an additional user does not reflect any additional consumption.

Where to go next

For the wider method behind a Documentum finding, read our complete OpenText audit defense playbook for 2026 and our ECM and Documentum audit defense track. If your finding includes service accounts you believe are infrastructure rather than users, open a case and we will classify and remove them with evidence.