OCR Contract Management: Paper Into a Repository

OCR gets paper contracts into a contract management repository in a form the repository can use. Scan each agreement, convert it so the file carries text, record a short row of fields for it, and import the signed scan, the text and the row together. Then sample the result before anyone relies on a search.

A repository here means any system your organization uses to hold its agreements and track their dates: a dedicated contract management product, a document management system with a contracts cabinet, or a disciplined shared drive with an index spreadsheet. The steps below do not depend on which one you have. Check your own system's import instructions for the file types and field formats it accepts.

What does OCR add to a contract management repository?

OCR gives a contract management repository something to search and something to sort. A scan loaded without it is a picture with a file name. With OCR the full wording of the agreement is searchable, and a person can read the terms off the text into fields the repository can filter and report on.

Think of a repository as answering two kinds of question.

The first kind is about wording. Which of our supplier agreements mention "most favored customer"? Does the Hartwell distribution agreement have an audit clause? A repository answers these by full-text search, and full-text search reads the text stored with each file. A contract that went in as an image is invisible to it. Unless your system reports the files it could not index, the search returns the agreements it could read and gives no warning about the rest.

The second kind is about facts held in fields. Which agreements end in the next ninety days? Which are governed by New York law? A repository answers these from structured data, one value per field per contract. Those values have to come from somewhere, and for a paper contract they come from a person or a program reading the converted text.

So turning scanned agreements into structured data is two jobs, in this order: text first, fields second. OCR does the first and makes the second possible. It does not do the second by itself. A date in the OCR text is just characters until someone decides it is the expiry date and types it into the right field.

OCR also helps with duplicates. A paper backlog can hold second copies of the same agreement. Once each scan has text, you can search for a distinctive phrase, such as a party's full legal name next to a signing date, and find the copy you already loaded.

A paper backlog often mixes a joint venture contract with a partnership agreement. Read each cover for the entity names and the date, and give a limited partnership file its own row so it stays apart from a general partnership file. Unsigned drafts go in the pile you still have to resolve.

Which legacy contracts are worth scanning and converting first?

Scan and convert first the legacy contracts that are still in force and that carry a date or an obligation someone must act on. Expired agreements with no surviving obligations go last, or stay in the box with a line in the index saying where they are.

A backlog project that treats every sheet as equal spends its effort in the wrong places. Sort the paper into tiers before a single page is fed, using facts you can read off the cover page or the first paragraph.

Three questions sort the pile.

1. Is it signed by everyone? Unsigned drafts and partly signed copies go in a separate pile for someone to chase or discard.
2. Is it still running? Look at the term clause, and look for a later amendment or termination letter clipped behind it.
3. Does money or risk still turn on it? A supply agreement with an annual price review matters more this quarter than a five-year-old catering contract for one event.

Within tier 1, order by the nearest date. An agreement that renews automatically in six weeks unless notice is given deserves to be loaded before one that runs for another four years.

Be honest about tier 4. Converting it costs pages and a little time, and it earns its place only if someone may later need to search an ended contract, for instance in a dispute. If budget is tight, scan tier 4 as images now and convert on demand.

Preparing a batch of paper contracts for a repository import

Prepare a batch by sorting the paper into one bundle per agreement, scanning each bundle to its own file, converting the files, recording the fields, and assembling an import folder with a manifest. Work in batches small enough that one person can check a whole batch in a sitting.

Fifty agreements is a workable size to start with; adjust it to your team. The procedure:

1. Bundle before you scan. One bundle is one legal instrument: an agreement with its own exhibits and signature pages. An amendment is its own bundle, tagged to its parent. Remove staples and unfold anything folded.
2. Give each bundle an ID. A simple running number on a slip sheet works: C-0412. Write the same ID on the box list. The ID will follow the contract through every later step.
3. Scan one file per bundle. Scan in a mode and resolution that recognition can work with. The settings are set out in the guide to digitizing paper files, under scanner settings that make OCR work.
4. Confirm each scan is whole. Compare the sheets in the bundle to the pages in the file before the paper goes back in the box. The post on missing pages in a scanned contract gives the checks to run.
5. Convert each file. Export a searchable PDF for the repository and a text or Word copy to read the terms from.
6. Fill in the field row. One row per agreement in a spreadsheet, using the column list in the next section.
7. Build the import folder. Signed scan, text file and nothing else for each ID, plus the manifest.
8. Run the pre-import check below, then import.

The manifest

The manifest is the spreadsheet that lists every file in the batch. It is what you reconcile against after import, so it needs columns the field row does not: the box the paper came from, the page count, who scanned it, who converted it, and whether the pre-import check passed.

A pre-import check

• Every ID on the box list has exactly one row in the manifest.
• Every row has a signed scan and a text file, and both open.
• The page count in the manifest matches the PDF.
• No two rows share the same counterparty, title and date. If two do, one may be a duplicate.
• Every date column uses one format.
• Every amendment row names its parent ID.

