v0.1.12

v0.1.12 — 2026-06-01

Added

• Merchant city + state are now extracted from checking-account
  transactions. The LOC column in the Transactions view used to
  be empty for every checking row because the checking parsers
  (Chase, Wells Fargo, Bank of America, US Bank) didn't extract
  the trailing CITY ST pattern that credit-card parsers had
  been extracting since their first release. v0.1.12 wires the
  same extractor into all four checking parsers, so card-purchase
  rows ("Card Purchase 02/17 Tst*Merchant Fremont CA"), ATM rows
  ("ATM Cash Withdrawal 3700 ... San Francisco CA"), and any
  other description ending in a recognizable city + 2-letter
  state code now populate the column on new ingests. Rows that
  don't have a CITY ST tail (ACH, Zelle, wire transfers) stay
  empty — those don't carry location info in the source PDF.

• One-shot backfill migration extracts LOC on existing checking
  rows. On first launch of v0.1.12, the sidecar scans every
  checking transaction with a NULL merchant_city, runs the
  extractor on the original description, and writes the city +
  state back if anything was found. Idempotent. Title-case city
  names ("Fremont", "Newark", "San Francisco") are now correctly
  captured alongside the all-caps format ("FREMONT", "NEWARK")
  credit-card statements use.

Fixed

• Chase business-statement transactions were being tagged
  kind = deposit even when they were outgoing payments. Surfaced
  by a v0.1.10 user looking at Tax Summary — the "Outgoing
  breakdown" showed 14 transactions labeled "deposit" totaling
  $7,061.54, when in fact those rows were all real debits (Chase
  Credit Card autopay, 7-Eleven purchases, ATM withdrawals,
  Zelle payments) that just didn't match the parser's specific
  description regexes. Root cause: the classifier used the
  SIGN of the amount as its fallback ("amountCents > 0 →
  deposit"), but the business-statement parser passes an unsigned
  amount because Chase Business PDFs don't print a sign —
  direction is implied by which section the row sits in. The
  fallback then returned "deposit" for every business-row debit
  whose description didn't match a specific regex. The fix passes
  direction explicitly, so the fallback is now direction === 'credit' ? 'deposit' : 'purchase' — bug eliminated for new
  imports.
• One-shot backfill migration corrects existing wrong kinds.
  Same first-launch pass re-classifies every transaction whose
  (direction, kind) pair is the impossible state the bug
  produced (e.g., debit + deposit, debit + direct_dep).
  Re-classification uses the corrected classifier on the original
  description, so backfilled rows are indistinguishable from
  freshly-ingested ones. Tax Summary's Outgoing breakdown now
  reads what it should — credit card payments, ATM withdrawals,
  purchases, transfers, fees — not a single sweeping "deposit"
  bucket. Idempotent.
• Tax Summary's breakdown now shows "Deposits" and "Direct
  deposits" instead of the raw lowercase deposit /
  direct_dep strings. Polish — the friendly-label map in
  the on-screen view was missing those entries (the PDF builder
  already had them).

Notes for existing users

• Two safe backfill migrations run on first launch. No data
  loss possible — they only write transaction_kind (kind
  backfill) and merchant_city / merchant_state (LOC
  backfill), and only on rows where the values are impossible-
  state or NULL respectively. Existing values are never
  overwritten. Audit log captures the counts for traceability.
  Backups (Time Machine etc.) of your pre-v0.1.12 database
  remain readable by older releases.
• Tax Summary will look different on existing imports.
  Specifically, the Outgoing breakdown will redistribute what
  was previously a giant "deposit" bucket into the real
  categories. If you handed a v0.1.10 Tax Summary PDF to your
  CPA already, regenerate it on v0.1.12 — the totals (Income,
  Outgoing, Net) are unchanged, but the kind breakdown
  shifts.
• The Transactions view's LOC column will start showing values
  for checking transactions after upgrade. Specifically:
  card-purchase rows and ATM rows that have a trailing CITY ST
  in their descriptions. ACH (e.g. Chase Credit Crd autopay),
  Zelle, and wire-transfer rows continue to show "—" because
  there's no location data to extract.

---