Chase bank statement to CSV. One row per transaction, and the sign convention the import screen expects.
A CSV is judged at the import screen, not on this page: amounts as text, a repeated page header in the middle of the file, or a debit column that should have been negative will all bounce or, worse, import cleanly and be wrong. The file is written only after the balance chain has been checked, so what you import already adds up.
Drop a Chase statement here
Or click to pick the file. It opens in the same page you would have used anyway — the balance chain starts re-adding on the next screen.
Three files free, 60 pages in total, no card needed. Paid plans are priced by the page — one page of the original is one page, up to 500 pages in a single file.
The failure is silent, and it happens after you have closed the tab
Most bad bank imports do not throw an error. They land 480 rows where there were 500, or they read every withdrawal as a deposit because the sign lived in a separate column. Nobody notices until the reconciliation is off by an amount that has no obvious owner. The CSV produced here is built from rows that already passed a balance check, and the count of rows printed vs rows exported is stated before you download.
What gets checked before you download
Every line below is arithmetic on the paper you sent — not a supplier's claim about how good its reading is. Where the arithmetic fails, you get the row and the exact difference, and the statement is not called balanced.
Rows printed vs rows exported
The count is stated. If the reader could not account for every line on the page, the file says so instead of shipping a shorter ledger that looks complete.
Debit and credit kept apart
Two numeric columns, or one signed amount column — your choice, applied consistently. The sign is derived from the statement's own columns, never from a guess about the description.
Dates written in one order
US statements are month-first. The CSV writes ISO dates so the receiving system cannot re-interpret 03/04/2026 under a different locale.
Headers and totals kept out of the data
Repeated page headers, 'continued' markers and subtotal rows are removed before the file is written. They are the most common reason an import produces phantom transactions.
Where a Chase statement goes wrong quietly
None of these announce themselves. Each one produces a file that looks correct.
The header row that appears four times
Multi-page statements repeat the column headings. In a CSV that becomes a transaction whose description is 'Date Description Amount'.
Page numbers sitting in the amount column
A lone integer near the edge of the page is usually the folio, not money. It gets flagged when it cannot be tied to a dated line.
Encoding that mangles merchant names
The file is UTF-8 with a BOM and CRLF endings by default, so accented names survive a double-click in Excel; plain UTF-8 is available for pipelines.
What we will not claim
We will not promise that your import screen accepts it. Column order and sign convention are documented, but the receiving software owns its own rules, and we have not tested against your particular version of it.
The same goes for the arithmetic: a clean run means the checks we ran found nothing to flag. It does not mean the document is correct — it means nothing in it failed the checks listed above.
How it runs
Upload the statement
A native PDF, a scan, or a phone photo of the Chase statement. No bank connection, no credentials, nothing to authorise.
The ledger is rebuilt and walked
Rows are put back in the order the statement prints them, page furniture is removed, and the balance chain is re-added line by line.
Check the flags, then export
Anything that did not add up is listed first, with its page and exact difference. Then take the CSV file, the other export shapes, and the review sheet.
What lands on your disk
- The .XLSX register — one row per transaction, no merged cells, amounts as numbers
- A Review sheet: who confirmed or corrected which cell, and what it said before
- Plain CSV, Xero-shaped CSV, and QuickBooks .QBO with unique transaction IDs
- A check report stating the rows printed, the rows exported, and every difference found
- Every cell still clickable back to the page and region it was read from
- Files are read, then destroyed — a second upload is a second read
Questions
What columns does the file have?+
Date, Description, Debit, Credit and Balance by default, or Date, Description and a single signed Amount — whichever the destination wants. The balance column is the one printed on the statement, not a recomputed figure.
Can I get CSV and QuickBooks from the same upload?+
Yes. The upload is read once; the exports are written from the same checked ledger, so the .QBO and the CSV cannot disagree with each other.
Does the CSV carry the review trail?+
The CSV stays import-clean, so the trail lives beside it: the .XLSX workbook, the review report, and the workspace itself, where every row still points at the page it was read from.
What does it cost?+
Three files are free, 60 pages in total, with no card and no account needed to try. Paid plans are sold by the page — $19 a month buys 1,000 pages — and a page is one page of the original document.
For the working paper you have to be able to defend.
For the import where QuickBooks decides whether a row is already there.
The same checks, without naming a bank — including the ones whose layouts we do not recognise.
A .QBO with the institution, the account and a transaction ID per row, so a re-import is refused.