Convert bank statement PDF to CSV on Mac (2026 workflow)

You have twelve bank-statement PDFs in a folder. Maybe twenty-four. Maybe last year’s plus a chunk of this year’s, because you put off the import to QuickBooks and now your accountant is asking. You’re at your Mac, not your phone, because this is a desk job — you want to see the rows, you want to spot-check the totals, and you want the output as one CSV that lands cleanly in your accounting tool.

Excel is one option. CSV is the other, and for anyone piping into QuickBooks Online, Xero, FreshBooks, Wave, or a custom ledger, CSV is the right format. It strips the formatting, keeps the data, and imports without the column-mapping fights that XLSX rounds and date cells cause downstream.

This guide is the Mac-native version of that workflow: convert bank statement PDFs to CSV on Mac, on-device on macOS 14.4+, with source-file provenance on every row and one consolidated output ready for accounting-tool import.

Why CSV (not Excel) for bank statements going into accounting tools

If the spreadsheet is a destination — pivot tables, charts, manual review — XLSX is fine. If the spreadsheet is an intermediate hop into QuickBooks or Xero, CSV wins for four practical reasons:

Date columns survive. Excel’s date typing is helpful in Excel and hostile everywhere else. A 2026-04-17 in a CSV cell stays 2026-04-17. The same value in XLSX often arrives in QuickBooks as 45769 (an Excel serial number) and the import fails or, worse, succeeds with the wrong dates.
Sign conventions stay explicit. A negative amount in CSV is -45.20. An XLSX cell with parentheses formatting ((45.20)) sometimes loses the negative on round-trip through accounting-tool importers that don’t handle the parens.
Encoding is predictable. UTF-8 CSV opens identically in QuickBooks, Xero, FreshBooks, and Wave. XLSX import behavior varies by tool version and by whether the file came from Numbers or Excel.
Diff-friendly. If you re-process a month and want to see what changed, diff on two CSVs is one command. Diffing two XLSX files is its own afternoon.

For a bookkeeper or finance operator whose workflow ends in an accounting tool, CSV is the format the rest of the stack actually wants.

Why the Mac is the right device for this

The iPhone version of this workflow exists for capture — the PDF arrives in Mail on the device that’s on. The Mac version exists for review and batch. Three reasons the Mac wins for the multi-statement case:

Drag-and-drop a folder. The whole year of statements in one drop. Mobile share sheets handle a few files at once, but a folder of forty PDFs is a Mac job.
Big screen for spot-checks. A 12-page bank statement spread across a 27” display next to the extracted CSV makes the three reconciliation checks (sign, balance, date) take seconds rather than minutes.
macOS 14.4+ on Apple Silicon runs the on-device model fast. A typical 12-page statement extracts in 3–6 seconds on an M2 or newer; a year-long batch of twelve statements finishes in under a minute. The same batch on a hosted pipeline would take longer and would mean uploading a year of personal financial data.

If your Mac has a T2 chip or earlier (Intel-era), the on-device path isn’t available; ignitai falls back to a hosted pipeline with documented zero retention. For Apple Silicon Macs (M1 onward) on macOS 14.4+, the entire batch runs locally.

Method 1: ignitai on Mac (the on-device way)

ignitai treats bank-statement extraction as a language task: you describe the rows you want, the model finds them across every PDF in the batch, and the output is one CSV with provenance baked in. The full flow:

Drag the folder of statements into ignitai. Or drag a Finder selection of PDFs. Or a mix. ignitai flattens them into a single batch queue — up to 500 PDFs in one pass on an M-series Mac. Mixed text-PDF and scanned-PDF inputs are fine; the app routes each file through the right pipeline automatically.
Describe what to extract, once, for the whole batch. Plain English. The prompt that works for almost every US/EU bank format:

“For each transaction, return date (ISO 8601), description, amount as a signed number (negative for debits, positive for credits), and running balance. Skip account summaries, marketing pages, and fee-disclosure inserts.”

