Convert bank statement PDF to Excel on iPad (2026 guide)

The statement PDF arrives in Mail on the first of the month, and the iPad is the device that’s on after dinner when you actually have the headspace to look at money. Your budget lives in an Excel workbook on iCloud — a sheet per month, a pivot that rolls spending up by category, a couple of charts you glance at to decide whether this is a tighten-up month. What’s missing is the fifteen seconds that turns the PDF into rows the pivot can read. Until those rows land, the budget is last month’s budget, and “I’ll do it on the Mac later” is the reason it stays that way.

The single-statement case is the one the iPad handles well: read a month of transactions, write clean Excel rows, push the workbook back to iCloud, and have the budget pivot refreshed before the dishes are done. This guide is the iPad-native version of that workflow: convert bank statement PDFs to Excel on iPad, on-device on iPadOS 26+, with merchants normalized and one consolidated sheet your budget pivot reads each month.

Why Excel (not CSV) when the spreadsheet is the destination

The iPad CSV walkthrough is the right path when your destination is QuickBooks, Xero, or another accounting tool that wants a flat import file. This post is the other case — when the spreadsheet itself is where the money work happens: a personal or household budget, a side-business cash tracker, a sheet you pivot and chart and color by hand. For that, XLSX is the right output for four reasons:

The pivot table lives in the workbook. A budget pivot that rolls category × month up to a spending total is a one-time setup in XLSX. Each month you append rows and refresh — you don’t rebuild. A CSV is a flat file with no pivot, no chart, no saved formatting; you’d be re-importing into a workbook anyway, so extract straight to the workbook’s format.
Number and date formatting survive. Currency formatting on the amount column, ISO date formatting on the date column, a category column with a dropdown — XLSX preserves all of it. CSV is plain text and your workbook re-infers types on every paste.
Multiple months in one file. A budget workbook is naturally one sheet per month or one running sheet with a month column. XLSX is built for that. A pile of monthly CSVs is a pile of monthly CSVs.
Formulas and conditional formatting persist. A =SUMIFS that totals dining-out spend, a red-fill rule when a category goes over budget — these are part of the workbook, and extracting to XLSX drops the new rows in underneath them without disturbing any of it.

If your workflow ends in an accounting tool instead, take the CSV path. If it ends in the spreadsheet, this is the one.

Why iPad is a reasonable place to do this

Bookkeeping on iPad used to be a compromise. In 2026 the reasons it wasn’t have evaporated:

iPadOS 26+ on M-series and A17-Pro iPads runs the model on-device. A typical fifteen-page statement extracts in 5–8 seconds on an M1 iPad or newer; the file never leaves the device. Older iPads fall back to a hosted pipeline with documented zero retention.
The screen is wide enough for the spot-check. Split View with the statement PDF on one side and the extracted rows on the other makes the reconciliation pass — does the row count match, do the totals tie — a thirty-second job, not the squint it is on a phone.
iCloud Drive makes the round-trip seamless. The XLSX lands in iCloud; the same workbook is open on the Mac next morning with the new month already appended. You do the iPad moment when the statement lands; the deeper analysis happens wherever you happen to be.
Files and the share sheet finally work. The statement in Mail goes share sheet → ignitai → done. No download dance, no AirDrop to a Mac, no “later.”

Why a bank statement is harder to extract than it looks

A bank statement looks like a simple three-column table — date, description, amount — and a generic extractor treats it that way and gets four things wrong:

Merchant strings need normalizing. The raw description is whatever the payment network passed: SQ *BLUE BOTTLE, TST* PIZZA HOUSE, AMZN MKTP US*2H4XK. The same coffee shop across a month appears as three different strings, and an un-normalized budget pivot splits one merchant into five rows. You want a clean merchant column alongside the raw description, so the pivot groups correctly.
Running balance is not a transaction. Most statements print a running-balance column. It looks like an amount and a coordinate-based extractor happily pulls it into your spend total, double-counting everything. The balance column has to be recognized as a balance, not an amount.
Multi-line descriptions. A wire or an ACH detail wraps onto a second and third line. Those continuation lines belong to the transaction above them, not to new rows — but a grid extractor turns each line into its own row with a blank amount.
Debit/credit sign convention. Some statements use separate debit and credit columns; some use one signed column; some mark credits with CR. The budget pivot needs one signed amount where money out is negative, regardless of how the bank chose to print it.

A tool that grabs “the table” hands you balances mixed with transactions and one merchant smeared across five rows. A tool that reads the statement as a statement gives you one row per transaction, a normalized merchant column, a single signed amount, and no balance contamination. That’s what the budget pivot needs.

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

ignitai treats the statement as a language task — “list every transaction with a clean merchant name and a signed amount” — not a coordinate-matching task. The full iPad flow:

