What OCR is, and what it isn't

Optical character recognition takes an image that happens to contain text (a scanned page, a photo of a receipt, a picture embedded in a PDF) and produces the text itself: characters a computer can search, copy, index, and feed into other software. Before recognition runs, a scan is only pixels; afterward, the same page is data.

The phrase OCR scanning blurs two different steps. Scanning produces the image, and OCR reads it. That is why you cannot select text in most scans: the scanner gave you a photograph of a document, and nothing has recognized the characters in it yet.

An OCR engine is the component that performs the recognition, while OCR software usually means an engine wrapped in everything around it: file handling, an interface, export formats. The best-known open source engine is Tesseract, which started at HP, was later maintained by Google, and ships under the Apache 2.0 license; in Python it is most often driven through the pytesseract wrapper.

Most engines split the job into three stages. Layout analysis decides which regions of the page hold text and in what order to read them. Detection finds the lines and words inside those regions. Recognition then turns each detected fragment into characters, usually with a confidence score attached to each word.

Classical engines matched character shapes against stored patterns and hand-built features, which held up on clean print and degraded fast on anything else. Current engines use neural networks that read whole lines in context: Tesseract switched to an LSTM-based recognizer in version 4, and commercial cloud engines run larger models built on the same general idea.

The practical consequence is that recognition on decent input has become the easy part. Print a paragraph, scan it flat at a reasonable resolution, and nearly any current engine reads it correctly. The interesting failures live elsewhere.

Suppose an engine reads a bank statement perfectly, every character correct. What you hold is still a long run of text: dates, descriptions, and amounts in reading order, with nothing marking which amount belongs to which transaction, or whether a given number is a debit, a credit, or a balance. Perfect recognition, zero structure.

Getting from recognized text to usable data takes layout parsing, field identification, and validation: deciding that this token is a date, that this column holds withdrawals, and that the figures ought to reconcile. This second half is where document extraction tools genuinely differ, because the first half increasingly does not.

It is also where trust gets decided. A recognizer that is right most of the time is dangerous precisely when its output lands in a spreadsheet nobody rechecks; the systems worth using are the ones that know when they are unsure and say so.

LedgerBox is the second half built on top of the first. Its extraction is OCR-backed rather than template-matched, so it reads PDFs and images of bank and brokerage statements, invoices, receipts, pay stubs, purchase orders, W-2s, 1099s, checks, and merchant statements without a stored layout for each one.

What comes back is structured rows, and the structure is checked before it is trusted: on a bank statement, debits, credits, and running balances must add up before the document is marked clean, and any row the extraction cannot read with confidence arrives flagged for a person to confirm rather than quietly filled in. Results export to Excel, CSV, QuickBooks formats, and JSON, or flow out through the REST API and the open source TypeScript SDK.