Skip to content
ignitai
← Back to blog · · 10 min read

Convert bank statement PDF to CSV on iPhone (2026)

Turn monthly bank-statement PDFs into clean CSV rows on iPhone — statements read on-device, never uploaded — a sign convention and balance check that hold up.

guides bank-statements iphone privacy

ignitai turns PDF bank, card, and brokerage statements into a clean transactions spreadsheet on your iPhone — your first conversion is free, then $19.99/mo after a 3-day free trial.

Download on the App Store ignitai — free download

You need a CSV, specifically — not an Excel file, a CSV. Your budgeting app imports CSV. Your accounting software’s bank-feed reconciler takes a CSV mapping. The Python script you wrote to categorize spending reads a CSV. And what you have instead is a bank-statement PDF sitting in Mail on your iPhone, with every transaction you need locked inside a layout that was designed to be printed, not parsed.

The format matters more than it looks. CSV is the universal import currency — plain text, one row per transaction, comma-separated, no formatting to strip. Almost every tool that ingests transactions wants CSV, and almost every bank hands you a PDF. Bridging that gap is the whole task. Doing it on an iPhone — where the PDF already lives — has historically meant either emailing the file to a Mac or pasting it into a web converter you shouldn’t trust with your account number.

This walkthrough covers the workflow that actually works in 2026: extract bank-statement PDFs to CSV on iPhone — the statement file read on-device, never uploaded.

Why CSV (and not XLSX) for this job

If your endpoint is “open it in Numbers and look at it,” XLSX is the better target — it carries number and date formatting. But if your endpoint is importing into another system, CSV is almost always the right call, for concrete reasons:

  • It’s what importers expect. YNAB, Copilot, Actual, QuickBooks, Xero, and nearly every “import transactions” feature take CSV first and XLSX second (or not at all). A CSV maps cleanly to “date, payee, amount” columns in an import wizard.
  • No formatting to fight. A CSV is just text. There’s no hidden cell formatting to misread an amount as a date, no locale quirk turning 1,234.56 into 1.23456. What you see is what imports.
  • It diffs and scripts cleanly. If you process statements with a script — categorizing, deduplicating, tagging — CSV is one line to read with pandas, the standard library csv module, or awk.

The trade-off: CSV throws away formatting, so a leading-zero account fragment or an ISO date has to be correct as text in the file, because nothing downstream will reformat it. That puts more weight on getting the extraction’s sign convention and date format right the first time — covered below.

Why bank statements are uniquely hard

“PDF to CSV” sounds like one task. With bank statements it’s at least four overlapping ones, and most converters only solve the easiest:

  1. Header noise. The first page has a logo, an address block, an account summary, marketing copy. The transaction table doesn’t start until midway down. Naive extractors grab everything and you spend ten minutes deleting rows.
  2. Multi-line transactions. Many banks wrap a single transaction across two or three lines — merchant on line one, location and reference on line two, foreign-currency conversion on line three. The output should be one CSV row per transaction, not three.
  3. Debit/credit columns vs. signed amount. Some statements have separate Debit and Credit columns; some have a single signed Amount; some put deposits on the right and withdrawals in red. To import anywhere you need a single signed numeric column, and the extractor has to infer the convention.
  4. Running balance. Almost every statement has one, and it’s the easiest column to misalign because it’s right-justified and visually identical to the amount. Get it wrong and your reconciliation is off by exactly one row — the worst failure mode, because it looks plausible.

A tool that handles only case 1 — the clean text-based PDF — is useless for the cases that actually waste your time. The right approach treats extraction as a language task: ask a model to find the transactions and return them in a defined shape, rather than reverse-engineering table coordinates.

Why on-device matters for this specific document type

If you’re converting a textbook PDF, “upload to a free web tool” is fine. Bank statements are a different threat model:

  • They contain your full account number (or the last four plus enough metadata to be linkable).
  • They reveal your monthly cash position, your employer, your landlord, and the name of every business you frequent.
  • Most free web converters’ privacy policies explicitly allow them to retain uploaded files for “service improvement,” and the smaller ones don’t even pretend.