If you convert with Schema Law, each upload is a PDF, PNG or JPEG of up to 20 MB, and the pages are read into text and tables you can view before exporting. On any plan you can choose several files at once, and they are read one after another into the account that uploaded them. The Team plan takes documents of up to 1,000 pages, and the pricing page lists the monthly page allowance on each plan. A backlog is easy to size in advance: 600 agreements averaging 14 pages is 8,400 pages.

Paper contracts are confidential business records, and an agreement may itself restrict disclosure. Before you send a backlog to any outside service, check each agreement's confidentiality clause and read what that service says it does with uploaded files. Schema Law's security commitments are written out on the homepage.

What should travel with each contract file into the repository?

Three things should travel with each contract: the signed scan as a searchable PDF, the plain text of the agreement, and one row of structured fields. The scan is the record, the text feeds search, and the row feeds filters, reports and reminders.

The signed scan

Load the searchable PDF as the primary document. It shows the executed pages and carries the text layer behind them. If your repository builds its own search index from PDFs, the text layer is what it will read.

The text

Check whether your repository builds its index from a PDF's text layer or from a separate text file. A plain text copy is also the quickest thing to open when you want to copy a clause. Load it as a secondary file or attachment, never as the main document.

The field row

Keep the row short. Every field must be something a person will filter on or be reminded about.

Working out the notice deadline from the term and renewal wording takes care, and the method is in the post on extracting contract terms from a scan. For a longer field list and the discipline of recording clause and page with each value, see contract data extraction from scanned agreements.

With a few dozen contracts, people can fill in the rows by hand. With thousands, you may want software to propose the values. The post on contract data extraction software explains what to test before you trust one with your agreements.

Keeping the signed scan and its text paired after import

Keep the signed scan and its text paired by giving them the same base file name, storing the contract ID inside both, and loading them to the same repository record. A text file that drifts away from its scan becomes an unsigned, unsourced version of the contract.

Name them as a pair

Use one stem and vary only the ending.

C-0412_Hartwell-Foods_Distribution-Agreement_2019-05-01_SIGNED.pdf
C-0412_Hartwell-Foods_Distribution-Agreement_2019-05-01_TEXT.txt

The ID comes first so the files sort together and so a search for C-0412 finds both. The date is the effective date in year, month, day order. Avoid version words such as "final" in a stem. If your repository keeps a version history, that does the job, and "final" in a file name goes stale the day a later copy turns up.

Put the ID inside the files

File names get changed by email systems, download dialogs and well-meaning colleagues. Add a first line to the text file that says what it is.

[C-0412. OCR text of the signed scan of the same ID. Converted 2026-10-09. Not the executed agreement.]

For the PDF, put the ID in the document's title property, or keep the slip sheet as the first scanned page if your organization accepts that.

One record, two files

Load both files to a single contract record, with the PDF marked as the primary document. Do not create one record per file. Two records for one contract double every count and split the history.

When a scan is replaced

Sooner or later someone finds a better copy: the missing page 9, or a fully signed version where the first scan had only one signature. When that happens, convert the new scan, replace both files together, and note in the record what changed and why. An old text file left beside a new scan puts the pair out of step.

Amendments get their own record with their own pair of files, linked to the parent by the parent ID field. Which amendment governs which clause is a reading exercise that the repository cannot do for you, and the post on building a conformed copy of a contract covers it.

Spot-checking a repository after a bulk contract import

Spot-check a bulk import by reconciling counts, then opening a sample of records and testing three things in each: the scan displays, a search finds a phrase from its middle pages, and the fields match the signed page. Sign the batch off only when the sample passes.

Reconcile first

Count before you sample. The manifest says 50 agreements went in. The repository should show 50 new records, each with two files. A count of 49 means one import failed quietly. A count of 51 means a duplicate. Sort the new records by counterparty and look for near-identical names, such as "Hartwell Foods Inc" and "Hartwell Foods, Inc.", which split one company's agreements across two entries.

Then sample

For each sampled record:

1. Open the PDF from the repository. Confirm it is the signed scan and that the last page is there.
2. Pick a phrase from a middle page, something unusual like a product name or an address. Search the repository for it. The record should come back. This tests that the repository indexed the text, which is a different thing from the file having text.
3. Read each date field against the page named in the source page field.
4. Read the counterparty name against the signature block.
5. For an amendment, follow the parent link and confirm it lands on the right agreement.

How much to sample

A scheme that scales with risk rather than volume:

Sign-off

Record the result on the manifest: who sampled, on what date, which records, what was wrong and what was fixed. Then mark the batch as accepted. Until that mark is there, tell users the batch is loaded but unverified.

A worked case shows why the search test matters. A fictional distributor, Calloway Brands LLC, imports 50 supplier agreements. Counts reconcile and the PDFs open. The search test fails on six records. All six were scanned on a different copier that saved pages sideways, and the converted text for those files was fragments. The fields had been typed by a person reading the image, so they were right, and nothing else would have exposed the problem until a search for a clause missed six suppliers. The fix was to rotate, convert again and replace both files in each pair.

Keep the manifests. A year on, when someone asks whether the repository holds every agreement from the Dayton office boxes, the answer is in those sheets.