How to scope Exstream batch processing volume
Batch processing is where most Exstream volume is produced, and it is also where most of the overcount hides. A nightly or monthly batch run composes communications at scale, but a batch environment also reruns failed jobs, processes test data, and generates intermediate output that was never delivered. When a finding counts all of that as production volume, the batch total balloons. Knowing how to scope Exstream batch processing volume lets a buyer reduce the batch total to the composed production output that the metric is meant to charge.
This article explains what batch processing generates, why it overcounts, and how a buyer scopes batch volume to its real license treatment. It supports our Exstream and customer communications audit defense practice and links up to the complete OpenText audit defense playbook for 2026.
What a batch run actually produces
A production batch composes a defined set of communications from a data file and a template set. Around that core, a batch environment also produces things that are not new production communications: reruns after a failed job, reprocessing after a data correction, test executions against sample files, and intermediate spool output. A count taken at the job or output level cannot separate these on its own. The composed production count is the figure the metric intends, and it is smaller than the raw batch output total. This is the same composition versus output distinction described in Exstream page and document counting explained.
A rerun is not new volume. A test job is not production. Intermediate output is not a delivered communication. Batch volume must be scoped to composed production, not totalled at the job level.
Why batch volume overcounts
The overcount comes from treating job activity as communication volume. A failed run that is restarted can double the apparent output for that cycle. A data correction that reprocesses a file repeats compositions that were already counted. Test executions against sample data sit in the same environment as production and are easily swept in, the issue covered in Exstream non production and test volume scope. API triggered batch jobs add another layer, treated in how Exstream API and batch jobs are counted. Each of these inflates the batch total above the composed production figure.
Scoping batch volume correctly
Scoping reduces the batch total to composed production. The categories that need separating are these:
- Composed production runs. The successful runs that produced delivered communications, the figure the metric intends.
- Reruns and reprocessing. Restarted and corrected jobs that repeat already counted compositions.
- Test and sample executions. Non production runs against test data.
- Intermediate and discarded output. Spool and staging output that was never delivered.
Each category is matched to the metric the authorization defines. The result is a batch volume that reflects composed production, with reruns, test executions, and intermediate output removed. The line by line approach is in defending an Exstream volume overclaim line by line, and the document count specifics in how to challenge an Exstream document count.
The evidence that supports the scope
The buyer proves the scope from batch operational records. Job scheduler logs show successful runs distinct from reruns and restarts. Data file and run records show which executions were test or sample and which were production. Output management logs distinguish delivered output from intermediate spool. Error and reprocessing logs show corrections that repeated compositions. Assembled before the vendor measurement, this evidence reduces a job level total to a composed production count. Gathering it is part of reconciling Exstream entitlements before an audit, and it feeds the broader case in reducing an Exstream finding with volume evidence.
A representative outcome
In a recent engagement, an Exstream batch finding had counted reruns, a quarter of test executions, and intermediate spool output as production volume. By rebuilding the composed production count from the scheduler and output logs, and by showing which runs were restarts and which were test, we reduced the batch total to its delivered figure. The matter settled far below the opening claim, consistent with the firm reductions, where the average finding has come down 68 percent across more than 200 defended audits since 2020.
Holding the batch scope forward
Batch scoping is worth carrying into the forward agreement. When the resolution records that composed production is the chargeable unit and that reruns, test executions, and intermediate output are excluded, the next review starts from an agreed scope rather than a raw job total. For the cost framing buyers ask about first, see how much does an Exstream volume finding usually cost.
Why batch is where the largest reductions sit
Batch processing deserves particular attention because it is where the volume is concentrated, and concentration cuts both ways. A small percentage error in how batch jobs are counted translates into a large absolute swing in the finding, because the base is so large. A run that is restarted twice, a quarter of executions that turn out to be test, and a layer of intermediate spool that was never delivered can together push a batch total far above the composed production figure, and because the remedy prices that excess at list and stacks maintenance on top, the inflated batch volume drives a disproportionate share of the settlement. The corollary is that careful batch scoping yields the largest reductions in a customer communications defense. The buyer that rebuilds the composed production count from the scheduler and output logs is not trimming a rounding error; it is correcting the single largest line in the finding. This is why we treat batch reconstruction as a priority rather than a detail, and why we build the scheduler, run, and output records before the vendor measurement is allowed to set the base. The same priority informs how API triggered jobs are handled, as set out in how Exstream API and batch jobs are counted.
A final practical point is that batch records age quickly if they are not captured. Scheduler logs roll over, spool files are purged, and the detail that distinguishes a rerun from a fresh run can be lost within months. A buyer that waits until an audit notice arrives to assemble its batch evidence may find that the records for the earlier part of the audit window have already been overwritten. The discipline, therefore, is to retain the scheduler, run, and output logs as a standing matter, so that the composed production count can be reconstructed for any period the audit reaches rather than only for the most recent cycles. That retention is inexpensive compared with the exposure it prevents, and it converts batch scoping from a scramble into a routine that is ready before the seven day notice ever lands.
Reduce the batch total to composed production
We separate reruns, test executions, and intermediate output from delivered communications and rebuild the composed production count. Open a case and we will scope your batch volume before the vendor totals it at the job level.
Open a case →If an OpenText or Micro Focus audit notice has arrived, the first seven days shape the outcome more than any week that follows. OpenText Audit Defense is an independent, buyer side practice founded in 2020 by former vendor compliance leadership. We have defended more than 200 audits, brought the average finding down by 68 percent, and mitigated more than $90M in claims against vendor positions. We do not resell OpenText software and we are not affiliated with OpenText Corporation. To open a case, use the contact form on this site.