How do you get a bank statement into a budgeting app?
You download a file from your bank and the app reads it. Which file to download is the part nobody explains, and picking the wrong one is why most statement imports fail.
What file should you download from your bank?
Download a CSV if your bank offers one, and if it does not, download the "Quicken" or "QuickBooks" option — those are OFX, QFX and QBO files, which carry the same data in a stricter format.
Most banks bury this. The download menu on a transactions page typically offers CSV, "Spreadsheet", "Quicken (.QFX)", "QuickBooks (.QBO)" and "PDF", and people who do not recognise the middle three pick PDF because it is the only word they know. CSV and the Quicken family are both good choices — the Quicken formats are arguably better, because they carry an explicit transaction type rather than leaving the app to guess the direction from a sign. Accountable reads CSV, TSV, Excel (.xls and .xlsx), OFX, QFX, QBO, OFC and QIF, and every one of them lands in the same preview.
Can you import a PDF bank statement?
Sometimes — a PDF that contains real text can be read, but a scanned one is an image of a statement and there is nothing in it to read.
This matters more than it should, because a number of banks have quietly made PDF the only format that goes back more than a year or two. Truist, where SunTrust’s customers ended up, caps CSV export at eighteen months, which is why an entire cottage industry of "convert your bank PDF to CSV" services exists — that is what an unmet need looks like from outside. Accountable reads text-bearing PDF statements directly. If yours is a scan, it will say so by name rather than guessing at it, because a guessed figure in a ledger is worse than a refusal.
Why do PDF statement imports get the amounts wrong?
Because a statement line ends in two numbers that look identical — the amount and the running balance — and a reader that takes the last number on the line imports your balance as a transaction on every row.
This is the failure mode to check for in any tool you use, because it is silent: the import completes, the rows look plausible, and every figure is wrong by an amount that grows down the page. The fix is to find the columns rather than assume them. Every text run in a PDF carries its own x/y position and a statement has a header row naming its columns, so a careful reader locates the header first and assigns each figure to the column whose horizontal range it falls in. Accountable does that, which is the whole reason its PDF support is exact rather than approximate. If a converter cannot tell you how it distinguishes the amount from the balance, assume it does not.
How do you stop an import creating duplicate transactions?
A good importer compares each incoming row against what you already have and against the rest of the file, and it has to do that on the date and amount rather than on the description.
The description will not match, and expecting it to is why naive duplicate detection fails. You logged "ATM · tips"; your bank calls the same deposit "ATM CASH DEPOSIT ON 08/23 2025 TOWNE LAKE PKWY". Accountable checks both ways: an exact match on date, direction, amount and description is a confident duplicate and is skipped, while a match on date and amount alone is flagged as "already logged" and offered with an import-anyway option — because two genuine $4.12 purchases on one day are a real thing that happens, and an importer that silently drops the second one is quietly wrong. It also counts rather than de-duplicates, so a file with two identical rows against a ledger holding one imports exactly one.
Does a bank statement include the categories?
No — a bank gives you a date, a signed amount and a description, and every category you see after importing one was guessed by the app.
This is the difference between importing from a budgeting app and importing from a bank. A Mint or YNAB export carries a category column, so the import is a straight copy. A raw bank line is `PURCHASE AUTHORIZED ON 08/21 EL POLLO DORADO AC ACWORTH GA S306233829518588 CARD 2168`, and turning that into "Eating out" requires reducing it to a merchant and then guessing from the merchant. Accountable classifies roughly 95% of a real statement and puts the rest in Uncategorised rather than guessing confidently — an obviously unfinished row you can fix in a second is better than a wrong one that silently distorts a total for ever.
Is it safe to upload a bank statement to a budgeting app?
It is safer than connecting the account, because a statement file contains a record of what happened and no credential that can reach the account it came from.
A statement is history: dates, amounts, descriptions, sometimes a masked account number. It cannot be used to log in, move money or read anything you did not download. That is a genuinely different risk profile from a live connection, where a stored token grants standing read access. What still matters is what the app does with the file afterwards — whether it holds the raw statement, who processes it, and whether you can delete it. In Accountable the file is parsed in your browser and never uploaded: what reaches the database is the rows you confirmed in the preview, and nothing is written until you confirm them.
What if your bank offers no export at all?
Then a text-bearing PDF is usually still available, and failing that, entering a month by hand takes less time than people expect — roughly four seconds per transaction.
Very small credit unions and a few app-only banks are the usual culprits. Before giving up on a file, check the desktop web banking site rather than the mobile app, since export is frequently desktop-only, and check for a "Quicken" option under a different menu than the statements list. If there is genuinely nothing, a month of forty transactions is under three minutes of typing — and the people who end up preferring manual entry are disproportionately the ones who were forced into it once and noticed they were paying attention for the first time.
Why did every purchase import as income?
Because credit card exports sign amounts from the issuer’s point of view — a purchase increases what you owe, so it is written as a positive number, which is the opposite of a checking account.
This is the most consequential import bug there is, and it is silent: the rows all arrive, the amounts are all correct, and the direction of every one of them is inverted. A month where you spent two thousand dollars reports two thousand dollars of income, the cash-flow figure is wrong by four thousand, and nothing looks broken. Card files and bank files genuinely disagree about this, and a file that carries no explicit direction column cannot be read correctly without knowing which kind it is. The defences are worth insisting on in any tool: an explicit direction column where the format has one (OFX, QFX and QBO all do, which is a real argument for choosing them over CSV), and a preview that shows the direction of each row before anything is written. Check the first three rows of any card import. It takes five seconds and it is the difference between a ledger and a work of fiction.
Why are the dates wrong by a month after importing?
Because 03/04/2026 is the third of April in most of the world and the fourth of March in the United States, and a file with no other clue in it can be read either way.
The ambiguity is only visible on days after the twelfth. A file whose first twenty rows are all dated 01 to 12 gives a reader nothing to go on, and a wrong guess quietly moves transactions between months — so a January figure includes February’s rent and nobody notices until a total refuses to reconcile. There are three ways out and they are worth knowing which your tool uses. Some formats are unambiguous by specification: OFX, QFX and QBO write dates as YYYYMMDD, which is one of the better reasons to prefer them. Some exports are recognisable by their origin, so a file identified as coming from a particular app can be read with that app’s known convention. And failing both, the file can be scanned for any date whose first component exceeds twelve, which settles the question for the whole file. What a tool should never do is assume its own locale silently.
How far back can you actually download from your bank?
Usually twelve to twenty-four months for the spreadsheet export and several years for PDF statements, and the gap between those two numbers is the reason most people end up converting a PDF.
The pattern is near-universal and almost never explained on the download screen. The transaction export is capped — eighteen months is a common figure, and it appears as a greyed-out date rather than as a message. The statement archive is a different system with a different retention period, typically running back years and often to when the account was opened. People hit the greyed-out date, conclude that is all the bank kept, and stop. It usually is not. Before giving up on older history, check the statements or documents area rather than the activity export, check the desktop site rather than the mobile app since export is frequently desktop-only, and if the archive itself looks short, ask through the bank’s secure message channel — retention obligations mean the records generally exist even when the interface does not offer them.
How do you import several years of statements without making a mess?
Import one file at a time, oldest first, and check the running total after each one rather than loading twenty-four files and reconciling at the end.
Two years is usually twenty-four PDFs and one or two spreadsheet exports, and the temptation is to do it in one sitting and check afterwards. Do not: a systematic error — an inverted sign, a misread date convention, a balance column read as an amount — is trivially fixable on one file and a genuine afternoon to unpick across twenty-four. Going oldest first means the categories you create early are available to the later files, so you are not renaming things halfway through. And check the total after each import against the closing balance printed on that statement; if the two agree, that file is right, and if they do not, you have one file to look at rather than a year. Expect duplicates where the spreadsheet export and the PDF statements overlap in the middle — a good importer flags those on date and amount rather than on the description, because your bank and your old app describe the same transaction completely differently.
What should you do about the transactions that import with no category?
Leave them uncategorised until you have finished importing, then sort them in one pass — categorising as you go means inventing categories you will merge later.
Anything importing a raw bank file is guessing a category from a merchant name, and even a good guess rate leaves a tail. That tail is not a defect: an obviously unfinished row you can fix in a second is much better than a confident wrong one, which silently distorts a total for ever and is nearly impossible to find afterwards. The efficient way to clear it is in bulk and at the end, when you can see the whole set at once — you will find that thirty uncategorised rows are usually six merchants, and that the categories you would have invented on row four are not the ones you want by row two hundred. A bulk edit that sets a category across a selection turns what looks like an hour of work into about five minutes.