Recognizing characters is only the first step. A usable statement export also has to place each amount in the correct Debit, Credit or Balance column. BankStatementMate therefore shows extracted rows for review and can stop on unsupported or ambiguous layouts.
When bank statement OCR is needed
A digital PDF normally contains selectable text. A scanned PDF, screenshot or photographed statement may contain only pixels, so ordinary PDF text extraction has little or nothing to read. In that case the converter uses local OCR to recognize the page before parsing supported transaction rows.
You can check quickly by opening the statement and trying to select a transaction description. If the whole page behaves like one picture, OCR is probably required.
How the local OCR workflow works
- Choose a PDF, PNG or JPG. Files stay in the current browser workflow rather than being sent to a statement-upload endpoint.
- Prepare the page. The browser removes long table rules that can interfere with recognition while preserving text positions used for column assignment.
- Run English OCR. The current OCR model is intended for clear English statement text and transaction tables.
- Parse the table. Recognized words are mapped into Date, Description, Debit, Credit and Balance fields when the layout is supported.
- Review before export. Compare the preview with the source, then download Excel or CSV.
What to review after OCR
Look closely at digits that OCR commonly confuses, especially decimal points, repeated numbers and characters such as 0/O. Confirm the transaction count, first and last rows, and debit/credit direction. If a running balance no longer follows the transaction sequence, treat that as a reason to inspect the source rather than a reason to force the numbers to fit.
The fictional sample is useful for a known check: the expected result is three transactions and a final balance of 2,295.50.
Current OCR limits
- Clear scans work better than blurred, cropped or angled photos.
- Input is limited to PDF, PNG and JPG, up to 10 MB; PDFs are limited to five pages.
- The current parser is tuned for English tables with separate Date, Description, Debit, Credit and Balance headings.
- Password-protected PDFs are not read by the current workflow.
- An OCR conversion is not a guarantee of financial accuracy. Review every row you plan to rely on.
- Unsupported layouts may need another conversion method or manual entry.
Prepare a scanned bank statement for Excel output for the next step.
Can Lightweight Vision Models Run Bank Statement OCR On-Device?
Yes, with a compatible model, runtime and device. For a supported statement you need in Excel or CSV now, start with the current browser converter. If you are building an offline mobile app, investigate on-device models; complex layouts or custom extraction workflows may justify independently testing a larger model.
What BankStatementMate does today
BankStatementMate uses browser-local OCR for supported scanned PDFs and PNG/JPG images, followed by transaction parsing into Date, Description, Debit, Credit and Balance columns for Excel or CSV export. It does not use MiniCPM or DeepSeek. Document processing is local; account, billing and usage services still communicate with servers. Local OCR does not mean the entire service works offline.
A separate route for mobile app developers
The MiniCPM-V 4.7 1B variant is one lightweight vision-language option. Its linked OCR example demonstrates image-to-text prompting, and the official on-device demos cover iOS, Android and HarmonyOS. This is a separate development route: install or build a compatible app/runtime, load model files, and check device memory, storage and performance. A mobile demo does not guarantee compatibility with every phone or browser.
When a larger model may be worth evaluating
For complex layouts, a larger vision-language model or hosted API may be worth testing. DeepSeek-V4.1-Flash-1017 supports image-and-text input; its large model repository makes it a different deployment proposition from lightweight phone OCR. We have not tested either model on bank statements. General benchmarks do not establish better transaction extraction.
Readable text is only the first step. Check column mapping, row count, dates, decimal points, debit/credit direction and balance consistency against the original. Manually resolve missing, merged or ambiguous rows before using any export.
Keep privacy decisions separate: browser-local OCR, an on-device app and a hosted API have different data paths. Before using remote inference, check what leaves the device, retention and provider terms. For a custom structured-data workflow, see bank statement PDF to JSON.