The 30-second version
Eleven questions to ask any PDF bank-statement converter before you commit a client workflow to it: which output formats it really emits, whether it reconciles or just extracts, how it handles your bank's locale, what happens to your PDFs after upload, scanned-document support, password-protected PDFs, the API and agent surface, pricing structure (rollover vs burn), data residency, SLA / DPA availability, and the agentic-workflow integration story. Use this as a checklist; treat any "contact us for details" on the first seven as a red flag.
If you're a bookkeeper or accountant who routinely converts client bank statements from PDF into your accounting software, the tool you pick matters more than people realise. A bad converter doesn't fail loudly — it ships a CSV that looks right at a glance, then bites you three weeks later when reconciliation refuses to match.
This is a practical checklist. Run any tool you're evaluating through these eleven points before you commit a client workflow to it. We'll cover what each check looks like in practice, the red flags to watch for, the often-overlooked items (pricing structure, data residency, agentic-workflow support), and the realistic decision matrix for which features matter most depending on your firm's size and client base.
1. What output formats does it actually produce?
Most tools list "Excel, CSV" and stop. That's fine if your software accepts those — but if you live in QuickBooks Desktop, Quicken, or anything that prefers OFX/QBO/QFX files, you'll spend more time massaging a CSV than you'd have saved by skipping the converter altogether.
The shortlist of formats worth checking for:
- CSV and Excel — universal; useful for spreadsheet review and any tool that maps columns at import time.
- QuickBooks (.qbo) — Web Connect / OFX; imports natively into QBO and QB Desktop with no column mapping. Saves the most time of any single format. See why QuickBooks imports fail for what a bad .qbo looks like.
- Quicken (.qfx) and generic OFX — for Quicken users and the long tail of open-source tools (GnuCash, MoneyDance, Beancount).
- Xero CSV — Xero accepts standard CSV but its native template skips column mapping. Different from a generic CSV; see AIB / Lloyds / Barclays → Xero.
- Sage 50 CSV — uses BP / BR row prefixes for bank payment / receipt. Generic CSVs need transformation.
2. Does it reconcile, or just extract?
Extraction is the easy part. Verification is the hard part. A converter that doesn't check whether opening + transactions = closing has no way to know if a row was misread. The first time you find out is during your monthly reconciliation in QuickBooks — three weeks after the fact, when you have no memory of which file produced which row.
Ask:
- Does the tool check opening balance + sum of transactions against the closing balance?
- Does it check each row's printed running balance against the chain?
- Does it surface which specific rows broke the chain — or does it just return a CSV with no warnings?
- Does the reconciliation verdict travel through to the exported file (CSV header, .qbo memo, Xero notes)?
We wrote a longer piece on this: what "auto-reconciled" actually means and why most converters skip it.
99% accuracy on a 200-row statement is roughly two wrong rows. Without reconciliation, you have no way to know which two.
3. How does it handle your bank's locale?
US-built converters often treat comma-decimal amounts (€1.234,56) as thousands separators, turning a €1.23 coffee into a €1,234.56 disaster. UK and Irish statements with separate Money In and Money Outcolumns get split into two amount fields that downstream tools don't know what to do with.
The locales worth testing against, in order of likelihood-of-trouble:
- EU number format (Germany, France, Spain, Italy, NL): comma decimal, period thousands. Most common silent failure.
- UK / Ireland / Australia / NZ: Money In / Money Out columns split.
- India: Indian numbering (lakh / crore commas like 1,23,456.78) plus Dr/Cr suffixes.
- Switzerland: apostrophe thousands separator (1'234.56) — non-standard.
- Brazil / Mexico: Débito/Crédito or Cargo/Abono columns plus EU number format.
Test the tool on a real statement from yourbank — not the demo PDF on its homepage. Look at whether amounts and dates come out in the locale you'd expect, and check whether the running balance survives the round-trip.
4. What happens to your PDFs after conversion?
Bank statements are some of the most sensitive documents you handle. A converter that retains them indefinitely is a liability — to you and to your clients. Three questions to ask:
- Where are files stored? If the tool is hosted in a jurisdiction without GDPR-grade data protection, your clients may have a procurement objection — and you may have a regulatory one.
- How long are files kept?"Indefinitely" is the wrong answer. Auto-delete within 24 hours is the right shape. We delete within 1 hour after a successful conversion.
- Is your data used to train AI models?Some converters now run on public-API model providers without enforcing no-training settings. Confirm explicitly — "we don't train our own model" isn't the same as "the model provider also doesn't use the data for training".
The retention question that traps many tools
Read the privacy policy carefully. "We may retain files for service improvement" or "we retain extracted data" usually means the source PDF or the parsed transactions sit in their system indefinitely. For GDPR-regulated data subjects (any client of an EU practice), that's a continuing data-processing relationship that needs to be in the practice's own retention policy too.
5. Does it handle scanned PDFs?
Statements scanned at a bank branch, photographed from paper, or saved as image-only PDFs all lack a text layer. Most converters treat these as empty and return nothing — or worse, return a few rows and silently drop the rest. A small but non-trivial percentage of your client statements will be in this shape, especially:
- Older corporate accounts that pre-date online banking
- Statements from physical paper, scanned by the client's admin team
- Pass-book style statements from co-operative banks (common in India)
- Statements that have been printed and re-scanned for circulation
A converter that handles scans uses vision-based extraction (not just OCR character recognition) and applies the same reconciliation step as digital PDFs. Without the reconciliation step, OCR errors on scanned statements compound invisibly.
6. Does it handle password-protected PDFs?
Indian banks, several EU corporate banks, and some private-banking services send statements as encrypted PDFs. The converter needs to either accept a password at upload time, or accept a pre-unlocked file. If it does neither, you'll be removing passwords by hand for every client — and that gets old fast. See how to unlock password-protected bank statement PDFs for the recovery flow.
Ask specifically how the password is handled — in memory only, written to a log, sent to error tracking, retained in the user's account, etc. The right answer is "held in memory for the conversion task, never written to database or logs".
7. Is there a real API, and is it on every plan?
Even if you don't need an API today, your firm probably will within a year — once you start hitting volume, integrating with workflow tools, or onboarding clients who already have automated processes. A REST API that's enterprise-gated ("contact sales") is worth less than one that's self-serve from the free tier.
Bonus points for:
- Bearer-token auth (industry standard)
- Stable per-row identifiers so you can dedupe on re-import
- Async job model with polling (so you don't hold long-running HTTP connections)
- An MCP server (Model Context Protocol) so you can call from Claude Desktop, Claude Code, or any agentic client
8. Pricing structure — rollover vs burn
Two common pricing patterns. Per-page burn (X pages per month, unused expire each month) is easier to model on the vendor side; predictable for them, painful for you when client volume spikes. Page allowance with rollover (pages roll forward N months) handles real-world seasonality far better — Q1 tax season needs more capacity than April-November on most practices.
Run the numbers on a realistic year for your client base. A €19/month plan with 500 rolling pages beats a $25/month plan with 1,000 use-it-or-lose-it pages for most accounting practices — the rollover absorbs the busy months.
9. Data residency
For UK / EU practices: confirm the vendor's data residency. "Hosted on AWS" doesn't answer the question — AWS has regions in 33 countries. "Hosted in eu-west-1 (Ireland)" or "hosted in fra1 (Frankfurt)" does answer it. Same applies to their database (Supabase, Postgres) and AI provider (OpenAI vs Anthropic vs Gemini — each has different regional offerings).
The right question to ask
"Where is the file processed, and where is the extracted data stored long-term?" You want a single jurisdiction answer for both. If they tell you "processing in EU, storage in US", that's a Standard Contractual Clauses problem you don't need.
10. SLA and DPA availability
For small practices, neither is strictly necessary. For larger firms, regulated clients (legal, healthcare, government suppliers), or any practice with a sub-processor audit obligation, both matter:
- Data Processing Addendum (DPA): most reputable B2B vendors will sign one on a paid plan. If the answer is "we don't do those", walk.
- SLA: best-effort is fine for most workflows. If you have a regulated client who needs uptime guarantees in writing, expect this to be a Business / Enterprise plan feature.
11. Agentic-workflow integration
Newer consideration but increasingly important. If your accountants are using Claude Desktop, Claude Code, ChatGPT, or any AI assistant in their daily workflow, a converter that ships an MCP server lets the assistant do the conversion in-line. Workflows like "Convert these 12 statements and aggregate the closing balances by month" become a single prompt instead of 12 manual uploads.
Ask:
- Is there an official MCP server package (installable via npm or similar)?
- Does it use the same API key as the web app, or does it require enterprise sign-off?
- Does the agentic surface respect the same page allowance, or is it gated to a higher tier?
The decision matrix — which checks matter most for which firm
| Firm shape | Top-priority checks |
|---|---|
| Solo bookkeeper, <20 clients | Formats (2), reconciliation (2), locale (3), pricing rollover (8) |
| Multi-client practice, mixed banks | Locale (3), reconcile (2), scanned-PDF support (5), password support (6) |
| EU-regulated practice | Data residency (9), DPA (10), retention (4), no-training (4) |
| Workflow-heavy / fintech | API (7), MCP / agentic (11), rate limits, stable IDs |
| Large firm / SOC review | All of the above + SLA (10) + sub-processor list |
The shortcut
If you're short on time and want to skip the evaluation cycle, here's our honest position: StatementEdge emits all five major formats, reconciles every conversion, handles 22 country locales natively, processes uploads in the EU (Frankfurt), auto-deletes source PDFs within 1 hour, accepts password-protected PDFs in-memory, ships a self-serve REST API on every plan (free tier included), and has a published MCP server for agentic workflows. Try it on a real client statement — free, no signup — and see how it clears your eleven-point checklist.
Honest answer either way: send us a message. A real human reads every one.
Further reading
- What "auto-reconciled" actually means — deeper on check #2.
- Why your QuickBooks import keeps failing — practical examples of checks 1, 3, 4 failing in the wild.
- AIB, Lloyds, Barclays → Xero — per-bank locale traps.
- Unlocking password-protected statements — practical workflow for check #6.
- REST API documentation · Security posture · Privacy policy.