How to import a bank statement into a budget app

The false choice: link your bank, or type it all in

Budgeting apps offer two doors. Behind the first, you authenticate to your bank through an aggregator — Plaid, MX, Finicity — and transactions arrive automatically. Behind the second, you type in every coffee by hand.

Door one is fast, and its cost isn't money: a third party ends up holding a durable credential that reads your accounts for as long as the link lives. Door two is private and unsustainable — three months of backlog is 400-odd rows, and nobody types 400 rows twice.

There is a third door. Nearly every bank will hand you a machine-readable file of your transactions on demand, two clicks from the account screen. You download it, you import it. No credentials leave your device, and nobody gets standing access.

The catch: these formats are only sort of standardised, and nobody explains what's inside them. Everything below is bank-agnostic — it works with any app that accepts a CSV.

Step 1: Download the file from your bank

The path has the same shape whatever your bank calls it:

Accounts → the account → Statements / Activity / Transaction history → Download or Export → pick a format and a date range.

It often hides behind a small "Export" link, not a button.

• Use desktop web, not the mobile app — bank apps often offer statements as PDF only.
• Take the widest date range offered. Ninety days is typical; some banks give 12 or 18 months.
• Export each account separately — checking, savings, each card. You'll import them separately too.
• Rename each file as you download it. chase-checking-2026-04-to-06.csv still means something in an hour; Download(3).csv doesn't.

Which format to pick from the dropdown:

If QFX is on the menu, take it. Otherwise CSV: five extra minutes on the first import, none after.

What's actually inside a bank CSV

Open the file in a plain text editor first. Not Excel — it will "help" by reformatting dates and stripping leading zeros, and then you're debugging Excel instead of your data.

A realistic export from a US checking account:

Posting Date,Description,Memo,Amount,Balance
04/03/2026,"SQ *BLUE BOTTLE COFFEE",PURCHASE,-6.75,2841.19
04/03/2026,"PAYROLL DEP ACME CORP",DIRECT DEP,2450.00,5291.19
04/04/2026,"TRADER JOES #221 SAN JOSE CA",PURCHASE,-84.32,5206.87

The same three transactions, as a European bank would encode them:

Date;Payee;Debit;Credit
03/04/2026;SQ *BLUE BOTTLE COFFEE;6,75;
03/04/2026;PAYROLL DEP ACME CORP;;2450,00
04/04/2026;TRADER JOES #221;84,32;

Identical events. Different date order, different delimiter, different decimal separator, two amount columns instead of one, and no minus sign anywhere. Neither file is wrong. There is no bank CSV standard, only whatever each bank's reporting system emits.

Underneath the variation, every budgeting app wants the same three fields:

• Date — when it happened
• Description — who you paid, in words a human recognises
• Amount — how much, and in which direction

Everything else — balance, check number, transaction ID — is optional.

Step 2: Column mapping, explained

Column mapping is where you tell the app which of its three fields matches which of your file's columns. It exists because no two banks agree, and an importer that never asks is guessing — a wrong guess being worse than a question, because it's silent.

Five things go wrong here.

Dates: the failure that doesn't announce itself

Row one of each example above: 04/03/2026 and 03/04/2026. Both are April 3rd, and both are valid under both readings. If the importer reads day-first where your bank wrote month-first, nothing errors. Your coffee moves to March, every transaction dated before the 13th of any month lands in the wrong one, and two months of budget quietly become fiction.

How to check, in ten seconds. Find a row dated the 13th or later: a number above 12 cannot be a month, so 25/04/2026 pins the format instantly. Failing that, use a row whose date you know — rent on the 1st, a flight. Set the format, then read the parsed preview and confirm it shows the day you remember.

Amounts: one column, or two?

Banks encode direction in at least four ways.

One signed column. The clean case — money out is negative:

Date,Description,Amount
2026-04-03,BLUE BOTTLE COFFEE,-6.75
2026-04-03,PAYROLL ACME CORP,2450.00

Two columns, Debit and Credit. Each row fills one and leaves the other empty. The sign lives in which column the number is in, not in the number:

Date,Description,Debit,Credit
2026-04-03,BLUE BOTTLE COFFEE,6.75,
2026-04-03,PAYROLL ACME CORP,,2450.00

If the mapping screen has separate Debit and Credit slots, map both. If it has one Amount slot, merge them first: in a spreadsheet add a column with =IF(D2="", E2, -D2), fill it down, delete the originals. Skipping that is the most common reason a first import counts every expense as income.

Parenthesised negatives. Accounting convention: (42.10) means -42.10. Some importers understand it, some reject the row as text, and some read it as positive 42.10 — the worst outcome, because it looks fine.

A separate flag column. CR / DR beside an always-positive amount:

Date,Description,Amount,Type
2026-04-03,BLUE BOTTLE COFFEE,6.75,DR
2026-04-03,PAYROLL ACME CORP,2450.00,CR

Same remedy: derive one signed column before importing.

Whatever shape the file is in, the acceptance test is the same. After importing, sort by amount. If your paycheck sits at the top of the spending list, your signs are inverted. Undo, flip the column, redo.

Credit cards invert the sign

On a checking account, a purchase reduces your balance and exports as negative. On a credit card, the statement is written from the bank's side: your purchase increases what you owe, so many issuers export purchases as positive. Import that unaltered and every purchase becomes income. Check one row; if purchases are positive, flip the sign, or use the importer's "invert amounts" option.

