# Batch OCR Discovery Documents Without Losing Order

- Author: Schema Law (https://www.schemalaw.com/)
- Published: 2024-07-28T16:55:43Z
- Updated: 2026-10-11T19:22:20Z
- Category: Litigation support
- Canonical: https://www.schemalaw.com/blog/batch-ocr-discovery-documents

> How to batch OCR discovery documents: split the set, name files so order survives, plan page limits, log failures and rebuild one complete set.

To batch OCR discovery documents without losing track of them, build a list before you touch a file. Record every file, its page count and its place in the production, split oversized files at document boundaries, name each piece so it sorts in order, and compare every export with that list before anyone relies on the set.

The recognition itself is the easy part. What costs a team its weekend is bookkeeping: a file that never finished, two halves of a split joined in the wrong order, a page count that is off by eleven and nobody knows where. The sections below set up that bookkeeping so a batch of thousands of pages comes back as the same set that went in.

## What goes wrong when you OCR thousands of pages at once?

Large batches fail quietly. A file is skipped, uploaded twice, cut off partway or exported out of sequence, and nothing announces it. On a ten-page job you would see the gap. Across six thousand pages you find it weeks later, when a search misses a document you know was produced.

The failures fall into a few types, and each has a cheap control:

| What happens | How it shows up later | Control |
| --- | --- | --- |
| A file was never uploaded | Searches miss a Bates range entirely | Tick each file off a manifest as it goes in |
| A file was uploaded twice | Duplicate hits; totals too high | One manifest row per file, one upload per row |
| A file stopped partway or failed | Output has fewer pages than the source | Compare exported page count with source page count |
| Split parts joined in the wrong order | Page 301 follows page 900 | Zero-padded part numbers in the file name |
| Files sorted differently on another computer | Set order changes between people | Names that sort the same everywhere |
| Rotated or blank pages dropped from view | Page numbers drift against Bates numbers | Keep blanks; count pages, never estimate |

Two of these deserve a closer look.

**Partial output looks like success.** A text file exists, it opens, and it has words in it. Unless you know the source had 412 pages, you have no reason to notice that the export stops at 380. Page counts are the only defense, which is why the manifest records them before anything is uploaded.

**Order is a property of the set, and files do not carry it.** A production arrives in an order the other side chose, usually by Bates number. Once you copy files into a new folder, rename them or split them, that order survives only if the names encode it. The post on [how to OCR Bates numbered documents](https://www.schemalaw.com/blog/how-to-ocr-bates-numbered-documents) covers tying each page to its number. This post covers keeping the files themselves in line.

A third risk is spending. If your plan counts pages per month, a batch run twice by mistake uses the allowance twice. Know the page total before you start.

## How should a batch be split before upload?

Split a batch only where a limit forces you to, and always at a document boundary. Leave files under the limits alone. For a file over the page or size limit, cut it between documents, never mid-letter or mid-contract, and record each part on the manifest with the page range it came from.

Start with the manifest. A spreadsheet is enough. Give it one row per file and fill in the first six columns before you upload anything:

| Column | What goes in it |
| --- | --- |
| Seq | Position in the production, 001 upward |
| Original file name | Exactly as received, never edited |
| Bates begin and end | From the first and last page of the file |
| Pages | Read from the file's properties in your PDF reader |
| Size | In megabytes, from the folder listing |
| Part of | Blank, or "2 of 3" for a piece of a split file |
| Uploaded | Date, and who did it |
| Result | Ready, failed, or redone |
| Pages out | Page count of the export |
| Notes | Anything odd: blanks, rotated pages, illegible stretches |

Then sort the list by pages and by size. Anything above your tool's per-document page limit or upload size limit needs splitting. Everything else goes up whole.

### A worked example

Say a production arrives as 48 PDFs, Bates range ACME0000001 to ACME0006200. Forty-six of the files are under 400 pages. One is a 1,400-page run of invoices and one is a 2,100-page email print-out.

On a plan that allows 1,000 pages per document, the invoice file becomes two parts and the email file becomes three. Open each in a PDF editor, find the page where one invoice or one email ends near the cut point, and split there. If the invoice file breaks cleanly after page 688, the parts are pages 1 to 688 and 689 to 1,400. Write those ranges and the matching Bates ranges on two manifest rows. The batch is now 51 uploads, and the manifest still adds up to 6,200 pages. Check that sum. If it does not match the production cover letter, stop and find out why before you go further.

### Mistakes to avoid when splitting

- **Splitting by even page counts.** Cutting every 500 pages is quick and slices documents in half. A search hit then lands in a file that holds only the back end of a contract.
- **Splitting the originals.** Work on copies. The files as received stay untouched in their own folder.
- **Forgetting file size.** A grayscale or color scan can pass a size limit long before it reaches a page limit. Check both columns.
- **Dropping blank pages to save volume.** Blanks often carry a Bates number. Removing them shifts every later page against the numbering.

## File names that keep a production in order

A good file name sorts correctly on any computer and tells you what is inside without opening it. Lead with a zero-padded sequence number, follow with the Bates range, and end with a part marker when the file was split. Keep the original name in the manifest and leave it out of the working name.

The pattern looks like this:

```
0001_ACME0000001-ACME0000212.pdf
0002_ACME0000213-ACME0000240.pdf
0017_ACME0002101-ACME0002788_part1of2.pdf
0017_ACME0002789-ACME0003500_part2of2.pdf
```

Each element earns its place:

- **Zero padding.** Without it, most systems sort "10" ahead of "2". Pad to one digit more than you think you need, so a late supplemental volume still fits.
- **Bates range in the name.** Anyone holding a single file can tell where it belongs, and anyone looking for ACME0002950 can find the right file from a folder listing.
- **Part markers that state the total.** "part2of2" tells you a part is missing in a way that "b" never will.
- **Plain characters only.** Letters, digits, hyphens and underscores. Spaces, commas, ampersands and slashes cause trouble in scripts, zip files and some upload forms.

Keep the same base name through every stage. If the upload is `0017_ACME0002101-ACME0002788_part1of2.pdf`, the text export should be `0017_ACME0002101-ACME0002788_part1of2.txt`. Rename downloads straight away if your browser adds "(1)" or the tool gives them a different name. A folder where source and output share names can be checked by eye.

Track the batch as one discovery production from the first file to the last. Write the Bates range and the page count on the job sheet before you split anything. That sheet is your chain of custody for the scan set. If a text export comes back short, you can see which piece of documentary evidence left the folder. Hand the sheet to the person who will search the production.

Productions without Bates numbers still need the sequence prefix. Use the order of the index or cover letter that came with the documents. Where there is no index, fix an order yourself, write down the rule you used, and keep to it.

## Page limits and monthly volume

Plan capacity before the first upload. Three numbers matter: the largest file a tool accepts, the most pages it reads in one document, and the pages you may process in a month. Compare each with the manifest totals. A batch that will not fit should be scheduled, or the plan changed, before you begin.

For Schema Law the figures are these. An upload is a PDF, PNG or JPEG of up to 20 MB.

| Plan | Pages per document | Volume |
| --- | --- | --- |
| Free | Up to 3 | 1 document a day |
| Solo | Up to 250 | 1,000 pages a month |
| Team | Up to 1,000 | 10,000 pages a month |
| Enterprise | No fixed limit | 100,000 pages a month |

Every plan runs the same software. On any of them you can choose several files at once, and they are read one after another, so a queue of fifty uploads still finishes file by file and each result goes on the manifest as it lands. The 20 MB limit applies to each file on every plan, Enterprise included. The [pricing page](https://www.schemalaw.com/pricing) has the current details, and the post on [OCR cost per page](https://www.schemalaw.com/blog/ocr-cost-per-page) works through the arithmetic of comparing plans.

Apply the limits to the example. The 6,200-page production fits inside a Team month with room to spare, and the two large files need the five-part split already planned. On Solo, the same production is more than six months of allowance and every file over 250 pages needs cutting, so the plan is the wrong size for the job. The free plan is for testing a few representative pages. Pick the worst pages in the set for that test, since they tell you more than the clean ones.

Three planning habits save trouble:

1. **Leave headroom for reruns.** A file that fails and is run again may count twice. Budget ten percent above the manifest total until you know how your tool counts.
2. **Check size as well as pages.** With a 20 MB cap, a few hundred pages of grayscale scans can be too large even though the page count is fine. Split those by size, still at document boundaries.
3. **Count rolling productions together.** If three more volumes are due this month, add their estimated pages now.

## Tracking which files failed

Assume some files will fail, and make failure visible. After every upload, write the result on the manifest. When a file fails, record why, fix the cause and run it again as the same manifest row. A batch is finished only when every row shows a result and a matching page count.

Common causes, roughly in the order you will meet them:

- **The file is too large or too long.** Split it and add rows for the parts.
- **The PDF is password-protected or damaged.** Open it in a PDF reader. If the reader also struggles, ask the producing party for a replacement and note the Bates range.
- **The upload was interrupted.** A dropped connection or closed laptop can leave a file half-processed. Run it again.
- **The file is not what its name says.** A spreadsheet or email container renamed to end in ".pdf" will be rejected. That file needs different handling, and your manifest should say so.

In Schema Law, a document that could not be parsed is shown as failed with a short message, and one whose parsing was cut off is shown as failed with a message that parsing was interrupted and to try again. Copy that message into the Notes column. A pattern across several files, such as every file from one custodian failing, usually points to a problem with how those files were made.

A failed file is the obvious case. The quiet one is a file that finished with the wrong number of pages. So the last check for each row is always the same: pages out equals pages in. Then open the export at three places, the first page, a page in the middle and the last page, and compare each with the same page of the source. That takes under a minute per file and catches truncation, wrong-file mix-ups and badly rotated runs. For judging the quality of the text itself, the guide to [why OCR output is full of errors](https://www.schemalaw.com/blog/why-is-ocr-output-full-of-errors) explains what to sample.

Keep the failure log. If you later raise illegible or broken files with the other side, a dated list by Bates range is what you will need. The guide to [making a document production searchable](https://www.schemalaw.com/blog/make-document-production-searchable#raising-ocr-problems-with-opposing-counsel) covers that conversation.

## Reassembling exports into one set

Reassemble in manifest order and prove the total. Join the parts of each split file first, then confirm the page count of the whole set against the production total. How you join depends on the export format, because each format marks page boundaries in its own way.

- **Searchable PDF.** Merge the parts in a PDF editor in part order, then check the page count. A Schema Law searchable PDF made from a PDF upload is the original file with an invisible text layer added, so the page images, including any Bates stamps, are the ones you received.
- **Plain text.** Schema Law's text export separates pages with a form feed character. Parts can be joined end to end, and a script or a text editor that shows control characters can count the form feeds to confirm the page total.
- **Word.** Each source page starts a new page in the exported document. Joining parts is a copy and paste, but long merged Word files are slow to work in. Keeping one Word file per produced document is usually better.
- **JSON and Excel.** Both carry a page number for the text on each page, counted from 1 within each uploaded file. That detail matters for split files, as the next paragraph explains.
- **CSV.** The file holds the tables found in the document. When a document has no tables, it holds the text as rows of page number and line.

Page numbers restart in every part. Page 1 of `part2of2` is page 689 of the original invoice file. Add the offset from the manifest when you merge: original page equals part page plus the number of pages in all earlier parts. Do the same to get from a page to its Bates number. Skipping this step is the most common reason a cite pulled from converted text points at the wrong page.

For delivery, give the reviewer a folder that mirrors the production: one searchable PDF per produced file, a matching text file beside it, and the finished manifest on top. The manifest is the index. It shows what was produced, what was converted, what could not be read and where to look. Teams that load the set into a review platform will need more structure than a folder, and the guide to [creating a load file from scanned PDFs](https://www.schemalaw.com/blog/how-to-create-a-load-file-from-scanned-pdfs) picks up from there.

Finally, decide what stays in the OCR tool once the exports are safely filed. Schema Law lets you delete any document at any time, and the [security commitments](https://www.schemalaw.com/#security) set out how uploads are treated while they are there.

## Try it on a real document

Upload a scanned PDF and export it as Word, a searchable PDF or plain text on the free plan. Your documents are never used to train an AI model. [Start free](https://www.schemalaw.com/api/auth/google)