OCR PDF to Excel: How Text Recognition Builds Columns

OCR PDF to Excel conversion works in two stages. Optical character recognition (OCR) first reads the picture of a page and turns the shapes into characters. A table step then sorts those characters into rows and columns. Both stages guess, so printed numbers come out mostly right and still need a check.

What OCR reads on a scanned PDF page

OCR sees a grid of pixels, nothing more. A scanned PDF holds one picture per page, with no text inside it, so the software must find the lines of print, cut them into characters and name each character. The result is text plus a position on the page for every word.

A normal PDF made by a bank's computer is different. It stores the characters themselves, each with a position, and a converter only has to read them back. A scan stores a photograph of those characters. If you are not sure which kind you have, the ten-second test for image PDFs settles it.

The steps OCR takes on one page

Most OCR engines follow the same order, whatever the brand:

1. Clean the image. The engine straightens a tilted page, removes speckle and turns grey or colour pixels into plain black and white.
2. Find the text areas. It separates print from blank margin, logos and ruled lines.
3. Cut lines and characters. It splits the print into lines, then into single glyphs, the shapes of letters and digits.
4. Name each glyph. It compares each shape with what it has learned and picks the most likely character.
5. Check against context. Many engines use a dictionary or language model to fix doubtful letters. That helps with words and does very little for account numbers or amounts.

Step 5 matters for statements. A word such as "SUPPLY" can be rescued by context, because only a few real words look like it. The string "4,812.60" cannot, because every digit is plausible. OCR on figures leans almost entirely on the shape of the glyph.

What OCR does not see

OCR returns characters and positions. It does not know that one number is a debit and the next a balance. It does not know a page is a bank statement. Colour, a faint watermark, a stamp or a handwritten note either vanishes or becomes stray characters. Anything you must keep from such marks has to be checked on the page.

From recognized words to OCR table columns

OCR puts words into columns by comparing their positions. Words whose left or right edges line up down the page form a column. Words that share a height form a row. The engine has no concept of "date column"; it sees a stack of words at the same horizontal spot and calls it a column.

Rows come from height, columns from alignment

Row detection is the easier half. Words printed on one baseline belong to one line. Trouble starts when a description wraps to a second line, because the second line sits at a new height and may look like a new row with only a description filled in.

Column detection looks for vertical gaps. If every row on the page has a clear empty strip between the description and the amount, that strip is a column boundary. Numbers help here, because amounts are usually right-aligned, so their right edges form a clean vertical line even when the lengths differ.

Where column building goes wrong

• Narrow gaps. A long description that runs close to the debit column can be read as part of the amount cell.
• Right-aligned text under left-aligned headers. The header "Amount" may sit left of the numbers below it, so the engine has to trust the numbers, not the label.
• A skewed scan. If the page is tilted, a column drifts sideways down the page, and the lower rows land one column over.
• Blank cells. A debit row has nothing in the credit column. With nothing to anchor it, the engine can slide the single amount into the wrong column.

The last one is the common source of a debit that turns into a credit. How a bank statement parser finds the transaction table covers the layout side of that problem, including how a parser uses the header row to fix where each column sits.

How accurate is OCR on printed numbers?

OCR is accurate on clean printed numbers and less accurate as quality drops, but no honest single figure exists. Accuracy depends on the engine, the font, the scan and the page. The practical answer is to assume a few digits in a long statement may be wrong and to check for them every time.

Why a small error rate is still a problem

A converter that reads 99 of every 100 characters correctly sounds good. On a page with 60 transaction lines of about 20 characters of figures each, that rate leaves around a dozen wrong characters, and a wrong digit in an amount changes the money. Text errors are annoying but harmless. A number error is wrong silently, because "4,812.60" and "4,812.80" both look like real amounts.

That is why the sensible target is not zero errors but zero undetected errors. A statement gives you a way to get there. Opening balance plus credits minus debits must equal the closing balance, and on statements with a running balance column every line must follow from the one above it. A misread digit breaks that arithmetic. The digit errors that OCR makes on bank statements lists the usual pairs, such as 1 and 7 or 5 and S.

What you can control

Four things move accuracy more than the choice of engine:

• Resolution of the scan. The settings that help are in the scanner settings guide.
• Page condition. A flat, clean, upright page reads better than a creased one.
• A single page per image. Two pages on one sheet confuse column detection.
• The original. A laser print reads better than a faded copy of a copy.

Fonts and print quality that trip up OCR

Fonts and print quality trip up OCR when two glyphs look alike or when ink is too light, too heavy or too broken to show the shape. Statement paper adds its own traps: dot-matrix print, thermal paper, tiny type, and stamps over figures.

Features that cause misreads

The cheapest fix is a better source

Before you tune anything, ask whether a cleaner copy exists. A bank can often send the statement as a PDF, which removes OCR from the job. If the paper is the only copy, scan it again at a higher setting and flat on glass before accepting a poor result.

Does OCR to Excel take longer than a digital PDF?

Yes. A digital PDF already contains its characters, so a converter reads them directly. A scan must be cleaned, cut into characters and recognized one glyph at a time, and every page does that work. The effect grows with page count, since each page is a full image to process.

What adds time

• Image cleaning and straightening, per page.
• Character recognition, which is the heaviest step.
• Large files. A scan at a high resolution is many times the size of the same page as text.
• A second pass for pages the engine flagged as uncertain.

FastBankConvert's own FAQ says the same in general terms: a typical digital statement is meant to take seconds, while long statements and scanned paper statements take longer, and the on-screen timer shows how long yours took. The product is getting ready to open, so join the list on the get started page if you want a trial when it does.

Time also depends on how many pages you send. A long scanned file is the case where one big upload becomes slow or fails, and converting large PDFs without timeouts is the place to read about splitting the work.

OCR confidence scores and when to distrust them

A confidence score is the engine's own estimate of how sure it is about a character or a word, usually a percentage. A high score means the shape matched one candidate clearly. A low score means two or more candidates were close. It is a hint, not a proof of correctness.

Why a high score can still be wrong

Engines are most confident about clean glyphs, and a clean "8" that was printed as "3" on a poor copy still looks like a clean "8". Confidence measures how well the picture matched a character, not whether the character matches what the bank printed. A confident wrong digit is the dangerous case, and no score will flag it.

A simple rule for when to check by hand

Check a value by hand when any of these is true:

• The score is low or the tool flags the cell.
• The amount is large. A mistake of a digit costs more on 12,480.00 than on 12.48.
• The row breaks the balance arithmetic.
• The cell holds a character that does not belong, such as a letter inside an amount.
• The value sits near a stamp, a fold or a page edge.

Do not rely on the flags alone. Spot-check a few random rows even when nothing is flagged, because the errors that matter are the ones the engine did not notice.

A worked example: one line, two scans

The same statement line was scanned twice. The values are made up for this example. The first scan was a clean 300 DPI greyscale copy, the second a skewed, faded copy.

The poor scan produced four faults on one line. The two letter-for-digit swaps leave text in cells that should hold numbers, so Excel will not add them. The swapped comma and period is worse, because "9.318,27" can be read as a plausible amount in another locale. In the clean scan nothing needs fixing, and the balance check passes at once. In the poor scan, the balance check fails on this row, which is exactly where you look first.

For a full step-by-step run from file to finished sheet, follow the guide to converting a scanned PDF to Excel. If your source is a photo or screenshot instead of a PDF, image to Excel covers that route.