ignitai reads the statement on-device: the PDF itself is never uploaded, never sits in a web tool’s queue, never lands in a stranger’s storage bucket. Only the text recognized on the phone is sent to ignitai’s private hosted pipeline to build the CSV. On iOS 26, Apple’s newest on-device document recognition reads the transaction tables natively, which makes the extraction noticeably sharper.

On iOS 17.4 through 18 — every supported version before 26 — the same flow works with Apple’s classic on-device text recognition; the file still never leaves the phone.

Method 1: ignitai (the no-upload way)

The full flow on iPhone, end to end:

  1. Open the PDF in Mail or Files. Tap the share sheet. Pick ignitai. (If you don’t see it, scroll right in the share sheet and tap “Edit Actions” to enable it.)
  2. Describe what to extract. For a bank statement, a prompt that works for almost every US/EU format: “For each transaction, return date in ISO 8601 (YYYY-MM-DD), description, and amount as a signed number — negative for debits and fees, positive for deposits. One row per transaction. Skip header rows, account summaries, and the running-balance column.” Save it as a preset — the second statement is then one tap.
  3. Pick CSV as the output format. ignitai writes UTF-8 CSV with a header row and properly quoted fields, so a description containing a comma (SQ *BLUE BOTTLE, OAKLAND) doesn’t break the columns.
  4. Hit Convert. A typical 12-page statement takes seconds, with live progress as it runs.
  5. Review the preview. ignitai shows the rows before saving. Spot-check the first few, the last few, and any that look unusual — wrong-signed amounts and split rows are the two failure modes worth catching before export.
  6. Save to Files. Drop it in iCloud Drive, OneDrive, or Dropbox. From there, your budgeting or accounting app’s import flow picks it up directly.

The whole thing fits in roughly 30 seconds of actual user time per statement. For a year of them, see the batch section below.

Method 2: Files app + Numbers, then export CSV

If you genuinely only have one statement and don’t want to install anything:

  1. Open the PDF in Files, tap and hold to select the transaction-table text, copy it.
  2. Open Numbers, paste into a new sheet, and split the columns by hand — Numbers has no Text to Columns command, so the cleanup is manual.
  3. Export with ⋯ → Export → CSV.

This is brittle. It only works on text-based PDFs (not scans). Multi-line transactions land on multiple rows; debit/credit columns collapse into one; and Numbers’ CSV export can attach a locale-dependent decimal separator you’ll have to fix. For a single one-page statement, fine. For anything more, the hand-cleaning exceeds the time to just install a real converter.

Method 3: AirDrop the PDF to a Mac

If a Mac is nearby and you don’t need this to be iPhone-native, AirDrop the PDF and follow the Mac CSV walkthrough instead. The Mac version handles a year of statements in one drag-and-drop and gives you a wider screen for review. It’s a perfectly fine fallback — this guide exists because for most people the PDF arrives on the phone, gets read on the phone, and ideally gets dealt with on the phone. The same iPhone flow targeting XLSX instead of CSV is in the iPhone Excel guide, and the iPad version is in the iPad CSV guide.

Method 4: web converters (and why not for this)

You can find half a dozen “PDF bank statement to CSV” web tools by searching. They work, technically. The reasons not to use them for this document:

  • You’re uploading. Even the ones with “private” or “secure” in the name send your file to a server you don’t control. For a bank statement that’s unambiguously bad.
  • They monetize the free tier with friction. Expect rate limits at 1–3 files/day, or download caps that push you to a paid plan after the third statement.
  • Most mishandle multi-line transactions and debit/credit columns, producing a CSV you then spend longer cleaning than extracting.

If the document is genuinely public — a synthetic statement, a sample, a tutorial fixture — they’re fine. For your actual finances, no.

Cleaning the CSV: the three details that matter

