Batch Bates Numbering Across Multiple PDFs (Continuous Ranges)

What Makes Batch Bates Numbering Different

Stamping a single PDF is a one-shot operation: set a start number and go. Stamping a batch of PDFs as one continuous series is a different problem, because the running count has to hand off correctly from the last page of one file to the first page of the next, across every file in the set, in the exact order you intend to number them.

This is the actual job in most litigation support workflows. A production rarely arrives as one PDF; it is usually dozens or hundreds of separate files pulled from email exports, scanned paper, and native document conversions. The numbering has to treat all of them as one logical document even though they remain separate files on disk.

The difference matters most at scale. A five-file batch with a numbering mistake is easy to spot and re-run. A 300-file batch with the same mistake, say a file processed twice or skipped entirely, can hide inside a range that still looks plausible at a glance, which is why the verification habits below matter more as batch size grows rather than less.

Folder Order Pitfalls

The single most common batch numbering error is file order. Operating systems sort filenames differently depending on locale and naming convention, so a folder that looks alphabetically sorted in a file browser is not guaranteed to be the order a batch tool will process it in. A file named "Doc10.pdf" can sort before "Doc2.pdf" under plain string sorting, which silently puts page 10's content ahead of page 2's in the Bates sequence.

Before running a batch, review the actual processing order the tool will use, not just how the folder looks in Explorer or Finder. If custody order or chronological order matters for the production, sort explicitly by date or by a manually assigned sequence number in the filename, such as 001_Contract.pdf, 002_Emails.pdf, rather than trusting default alphabetical sort.

Collision Checks Before You Produce

A collision is when the same Bates number appears on two different pages, usually because a second production from the same party started at 1 again instead of continuing from the previous production's last number. Collisions are serious because every citation that relies on Bates numbers being unique breaks the moment two pages share a number.

Before running any production after the first, confirm the highest Bates number used across every prior production from that party, and set the new start number to exactly one past it. Keep a running log, even a simple spreadsheet with production date, prefix, start, and end number, so this check takes seconds instead of an archive search.

Output Naming by Bates Range

Once a batch is stamped, rename each output file after the Bates range it covers rather than keeping the original working filename. A file named ABC000001-000045.pdf tells anyone exactly what it contains without opening it, and it makes locating the source file for a specific Bates number a matter of scanning filenames instead of opening files one by one.

Worked Example: A 300-File Production

Consider a production of 300 native files, averaging 8 pages each, prefix ABC, six-digit padding, starting at 000001. Processed in a fixed, verified order, the running count looks like this for the first few files:

With an average of 8 pages across 300 files, the set totals 2,400 pages, ending at ABC002400. Six-digit padding leaves headroom for nearly 250 more productions of this size before the numbering scheme needs to widen, which is exactly the kind of margin worth planning for up front rather than discovering mid-case.

Note that "average 8 pages" is just that, an average; real productions mix one-page cover letters with fifty-page contracts. The continuous count does not care about that variance, it simply adds whatever page count each file actually has, in order, which is why locking file order matters far more than any assumption about typical document length.

Handling Attachments and Document Families in a Batch

Email productions rarely arrive as flat, standalone files. A single email with three attachments is really a family of four related documents that should stay grouped together in the Bates sequence, ideally with the parent email numbered first, immediately followed by each attachment in its original order. Breaking a family apart across a batch, so that unrelated documents get numbered between an email and its own attachment, makes the resulting range far harder to work with in review.

When exporting email threads for a batch, keep the family structure intact in the folder or file list before numbering, and consider tracking a family identifier alongside the Bates range in your production log. This matters even more when the same family later needs a BEGATTACH field for a load file, since that field depends on knowing exactly where each family starts, a topic covered in depth in our Bates numbers in load files guide.

The Time Cost of Manual Batch Tracking

Manually tracking a running Bates count across a large batch, updating a spreadsheet by hand as each file is stamped separately, is possible but slow and error-prone at scale. For a 300-file production, manually calculating and re-entering a start number for every file adds meaningful time and introduces exactly the kind of off-by-one arithmetic mistakes that a tool automating the running count avoids by design.

The practical tradeoff is simple: batch tools that carry the count automatically remove the arithmetic step entirely, so the only manual work left is verifying the final output against the three checks described earlier, start number, file-to-file continuity, and final total, rather than computing every intermediate range by hand.

Standardized field naming for these ranges in review platforms, including BEGBATES and ENDBATES, follows conventions documented by industry bodies such as the EDRM (Electronic Discovery Reference Model), which many e-discovery workflows use as a shared reference point.

Frequently Asked Questions