Documentum Capture and Intelligent Capture license traps

Capture products sit at the front door of a Documentum estate, turning paper and images into content the repository can manage. They are also licensed on metrics that have little to do with how many people touch them, and that mismatch is where a Documentum Capture finding inflates.

Documentum Capture and Intelligent Capture do a narrow job extremely well. They scan, classify, extract, and route documents into the repository, often running as unattended back office processes rather than tools that staff sit in front of all day. That operating model is exactly what makes the licensing easy to misread. The metrics applied to capture products tend to count scan stations, processing volume, or pages, and a finding that maps those metrics onto the wrong population, or onto peak throughput that the business never sustained, produces a number far larger than the capture capacity actually in use. Because the OpenText EULA places compliance squarely on the licensee, the burden of establishing what the capture estate genuinely consumes falls to the buyer, and that is precisely the analysis an audit hopes the buyer cannot produce.

How Documentum Capture is licensed

Capture products are rarely licensed the same way as named seat products. Depending on the edition and the contract, the metric may be a count of capture or scan stations, a count of concurrent processing threads, an annual or monthly page or document volume, or a server based capacity figure. Each metric counts something different, and a finding that picks the most expensive reading of an ambiguous contract is the first trap to watch for. A station based metric counts points of input; a volume based metric counts throughput; a server based metric counts deployed capacity. Confusing one for another, or applying two at once, is a common source of overstatement.

The principle a buyer should hold to is that the metric defined in the entitlement governs, not the metric the audit finds most convenient. Where the contract licenses capture by station, the number of stations actually configured for capture is the count, regardless of how many documents passed through them. Where the contract licenses by volume, the genuine processed volume over the contract period governs, not an extrapolation from a busy day. Establishing which metric applies, and reading it precisely, is the substance of the defense.

Where an Intelligent Capture finding overstates

Peak volume read as sustained volume

Capture workloads are spiky. A migration, a year end document push, or a one off backfile conversion can drive processing volume far above the normal run rate for a short period. A finding that takes the peak and treats it as the licensable volume charges for capacity the business used once. The defensible figure is the sustained volume over the contract term, with one off spikes documented as what they were.

Reprocessing and test runs counted as production

Capture pipelines often reprocess the same documents during tuning, or run test batches that never reach the live repository. Counting those pages or documents as production throughput double counts work that produced no managed content. Separating genuine production capture from test and reprocessing is a standard correction, and it parallels the boundary argued in Documentum non production environments and license claims.

Station counts taken from installed software, not configured capture

Where capture is licensed by station, a finding may count every machine with the client installed rather than the stations actually configured and used for capture. Installed but idle clients are not capture stations in use, a distinction that mirrors the consumer question explored in Documentum read only users and the consumer definition.

Defending a Documentum Capture finding 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 capture configuration, the metric that actually applies, and the throughput records are documented before any measurement is read against the broadest possible interpretation.

Reconstruct. We build the effective license position independently. We identify which capture metric the entitlement defines, count the stations genuinely configured for capture or the sustained production volume over the term, and separate test, reprocessing, and one off conversion work from ongoing production. The reconstructed position reflects the capture capacity the business actually runs.

Rebut. We challenge the finding line by line. Where peak volume has been read as sustained, we supply the run rate. Where reprocessing or test runs have been counted, we scope them out. Where installed clients have been counted as capture stations, we establish the configured population. Each correction rests on the configuration evidence and the metric definition in the contract.

Resolve. We settle on the corrected position and, where it serves you, convert forward into an OpenPass agreement that records exactly how capture is measured, including how volume spikes and non production processing are treated, so the next audit cannot rebuild the count from peak throughput.

An anonymised outcome

The reason a capture overstatement is expensive is 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 OpenText incurs performing the audit, so an inflated volume or station count multiplies through four charges at once. 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. That engagement turned principally on disqualifying ineligible accounts from a seat count, but the same discipline, holding a metric to what the business genuinely consumes, is exactly what corrects an inflated capture volume.

Read the metric before you accept the number

The lasting lesson is that a Documentum Capture finding is only as sound as the metric reading behind it. Capture products invite overstatement because their throughput is uneven, their test and production work blend together, and their client software outlives its active use. Each of those features gives an audit a larger number to reach for, and each is answered by evidence the buyer controls. The metric in the entitlement is the anchor, and a count that drifts away from it is a count to challenge.

For a buyer, the practical step is to record which capture metric the contract defines, document the configured stations or the sustained production volume, and keep test and reprocessing work clearly separated from production. To prepare that material, read how to reconcile Documentum entitlements before an audit, and to see how capture fits the wider defense, read our ECM and Documentum audit defense track. If a capture finding has charged for volume or stations the business does not use, 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 understand how the underlying repository count is built, read how Documentum named user counts inflate an audit finding.