TL;DR

Chase Business exports use a Details field that gates how Description is formatted. ACH credits have the payer name; wire transfers have the sender bank info first; check deposits have nothing useful. Match on amount + date, fall back to manual review for check deposits. Disable the QB bank feed before running the CSV reconciliation or you’ll double-count.

What breaks when reconciling Chase with QuickBooks

I spent an entire month doing this combo for a 12-property real-estate client. Four things became routine:

The Details field is the rosetta stone. Chase’s CSV has a Details column with values like ACH_CREDIT, WIRE_INCOMING, CHECK_DEPOSIT, BUSINESS_DEBIT_CARD, etc. The Description field’s structure depends entirely on which Details value you have. ACH_CREDIT descriptions usually contain the payer’s company name; CHECK_DEPOSIT descriptions are useless (“REMOTE ONLINE DEPOSIT 47291”); WIRE_INCOMING descriptions start with sender bank info (“FED REF NO 12345… ORIG: ACME INC”) and you have to strip the prefix.

Posting Date vs Transaction Date. Chase shows both. They can differ by up to 3 business days for ACH and weekend timing. If you key your match by Posting Date but the invoice was actually paid on Friday, your date window logic will fail. Use Transaction Date for matching, Posting Date for the audit trail.

Check deposits have zero counterparty info. Mobile check deposits — a thing for any business handling rent or service contracts paid by check — show up as "REMOTE ONLINE DEPOSIT 47291" with no payer name, no invoice number, nothing. Pure amount-based matching only. Plan to manually verify any amount that has more than one open invoice at the same value.

QuickBooks bank feed already created these as ledger entries. If you connected the Chase feed in QB, every Chase transaction is already a Bank Deposit or Bank Debit in the QB ledger. Running our CSV reconcile on top creates duplicate evidence — same invoice appears as “Paid (QB matched)” and “Likely paid (CSV matched)”. Pick one workflow per period.

Export the Chase statement

  1. Log into Chase Business → Statements & documents (top nav).
  2. Select the account → pick the statement period → Download → CSV. Or for in-period reconciliation, use Activity → date range → Download → CSV (Comma-delimited).
  3. File arrives as Chase<account-last-4>_Activity_YYYYMMDD.CSV, all-caps extension. UTF-8, all fields quoted.

Columns: Details, Posting Date, Description, Amount, Type, Balance, Check or Slip #. Amount is signed — positive = credit, negative = debit. Type further refines the transaction (ACH_CREDIT subtypes include CCD, PPD, etc.).

The Check or Slip # column is populated only for check deposits. It’s the check number, which sometimes correlates with the invoice number if the payer wrote it on the check. Worth scanning manually for high-value checks.

Export the QuickBooks invoice list

  1. QBO → Reports → “Invoices and Received Payments”.
  2. Date range: extend the start by 30–60 days before the Chase statement period — invoices issued in March can be paid in April.
  3. Export → Export to Excel. The export saves as .xlsx; we usually save-as .csv for batch processing.

Columns: Date, Transaction Type, Num, Name, Memo/Description, Amount, Balance. Two row types per invoice: the Invoice line and (if paid) a separate Payment line. Filter to Transaction Type = Invoice for the open-receivables view; keep both if you want to see what QB already recorded as paid.

Match algorithm cheats for this combo

  1. Details-aware description parsing. For Details = ACH_CREDIT, the payer name is usually the second tokenized segment in Description. For Details = WIRE_INCOMING, strip everything before the first occurrence of "ORIG:" or "ORG:" to isolate the originator. For Details = CHECK_DEPOSIT, skip description parsing entirely.
  2. Amount-first with date window. Match Chase Amount against QB Amount. For check deposits especially, this is your primary signal. Use a ±7 day window: checks take time to deposit after being received.
  3. Fuzzy name match (where description is useful). After stripping ACH/wire prefixes, fuzzy-match against QB Name. Chase ACH descriptions are typically uppercase — QB names are mixed case — normalize both to lowercase before Jaro-Winkler comparison.
  4. Check number heuristic. When Check or Slip # is populated and you have multiple open invoices at the same amount, try matching the check number against the last 4 digits of Num in QB. Long shot, but free precision when it hits.
  5. Reverse-direction de-dup. Before running matches, query QB for any Transaction Type = Deposit rows in the same period. If a Chase row’s Reference matches a QB Deposit’s Memo, the bank feed already pulled it in — skip to avoid double-counting.

Real example

Chase ACH inflow:

"ACH_CREDIT","04/18/2026","ORIG CO NAME:ACME CONSULTING ORIG ID:1234567890 DESC DATE:042026 CO ENTRY DESCR:INV-2207     SEC:CCD","8500.00","ACH_CREDIT","145232.50",""

QB invoice line:

2026-04-01,Invoice,2207,Acme Consulting LLC,"April retainer + project hours",8500.00,8500.00

After parsing: extract "ACME CONSULTING" from the ACH description, normalize to lowercase, fuzzy-match against "acme consulting llc" — score 0.91. Amount exact. Invoice number 2207 extracted from CO ENTRY DESCR:INV-2207 matches QB Num = 2207. Confidence: Exact (multi-signal).

Edge cases this combo hits

ACH same-day vs next-day settlement. Chase processes inbound ACH in two batches per business day. A 3pm-initiated payment may post same-day or next-day depending on the sender’s bank. If your invoice has Net-15 terms and the payment hits the bank 16 days later, the date alone might push it into the wrong aging bucket — check Transaction Date, not Posting Date.

Returned ACH (R-series codes). If a payer’s ACH bounces, Chase posts the original credit then a debit a few days later with Description containing "RETURNED" or specific R-codes (R01 = insufficient funds, R02 = closed account, etc.). Pair the two rows by amount + payer; treat the net as unpaid.

Wire transfers from non-US banks. International incoming wires through Chase go through an intermediary correspondent bank. The Description will sometimes show only the correspondent bank’s name, not the originator. The originator info is typically in the wire details, accessible via the Chase web detail view but NOT in the CSV. For these, manual matching is required.

Multi-deposit batches. If a client pays you 3 invoices with a single wire (total amount = sum of invoices), Chase shows one row. QB shows three separate invoices. Match Chase amount against the sum of any combination of open QB invoices for the same payer — our matcher does subset-sum within payer scope.

When this combo breaks our tool

Our matcher handles check deposits in “amount-only” mode, but if you have more than 5 open invoices of the same amount and a generic REMOTE ONLINE DEPOSIT row, we’ll bucket it as “Likely paid” without a confident assignment. Manual review in the result view.

Chase’s CSV doesn’t include FedWire reference numbers in the standard download. If you need wire-trace precision (audit, compliance), you have to pull the wire detail PDF from the Chase web view separately — outside our tool’s scope.

When the QB bank-feed integration is on, our CSV reconcile will partially overlap with QB-internal matches. There’s no automatic detection. Best practice: snapshot QB’s “Bank Register” before running our reconcile and compare deltas after.

Faster way

Drop the Chase Activity CSV + QB invoice report into the reconciler on the homepage. The Details-aware description parsing, the ACH prefix stripping, and the multi-deposit subset-sum logic all run automatically.

If you’re newer to bank reconciliation as a process, the bank reconciliation glossary entry covers the conceptual frame.

For the ACH-specific terminology that shows up in Chase descriptions, the ACH payment glossary entry explains the codes and conventions.