Good tax source document scanning gives OCR software a flat, sharp, complete page: 300 dpi, color or grayscale, saved as PDF, with every back page included and nothing cropped. Phone photos work when the page is flat, evenly lit and filling the frame. Handwritten forms can be read, but expect more fields that need a person to confirm.
Scanner settings for tax source documents
Scanner settings for tax source documents decide how much detail reaches the OCR step. Optical character recognition (OCR) is software that turns an image of text into characters a computer can use. The aim is a file sharp enough to tell a 3 from an 8, small enough to email or upload, and complete down to the last back page.
Most office scanners offer the same handful of choices. The table below gives a sensible starting point for tax forms and statements and the reason for each choice. These are working defaults, not an IRS requirement.
| Setting | Recommended choice | Why |
|---|---|---|
| Resolution | 300 dpi | Small box text and code letters stay sharp; higher settings grow the file without much gain for printed forms |
| Color mode | Color or grayscale | Shaded boxes and colored form backgrounds can turn black in pure black-and-white, hiding numbers |
| File type | PDF, one file per document | PDF keeps pages together and in order; image files split one form into loose pictures |
| Duplex | On | Back pages of statements and K-1 attachments are captured without a second pass |
| Blank page removal | On, with a check | Saves pages, but confirm it does not drop a faint page |
| Auto-rotate and deskew | On | Upright, straight pages read better and are easier to review |
Resolution and color
Resolution is the setting most often set wrong. A scanner left at 150 dpi to save space can blur the small type in W-2 Box 12 or the transaction rows of a brokerage statement. Going far above 300 dpi rarely helps a printed form and makes files slow to upload.
Black-and-white mode is the other trap. Many tax forms print boxes on a tinted background. A black-and-white scan can turn the tint into solid black or wash out light numbers entirely. Grayscale keeps the contrast without the size of full color.
Duplex and back pages
Double-sided scanning matters more than it looks. The IRS General Instructions for Forms W-2 and W-3 (2026) note that Copy B of the W-2 carries a notice on its back. Brokerage statements and K-1 attachments often continue on the reverse side. A one-sided scan of those pages loses figures without any sign that something is missing.
Can clients photograph tax source documents with a phone?
Clients can photograph tax source documents with a phone, and the result is usually readable. What ruins a phone photo is the setting, not the phone: shadows across the page, glare on glossy paper, a curled form, a tilted angle or a crop that cuts off a box. A scanning app that saves PDF beats the plain camera.
A phone camera has plenty of resolution for a tax form. The problems are physical. A form held in one hand bends. A desk lamp throws a shadow across Box 1. A glossy statement reflects the ceiling light straight over the total. Each of these hides the very digits OCR needs.
Five-point phone-photo checklist
Send this list to clients before tax season. It fits in a text message.
- Flat on a dark surface. Lay the page on a table, not a lap or a hand, with a plain background around it.
- Even daylight, no flash. Light from a window or overhead light, with no shadow from the phone or your hand.
- Straight above. Hold the phone parallel to the page, so the edges look square, not like a trapezoid.
- All four corners in frame. Every edge of the page shows, with a little space around it.
- Every page, front and back. Photograph each side that has printing, in order, and send them together.
Clients who follow those five points send pages most readers can handle. The client-facing version, with more on scanning apps, is in how to scan tax documents with a phone. How the photos reach the firm, by upload link or email, is covered in the client document collection category.
Handwritten tax forms and OCR: what to expect
Handwritten tax forms can be read by OCR, but less reliably than printed ones. Printed digits look the same on every copy; handwriting varies by writer, pen and how neatly the boxes were filled. Expect handwritten fields to come back with lower confidence and to need a person to confirm them more often.
Handwritten forms still show up every season. A household employer may fill in a W-2 by hand. A small business may hand-write 1099s for a few contractors. Clients sometimes write figures on a printed organizer or add a note in the margin of a statement.
Several things make handwriting harder to read. Digits like 1 and 7, or 4 and 9, look alike in some hands. Amounts that run past the box edge get cut off or merged with the next field. Corrections written over earlier figures leave two numbers in one box. Pencil and light ink fade on a scan.
The practical response is to sort handwritten pages out early. Treat them as a separate pile that always gets human review. Where a handwritten form has a check built in, use it. On a W-2, for example, Box 4 social security tax should be 6.2% of Box 3 social security wages under the W-2 instructions, which lets a reviewer test a doubtful digit quickly.
Better scanning helps handwriting more than it helps print. Use 300 dpi, grayscale and good light, because faint pencil disappears first. Why a form's boxes and codes make OCR harder than ordinary text, whether printed or handwritten, is explained in the post on why tax document OCR is harder than plain text OCR.
Should tax source document scans be one PDF per form or per client?
Tax source document scans work best as one PDF per form. A file per form keeps each document's pages together, makes a missing or duplicate form obvious, and lets OCR software read each file against the right form type. One PDF per client is easier to send, but it pushes the splitting work onto whoever opens it.
A single client PDF is common because it is simple. A client puts a stack in a scanner feeder and presses one button. The result is one file with a W-2, three 1099s, a 1098, a property tax bill and a few blank pages, often in random order.
That file has to be split before anything else can happen. Someone, or some software, has to find where each document starts and ends, decide what it is, and drop the blank pages. If a form's back page ended up at the end of the file, it has to be reunited with its front.
One PDF per form avoids all of that. The firm can see at a glance that six forms came in. A second copy of the same W-2 stands out as an extra file. Each file can be named by form, issuer and year, which keeps the client folder tidy.
A sample batch, before and after
Here is a fictional client, the Varga household, whose scanner produced one 14-page file called scan_0412.pdf. Opened page by page, it held:
| Pages | What they were |
|---|---|
| 1 to 2 | W-2 from Westbrook Logistics, front and back |
| 3 | Blank |
| 4 | 1099-INT from Example Community Bank |
| 5 to 10 | Consolidated brokerage statement from Example Securities |
| 11 | W-2 from Westbrook Logistics, a second scan of page 1 |
| 12 | 1098 from Example Home Loans |
| 13 | Blank |
| 14 | Back page of the brokerage statement, scanned out of order |
Split one file per form, the same batch becomes four documents: 2026 W-2 Westbrook Logistics.pdf, 2026 1099-INT Example Community Bank.pdf, 2026 Consolidated 1099 Example Securities.pdf with page 14 moved back into place, and 2026 1098 Example Home Loans.pdf. Page 11 is set aside as a duplicate, and the two blank pages are dropped. The four files tell the reviewer what arrived; the single file did not.
When one file per client is fine
Splitting is a solved problem for software that classifies pages. Schema CPA classifies every page of an upload by document type, issuer and period, so a single 40-page client PDF still comes out as a list of separate forms. The document categories on the homepage show the forms it recognizes. For firms that split by hand, naming and folder conventions are covered in the organizing client files category.
Tax source document scanning errors that ruin a read
The tax source document scanning errors that ruin a read are physical ones: cropped boxes, skipped back pages, faint copies, glare and pages fed crooked or upside down. Each removes information OCR cannot recover later. Catching them at the scanner costs seconds; catching them at review means asking the client to send the page again.
Cropped boxes
A crop that cuts off the edge of a form often removes the employer's EIN, a state line or the last digit of an amount. The scanner's auto-crop can do this on its own when the page sits near the glass edge. Leave a margin around every page.
Skipped back pages
A one-sided scan of a double-sided document loses the back. On a K-1, that can mean a missing statement, and coded amounts with no detail behind them. Why those statement pages matter is covered in K-1 OCR on the face page versus the supplemental statements. Check that every statement a K-1 refers to is in the file before the scanner is put away.
Faint copies
A photocopy of a photocopy loses contrast with each generation. Light gray digits on a light background are where OCR guesses wrong. Ask clients for the original or a fresh PDF from the issuer's portal whenever a copy looks washed out.
Glare and shadows
Glossy paper reflects light. A bright streak across a statement can hide a balance completely. Tilt the page or move the light rather than the phone.
Crooked or upside-down pages
Most readers handle mild tilt, and many auto-rotate. Pages fed at a steep angle or mixed upside down still cause trouble, especially for tables of transactions where rows must line up. Turn on deskew, and check the first and last pages of each batch.
After the scan
Once the pages are clean, the next step is reading the boxes. The post on tax document OCR covers how readers handle tax forms and which checks catch misreads, and W2 OCR walks through pulling every W-2 box into a spreadsheet.