To scan a spreadsheet into Excel, lay the printout flat and square on the glass, scan at 300 DPI in greyscale, and run the image through table OCR. The values come back, but the formulas do not: a printout holds only results. You rebuild each total with a SUM and compare it with the printed figure to catch misreads.
Keeping a printed spreadsheet square on the scanner glass
A printed spreadsheet converts best when its grid lines sit exactly parallel to the scanner edges. OCR builds rows by following straight lines, so a sheet tilted by a couple of degrees can push the right-hand cells of one row into the row below. Squaring the page takes seconds and saves most row errors.
On a flatbed, push the top edge of the paper against the ruler at the back of the glass, then close the lid gently so the page does not slide. If the printout is larger than the glass, as A3 or tabloid sheets often are, scan it in two halves with a generous overlap and keep the same edge against the ruler each time.
On a phone, the scanner apps built into notes and file apps detect the page edges and flatten the perspective. They work well on a single sheet laid on a dark, plain surface. Hold the phone directly above the page, not at an angle, and let the app find all four corners before you capture. A spreadsheet has many fine lines, and keystone distortion from a tilted phone bends them more visibly than it bends normal text.
Two more habits help:
- Remove staples and unfold the page fully. A fold that crosses the grid creates a dark line OCR may treat as a border.
- Scan in greyscale. Pale gridlines and light shading on alternate rows often vanish in black-and-white mode, and the shading itself can turn into noise.
The settings that suit any paper page, such as resolution and file type, are listed in scanner settings that help Excel conversion.
Can OCR read the small print on a spreadsheet printout?
OCR can read small print on a spreadsheet printout if the characters are still a reasonable size in the scan. The trouble is that spreadsheets are often printed with "fit to page" turned on, which shrinks a wide sheet until its text is tiny. Below a certain size, digits blur together and the engine starts guessing.
A practical test is to zoom the scanned image until one row of digits fills the screen. If each digit has clear gaps around it and the loops in 6, 8 and 9 are open, OCR has enough to work with. If the digits touch or the loops are filled in, raise the scan resolution or reprint the sheet at a larger scale.
Reprinting is the better fix when you can. If you have access to the person who printed the sheet, ask for it again without fit-to-page, split across several pages at normal size. A larger font on more paper converts more reliably than a small font on one page, even though there are more pages to join afterwards.
When reprinting is not possible, scan at a higher resolution than usual, such as 400 or 600 DPI, for that one page. It produces a larger file and a slower conversion, but it gives the engine more pixels per character. Light grey text, which many spreadsheet themes use for notes and headers, is also worth checking separately, since it often comes back incomplete.
Spreadsheet printouts split across several pages
A spreadsheet that is wider or longer than one sheet of paper prints across several pages, and OCR returns each page as its own block. Long sheets split by rows, which stack back easily. Wide sheets split by columns, which is harder, because the second page has no row labels unless the author set them to repeat.
Rows first. If the printout repeats its header row at the top of every page, delete the repeated headers after conversion and stack the pages in order. If it does not repeat the header, the first row of each later page is data, so be careful not to delete it.
Columns are trickier. A page of columns H to N with no row labels gives you numbers without context. Match it to the first page by row position: row 5 on page two belongs with row 5 on page one, as long as both pages start at the same row. Check that assumption by finding a row with a distinctive value, such as a blank row or a subtotal, and confirming it sits at the same position on both pages.
Number the pages before you scan, in pencil, in the order they should be joined. Printers number pages "down then over" or "over then down" depending on a page setup option, and it is easy to stack the wrong pair once they are scanned.
If you would rather join pages with code, the same idea of stacking extracted blocks appears in extracting a PDF table into an R data frame, where each page becomes one block to bind together.
Rebuilding totals and formulas from a printed spreadsheet
A printed spreadsheet contains results, not formulas, so the scan gives you the number 4,830 where the original had =SUM(B2:B6). You rebuild each formula by hand, and in doing so you get a free check. When your rebuilt total matches the printed one, the cells above it were read correctly.
A worked example
The figures below are an example. A printed household budget has five lines and a printed total:
| Row | Item | Printed amount | Scanned value |
|---|---|---|---|
| 2 | Rent | 1,850.00 | 1,850.00 |
| 3 | Utilities | 214.60 | 214.60 |
| 4 | Groceries | 682.15 | 632.15 |
| 5 | Transport | 196.40 | 196.40 |
| 6 | Insurance | 141.85 | 141.85 |
| 7 | Total (printed) | 3,085.00 | 3,085.00 |
In the converted sheet, put a rebuilt total in an empty cell and a difference beside it:
D8: =SUM(D2:D6)
E8: =D7-D8
Here D8 returns 3,035.00, so E8 shows 50.00. The printed total is 50 higher than the sum of the scanned values, which means one value came back 50 too low. A gap that is a round multiple of 10, 100 or 1,000 usually points to one misread digit: here, an 8 in the tens place of Groceries read as a 3. Compare that row with the paper and correct it.
Do this for every printed total and subtotal. Then replace the hard-coded totals with your rebuilt formulas, so that the sheet works as a spreadsheet again. Percentages, averages and running balances can be rebuilt the same way, by writing the formula and checking one result against the printout.
Why do printed spreadsheet cells come back as text?
Printed spreadsheet cells come back as text when they carry formatting characters that Excel does not read as part of a number. Currency signs, thousands separators in the wrong style, percent signs, parentheses for negatives and trailing spaces can all turn a value into a string. Excel then leaves those cells out of any SUM.
Common examples, and what each becomes:
- "$1,214.00" usually converts, but a currency sign from another locale may not.
- "(214.60)" for a negative is read as a negative by some imports and as text by others.
- "12.5%" may arrive as text with the percent sign attached.
- "####" is what Excel prints when a column is too narrow to show its number. The scan has no number at all in that cell, and the only fix is the original or a reprint with wider columns.
- A dash for zero, which accounting formats print, comes back as a hyphen character.
Text numbers are easy to spot. They sit on the left of the cell, while numbers sit on the right. Select the column and use Find and Replace to remove currency signs or spaces, or use =VALUE() in a helper column. Printouts with notes in the margins, such as amounts written in pen, need a different approach, and what OCR can do with handwritten PDF pages explains the limits.
For pages that are mostly sentences or lists rather than a grid, such as a printed memo with a few figures, scanning text into Excel line by line is the closer fit.
When the original spreadsheet file still exists
If the original spreadsheet file still exists, scanning its printout is the slowest and least accurate way to get it back. The file has every formula, every unrounded value and every hidden column, while the printout has only what fitted on paper. Ask for the file before you reach for the scanner.
That applies even when the person only has a PDF. A spreadsheet saved or printed to PDF from Excel contains real text, not a picture, so it converts without OCR and without misreads. Check by trying to select a number in the PDF. If you can highlight it, the PDF has a text layer and you can convert it directly.
Scanning is the right choice for paper with no digital twin: old ledgers, printouts from a system that no longer exists, or a sheet someone has annotated by hand. If you need only a few figures from such a page, such as a total and a date, pulling single fields from a scanned PDF is faster than converting the whole grid.
For paper bank statements, the same logic holds: most banks let you download past statements as PDF, which reads cleanly. FastBankConvert is built to turn those PDFs into spreadsheet rows, and it is getting ready to open; the homepage has the details on joining.