OCR for Litigation Support Teams: Tools and Volume

OCR for litigation support is a tool the team runs itself on the scanned material that never reaches the review platform, or reaches it too late: small productions, exhibits, subpoena returns and client paper. Buy it on monthly page volume, pages per document, export formats and user count, then run it with an intake form and a page forecast.

The buying questions differ from the ones a solo lawyer asks. A litigation support group serves several case teams at once, answers for the format of what it hands back, and has to explain its spend.

Use the side tool for work the case team needs today. A paralegal may need a deposition transcript searchable before the outline is due, or a small discovery set in text the same afternoon. Leave predictive coding and legal hold in the systems built for them. Log each upload by matter so you can say which attorney approved it.

What does a litigation support team use OCR for outside the review platform?

A litigation support team uses OCR outside the review platform for scanned material that is too small, too urgent or too peripheral to justify a processing job: a late supplemental production, a subpoena return, deposition exhibits, client paper collected at intake, and filed documents pulled from a docket as image-only PDFs.

The post on where OCR sits in e-discovery covers the pipeline itself. The work described here sits around that pipeline. Sorting it by what the requester does with the result shows what the tool has to export.

Two questions settle whether a job belongs in this lane or in the platform.

Will the documents be reviewed and coded? If reviewers will tag them for responsiveness and privilege, they belong in the platform with everything else, and the remaining decision is where recognition runs. The post on running OCR before uploading to a review platform deals with that choice.

Does anyone need more than search? A paralegal who needs the figures from forty scanned invoices in a spreadsheet is not asking for review at all. That is a conversion job, and a platform built for coding documents is the wrong place to do it.

Write the answers down as a rule the case teams can read. One line is enough: scanned sets under a page count you choose, needed within a time you choose, come to litigation support for direct conversion; everything else goes through processing.

Is OCR a litigation support job or a job for each case team?

OCR is a litigation support job when the output has to follow a format, feed another system or be repeated the same way across cases. It is a case team job when one person needs text from one document today. Split the work on that line and write the split down.

Three things change with ownership, and each is worth deciding on purpose.

Consistency. A central team applies one naming rule, one export choice per task and one quality check. Six case teams converting on their own will produce six habits, and the differences surface when sets are merged for trial.

Speed. A paralegal with an account converts a ten-page exhibit while the request to litigation support would still be sitting in a queue. Centralizing every page creates a bottleneck that case teams will route around.

Accountability. Someone has to know which documents went into an outside tool, under which matter, and whether a protective order or client instruction allowed it. That is easier to answer when uploads run through a small number of named people or a shared workspace than when they are scattered across personal accounts.

A workable split looks like this:

• Self-service by the case team: single documents, anything under a page count the firm sets, output used only inside the team.
• Litigation support: whole productions, anything going into the review platform or a trial presentation tool, anything leaving the firm, and anything under a protective order.
• Either, with a note to litigation support: recurring sets from the same source, so that the second batch is handled like the first.

The tool has to allow that split. Check how each candidate counts users before you design the workflow around it. On Schema Law no plan puts more than one person on an account, so the split there means an account for each person who uploads. Every plan takes several files at a time. The pricing page has the full plan lines.

A processing vendor's per-page fee versus in-house OCR for small productions

For a small scanned production, compare the vendor's whole invoice for the job, including any minimum charge and the turnaround, against the share of an in-house subscription the job uses plus the staff time to run and check it. Put both on one line per job and choose by the total, not the headline rate.

Vendor quotes differ in structure, so read your own. Look for a per-page or per-gigabyte line for imaging and OCR, a minimum per job, a project management or hourly line, a rush charge, and the stated turnaround. Then set out the in-house side with the same care.

A worked example with fictional parties. In Calder v. Ostrow Marine, the defendant serves a supplemental production of 1,840 scanned pages in 23 PDFs on a Tuesday, with a deposition the following Monday. The associate needs to search it by Wednesday. The team's vendor quote carries a job minimum and a two-business-day turnaround before rush charges. The team's in-house plan allows 10,000 pages a month and the month's other work is forecast at 5,500. The production fits inside the remaining allowance, no single PDF exceeds the per-document limit, and a paralegal can upload and spot-check it the same afternoon. In-house wins on time, and the recognition itself adds nothing to the month's bill because the pages were already paid for.

Change one fact and the answer flips. If the same set has to be loaded into the review platform with document boundaries, page-level text files and an image cross-reference, and the team has no way to produce that load format itself, the vendor's fee buys work the in-house tool does not do.

The division that turns a monthly plan into a figure per page, and the comparison with per-page billing, is worked through in the post on OCR cost per page. Use it to fill the first row with real numbers. Whether either cost can be passed to the client depends on the engagement terms and the rules in your jurisdiction, so check both before you bill it.

Load files and custom export layouts as a litigation support buying requirement