Save it as a preset. Next month you reuse it with one click.
Pick CSV as the output format. UTF-8, RFC-4180 quoting, comma-separated. This is the format QuickBooks Online and Xero both accept directly in their bank-import flow.
Hit Extract. ignitai runs each PDF through the on-device model, streams results into a single consolidated CSV, and shows live per-file progress. A 12-statement batch on an M2 Mac takes about 45 seconds.
Review the consolidated output. Every row includes a source_file column — the original statement filename — and a source_page column for multi-page statements. Open in Numbers or Excel for review, but keep the file as .csv for import.
Re-run failures, not the whole batch. If any PDFs failed (corrupted, password-protected, blank scans), they’re listed separately. Fix them, re-run just those files, append to the same CSV.

The whole batch lives on your Mac. Twelve months of personal financial detail never leaves the device.

Method 2: pdftotext + a Python parser (the DIY path)

If you want to build it yourself and your statements all come from one bank with a stable template, the macOS-native tooling is most of the way there:

brew install poppler
pip install pdfplumber pandas

Then a script that opens each PDF, extracts the transaction table, and writes one consolidated CSV with a source_file column:

import pdfplumber, pandas as pd
from pathlib import Path

rows = []
for pdf_path in Path("./statements").glob("*.pdf"):
    with pdfplumber.open(pdf_path) as pdf:
        for i, page in enumerate(pdf.pages):
            for table in page.extract_tables():
                for row in table:
                    rows.append([*row, pdf_path.name, i + 1])

df = pd.DataFrame(
    rows,
    columns=["date", "description", "amount", "balance", "source_file", "source_page"],
)
df.to_csv("transactions.csv", index=False)

This is fine for one bank, one stable template, all text-based PDFs. It breaks the moment any of the following happens:

The bank changes its PDF template. extract_tables() infers grids from drawn lines; a redesign re-anchors the grid and your column order shifts silently.
One statement is a scan. A check deposit reissued as a scanned PDF returns no text from pdfplumber. You’d layer in pytesseract and the accuracy collapses on dense transaction tables.
Multi-line transactions. A merchant name on one line and a foreign-currency reference on the next becomes two rows in your CSV unless you write join logic.
Debit/credit columns. Banks that use separate Debit and Credit columns instead of one signed Amount need a per-bank post-processing step.

For one-bank stability, the script is a one-time cost. For real-world bookkeeping across a small business with multiple bank accounts, the maintenance burden eats the savings.

Method 3: Bank-native CSV exports (always check first)

Before extracting from PDFs at all, check whether your bank offers a CSV export directly. Most US and UK retail banks do, buried under different names:

Chase, Bank of America, Wells Fargo: Account activity → Download → CSV (typically 18 months of history).
Capital One, Discover, Amex: Statements → Download → CSV.
Revolut, Wise, Monzo, Starling: Statement exports → CSV, usually with a richer column set than the PDF.
HSBC, Barclays, Lloyds: Online banking → Statements → CSV download (limited window, often 12 months).

Where bank-native CSV exists, use it. The PDF-extraction workflow is for the cases the bank doesn’t cover: small business accounts that only ship PDF, brokerage cash sweeps, foreign banks without an English CSV option, historical statements past the bank’s online retention window, or PDFs your accountant sent you from a system you don’t have access to.

Method 4: Web converters (and why not for bank statements)

Half a dozen “PDF bank statement to CSV” web tools exist. The reasons not to use them for live financial documents:

You’re uploading the file. Even the ones with “private” or “secure” in the name route through a server you don’t control. The privacy policy on most free tiers retains uploads for “service improvement.”
Free tiers gate at one to three files. Past that, watermarks, paywalls, or download caps. A year of statements is twelve files; the math stops favoring the free tool by month four.
Bank-aware extraction is rare. Most generic “PDF to CSV” tools treat every PDF as a generic table grid and miss the multi-line transactions, debit/credit columns, and running-balance reconciliation that bank statements specifically need.

For a tutorial fixture or a sample statement, web tools are fine. For your real accounts, no.

The three reconciliation checks, on Mac

Once the CSV is written, three Numbers (or Excel) checks separate “I have a file” from “I have a clean import-ready ledger”:

