[SamsonNegedu]

Summary

Search by amount        "12.50" exact · "12" = 12.00–12.99 · sign and € ignored
  Transactions page     SearchFilter ─ matchesAmountQuery (shared/utils)
  Trip › Transactions   new search box, kept in the URL as ?q

Trip cards              "-€380 left"  →  "€380.23 over what was put in" (red)

Transfer rows           subtext: "To …3000 · from …5678"  (last 4 of IBAN)

Rules                   new condition: other account's IBAN

 processTransactions
   categorizeWithRules
-    isTransfer / patterns  → Transfer
-    findRule
+    findRule               → a rule of yours wins
+    isTransfer / patterns  → Transfer (only if no rule)
   detectDoubleBookings
+    put the rule's category back

Why the rule order changed: without it an IBAN rule could never turn a credit to your savings account into Savings, because transfer detection ran first and double-booking re-filed it afterwards.

Evidence

• Before: typing 12.50 found nothing; a savings credit stayed hidden as Transfer with no way to tell which account it joined.
  After: npm test passes, API 228 and web 236. npm run check is clean.

matchesAmountQuery(12.5, '12,5')                       → true
matchesAmountQuery(12.99, '12')                        → true
findRule({recipientIban:'de89 3704…'}) w/ iban rule    → Savings
categorizeWithRules([own, other])                      → [Savings, Transfer]
CreateRuleSchema.parse({iban:'DE89'})                  → rejected

Not checked by eye in the running app.

Merge Danger

Door: two-way

No schema or data migration. A rule's IBAN lives in the already-encrypted match JSON, and older rules still work.

Blast Radius: categorizing

Any rule of yours now outranks transfer detection, so a broad rule (say a payee that also appears on a transfer) can turn a Transfer into a counted expense or income. The paired incoming side of a transfer stays excluded from income.

🤖 Generated with Claude Code