Load files and custom export layouts matter to litigation support when converted pages must enter a review platform or a firm database without manual rework. Treat them as a written requirement. Schema Law offers neither on any plan: its exports are the eight standard formats, the same on every plan.

Where another vendor's feature list mentions load files in a phrase, do not assume a format, a field list or a delimiter from it. Ask in writing what the line covers for your platform before you count on it.

The standard formats are listed under export formats on the homepage: Word, Excel, CSV, JSON, searchable PDF, plain text, Markdown and HTML. Every plan includes all eight. Decide which of your tasks those cover before you decide that a load file is a must-have. A team that only needs searchable PDFs for attorneys and spreadsheets for paralegals does not have a load file requirement at all.

If you do have one, write it so that a vendor can answer yes or no:

1. Name the destination. State the review platform or database and the import format its documentation specifies.
2. List the fields. Copy them from your own production protocol or the platform's import documentation, not from memory.
3. State how text and images are delivered. Use the wording of the same import documentation, so the answer can be checked against it.
4. State who sets document boundaries. Recognition does not decide where one document ends and the next begins. Say who does.
5. Attach a sample. A ten-document load that imported cleanly is the clearest specification you can hand over.

The anatomy of the files themselves, including the delimiters, belongs to the post on the Concordance load file. Then run each candidate on real case material before you sign. The post on how to test OCR software sets out a trial you can adapt to a load.

How should litigation support forecast OCR pages across active cases?

Forecast OCR pages case by case: list each active matter, estimate the scanned pages you expect this month from known events, add a reserve for surprises, and compare the total and the largest single document with the plan's monthly and per-document limits. Redo it monthly.

Count pages, not documents, when the plan you hold is metered in pages, as Schema Law's paid plans are. Check the unit on any other candidate. Three limits apply to every job:

• The monthly allowance. On Schema Law that is 1,000 pages on Solo, 10,000 on Team and 100,000 on Enterprise.
• Pages per document. Up to 250 on Solo and up to 1,000 on Team. Enterprise has no fixed page limit per document.
• File size per upload. Schema Law accepts a PDF, PNG or JPEG of up to 20 MB, so a long color scan may need splitting before it goes in whatever the page count.

Build the forecast from events on the calendar, since those are what generate scans.

Read against the plan lines, this month fits a 10,000-page allowance with little room, and the 880-page file fits a 1,000-page document limit. A month that adds a trial would not fit. That is the signal to look one plan up, or to send the largest set to the processing vendor.

Three habits keep the forecast honest.

Record actuals. At month end, write the real page count beside each estimate. After three months you will know how far your estimates run from the truth and can size the reserve from evidence.

Count re-runs. A set that is rescanned and converted again uses pages twice. Note those separately so they do not hide inside a matter's total.

Watch the per-document limit before the monthly one. A single 1,400-page deposition binder stops a job on a 1,000-page document limit even in an empty month. Splitting large sets in a sensible order is covered in the post on batch OCR for discovery documents.

An OCR request form for case teams sending work to litigation support

An OCR request form asks the case team for the matter, the source of the documents, any restriction on them, the page count, the output needed, the deadline and who will check the result. Seven answers let litigation support start work without a follow-up call.

Copy this and change it to fit your firm.

OCR REQUEST

1. Matter name and number:
2. Requested by / attorney responsible:
3. Where the documents came from
   (opposing production, subpoena return, client, court docket, other):
4. Restrictions
   [ ] Protective order applies (attach or cite the paragraph)
   [ ] Client or outside counsel guidelines limit outside vendors
   [ ] None known
5. What is being sent: number of files, approximate pages,
   location of the files, any control number range:
6. What you need back
   [ ] Searchable PDF   [ ] Word   [ ] Excel or CSV of tables
   [ ] Plain text       [ ] Loaded to the review platform
   [ ] Other:
7. Needed by (date and time) and why:
8. Who on the case team will check names, dates and amounts
   against the page images:
9. After delivery: keep the working copies until ________ / delete on delivery

A few of the lines earn an explanation.

Line 4 comes before the page count for a reason. Whether a set may go into an outside tool at all is a question for the responsible attorney, read against the order or the client's instructions. Litigation support should not be the one guessing. A ticked box with no paragraph cited goes back to the requester.

Line 6 names the output, not the tool. Case teams ask for "OCR" when they mean four different things. Making them tick a box tells you whether the job is a text layer, a conversion or a platform load.

Line 8 assigns the check. Schema Law's homepage says recognition is strongest on clean print and weaker on faint faxes, stamps over text and handwriting, and that nothing marks a passage as uncertain. Other tools vary. Either way someone who knows the case should read names, dates and amounts against the original, and the form should say who.

Line 9 closes the job. A working copy that nobody owns stays in the tool indefinitely. Decide at intake when it goes, and confirm from the tool's own terms that the team can delete a document on the date the form names.

Keep the completed forms. Twelve months of them are the best evidence you will have for next year's plan size, and for the conversation about whether the team needs another seat, a larger allowance or a load file feature.