Share the PDF into ignitai. From Mail, Files, or your bank’s app: share sheet → ignitai. Or open ignitai and pick the file from Files. A multi-statement month — checking plus savings plus a card — can go in as one batch.
Describe what you want, once. Plain English, saved as a preset:

“List every transaction as one row: date (ISO 8601), raw_description, merchant (normalized — collapse payment-network prefixes and store numbers to a clean name), category (best guess from the merchant), and amount (single signed number, money out negative). Ignore the running-balance column and any opening/closing balance lines.”

Next month it’s one tap.
Pick XLSX as the output. One sheet, one row per transaction, currency formatting on amount, ISO dates on date.
Tap Extract. The on-device model reads the PDF and streams rows in with live progress. A month of forty transactions finishes in a few seconds on an M-series iPad.
Spot-check in Split View. Statement on one side, extracted rows on the other. Confirm the transaction count matches and the closing balance ties. Every row carries a source_file column so a number traces back to its statement.
Send it to the budget workbook. Open the XLSX in Excel for iPad (or Numbers), or append the rows into your running budget sheet on iCloud. The pivot refreshes; this month is in the budget.

The statement — account number, balance, every transaction — stays on the iPad. Nothing is uploaded.

Method 2: Numbers copy-paste (the no-install fallback)

For one clean, text-based statement you don’t want to install anything for: open the PDF in Files, tap into the text, select the transaction table, copy, and paste into Numbers. On a simple grid this lands roughly. It falls apart the moment the statement has multi-line descriptions, a running-balance column you now have to delete by hand, or any scanned page — and it does nothing to normalize SQ *BLUE BOTTLE into “Blue Bottle,” so your pivot still fragments. For a single tidy statement, it’s a five-minute manual job. For every month, save the preset in Method 1.

Method 3: web converters (and why not on iPad)

Plenty of “PDF bank statement to Excel” web tools exist, and a bank statement is precisely the document you should not upload to one. You’d be handing your account number and a month of transaction history to a server you don’t control; free tiers gate at one to three files; and almost none normalize merchants or strip the balance column, so you get a denormalized table you clean by hand anyway — after the upload. On iPad specifically, the whole appeal is that the on-device path needs no upload at all. For a statement with real numbers on it, the web converter is the wrong tool.

The reconciliation checks, on iPad

Two quick checks turn “I have rows” into “I trust this month’s budget”:

Closing-balance tie. Opening balance plus the sum of your signed amount column should equal the statement’s printed closing balance. In a free cell: =opening_balance + SUM(amount_column). If it ties, no transaction was missed or double-counted — this single check is the one that matters.
Merchant-normalization scan. Sort by merchant and skim for the same store under two spellings. Push any fix into the saved prompt — *“treat ‘SQ BLUE BOTTLE’ and ‘BLUE BOTTLE COFFEE’ as ‘Blue Bottle’” — so next month’s pivot groups it right without your intervention.

Skip the first check and the budget quietly drifts from reality; skip the second and one merchant shows up as three categories.

Where this fits in the monthly loop

The point of doing it on iPad is that the friction is low enough to actually happen every month:

Statement lands in Mail → share into ignitai → preset → XLSX → append → pivot refresh. Five taps, a few seconds, the budget is current.
The Mac picks up the same workbook. Because the XLSX is on iCloud, deeper analysis — quarter-over-quarter, category trends — happens on the Mac next morning with no re-import. The Mac bank-statement flow covers the year-end consolidation when you want every month in one place.
Credit cards run the same way. A card statement is a close cousin with merchant strings that need even more normalizing; the credit-card iPhone guide shows the in-the-moment capture version of the same idea.

When this workflow doesn’t fit

Honest edge cases:

Your bank already exports CSV or QFX. Many banks have a “download transactions” button in their app or web portal. If yours does and the export is clean, use it — extracting from the PDF is for banks that only hand you a statement, which is still common for older accounts and many credit unions.
You want it in an accounting tool, not a spreadsheet. Take the CSV path instead — CSV imports more cleanly into QuickBooks and Xero than XLSX does.
A year of statements at once. That’s a desk batch, not an after-dinner iPad task. Drag the folder into ignitai on the Mac and consolidate in one pass; the Mac batch guide covers it.

Bottom line

For a monthly bank-statement PDF that needs to land in a budget workbook on iPad — pivot tables, charts, the sheet you actually use to run your money — share it into ignitai, write the prompt once, pick XLSX, tap Extract, run the closing-balance tie, and append to your sheet. The on-device path on iPadOS 26+ keeps the account number and every transaction on the device, and iCloud carries the workbook to the Mac for the deeper passes. For an accounting-tool destination, take the CSV path; for a year at once, take the Mac batch. For the after-dinner, single-statement, keep-the-budget-current case, the iPad is the right device and XLSX is the right format.

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