OCR vs Manual Data Entry: Retype the Page or Read It?
By Schema LawPublished Updated
OCR vs manual data entry comes down to the page and the stakes. Recognition suits long, cleanly printed documents where you need all of the text. Typing by hand suits short, faint or handwritten pages and the few values a case turns on. Either way, someone must check the result against the original.
Neither method is the careful one and neither is the careless one. They fail in different ways, they cost time at different points, and the checks that catch a typist's slip are not the checks that catch a machine's. Knowing those differences lets you choose per document and not per habit.
OCR vs manual data entry: which suits a legal document?
OCR suits a legal document when the print is clean, the document is long, and you want the whole text to search, quote or edit. Manual data entry suits a document when the page is hard to read, the item is short, or you need only a handful of values and each must be right.
Four questions settle it for a given document:
| Question | Points toward recognition | Points toward typing |
|---|---|---|
| How is the text on the page made? | Printed or typed, dark, on a plain background | Handwritten, faint, stamped over, or a poor copy of a copy |
| How much of it do you need? | All or most of it | A few names, dates and figures |
| How long is it? | Many pages | A paragraph, a short list, one form |
| What will you do with the result? | Search it, edit it, move tables into a spreadsheet | Enter values into a system field by field |
The two methods also combine. A common-sense split for a long agreement is to run recognition on the whole document so it can be searched, and then key the six or seven values that go into the matter record by hand while looking at the page image. The machine does the bulk, and a person owns the values that carry weight.
Type a short invoice when you only need the total, the date, and the party name. On a long transcript, let recognition supply text you can search for a citation, and type the damages lines yourself while you watch the page. Pick the split according to the strings you will look up again.
One more category sits beside both. The label "intelligent document processing" covers software meant to pull named values out of documents without a typist. The explainer on what intelligent document processing means covers what that label includes and what to ask about it.
How do a typist's mistakes differ from a machine's?
A typist's mistakes are slips of attention and of the hands: digits swapped, a line skipped, a word silently corrected. A machine's mistakes are slips of vision: one shape taken for a similar shape. Typed errors look plausible and land anywhere. Recognition errors look like the original and gather where the image is poor.
What a person gets wrong
- Transposition. Two neighbouring characters change places: 1987 becomes 1978, "form" becomes "from".
- Eye-skip. The eye returns to the page at the wrong occurrence of a repeated word and a line or a clause drops out. Contract boilerplate, with its repeated phrases, invites this.
- Repetition. The reverse: a line typed twice.
- Silent correction. The typist fixes a misspelling or a wrong date that is in the original. For a quotation or an exhibit, that is an error.
- Autocorrect. The word processor changes a surname or a defined term into a dictionary word after the typist has moved on.
- Wrong field. The right value goes into the wrong box of a form or the wrong column of a sheet.
What recognition gets wrong
- Look-alike characters. A lowercase l for a 1, a capital O for a zero, "rn" for "m".
- Lost or invented punctuation. A decimal point dropped from an amount, a speck read as a comma.
- Word boundaries. Two words joined or one split.
- Reading order. Columns or side notes stitched into the wrong sequence.
- Missed regions. A stamp, a margin note or a faint paragraph that returns nothing.
Why the difference matters when checking
| Typed by a person | Read by recognition | |
|---|---|---|
| Where errors fall | Anywhere, more as attention fades | Where the print is small, faint, skewed or marked |
| What an error looks like | A real word or a believable number | Similar in shape to the correct character |
| Same error repeated | No pattern | The same misreading can recur wherever that shape recurs |
| Whole lines missing | Yes, by eye-skip | Yes, by a missed region |
| Affected by the scan | Only if the typist cannot read it | Directly |
| Affected by length | Yes, through fatigue | No |
Two consequences follow. A spell checker finds little in typed text, because a transposed date is still a date. And a recognition error found once is worth searching for across the document, because the cause may repeat.
Double keying and other checks borrowed from data entry work
Double keying means two people type the same source independently and software compares the two versions. Wherever they differ, someone looks at the original and decides. It works because a slip made by one typist and not the other shows up as a disagreement.
Double keying is the heaviest control in the table that follows. The lighter ones cost less time, and all of them can be applied to recognized text as well as to typed text.
| Control | How it works | Catches | Misses |
|---|---|---|---|
| Double keying | Two independent entries, compared | Slips made by one person only | An ambiguity in the source that both read the same wrong way |
| Read-back | One person reads the entry aloud while another follows the original | Wrong digits, missing lines | Homophones and spellings, unless names are spelled out |
| Control total | Add a column of entered figures and compare with the total printed on the document | Any wrong amount in the column | Two errors that cancel; non-numeric fields |
| Record count | Count entries and compare with the count of items on the source | Skipped or doubled lines | Wrong content in a line that is present |
| Format check | Test that every date is a real date, every amount has two decimals, every reference has the right length | Malformed values | Well-formed wrong values |
| Sight check | One person compares entry and source, value by value | Whatever the checker's attention holds | Whatever it does not |
Using double entry with recognition
You do not need two typists to get the benefit. Treat the recognized text as the first entry and a person as the second.
- Run recognition on the document and export the text or table.
- Have someone who has not seen that output key the values that matter from the page image: parties, dates, amounts, account numbers.
- Compare the keyed values with the same values in the recognized text.
- Wherever they differ, look at the original and correct whichever is wrong.
A machine and a person fail in different ways, so a disagreement between them points you to the page. Agreement is not proof: a digit that is truly ambiguous on the page can mislead both.
A worked control total
Priya Raman is preparing a schedule of deposits from a twelve-page bank statement in a fictional matter, Hollis v. Dunmore Supply. The statement prints total deposits for the period as 48,310.55. After recognition and export to a spreadsheet, the deposit column sums to 48,319.55. The nine-dollar difference tells her one amount is wrong and roughly by how much. She reads down the column against the page looking for an amount nine dollars too high, finds 1,240.00 where the page shows 1,231.00, and corrects it. The total then agrees. Without the control total she would have had to compare every line.
Timing both methods on ten pages of your own file
The only timing that means anything is one taken on your own pages by your own people. Take ten representative pages, produce the text both ways, and record the minutes spent on each stage, including checking and correcting. Compare the totals, not the first stage alone.
Speed figures quoted for typists or for software describe other people's documents. Your faxed medical records and your typed pleadings will give different answers from each other, so run the test once per kind of document.
The procedure
- Choose ten pages that represent the batch, including one or two of the worst.
- Decide what "done" means: full text, or a named list of values.
- Typed route. One person types from the paper or the image. Record the minutes. A second person checks the result against the original and marks every error. Record those minutes and the number of errors. Record the minutes spent correcting.
- Recognition route. Upload the same ten pages, wait, export. Record the minutes, including the time to scan or locate the file. A person who did not do the typing checks the result against the original in the same way. Record minutes, errors and correction time.
- Fill in the table.
| Stage | Typed route | Recognition route |
|---|---|---|
| Producing the first version (minutes) | ||
| Checking against the original (minutes) | ||
| Errors found | ||
| Correcting (minutes) | ||
| Total minutes | ||
| Total minutes per page |
Turning minutes into cost
For each route, multiply total minutes by what a minute of that person's time costs the firm. For the recognition route add the software cost for those pages. With Schema Law the figures come from the pricing page: the Solo plan is $49 a month for 1,000 pages, and the free plan allows one document a day of up to three pages, so a ten-page test needs a paid plan or several days of three-page uploads.
Three cautions about reading the result:
- Count the errors the checker missed. If you can, have a third person check both final versions. A route that looks quick because its checker was quick has not been measured.
- Do not extend one result to other documents. Ten pages of clean print say nothing about a handwritten ledger.
- Keep the sheet. A dated record of the test explains the firm's choice of method if anyone asks later.
Documents where typing by hand still beats recognition
Typing by hand is the better choice where recognition has little to work with or little to save: handwriting, very short items, a few values wanted from a long document, pages too degraded to read by machine, and documents you are not permitted to upload anywhere.
| Document | Why typing wins | What to watch |
|---|---|---|
| A handwritten note, letter or annotation | Recognition is weaker on handwriting; a person who knows the writer may read it better | Mark doubtful words as doubtful instead of guessing |
| A list of eight names from a cover page | There is little typing for a conversion to save | Spell each name back against the page |
| Six dates and three amounts from a sixty-page lease | You need values, not text | Record the page each value came from |
| A faint carbon copy or a late-generation fax | Recognition is weaker on faint print | A person may also be guessing; note illegible passages |
| A form crowded with stamps and margin notes | Marks overlap the print | Transcribe print and annotations separately |
| A verbatim transcript for filing or exhibit | It needs conventions such as "[illegible]" that a person applies | Do not correct the original's mistakes |
| A document under a restriction on where it may be sent | The restriction, not the technology, decides | Read the order, agreement or firm policy that applies |
For the short-list case there is a fuller treatment of the break-even point in the section on when retyping a short list is faster than OCR into Excel.
Typing still starts from an image when the paper is elsewhere, so scan quality matters to the typist too. A person reading a blurred page on screen is exposed to every slip a typist makes, and to guessing as well.
Does recognized text need less proofreading than typed text?
Recognized text does not need less proofreading than typed text. It needs different proofreading. Both must be compared with the original before anyone relies on them, and the comparison should aim at the errors that method produces.
What to aim at:
- In typed text, look for what is absent or reordered: count paragraphs and list items against the source, read every number digit by digit, and check that repeated phrases appear as many times as they do on the page.
- In recognized text, look at shapes: characters that resemble each other, punctuation inside numbers, the sequence of columns, and any region of the page that was faint, stamped or tilted.
Schema Law's home page says recognition is strongest on clean print and weaker on handwriting, and that nothing marks a passage as uncertain. So the output will not point you to its own weak spots. The page image has to do that: where the image looks poor, read the text closely.
Whichever route produced the text, sort its contents by what an error would cost:
- Check every instance: names of parties, dates, amounts, account and case numbers, citations, and any language you will quote.
- Check a sample: running prose that will only be searched.
- Record the check: who compared what against which copy, and when.
The step-by-step method for the comparison itself, including how to split the work between two people, is in the section on proofreading OCR output against the original.