Sign convention sweep. Open the file in Numbers. Sort the amount column ascending. Every negative number should be a debit (purchases, withdrawals, fees). Every positive number should be a deposit, refund, or interest credit. If a positive amount is clearly a debit, your prompt didn’t enforce the convention — re-run with explicit instruction like “deposits, refunds, and interest are positive; all other transactions are negative.”
Running-balance integrity. Add a column: =previous_balance + amount. It should equal the extracted balance column row by row. Any divergence means a transaction was missed, duplicated, or misread. This single check catches almost every extraction error and is the difference between a clean import and a ledger that’s silently off by $47.83 in March.
Date format normalization. ISO (YYYY-MM-DD) is what QuickBooks and Xero want. If the extractor returned 04/17/2026 despite the prompt asking for ISO, fix the column in Numbers (Format → Date & Time → ISO 8601) before exporting CSV. Mixed date formats in the same column will cause partial import failures that look like data corruption.

Skip these three and you’ll catch the error at reconciliation, when the P&L is off by a number that doesn’t match any single transaction and you have no idea where to start.

Importing the CSV into QuickBooks Online and Xero

The two tools account for most of the small-business market. Both accept CSV from a generic source as long as four columns are present: date, description, amount (signed), and an optional balance.

QuickBooks Online:

Banking → Transactions → Upload.
Pick the bank account the statements belong to.
Drag the consolidated CSV.
Map columns: date → Date, description → Description, amount → Amount. Skip balance, source_file, and source_page (or import them as Memo if you want the audit trail in QuickBooks itself).
Review the preview, accept.

Xero:

Accounting → Bank accounts → Manage account → Import a Statement.
Upload the CSV.
Map the same four columns. Xero’s importer is stricter on date format — ISO 8601 will save you a re-export.
Confirm and post.

In both, the source_file column being present in the CSV but not mapped is exactly what you want — your file keeps the audit trail, QuickBooks/Xero don’t have to know about it.

Batch mode: a year (or three) in one pass

The real win at month-end, quarter-end, or year-end is the batch:

In Finder, gather all the bank statement PDFs into one folder. Subfolders are fine if ignitai is configured to recurse.
Drag the folder into ignitai.
Apply the saved prompt preset.
Pick CSV.
Extract.
One CSV out, with source_file per row, sorted by date if you toggle that option in ignitai’s batch settings.

For end-of-year tax prep, this is the difference between a Saturday and ten minutes. For monthly bookkeeping discipline it’s the difference between staying current and falling six months behind.

When this workflow doesn’t fit

Honest edge cases:

Brokerage statements with positions, lots, dividends, and corporate actions. The transaction-extraction prompt above won’t capture the structure. Use the brokerage’s tax-document export (often a 1099 in CSV form) and only fall back to PDF extraction for the cash transactions on the side.
Crypto-exchange “statements” that are actually screenshots. Most exchanges have a real CSV export under account history. Use that. Extracting from a PDF screenshot of one is a workflow built backwards.
International statements with mixed-currency transactions. Tighten the prompt: “For each transaction, return original_amount, original_currency, converted_amount in account currency, and conversion_rate as separate columns.” Three columns instead of one is a small cost; a clean per-currency reconciliation in your books is a large benefit.
Statements older than online retention. If you’re scanning paper statements from a filing cabinet, those are scans, not text PDFs. The extraction still works on iPad/Mac because ignitai routes scans through the OCR-then-extract pipeline; spot-check more carefully because OCR adds a small accuracy hit.

Bottom line

For a folder of bank-statement PDFs that needs to end up as one CSV on Mac, ready for QuickBooks or Xero: install ignitai, drag the folder in, write the prompt once, pick CSV, hit Extract. For a single one-bank stable workflow that you want to own end-to-end, a pdfplumber-plus-pandas script is a valid alternative if you don’t mind maintaining it. For everything else — multiple banks, scans, mixed templates, anything you’d rather not upload — the on-device path is the shortest distance from PDF folder to import-ready CSV.

The single-file walkthrough on iPhone is in the iPhone bank-statement guide; the broader Mac batch workflow across mixed document types is in the Mac batch guide; the iPad-side equivalent for vendor invoices is the iPad invoice walkthrough. The app is the same across all three; presets and outputs sync via iCloud, so the Mac is the batch and review surface and the mobile devices are the capture points.

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