Old plans and poor scans: what OCR can and cannot do

OCR (optical character recognition, in German Texterkennung) works best on clean print at good resolution. In my own test on invoices, which nobody has checked independently, a vision model reached 99.85 per cent character accuracy and standard OCR 64.2 per cent. For plans, handwriting and your own scans that figure says nothing, and there a spot check decides.

Two ways to read a scan

Classic OCR recognises characters image by image and assembles lines from them. A well-known free example is Tesseract. Its documentation says openly what it was built for: by default it is designed for continuous sentences. It works best from 300 dpi. If a page is too skewed, the quality of line recognition drops noticeably. The software cannot remove certain kinds of noise, and it easily reads dark scan edges as characters.

A vision language model looks at the page as an image and reads it in context. In my assessment this helps with columns, tables and labels, because the surroundings of a figure are seen as well. Between the two lie services for layout analysis. Microsoft describes them as a combination of OCR and models that extract headings, headers and footers, tables and figures as structure.

Which way suits you depends on your archive. An archive of clean letters can cope with simple OCR. For mixed collections with tables and forms, a model that sees the context can be worthwhile. What it costs per page and what it brings is best measured in a pilot on your own documents.

My test on invoices

I measured both ways against each other on invoices. The vision model reached 99.85 per cent character accuracy, standard OCR 64.2 per cent. Both values come from my own test, which nobody has checked independently. It covered invoices only. The number of invoices and the programmes used are not published here, so the figure cannot be reproduced from outside. It cannot be generalised, and certainly not to plans. How a better prepared classic OCR or another type of document would perform, the test does not show.

To put it in perspective, a calculation with invented figures: if a page has 2,000 characters, then at 99.85 per cent three wrong characters remain, in arithmetical terms. If one of them is in a dimension, a quantity or an amount, the statement is wrong even though the page was read “almost perfectly”. Where figures matter, high character accuracy alone does not help.

Where the limits lie

The following statements come from the vendors’ documentation (as of November 2026). In the documentation of its vision feature, Anthropic writes that the model can hallucinate or make errors with low-quality, rotated or very small images (under 200 pixels). Location information in the image is only approximate. Heavy JPEG compression can make text hard to read. For its Read service, Microsoft names a minimum text height: 12 pixels for an image of 1,024 by 768 pixels, which corresponds to about 8 point at 150 dpi. The service recognises handwriting only in the supported languages.

For construction documents this means:

How well this works on your plans, I have not measured. The rows on title blocks and dimension chains are my assessment, based on the vendor statements above and on how such plans are built, not a measurement result.

A second risk concerns vision models. In its documentation, Anthropic speaks of hallucinations: with a poor source, a model can deliver text that sounds plausible but is not in the image. This does not stand out while reading, which is why a comparison with the original is needed.

What you can influence before scanning

A large part of the quality is created before any software runs. The Tesseract documentation advises at least 300 dpi, straight pages and removing dark scan edges. Microsoft asks for a clear photo or a high-quality scan per document and names the minimum text height of about 8 point at 150 dpi. Anthropic points out that heavy compression makes text hard to read and that very large images may be reduced in size before processing, which makes small print less legible.

For your existing archive this means: first check what already contains text. PDFs exported directly from Word or from a planning programme often carry the text already, and a test by selecting a sentence is enough. Only pure image scans need OCR. For important, badly scanned plans, a new scan can make more sense than a correction afterwards. Why the text has to be there for a searchable archive is explained in Making project files searchable.

Why spot checks remain

A fixed procedure follows from this. Before reading in an archive, you draw a sample from each type of document, as a starting assumption about 20 pages per type. You place the recognised text next to the original and compare figures, dimensions, dates and plan statuses. You write down the errors, sorted by kind and document type. From that you can see where a better scan, a different method or an obligation to check is needed.

Microsoft’s Read service returns a confidence value for every recognised word. Such values can be used to present uncertain passages for checking. They are an indication, not proof, and they do not replace the spot check.

In operation the original stays accessible. Every hit in a knowledge base names the document and page, and anyone who wants to use a figure reads it on the scan.

What you can do now

1. In ten PDFs from your archive, select one sentence. If that is not possible, the scan is a pure image without a text layer.
2. Rescan three originals (a letter, a table, a plan) at at least 300 dpi and compare them with the old scan.
3. Run a small test of your own: have a page recognised, lay it next to the original, compare figures and dimensions, count the errors.
4. Decide which details are never used without a look at the original: dimensions, amounts, deadlines and plan statuses.