The OCR commercial real estate teams rely on is a pixel-matching process, not a reading process, and that distinction is where scanned offering memorandums go wrong. Optical character recognition analyzes the shapes of marks on a page and predicts which characters they represent. On a clean, native PDF it is close to perfect. On a scanned, faxed, or photographed offering memorandum, character accuracy can fall from 99% to the high 80s, per docuclipper and OCR benchmark data, and the errors land in the worst possible place: numeric fields and tables. A 5 read as an S is harmless in a tenant name and catastrophic in a rent figure. The problem was never getting text off the page. It is knowing which of the extracted numbers to trust.
Key Takeaways
OCR character accuracy on clean printed text runs 97 to 99%, but a document that has been faxed and re-scanned can drop to about 88%, per docuclipper and 2025 OCR benchmarks.
Scan resolution below 300 DPI causes a measurable accuracy drop, with some studies putting degradation at 20% or more for poor scans. A page skewed even 5 degrees loses 3 to 8% for traditional OCR engines.
OCR reliably confuses 0 with O, 1 with l, 5 with S, and rn with m. In a tenant name these are cosmetic. In a rent roll they are wrong dollar values.
Tables are the hard case. Standard OCR returns unstructured text, not analyzed data, and merged cells and multi-column layouts get scrambled, per Nanonets and PRODA.
The fix is not a better OCR engine. It is confidence scoring plus source citations, so a suspect number is flagged and verified against the original page instead of trusted blind.
How Accurate Is OCR on Scanned Real Estate Documents?
OCR accuracy on scanned real estate documents depends almost entirely on scan quality, ranging from 97 to 99% character accuracy on a clean 300 DPI scan down to the high 80s on a degraded one. Per docuclipper's benchmark data, a clean original scanned at 300 DPI might reach 99% character accuracy while the same document faxed and re-scanned drops to about 88%.
That range matters because an offering memorandum is rarely a clean original. It is often a PDF of a scan of a printout, sometimes a photograph, sometimes a document that has passed through a fax at some point in its life. Each degradation compounds. According to 2025 OCR benchmarks, resolution below 300 DPI causes a measurable accuracy drop, with some studies putting degradation at 20% or more for poor scans, and a page skewed even 5 degrees loses another 3 to 8% on traditional engines. A rent roll buried on page 40 of a memorandum that has been scanned twice is squarely in the low-accuracy regime, and it is also the single page an underwriter most needs to be right.
Document condition | Typical character accuracy | Source |
Clean native or 300 DPI scan | 97 to 99% | docuclipper, 2025 OCR benchmarks |
Faxed and re-scanned page | ~88% | docuclipper |
Below 300 DPI resolution | Drop of 20%+ in degraded cases | 2025 OCR benchmarks |
5-degree skew | Additional 3 to 8% loss | 2025 OCR benchmarks |
Which OCR Errors Cost the Most on an Offering Memorandum?
The costliest OCR errors are character substitutions in numeric fields, because they turn a wrong guess into a wrong dollar value. OCR analyzes pixel patterns, and when characters share shapes it guesses. The reliable confusions, per multiple OCR error guides, are 0 with O, 1 with l, 5 with S, and rn with m. In prose these produce typos. In a rent roll they produce false numbers.
Consider the mechanism on the fields that drive underwriting. A monthly rent of $5,100 read as $S,100 fails loudly and gets caught. The dangerous version is subtler: a unit count where a 1 becomes a 7 because of a stray pixel, or a $1,050 read as $1,05O so the parser drops a digit, or a square footage where a smudge turns 21,500 into 2,500. As one OCR analysis puts it, lookalike characters like 5 and S, 0 and O, 1 and l are not cosmetic errors; on financial documents they represent wrong values. The error does not announce itself. It flows into the in-place income line, then the net operating income, then the valuation, carrying no flag that anything is wrong. This is why raw OCR output on a financial document is a liability until every number is either verified or scored for confidence.
Why Do Tables Break OCR More Than Text?
Tables break OCR because OCR extracts characters, not structure, and a rent roll is nothing but structure. Standard OCR tools return unstructured text, not analyzed data, per Nanonets, so a table becomes a stream of values with no reliable sense of which number belongs to which row and column. Merged cells, multi-column layouts, and stacked headers scramble that stream further.
The failure is worse than a wrong character because it is a wrong association. Suppose a rent roll has columns for unit, tenant, square feet, monthly rent, and lease expiration. When OCR loses the column boundaries, a monthly rent can land in the square-feet position, or a lease-expiration date can attach to the wrong tenant. Every individual number might be read correctly and the table can still be wrong, because the values are assigned to the wrong fields. PRODA notes that extracting information accurately from tables embedded in PDFs requires specialized parsing to understand table structure and retrieve cells correctly, and that tools like ABBYY FineReader or Adobe Acrobat deliver unstructured text you still must parse, organize, and validate by hand. A misread character is a one-cell error. A misread table is a systematic one, and it hides because each cell looks plausible on its own.
Table failure | What goes wrong | Why it hides |
Lost column boundaries | Values land in the wrong column | Each number is individually valid |
Merged cells | One value splits across rows or drops | Row counts still look right |
Multi-column page layout | Reading order scrambles across columns | Text is present, just reordered |
Stacked or multi-row headers | Columns mislabeled or misaligned | Header looks readable at a glance |
How Do You Catch OCR Errors Before They Reach the Model?
You catch OCR errors by never trusting a raw extracted number, and instead scoring each field's confidence and grounding it to the source page so a suspect value is flagged and verified rather than believed. The catch cannot be a human re-reading every figure; at deal volume there is no time. It has to be built into the extraction so that the low-confidence numbers surface themselves.
Three controls do the work. First, confidence scoring per field, so a value the engine was unsure about, exactly the 5-versus-S guesses, routes to review instead of flowing through silently. Second, source citation, where every extracted number links back to its page and coordinates so a reviewer confirms it against the original in seconds rather than hunting through 60 pages. Third, cross-field validation, where extracted numbers are checked against each other: unit rents that do not sum to a stated total, or a square footage that implies an implausible rent per foot, get flagged as internal contradictions. As a principle to hold: OCR was never the hard part, and the discipline that makes it safe is refusing to treat any extracted number as true until it is either scored or checked against its source. Modern intelligent document processing raises the automation ceiling not by reading pixels more cleanly but by understanding context and relationships that plain OCR cannot, per practitioner accounts, which is what lets the suspicious minority of fields be caught instead of trusted.
Frequently Asked Questions
How accurate is OCR on scanned commercial real estate documents? OCR character accuracy runs 97 to 99% on a clean 300 DPI scan but can fall to about 88% on a faxed and re-scanned page, per docuclipper. Resolution below 300 DPI and page skew degrade it further. Because offering memorandums are often scans of scans, the rent roll page an underwriter most needs is frequently in the low-accuracy range.
What does OCR most often get wrong on an offering memorandum? OCR most often confuses visually similar characters such as 0 with O, 1 with l, 5 with S, and rn with m, and it scrambles table structure by losing column boundaries and mishandling merged cells. On financial documents these are not typos; they produce wrong dollar values and misassigned rows in a rent roll.
How do you catch OCR errors before they reach an underwriting model? Catch them with per-field confidence scoring, source citations that link each number to its page, and cross-field validation that flags internal contradictions like unit rents that do not sum to the stated total. These controls surface the suspicious minority of fields for review instead of letting every extracted number flow through unchecked.
Conclusion
OCR in commercial real estate is a guess about pixels, and on a scanned offering memorandum it guesses wrong exactly where the money is: the numeric fields and the tables. The technology got the text off the page decades ago. What it never did was tell you which of its guesses to trust, and on a degraded scan a wrong number arrives looking identical to a right one.
The operator takeaway is to stop asking whether an OCR engine is accurate and start asking whether its output is checkable. Accuracy is a property of the page you happened to receive. Checkability is a property of the workflow you built. A number that carries a confidence score and a link to its source page can be verified in seconds and caught when it is wrong. A raw number that flows straight into the model carries its errors invisibly into the valuation. Firms that treat extracted numbers as claims to be verified catch the misreads. Firms that treat them as facts inherit them.
Related
OCR
The Rent Roll Is the Most Under-Analyzed Document in the Deal