Chase CSV to QBO Converter

Chase does not have one CSV format, it has two, and they share almost nothing. A checking or savings download opens with a Details column that flags each line as a debit, credit, or check, then gives you a Posting Date, a Description, a signed Amount, a granular Type such as ACH_DEBIT or DEBIT_CARD, a running Balance, and finally a Check or Slip number that is blank on most rows. A credit card download from the same login has two date columns instead of one, adds a Chase-assigned spending Category, and drops the Balance and check-number fields entirely. Mapping that worked yesterday on the operating account will not work today on the card.

The good news is that Chase gets the parts that matter right. Dates are written as MM/DD/YYYY, which converts without ambiguity. Amounts are signed the way the OFX standard expects — negative for money out, positive for money in — on both the checking and the card layouts, so nothing needs inverting. And the Description text is the full merchant string rather than a truncated abbreviation, so what shows up in QuickBooks for review is legible enough to categorise from. Three columns are all that has to be identified: a date, a description, and an amount.

Converting to QBO rather than uploading the CSV to QuickBooks matters most for the review step. A QBO file is what QuickBooks Online receives from a working bank feed, so an uploaded one lands in the same For Review queue and behaves the same way: the account is declared inside the file, every transaction carries an identifier, and no column-mapping dialog stands between you and the import. This is the usual route for a Chase business account that never got a working feed, for backfilling the gap left when a feed disconnects mid-quarter, and for a bookkeeper handling several Chase accounts who would rather see the file before it touches the books.

The column mapping I saved for checking is wrong on my credit card file. It is not a saved-setting bug — the two Chase exports genuinely have different columns in different positions. Checking leads with Details and has a single Posting Date; the card export leads with Transaction Date and has two date columns. Re-map every time you switch account type, and confirm you picked Post Date rather than Transaction Date on card files.

Converting the same Chase file twice created duplicates in QuickBooks. A CSV has no transaction IDs in it, so the converter generates a FITID per row from the moment of conversion. Convert the file once and import that one QBO. Running the same CSV through again produces a fresh set of IDs, and QuickBooks has no way to recognise the transactions as ones it already has.

A few amounts imported as the wrong number. Currency symbols and stray spaces are stripped harmlessly, but a thousands separator is not: a value like 1,234.56 is split at the comma while the file is being read and the row is knocked out of alignment. If Chase or an intermediate edit in Excel introduced separators, remove them before converting — this is the single most common cause of a garbled amount.

Downloaded transactions overlap what the bank feed already brought in. Feed transactions and uploaded ones carry different identifiers, so QuickBooks treats them as separate and both land in For Review. Convert only the date range the feed missed. If duplicates are already in the queue, exclude them there rather than adding and deleting them from the register.