# Contract Data Extraction Software: What to Evaluate

- Author: Schema Law (https://www.schemalaw.com/)
- Published: 2024-01-11T01:22:01Z
- Updated: 2026-10-11T19:22:20Z
- Category: Contracts and agreements
- Canonical: https://www.schemalaw.com/blog/contract-data-extraction-software

> Choosing contract data extraction software for scanned agreements: what it automates, the kinds of tool on offer, a trial scorecard and export fields.

When your contracts are scans, judge contract data extraction software on four things: how well it reads the page images before it extracts anything, whether every extracted value points back to its place on the signed page, how it reports a term it could not find, and whether the export fits the system the data is going to.

A demonstration run on clean files made from Word shows none of the four, so ask what a vendor's demonstration used. This post is a buyer's guide for the other case, the one where the agreements came out of a filing cabinet. It names no products. The only comparison that counts is the one you run on your own agreements.

## What does contract data extraction software actually automate?

Contract data extraction software automates the reading step: it goes through an agreement, proposes a value for each field on a list, and writes the values to a table. It does not decide which fields matter, settle what an ambiguous clause means, or confirm that its own proposals are right.

Split the work of charting a contract into its tasks and the scope becomes clear.

| Task | Who does it | Comment |
| --- | --- | --- |
| Turning page images into text | Ask | A tool either includes OCR or expects text |
| Locating the clause that holds a term | The tool | The core of the product |
| Copying the value out | The tool | Dates, names, amounts, periods |
| Normalizing the value | Ask | "the fifth anniversary of the Effective Date" into a calendar date |
| Classifying the agreement type | Ask | NDA, lease, supply agreement |
| Deciding what to extract | You | You supply or approve the field list |
| Reading several documents as one deal | Test it | Amendments, side letters, order forms |
| Confirming the value against the signed page | You | A person does this |
| Judging what the clause means for the client | You | Legal analysis |

Two rows deserve a closer look.

Normalizing is where automated contract data extraction adds value and adds risk in the same motion. A person charting by hand writes down "five years from the Effective Date" and looks up the Effective Date. A tool that outputs "2027-03-01" has done arithmetic on two extracted values, and if either was wrong the result is wrong with no visible sign. Ask to see both the quoted wording and the computed value.

Reading several documents as one deal is the row to test hardest. An extraction that reports the original notice period, unaware that the second amendment changed it, is accurate about the document and wrong about the contract.

Set the field list to the facts a person must still check: the parties, the date, the term, and any choice of forum or venue the clause states. Ask the software for the quoted words and the page. You compare those proposals with the signed image. A header that names one state can disagree with the clause.

## Which kinds of contract extraction tools can a legal team choose from?

A legal team can choose among five broad kinds of contract extraction software: a module inside a contract management system, a standalone extraction or review product, a general-purpose AI assistant, a rules-and-templates tool, and a do-it-yourself pipeline of OCR plus scripts. They differ in setup, control and where the data ends up.

| Kind | How it works | Suits | Watch for |
| --- | --- | --- | --- |
| Module in a contract management system | Extracts on upload and fills the system's own fields | A team that already runs such a system and wants the fields populated | Whether the field list is fixed; whether you can see the text it read |
| Standalone extraction or review product | Built for charting many agreements | Large, time-boxed reviews | How it is priced; how the output moves elsewhere afterwards |
| General-purpose AI assistant | You give it contract text and ask for the terms | Small sets, exploratory work | Whether you must impose the schema yourself; whether a second run gives the same answers; the terms on confidentiality |
| Rules and templates | You define patterns or zones for each field | Many agreements on one form, such as your own standard terms | Agreements on a counterparty's paper, where the terms sit elsewhere |
| OCR plus your own scripts or a person | Convert to text, then search and record | Small teams; unusual field lists; full control | Slower per contract; depends on the reader's care |

A few points on choosing among them.

**Weigh volume before features.** A person can chart forty agreements from converted text and check every value as it is entered. Four thousand is a different job. For a small set, estimate the setup and verification cost of a dedicated tool against the reading it would save.

**Uniform paper favors simple tools.** If nearly all your agreements are on your own template, the terms sit in the same place every time, and a rules-based tool or even a search routine can find them. Mixed third-party paper needs a tool that copes with a clause it has never seen in that position.

**Where the data lands matters.** A module inside your contract system writes straight into the fields you will use. Any other route ends in an export that must be mapped and loaded. That is not a reason to reject the other routes, but cost the loading step. The post on [OCR for contract management](https://www.schemalaw.com/blog/ocr-contract-management) covers what should travel into a repository with each agreement.

**The last row is a real option.** Converting scans to text and extracting by hand or with a short script is slower, but nothing is hidden. Schema Law sits in that row, and only in its first half: it reads scanned pages into text and tables that you export. It does not extract contract terms, and its JSON export holds each page's text and tables with no field called "expiry date".

## Why scanned contracts change the software decision

Scanned contracts change the decision because extraction can only work on text, and a scan has none until OCR supplies it. Whatever tool you buy will either run its own OCR or need you to run one first, and the quality of that step caps the quality of everything after it.

The distinction between the two steps, and how to tell which one caused a wrong value, is explained in the post on contract data extraction under [OCR versus extraction as two different steps](https://www.schemalaw.com/blog/contract-data-extraction#ocr-versus-extraction-two-different-steps). For a buyer, it turns into a set of questions.

### Questions about the OCR inside the product

- Does the product accept image-only PDFs, or must files already carry text?
- If a PDF already has a text layer, does the product use that layer or read the images again? A poor layer added by an office copier years ago will poison the extraction if the tool trusts it.
- Can you see the recognized text for any page, side by side with the image?
- What happens to a page the OCR could not read? Is it reported, or does extraction simply find nothing there?
- Are tables in schedules kept as tables?
- Is there a page or file size limit, and are scanned pages priced differently from digital ones?

### What a scan does to extraction

A scanned agreement gives an extraction tool problems a Word file never does. Page headers and footers interrupt sentences that run across a page break, so a clause can be split in two. Handwritten fill-ins, such as a date or a dollar figure written into a blank, may be missing from the text altogether, which leaves the tool to extract the blank. A strike-through with a replacement written above it leaves the struck text in place as if nothing happened. Signature pages returned separately may sit in another file.

None of these is the extraction engine's fault, and none shows up in a demonstration run on born-digital files. So insist that the trial uses scans.

### Running OCR yourself first

There is a case for separating the steps even when the product includes OCR. If you convert the scans yourself, you can look at the text before extraction starts, fix or rescan the bad files, and feed every candidate tool the same input. That makes the comparison fair: differences in the results are then differences in extraction. It also leaves you with searchable copies whatever you decide about the software.

## A trial that tests contract extraction software on your own agreements

Test contract extraction software by building an answer key by hand for a small set of your own scanned agreements, running each candidate on the same set, and scoring every cell as right, wrong, missed or invented. Score cells, not impressions, and score the scans separately from the clean files.

The general way to run a document trial, including what you may upload during one, is in the post on the best OCR for lawyers under [running your own test on real documents](https://www.schemalaw.com/blog/what-is-the-best-ocr-for-lawyers#running-your-own-test-on-real-documents). What follows is specific to extraction.

### Build the set

Choose 15 to 20 executed agreements that look like your real population. Include:

- at least ten that exist only as scans, with one poor fax or photocopy among them;
- one agreement with a handwritten change;
- one with an amendment that alters a field on your list;
- two on a counterparty's paper;
- one agreement that is silent on a field, such as a contract with no governing law clause.

Check your confidentiality obligations before any of them leave the building.

### Build the answer key

Have a person chart all of them against your field list, with the clause and page for each value, and have a second person check the chart. This is the slow part. It is also the only thing that turns the trial into a measurement.

### Score each cell

| Mark | Meaning |
| --- | --- |
| Right | Value matches the key |
| Wrong | A value was given and it differs from the key |
| Missed | The key has a value; the tool left it blank or said not found |
| Invented | The key says the contract is silent; the tool gave a value anyway |
| Correctly blank | The key says silent; the tool said so |

Wrong and invented are the expensive marks. A missed value sends someone to the contract. A wrong or invented one looks finished.

### A worked scorecard

Twenty agreements and twelve fields make 240 cells. Suppose the results for two candidates read like this. The numbers are made up to show the method.

| | Tool A | Tool B |
| --- | --- | --- |
| Right or correctly blank | 214 | 221 |
| Missed | 19 | 6 |
| Wrong | 6 | 9 |
| Invented | 1 | 4 |
| Wrong or invented on scanned agreements | 5 of 7 | 12 of 13 |
| Values that link to a page location | All | About half |

Tool B has more right answers. It also has nearly twice as many wrong or invented ones, almost all on scans, and half its values cannot be traced. For a team that will verify every renewal date anyway, Tool A's habit of leaving a blank when unsure may be the safer behavior. The scorecard does not make the choice. It shows you what you are choosing between.

### Also record

- Minutes a reviewer needs to verify one agreement's row using the tool's own screen.
- Whether the tool caught the amendment.
- What it did with the handwritten change.
- Whether a second run on the same file gave the same values.

## What does automated contract extraction still leave to a lawyer?

Automated contract extraction leaves a lawyer the field list, the verification of every value that will be relied on, the reading of documents together, and every question of meaning. The software shortens the search for a clause. It does not take over responsibility for what the chart says.

**Choosing the questions.** A tool extracts what it is asked for. If the deal turns on an exclusivity clause and exclusivity is not on the list, the chart will be complete and useless. The field list comes from the client's question, and writing it is legal work.

**Verification.** Every value someone will act on needs a human reading against the signed image. A link from each value to its page makes this faster, which is a reason to weight that link heavily. Decide in advance which fields get checked on every row and which are sampled.

**Silence and absence.** "Not found" from a tool can mean the contract has no such clause, the clause is worded in a way the tool did not recognize, or the page that held it converted to rubbish. Only a reader can tell these apart, and the difference between "no assignment clause" and "assignment clause not detected" can be the whole point of the review.

**The contract as a family.** Someone has to establish which amendments exist, in what order they took effect and which values they replace. The post on [building a conformed copy of a contract](https://www.schemalaw.com/blog/conformed-copy-of-a-contract) covers that work.

**What is not in the text.** Handwritten changes, initialed deletions and filled-in blanks may never reach the extraction step. The post on [handwritten changes to a contract](https://www.schemalaw.com/blog/handwritten-changes-to-a-contract) explains how to sweep for them.

**Meaning.** Whether "commercially reasonable efforts" was met, whether a merger is an "assignment" under clause 14, whether a cap applies to the indemnity. A cell can hold the quoted words. The conclusion belongs in a separate column with a lawyer's name beside it.

Professional duties of competence and supervision when using software vary by jurisdiction and are outside this post. Check the rules and guidance that apply where you practice.

## Contract metadata fields to demand in the export

Demand an export with one row per agreement and, for every extracted value, three companions: the quoted source text, the page and clause it came from, and its review status. Contract metadata extraction is only useful downstream when each value can be traced and when blanks are explained.

Contract metadata means the facts about an agreement that sit outside its wording or summarize it. It comes in three layers, and an export should carry all three.

### Document metadata

| Field | Why you need it |
| --- | --- |
| Your own document ID | Ties the row to your file and your repository |
| Source file name | As uploaded, unchanged |
| Page count | A check that the whole file was read |
| Whether the file was OCR'd by the tool | Tells you which rows rest on recognition |
| Date and time processed | Distinguishes a rerun from the first run |
| Tool or model version | Results can change between versions |

### Extracted contract fields

Parties, agreement type, effective date, term, renewal mechanism, notice period, governing law, and whatever your question adds. The longer list, with the traps in each field, is in the post on [which contract terms are worth extracting](https://www.schemalaw.com/blog/contract-data-extraction#which-contract-terms-are-worth-extracting).

### Provenance for each value

| Companion | What to insist on |
| --- | --- |
| Source text | The exact words the value came from, as a quotation |
| Location | Page number of the scan, and section number where there is one |
| Raw and normalized forms | Both "ninety (90) days" and `90` |
| Empty-cell reason | "Silent", "not found" and "unreadable" as distinct values |
| Review status | Unreviewed, confirmed or corrected, with who and when |
| Original value after correction | So you can see what the tool proposed |

### The shape of the file

Ask for a sample export before you sign anything, and open it.

- CSV or Excel for people, JSON for systems, and ideally both.
- Dates in one unambiguous format, year first.
- Amounts as numbers with the currency in its own column.
- One stable column name per field, the same in every export.
- Party names exactly as written, with any cleaned-up version in a second column.
- A way to export everything, including the recognized text, if you stop using the product.

Do not skip that last item. The recognized text of your own agreements is worth keeping. If you run OCR separately before extraction, you already hold it, in whatever formats you chose from the [export formats](https://www.schemalaw.com/#formats) your converter offers.

## 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)