1. Problem
Users with multiple accounts (business, personal, savings, joint, foreign currency, brokerage) can’t see in the app how money flows between their accounts within a given cycle. The dashboard shows balances and spending categories, but doesn’t answer questions like:
- “How much from the last invoice actually stayed in savings, and how much was just passing through?”
- “Which account did the transfers to savings come from?”
- “What’s still waiting to be paid this cycle?”
Currently, such analyses are done ad hoc in chat with AI as a text-based graph — without access to per-account data, which forces heuristics and guesswork (see: the bug with missing account_id and per-account balances in the analytics context).
2. Proposal
An interactive, native “Flows” view (tab next to Assets / Spending), rendered for a selected financial cycle or calendar month:
2.1. Graph structure
- Input nodes — income sources (invoices, salary, interest) with amounts.
- Account nodes — each user account as a separate node with two values: inflow for the cycle and balance after flow.
- Output nodes — expenses grouped by category, with amounts.
- Edges — transfers with amounts; color/type distinguishes internal transfers (transit) from actual expenses.
2.2. Key features
- Semantic color coding: green = savings/investments (money stays in user’s system), yellow = transit between accounts, red = expenses (money leaves).
- Cycle summary: how much went to savings vs. expenses vs. transit — as a bar/table below the graph.
- Time perspective: toggle between financial cycle ↔ calendar month; time slider for animating flows.
- “Awaiting payment”: section with predicted, not-yet-paid obligations for the cycle (taxes, installments, fixed charges) — based on detected payment patterns.
- Interactivity: click on node/edge → drill-down to transaction list; hover → transfer details.
2.3. Required data (dependencies)
This feature requires closing the data gap first:
account_idper transaction — propagating the source account identifier to the analytics layer (today transactions are aggregated per bank).- Balances per account — from the
GET /accounts/{id}/balancesendpoint, refreshed with each sync. - Mapping accounts to roles — user-configurable (business / personal / savings / joint / foreign currency / brokerage), stored in profile; AI can suggest them automatically based on transaction patterns (e.g., invoice inflows + social security → business).
Without points 1–2, the graph will have the same problem as the current chat solution: assumed directions, not confirmed ones.
3. User value
- Awareness, not just records: users see what portion of income actually stays (savings) vs. leaves — in one view instead of manual reconstruction.
- Habit verification: e.g., “~17% from each invoice lands in savings” becomes immediately visible.
- Obligation control: the “awaiting payment” section prevents surprises at the end of the cycle.
- Reduced AI queries: the graph answers a class of “where did my money go” questions that today generate lengthy chat analyses.
4. MVP scope vs. extensions
MVP
Static graph per cycle: accounts + flows + expenses by category, semantic colors, summary table
v1.1
Balances after flow, drill-down to transactions, “awaiting payment” section
v1.2
Time animation, cycle comparison, automatic account role mapping suggestions
- Risks
- Data quality: without
account_idper transaction, the graph will be misleading — the feature should only launch after closing the data gap (or with clear marking of heuristic assignments). - Visual complexity: with >8 accounts, the graph becomes unreadable — grouping needed (e.g., collapsing foreign currency accounts) and limits on spending nodes (top N + “other”).
- Internal transfer classification: detecting internal transfer pairs (same amount, same day, two accounts) must be robust against missing data and currency conversions.