Troubleshooting
Scanned vs text PDF bank statements: why rows go missing
A readable bank statement can still hold pictures of transactions or incorrect stored text. Before choosing OCR, try copying a transaction date, description and amount into a plain-text editor.
By AnyStatement
Published , 10 min read
Searching for a visible word is another check. If neither test works, copying permissions could be the reason, so don't call it a scan yet. Test pages with missing rows, compare their output page by page and recompute the balances.
Try this 60-second text check
Transaction pages matter here, rather than the cover or summary. Keep the original unchanged. This is quick triage, not a timed benchmark, full review, authenticity test or reconciliation.
The controls here follow Adobe Acrobat Reader desktop and Apple Preview (macOS 27 selected) documentation, opened on October 17, 2026. The OCR controls below are for Acrobat and may not be in Reader. QuickBooks references cover US Online, not Desktop, so check what's available in your account.
- In Reader, right-click → Select Tool, then drag across a transaction row and copy it into a plain-text editor. You're checking whether the date, merchant, minus sign and decimal mark match the page, so a pasted image doesn't count. See Adobe's copying guide, updated June 21, 2026.
- A short, distinctive merchant word is a better search target than a whole wrapped description. In Reader, right-click → Find; in Preview, use the toolbar search field. Check that the match is on the transaction page rather than a note or summary. See Adobe's Find instructions, updated June 21, 2026 and Apple's Preview search guide.
- In Reader, right-click → Document Properties → Security to read the Document Restrictions Summary. If copying is disallowed, a failed copy doesn't indicate a scan. The Fonts tab, Description and metadata offer clues, not a verdict.
- A later transaction page may behave differently, especially one missing from the spreadsheet. Try copying there too, and record any page and field that copies incorrectly.
Correct copied text only shows that your viewer can read text there. It doesn't prove the bank generated that text or another extractor can rebuild the rows. Scans can already have an OCR text layer, as Adobe describes in its scanned-document OCR guide, updated September 23, 2025. Apple also documents copying text from photos with Live Text. So selecting words in a photo doesn't prove it contains embedded PDF text.
Garbled characters point to a text-reading problem, not necessarily a scan. When copying is allowed but both tests fail on visible transactions, treat that page as image-only or unusable-text until another reading method tells you more.
File properties are clues, not proof
Adobe's document-properties guide, updated September 23, 2025 covers security, fonts and application metadata. If a creating application or PDF producer is recorded, a scanner name suggests checking image quality, while a PDF printer suggests requesting the bank's original. Neither proves how transactions are stored, and fonts may belong only to headings or OCR overlays.
File size won't settle it either: "large means scanned" and "small means text" aren't reliable rules. Adobe's scan settings, updated December 5, 2025 cover resolution, compression and the file-size/quality tradeoff. Size and producer hints help you decide what to check, but don't classify a scan or establish authenticity.
Opening passwords and copying restrictions are separate access problems, not evidence of scans. Reader's Security tab shows copying restrictions. If access is blocked, use your authorized password or ask the bank or owner for an accessible copy, rather than using OCR to bypass permissions. Don't post the password publicly.
Trace the missing rows back to the page
Where the output goes wrong can guide your comparison with the source page before you change anything. These are possible causes, not a diagnosis of your file:
- If nothing extracts, try copying a date and amount to check for readable text. Image-only pages need OCR or an original.
- When only some pages appear, the PDF may mix text and scans, or the reader may have skipped a table. That's why each missing page needs its own copy test and reading.
- If names copy but amounts don't, the amounts may be images or unusable text. Select them separately and compare a fresh reading.
- Rows that stop at a page break need a comparison of both edges before you repair the boundary and recount. Repeated headers, footers or carried-forward balances can interrupt tables or be misread as transactions.
- Blank-date descriptions may be wrapped text that became a separate row and was discarded during cleanup. Follow them on the source and join only proven continuations, rather than deleting all blank-date rows.
- If amounts land in the wrong columns, check the source headings before rebuilding the rows. Merged or shifted columns can replace amounts with balances, or leave no recognizable amount and lose the row.
- A missing sideways page may mean the reader couldn't handle its orientation. Inspect it and save an upright working copy.
- If digits or decimal marks disappear, zoom into the original image. Blur, faint print or compression may require a clearer source.
- If copying is disabled, check the Security tab and request authorized access.
Empty cells aren't the only warning: look for misplaced rows as well as missing ones.
OCR isn't always the problem. Microsoft's Power Query PDF connector documentation covers misidentified multi-line rows, page ranges and combining similar tables across consecutive pages. Use Transform Data in Power Query's Navigator to inspect the tables, and include every transaction page if you restrict the range. When characters copy correctly, table selection and row grouping are worth checking before rerunning OCR, because reading characters and rebuilding tables are different jobs.
Selecting one month's table proves nothing about the next, so check each month before appending its rows. The monthly PDF-to-Excel guide keeps that consolidation review separate.
A PDF can hold both text and scans
A file can mix text summaries, scanned transactions and text disclosures, and even a single page can have readable headings above a pictured table. That's why the copy test needs dates and amounts, not just the bank name. Label each page "text copied correctly," "image or unreadable text," or "no transactions." That last label requires looking at the page, not getting an empty extraction.
Compare the PDF page count with any printed "Page X of Y" sequence. If a transaction page is missing, request the complete statement, because no extractor can recover a page that isn't in the file.
OCR (optical character recognition) reads characters from images. A searchable scan can still have wrong dates, amounts, signs or row boundaries. Adobe's OCR route is All tools → Scan & OCR → In this file, where you select the page range and language, then Recognize Text. Being able to search the result isn't enough; accuracy and completeness need checking against the visible statement.
The image matters more than its filename. Check photos and flatbed scans for faint decimal marks, small digits and sideways text. With phone photos, also look for perspective, glare, shadows and cropped edges. Microsoft's Data from Picture guidance for Excel for Microsoft 365 calls for a head-on, focused image cropped to the data, followed by review and correction.
A fresh bank download is preferable to rescanning. If you must rescan, capture an upright, evenly lit page with every transaction, column heading, page number and statement balance visible. Adobe recommends 300 dpi for grayscale or color scans, but that's not an accuracy guarantee. Enlarging a blurred digit won't tell you what it was.
Keep the original separate from OCR or rotated copies, including the complete page if you crop a table. An illegible digit calls for a clearer statement, not a guess at the amount that would make the closing balance agree.
Compare the rows in printed order
OCR, text extraction and manually typed rows all need the same checks. Work with one account, currency and statement period in printed order, because reordering same-day rows can break the running-balance comparison without changing the total.
- Compare each page's transaction count with the output, excluding description lines, headings, subtotals and brought-forward balances. A transaction spanning two pages still counts once, with both pages noted.
- A missing row and a duplicate can leave the count unchanged, so match dates, descriptions, amounts, direction and printed balances too. Pay particular attention to the first and last transactions at every page break.
- Add signed transactions to the opening balance and compare with the printed closing balance. For the deposit account below, money in is positive and money out negative. Don't use available balance or count a summary total as a transaction. For cards, establish the card statement's sign convention separately.
- Starting at the opening balance, add amounts in source order and compare every printed running balance. A mismatch narrows your search to the rows since the last agreeing checkpoint. The missing row may be just before the mismatch, not where it appears.
Without printed running balances, there's no row-level arithmetic check. Without an opening or closing balance, you can't complete the statement equation either. Record that gap rather than inventing a balance. The statement balance checker can do the arithmetic, but can't count PDF transactions you haven't compared.
A missing fee and a reversed refund look different
This fictional USD deposit account isn't a customer statement or an OCR test. It has two transaction pages with two transactions each, an opening balance of 1,000.00 and a printed closing balance of 1,190.00.
| Page / row | Description | Amount | Running balance |
|---|---|---|---|
| 1 / 1 | Client deposit | +250.00 | 1,250.00 |
| 1 / 2 | Supplies | -75.25 | 1,174.75 |
| 2 / 3 | Refund received | +20.00 | 1,194.75 |
| 2 / 4 | Monthly fee | -4.75 | 1,190.00 |
The net movement is 250.00 - 75.25 + 20.00 - 4.75 = 190.00. Opening plus net movement is 1,000.00 + 190.00 = 1,190.00. Throughout this example, the difference means computed closing minus printed closing.
| Output problem | Rows | Computed closing | Difference |
|---|---|---|---|
| Fee omitted | 3 | 1,194.75 | +4.75 |
| Refund changed to -20.00 | 4 | 1,150.00 | -40.00 |
| Supplies -65.25; fee -14.75 | 4 | 1,190.00 | 0.00 |
With the fee missing, page 2 has one output transaction instead of two, and the 4.75 difference matches the fee. Running balances agree through the refund, but there's no final fee row, so check the bottom of page 2 before changing other amounts.
Reversing the refund leaves the correct row count, but changing positive 20.00 to negative 20.00 reduces the total by 40.00. Half the difference's magnitude points to the refund, where the running balance first disagrees. That's a clue, not proof, because multiple mistakes could cause the same difference.
In the last case, the supplies error adds 10.00 and the fee error subtracts 10.00. They cancel at closing, but the intervening running balances and source amounts reveal them. A zero difference doesn't prove dates or descriptions are right either. See why a balanced statement can still be wrong. Never add a balancing transaction to hide the difference.
Statement arithmetic only compares extracted amounts with printed balances. It isn't reconciliation, which compares statement activity with your ledger, or an authenticity check on the source itself. Passing the arithmetic check proves neither of those.
You may not need another converter
A native bank export covering the missing period is the first option to look for. If only a few legible rows are missing, typing and checking them manually may be worthwhile. QuickBooks Online may not need a separate converter either: Intuit's US help, updated August 24, 2026 documents English-language PDF and image uploads with side-by-side review and correction. Because some statements may be reviewed by its global experts, check the workflow and data handling before uploading client records. We didn't test a live QuickBooks import.
If you need a reviewable spreadsheet, try AnyStatement. Its repository code uses embedded text and chooses OCR pages by text quantity, unreadable characters and image coverage. Those checks can miss partly image-based tables or plausible but wrong text. OCR use appears as an informational issue, while source-linked rows and balance arithmetic help you review the result. They don't guarantee every transaction was found.
Read again with OCR ignores embedded text and sends every page as an image to the configured OCR provider. Try it when copied amounts or names disagree with the page, but don't expect a guaranteed repair. Export the current result and save review notes first: rereading discards the old result and saved edits before the new read succeeds. The API permits up to three forced all-page OCR reread requests per uploaded conversion, if OCR is available. Read again without OCR restores automatic text/scan selection. Despite the label, it doesn't disable OCR for pages classified as needing it.
Without an OCR provider, selected pages are reported as unread if other pages yield transactions. Otherwise, extraction can fail. The review screen shows reported unread pages and running-balance breaks, but hides individual low-confidence row flags when statement arithmetic reconciles. An unflagged row can still have wrong text or amounts, so recount pages and rerun the arithmetic after rereading. These are code-reviewed behaviors, not live OCR tests or accuracy measurements.
Don't import an incomplete file
Your review notes should stay with the complete original, identifying the account, currency, period, page numbers, copy-test results and image defects. Include matched transaction counts per page (continuations counted once), source-checked dates, descriptions, amounts and signs, the opening/closing check and any running-balance exceptions. Unreadable values and unavailable checks remain unresolved. Before uploading replacement rows, check for overlap with your ledger.
Unexplained missing rows or unreadable amounts mean the file isn't ready to import. Mark it incomplete until a clearer source lets you verify them. A missing balance check is a separate limitation, so record it and finish comparing source rows without inventing a balance.
If you need help, give the page number, expected and extracted counts, first mismatch and reading method. A public post should use a fictional reproduction, not your statement. The CSV pre-import checks come next, once the extraction is sound.
What we checked, and what we didn't
We opened every linked Adobe, Apple, Microsoft and Intuit source on October 17, 2026. Apple's pages showed no update date. Microsoft's update metadata gave October 9, 2026 for the PDF connector and June 25, 2026 for Data from Picture. These are metadata dates, not observed software release dates.
We checked the repository's PDF classification, extraction engine, reread API and review-screen code, and independently recalculated the fictional four-row example, every running balance and all three damaged variants with Python Decimal arithmetic. We didn't test a scan through an OCR service, measure accuracy, test viewer menus, upload to QuickBooks or test every operating-system/subscription combination. The example demonstrates diagnostic arithmetic, not vendor performance.