Description vs Memo vs Payee

Bank files carry two or three text columns with no consistency about which is useful:

• Description — usually the merchant string, and usually the one you want
• Payee — sometimes cleaner, sometimes empty
• Memo / Notes / Type — sometimes the good name, sometimes just POS DEBIT

Read three rows and map the column a human can read. TRADER JOES #221 SAN JOSE CA is a description; PURCHASE is not. If the readable text is split across two columns, concatenate them first.

Encoding and delimiters

Delimiters. "CSV" means comma-separated, except when it doesn't. Many European banks use semicolons, because where the comma is the decimal separator a comma delimiter would be ambiguous. If the preview crams every row into one column, the delimiter is wrong. Most importers let you set it; if yours can't, find-and-replace ; with , and the decimal , with . first.

Encoding. If CAFÉ MØRK arrives as CAFÉ MØRK, the file is UTF-8 being read as Latin-1, or the reverse. Amounts and dates are unaffected, but it makes merchant names hard to search. Reopen the file in an editor that lets you set the encoding (VS Code: status bar, Reopen with Encoding) and re-save as UTF-8.

Duplicates

The importer has no idea what you imported yesterday. Pull January–March, then later pull February–April, and two months land twice.

• Import non-overlapping ranges, and write down where you stopped: imported through 2026-06-30.
• Reconcile against a number you can verify — the closing balance on the bank's statement. A month that comes out exactly double was imported twice.
• If it happens, delete the whole batch and redo it. Hunting individual rows takes longer than starting over.

Why QFX skips this step entirely

A CSV is a grid of unlabelled values: the file never says what a column means, so you supply the meaning.

QFX, and its sibling OFX, is tagged — every value arrives wearing a label:

<STMTTRN>
  <TRNTYPE>DEBIT</TRNTYPE>
  <DTPOSTED>20260403120000</DTPOSTED>
  <TRNAMT>-6.75</TRNAMT>
  <FITID>202604030001</FITID>
  <NAME>SQ *BLUE BOTTLE COFFEE</NAME>
</STMTTRN>

There's nothing to map. DTPOSTED is the date, in a fixed YYYYMMDD layout that can't be misread as month-first. TRNAMT is the amount, already signed. NAME is the description. FITID is a unique ID the bank assigns, which is how a good importer knows it has already seen a row rather than guessing from date-plus-amount.

So take QFX whenever it's offered: none of the five problems above can occur, and the mapping screen never appears. What puts people off is the label — many banks file QFX under Quicken, which makes it look like you need Quicken to open it. You don't. See how to open a QFX file without Quicken.

Step 3: Importing into Money Map

Money Map is a personal budgeting app for iPhone and Mac built around exactly this workflow. No bank connection, no aggregator, no account, no email address. You bring the file.

The import lives at Transactions → + → choose your file type.

• CSV opens the column-mapping interface described above. Point Date, Description and Amount at the right columns, check the preview against a row you recognise, confirm. The bank-specific strangeness gets absorbed here, which is why the app asks instead of guessing.
• QFX has no mapping step. The file declares what everything is, so the app reads it directly.
• JSON is also supported, useful if you're migrating from an app that exports it.

For the first run:

• Import one account at a time — checking, then each card. They land in one combined view, so you see spending across all of them without merging anything by hand.
• The free tier holds 100 transactions: enough to run one small file end to end and confirm your mapping before committing three months of history. Unlimited transactions require a subscription.
• Your data lives in your own iCloud, encrypted. It syncs between iPhone and Mac because it's your iCloud account, not because it passed through a server on our side — RationalBit holds no copy and can't read it. Face ID or Touch ID locks the app.

Cleaning up after the import: categories and recurring transactions

An import gets rows into the app. It doesn't tell you what they mean. Budget an hour for the first three months; after that it's minutes a week.

Categorise merchant by merchant, not row by row. Every TRADER JOES line is groceries, every SQ *BLUE BOTTLE is coffee. It's also where you learn the shape of your spending — the part a bank feed does for you, and in doing so hides.

Use subcategories where the top level is too coarse. A Food category that lumps groceries with restaurants tells you nothing you can act on. Groceries, Restaurants and Coffee underneath Food tell you which one moved.

Declare the repeating ones as recurring. Rent, salary, insurance, subscriptions. Setting them up as recurring transactions stops you re-importing them by hand.

Then set budgets. Money Map takes a per-category budget as a fixed amount or a percentage of income — percentages are better if your income varies, or if you're working from a framework like 50/30/20. Three months of history is what makes those numbers honest.

Check your work month over month. A category that triples in one month is usually a duplicate import, not a lifestyle change.

Why a file import is more private than a bank connection

The distinction isn't about where the data ends up. It's about what you handed over to get it there.

A bank connection means you authenticate through a third party, which comes away holding a durable credential that reads your accounts. Not one file, once — the account, continuously, until somebody revokes it. That company now holds a copy of your transaction history, its own breach surface, and a privacy policy it can rewrite.

A file export hands over nothing. You sign in to your bank directly, the way you always do. The bank gives you a file. You move it to an app on your own device. Nothing holds standing access, and there is nothing to revoke, because nothing was granted.

That's the trade: a few minutes a month, and no company sits between you and your bank.

Money Map is built for people who want that trade — no bank login, no account, no email address, just a file and your own iCloud. For the longer version, read budgeting without a bank login. Otherwise the four steps above are the whole commitment: export, map once, import, repeat.