OCR demonstrations always use the same page: one column of black type on white paper, perfectly level, in one language. Real documents are photocopies of printouts, photographed on a phone at an angle, then stamped, signed and written on. The distance between those two pages is where a document reader earns its keep.
The AI Document Reader & Analyzer on my projects page extracts, analyses and summarises text from PDFs, images and other formats. Its case study sets out the order of work: OCR to turn pixels back into text, language processing to find structure, then summarisation. Each stage inherits the mistakes of the one before, and a summariser handed scrambled text does not complain. It writes a fluent summary of nonsense.
One check comes first: many PDFs were never scanned and already carry their text. Read that text layer directly. OCR is for when there is nothing else to read.
1. The page is crooked
The failure. Phone photos are taken at an angle, and scanned bundles include pages fed in sideways or upside down. OCR engines read along lines of text. When the lines slope, the engine breaks one line into fragments or reads across two as if they were one. A page fed in upside down produces gibberish, sometimes with surprisingly high confidence.
The recovery. Fix the picture before reading it. Check orientation page by page: try the four rotations and keep the one that yields the most real words. Measure the angle of the text lines and turn them level. For phone photos, find the corners of the paper and flatten the perspective. Then even out the lighting with a threshold that adapts across the page, so a shadowed corner is not read as a block of ink.
2. The answer is in a table
The failure. Invoices keep their important numbers in tables, often with no ruling lines. Plain OCR reads straight across, so description, quantity, rate and amount run together, and a description that wraps onto a second line pushes its tail into the next row. Every amount is still there. Which amount belongs to which item is gone.
The recovery. Keep the positions. OCR can return every word with its box on the page, and those boxes are the table: edges that line up form columns, shared baselines form rows, and a line with no amount beside it is usually a wrapped description from the row above. Then check it the way an accountant would. Line amounts should add up to the printed total, and every amount should parse as a number, grouped the Indian way (1,00,000) or the western way (100,000). A zero misread as the letter O is caught here or not at all.
3. The text runs in columns
The failure. Annual reports and newsletters set text in two or three columns. Read straight across and the first line of the left column joins the first line of the right, so every sentence becomes half of two different ones. Quieter, but just as damaging: a footer repeated on every page is seen a dozen times, and the summariser decides it matters.
The recovery. Work out the layout before the reading order. Find the blocks of text, decide which are columns, and read each top to bottom before moving right. Remove anything that repeats in the same place on every page, and rejoin hyphenated words. None of this is glamorous. All of it decides whether the summary makes sense.
4. Someone stamped it, signed it or wrote on it
The failure. A rubber stamp across printed text ruins both. A signature is transcribed as random letters. A handwritten "paid" in the margin is lost or spliced into a printed sentence, and it may be the most important word on the page.
The recovery. Colour helps more than people expect. Stamp ink is usually blue, red or violet over black print, so separating the colour channels can lift a stamp off the text beneath it. Handwriting belongs in its own region: read it with a model trained on handwriting, or flag it for a person, but never merge it silently into the print. For a signature, the useful output is "signature present", not a transcription.
5. It changes language halfway down
The failure. Bilingual letterheads and forms printed in two scripts are ordinary in India. An engine set up for English reads Devanagari as a jumble of Latin lookalikes, or as nothing. Names written in two scripts stop matching, so one party appears twice in the analysis under two spellings.
The recovery. Detect the script block by block and read each with a model for that language, or one trained on several. Carry each passage's language forward to the later stages, and leave names untranslated. Then measure: when the share of recognisable words in a block falls, or the engine's own confidence drops, treat that block as unread rather than read badly.
Where a person still has to look
All five recoveries reduce errors. None reduces them to nothing, and a reader should be designed on that assumption rather than embarrassed by it. I hold every model I put into production to the same standard: a defined behaviour for when it is wrong, because sometimes it will be.
A person should still check any number that will be paid or filed, anything marked low confidence, anything handwritten, and any summary of a clause where one "except" changes the meaning. Summaries are good at the gist and poor at exceptions, and agreements live in their exceptions.
What makes checking fast is tying every extracted value to the place on the page it came from: select a figure, see the patch of scan behind it, confirm or correct. The person's job changes from re-typing the document to glancing at it, which was the point all along. If someone in your office re-types the same PDFs every month, send me a sample.