Because CSV carries no formatting, these three checks matter more than they would for XLSX — nothing downstream will quietly fix them. Open the file in Numbers (or your importer’s preview):

  1. Sign convention. Sort the amount column ascending. Every negative should be a debit (purchase, withdrawal, fee) and every positive a deposit. If any sign is flipped, re-run with an explicit instruction like “deposits are positive, all other transactions are negative.” A CSV imported with a flipped sign silently doubles your apparent spending in some apps.
  2. Date format. Confirm every date is ISO YYYY-MM-DD. Importers are far more forgiving of ISO than of 04/17/26, which is ambiguous between US and EU order. If the extraction returned a local format, re-run with “date in ISO 8601 format” in the prompt rather than reformatting 400 rows by hand.
  3. Running-balance sanity check. Even though you excluded the balance column from the CSV, do this check once in a scratch sheet before you trust the file: paste the amounts, add =previous_balance + amount, and confirm it tracks the statement’s printed running balance row by row. Where it doesn’t, you’ve found a missed or duplicated transaction. This single check catches almost every extraction error.

Skip step 3 and you’ll discover a misread row when your reconciliation is off by $47.83 with no idea where to look.

Batch mode: a year of statements into one CSV

The real win is twelve statements (or twenty-four, or all of last year for taxes) becoming one consolidated CSV, not twelve files your importer makes you load one at a time.

On iPhone:

  1. In Files, select all the PDFs. Share → ignitai.
  2. Apply the same extraction prompt (or a saved preset) across the batch.
  3. ignitai reads them on-device and writes a single consolidated CSV. Ask for account_last_four and statement_period columns in the prompt — pulled from each statement’s own header — so every row stays attributable to its statement.
  4. Save once. Import once. You now have a year of transactions in one file, ready for a pivot or a category mapping.

For tax prep this is the difference between an evening and a weekend; for monthly budgeting, the difference between doing it and not.

When this workflow doesn’t fit

Be honest about edge cases:

  • Your bank already offers a CSV export. Many banks have a “download transactions as CSV” option buried in online banking, often limited to a rolling window (90 days, 18 months). If it covers the period you need, use it — extracting from a PDF when the bank will hand you a CSV is a workflow built backwards. The PDF path is for closed accounts, older periods past the export window, and banks that only provide statements.
  • Brokerage statements with positions, lots, and dividends are a different structure; the transaction prompt won’t capture them. The iPhone brokerage-statement guide covers the prompt built for exactly that structure.
  • Mixed-currency international statements need a richer prompt — ask for original_amount, original_currency, and converted_amount as separate columns.

Bottom line

For one bank statement on iPhone that you need as a CSV — for a budgeting app, accounting import, or a script — and don’t want to upload: install ignitai, Share → ignitai, pick CSV, save. For a year of them, the same flow batches into one file. For the edge cases — brokerage, mixed currency, or a bank that already exports CSV — fall back to native exports where they exist.

The point of doing this on iPhone is that the PDFs are already there, the on-device document reading means the file itself never moves, and the Mac CSV workflow is one AirDrop away if you want the bigger screen. Pick the one that matches where you are when the statement lands.

Get ignitai on the App Store — free download, $19.99/mo unlocks unlimited extractions and batch mode after the 3-day trial.

FAQ

How do I convert a bank statement PDF to CSV on iPhone?

Open the statement in Mail or Files, share it to ignitai, describe the columns in plain English, pick CSV, and tap Convert. The statement is read on the phone and a clean CSV lands in seconds, ready to save to Files or send on.

Does the statement leave my iPhone?

The PDF itself never does — it is read on-device and never uploaded. Only the text recognized on the phone is sent to ignitai’s private pipeline to build the CSV.

How do I check the CSV is accurate?

Sum the amount column and add it to the opening balance — the result must equal the printed closing balance to the cent. If it ties out, the extraction is clean; if not, tighten the prompt’s sign convention and re-run.