# Convert Scanned Table to Excel with Its Columns Intact

- Author: FastBankConvert (https://www.fastbankconvert.com)
- Published: 2025-07-24
- Updated: 2025-07-24
- Category: Scanned and image statements
- Canonical: https://www.fastbankconvert.com/blog/convert-scanned-table-to-excel

> Convert a scanned table to Excel with its columns intact: how ruled lines guide OCR, why borderless scans drift, and how to check each column.
To convert a scanned table to Excel with its columns intact, run the page through OCR that detects table structure, then check each column on its own. Ruled grid lines give the software clear cell borders. Borderless tables rely on gaps between words, so values drift into the wrong column, and those drifts are what your check should hunt for.

## How do ruled lines guide OCR on a scanned table?

Ruled lines are the printed borders between rows and columns, and OCR software treats them as a map of the cells. Before reading any text, a table-aware engine finds the long horizontal and vertical strokes, builds a grid from them, and then places each recognized word in the cell whose borders surround it.

That two-step order matters. Text recognition and cell placement are separate jobs. A table with a full grid lets the second job succeed even when the first one stumbles: a misread digit still lands in the right cell, so the column stays clean and the error is easy to find.

Grid lines help most when they are continuous and dark. Several things weaken them on a scan:

- **Faint or dotted rules.** Light grey lines can vanish in a black-and-white scan, leaving the engine to guess.
- **Broken lines.** A fold, a staple hole or a coffee ring that crosses a border can split one cell boundary into two pieces.
- **Skew.** A page scanned at a slight angle turns straight rules into slopes, and a cell border may cross the text it should separate. Straightening first is covered in [whether to straighten a scanned PDF before conversion](/blog/convert-scanned-pdf-to-excel#should-you-straighten-a-scanned-pdf-before-conversion).

Partial grids are common too. Many printed tables draw only horizontal lines under each row and none between columns. Those lines keep rows apart but say nothing about columns, so the column problem below still applies.

## Borderless scanned tables and drifting columns

A borderless table has no printed column lines, so OCR has to infer columns from the white space between words. Each vertical gap that runs down the whole table becomes a column break. When a long value crosses one of those gaps, or a short column has empty rows, the inferred breaks move and values drift.

Drift has a recognizable look in Excel. One row has its amount in the description column and an empty amount cell. Another row has a description split across two cells, with the second half sitting where a date should be. A run of rows near the bottom of a page shifts one column to the right, because a footnote or page number changed where the gaps appeared.

Several patterns cause most drift:

1. **Long descriptions.** A payee name that runs right up to the amount column closes the gap the engine needed.
2. **Right-aligned numbers next to left-aligned text.** The gap between them varies row by row, so one tight row can merge the two.
3. **Empty cells.** A column that is blank on most rows, such as a check number column, can disappear entirely and pull everything to its right one place left.
4. **Totals and subtotal rows.** These are often indented or bold, and their spacing differs from the data rows.

Some tools let you draw column boundaries yourself before extraction. On a borderless scan, that one step usually removes most drift, because the boundaries no longer depend on the spacing of each row. For background on how engines group words into columns, see [how recognized words become OCR table columns](/blog/ocr-pdf-to-excel#from-recognized-words-to-ocr-table-columns).

## Merged headers and wrapped cells in a scanned table

A merged header is a heading cell that spans two or more columns, such as "Amount" sitting above separate "Debit" and "Credit" columns. A wrapped cell holds text that runs onto a second line inside one row. Both confuse the row and column count, and both need a small manual repair after conversion.

Merged headers usually come out in one of two ways. Either the header text lands in the first of the spanned columns and the others are blank, or the engine creates an extra header row. Neither is a real error in the data, but it matters when you later turn the range into an Excel table or import it elsewhere, because each column needs one clear name. Rename the columns by hand to something like "Debit" and "Credit" and delete the spanning row.

Wrapped cells are more dangerous. A description that wraps onto a second printed line can be read as a new row with text in one column and nothing else. If that new row is not caught, the next real row is fine, but the sheet now has a phantom line. In a statement, that phantom line has no amount, so it can hide in plain sight. In a price list or inventory table, it may get a value from the row below and double count it.

Look for rows that have text in one column only and blanks everywhere else. Most are wrapped continuations. Join the text back into the row above with a formula such as `=A5&" "&A6`, paste the result as a value, and delete the extra row. The guide to [making a scanned PDF fully editable in Excel after OCR](/blog/convert-scanned-pdf-to-editable-excel) covers the wider cleanup that follows, such as numbers stored as text.

## A column-by-column check for scanned table output

A column check tests each column against the kind of data it should hold, instead of reading the whole sheet line by line. Dates should all be dates, amounts should all be numbers, and totals should add up. Each test takes seconds in Excel, and together they catch most drift, misreads and phantom rows.

The table below is a checklist. Use the rows that match your table's columns.

| Column type | What a clean column looks like | Quick check in Excel |
| --- | --- | --- |
| Date | Every cell is a real date, right-aligned | Filter for blanks, then use `=ISNUMBER(A2)` down the column |
| Description or name | Text only, no stray amounts | Sort A to Z and look at the top and bottom for numbers |
| Amount | Every cell is a number, two decimals | `=COUNT(C:C)` should equal the number of data rows |
| Reference or account number | Same length on every row | `=LEN(D2)` down the column, then look for outliers |
| Total or subtotal row | Equals the sum of the rows above it | `=SUM(C2:C40)` compared with the printed total |

Run the checks in that order. A drifted row shows up first as a non-date in the date column or a text cell in the amount column. Fix those rows, then run the totals check, because a total that still disagrees after drift is fixed points to a misread digit rather than a misplaced value.

Keep the scan open beside the sheet while you work. When a check flags a row, look at that row on the page before editing. Guessing from the sheet alone tends to introduce a second error on top of the first.

If the scan is a printed spreadsheet rather than a typeset table, the grid is often regular enough to work with, and [scanning a printed spreadsheet into Excel](/blog/scan-spreadsheet-into-excel) explains how to keep its rows square on the glass.

## Do long numbers from a scanned table survive Excel?

Long numbers from a scanned table often do not survive Excel's default handling. Excel keeps 15 digits of precision, as [Microsoft's Excel specifications and limits](https://support.microsoft.com/en-us/excel/excel-specifications-and-limits) state, so a 16-digit card or account number loses its last digit, and anything long enough appears in scientific notation, such as 4.11E+15. Leading zeros on reference numbers are dropped as well.

This is not an OCR problem. The engine may have read every digit correctly, and the damage happens at the moment the value enters a cell as a number. That is also why it is easy to miss: the scan was fine, the CSV file was fine, and the change happened when Excel opened it.

The fix is to treat identifier columns as text. When importing a CSV, set those columns to Text in the import step instead of General. When pasting, format the target column as Text first. Once a long number has been stored as a number, the lost digits cannot be recovered from the cell, so go back to the source file or the scan. The full set of ways to prevent this is in [how to stop Excel turning long numbers into scientific notation](/blog/stop-excel-scientific-notation).

Amounts are different. They should be numbers, because you will sum them. Only codes that you never do arithmetic on, such as account numbers, check serials, invoice IDs and postcodes, belong in text columns.

## When retyping a scanned table beats converting it

Retyping beats conversion when the table is small, the scan is poor, or the layout is irregular enough that cleanup would take longer than typing. Ten rows of three columns take a couple of minutes to type and leave no doubt. Running OCR, checking every column and fixing drift on the same table can take longer.

Other signs that typing is the better choice:

- **The scan is a phone photo taken at an angle**, with curved lines and shadows across the text.
- **The table mixes handwriting with print**, such as figures added in pen beside printed rows.
- **Every row has a different layout**, as in some forms where each line holds a different kind of entry.
- **You need only one column.** Typing twenty amounts is faster than extracting and cleaning six columns to keep one.

Conversion wins on volume. A bank statement with a hundred transaction lines across several pages is exactly the kind of regular, repeating table OCR handles well, and the running balance gives you a built-in check. FastBankConvert is built for that case: it reads statement PDFs, including scanned ones, which take longer than digital files, and warns you before download when balances do not add up. It is getting ready to open, and you can join through [Get started](/get-started).