Personal Finance Manager

0Overview

A personal finance application that gives the user a single, unified view of all their accounts, income, and expenses, and helps them understand where their money is going and where it's headed next.

Assumptions made while drafting this doc — flag any that are wrong

Single user per instance (no multi-user households/shared accounts) — at least for v1.
The user manually maintains balances (no bank sync/Plaid-style integration) — at least for v1.
Mobile-first application.
Amounts are entered by the user; no automatic transaction import (no bank sync/Plaid) — manual transaction logging instead (see section 3, now in v1).

1User Profile Configuration

1.1 Accounts

User can add one or more financial accounts. Each account has:
- Name (free text, e.g. "Chequing", "TFSA - Wealthsimple")
- Type: Chequing, Savings, Credit Card, TFSA, RRSP, Crypto, Investment, Loan, Other (extensible list)
- Current balance
- Currency (see 1.4)
- Optional: institution name, account color/icon for visual identification
User can edit or delete an account after creation.
Credit card / loan accounts should support a negative balance / balance owed distinct from asset accounts (see 4.4 net worth calc).
Optional: credit limit field for credit cards, to show utilization.

1.2 Income / Paycheck Configuration

User designates which account receives the direct deposit.
User sets pay frequency: Weekly, Bi-weekly, Twice a month (semi-monthly), Monthly.
Paycheck amounts are not fixed — they vary deposit to deposit. The app only tracks the schedule (frequency + next expected date) up front; there is no fixed "pay amount" configured during setup.
The user manually enters the actual deposit amount each time a paycheck lands, via a confirmation action (e.g. "Confirm deposit" prompt on/after the expected date). This logged amount becomes the basis for that paycheck's allocation (1.3) and a corresponding income transaction (section 3).
Minimum income value: the user also sets a minimum expected paycheck amount per income source during setup (a conservative floor, e.g. "I never make less than $X"). This is used instead of an average/last-deposit guess anywhere the app needs to project with an unconfirmed paycheck (see 2.3), so projections don't overstate available funds.
Until the user confirms a given paycheck, the dashboard's "next direct deposit" (2.2) shows the expected date only; the minimum income value may be shown alongside it as a conservative floor, clearly labeled as such (not a prediction of the actual amount).
Support for more than one income source (e.g. two jobs, side income) — confirm if needed for v1 or if single income is acceptable to start.

1.3 Paycheck Allocation Rules

User defines a distribution of each paycheck across accounts, e.g.:
- 10% → RRSP
- 10% → Savings
- Remainder → Chequing (default/receiving account)
Validation: percentages across all rules must not exceed 100%.
Each allocation rule references one target account and either a % or a fixed amount.
These allocations are planned/expected transfers — the app should show them as upcoming/scheduled, not assume they happened automatically unless there's a bank sync (out of scope for v1).

1.4 Currency Settings

User sets a main/base currency for the whole app (used for aggregated totals, net worth, dashboard summaries).
Each account has its own currency, which may differ from the main currency (e.g. USD account, EUR account, crypto "currency").
App converts each account's balance into the main currency for aggregate views, using a live exchange rate API (fetched at display time or on a short refresh interval — e.g. hourly/daily cache to avoid excessive API calls).
If the exchange rate API is unreachable, the app should fall back to the last successfully fetched rate and indicate that the rate may be stale.

1.5 Recurring/Monthly Expenses

Recurring/monthly expenses are always fixed amounts (e.g. Rent, Streaming, Subscriptions, Insurance). User can add: name, category, amount, currency, frequency (weekly/monthly/yearly), due date/day, and the account it's paid from.
User can edit, pause, or delete a recurring expense.
Variable expenses (e.g. groceries, one-off purchases) are not configured as recurring expenses at all. They are not part of the monthly expenses list/rate. Instead, the user logs them as a regular ad-hoc expense transaction (section 3) at the moment the purchase happens, with an amount, category, and account.
This distinction matters for the dashboard: "upcoming bills" (2.3) is built only from fixed recurring expenses, since variable expenses have no predictable due date or amount to project.

1.6 Editing the Profile

All of the above (accounts, income, allocation rules, currencies, recurring expenses) must be editable after initial setup, not just configured once during onboarding.

2Home Dashboard

2.1 Accounts Overview

List/grid of all accounts with current balance, in the account's native currency, plus its converted value in the main currency.
Total net worth (sum of asset accounts minus liabilities like credit cards/loans), in main currency.
Visual grouping by account type (optional: cash vs. investments vs. debt).

2.2 Next Direct Deposit

Shows the expected date of the next paycheck and which account it lands in. Since paycheck amounts vary, no fixed amount is guaranteed ahead of time; the minimum income value (1.2) may be shown as a conservative floor, clearly labeled as such — not a prediction of the actual amount.
On or after the expected date, the dashboard prompts the user to confirm the deposit by entering the actual amount received.
Once confirmed, shows the resulting allocation breakdown for that paycheck (per section 1.3), calculated against the actual entered amount.

2.3 Upcoming Bills

List of upcoming recurring expenses within a configurable window (e.g. next 7/14/30 days), sorted by due date.
Indicates which account each bill will be paid from, and whether that account will have sufficient balance by the due date (requires basic projected-balance logic).
For any unconfirmed paycheck that falls within the projection window, the projection uses the minimum income value (1.2) rather than an average or last-deposit guess, so the "sufficient funds" check stays conservative and doesn't overstate available money. Once a paycheck is confirmed (2.2), the projection switches to the actual confirmed amount.
Flags overdue or "insufficient projected funds" cases.

2.4 Cash Flow Snapshot Suggested addition

Simple projection: balance trend for the receiving account between now and the next paycheck, factoring in scheduled bills and, for any unconfirmed paycheck in range, the minimum income value (1.2) as the conservative baseline.
Helps answer "will I be okay until payday?" — this seems like the natural payoff of tracking paycheck + bills together, so it's worth including even though it wasn't explicitly requested.

3Transaction Tracking In scope for v1

User can log actual transactions (income, expense, transfer between accounts) that affect account balances.
A transaction has: date, amount, currency, account, category, optional note, and type (income/expense/transfer).
Three ways a transaction gets created:
1. Recurring expense (fixed) — auto-generates a pending transaction on its due date, which the user confirms/edits/deletes once it actually happens (1.5).
2. Variable/ad-hoc expense — user manually logs it at the moment the purchase happens (1.5).
3. Paycheck deposit — user manually confirms the actual amount when a direct deposit lands (1.2, 2.2), which also generates the allocation transfer transactions per the allocation rules (1.3).
Account balance = manually-entered starting balance + sum of all transactions. This keeps balances current without needing bank sync.

4Budgeting & Categorization Suggested addition

Expense categories (Rent, Groceries, Subscriptions, etc.) should be a manageable list, user-editable.
Optional: monthly budget target per category, with dashboard indicator of spend vs. budget.

This can be deferred to a v2 if you want to keep scope tight for a first build.

5Reports & Analytics v2

Historical net worth over time (chart).
Spending by category over a selected period.
Income vs. expenses trend.

6Notifications v2

Reminder before a bill is due.
Alert when a projected balance would go negative before the next paycheck.
Delivery mechanism: in-app only, or email/push? Needs a decision, but deferred to v2 planning.

7Multi-Currency Handling — Details

Live exchange rate API is used for all conversions (see 1.4), with a short caching window to limit API calls.
All aggregate figures (net worth, dashboard totals) computed in main currency at time of display, using the current live rate.
For v1, individual transactions can simply store the rate at the time they were recorded (for basic accuracy), even though historical trend reporting itself is deferred to v2 (section 5). This avoids having to retrofit rate history later.

8Non-Functional Requirements

Data privacy/security: this is sensitive financial data — requires authentication (login), encrypted storage of balances/account data, and no third-party data sharing.
Platform: mobile-first. UI/UX should be designed primarily for phone screen sizes and touch interaction (e.g. quick-entry flows for logging a variable expense or confirming a deposit on the go); a web/desktop layout can follow later but should not drive the initial design decisions.
Performance: dashboard should load account summaries and upcoming bills quickly (sub-second for a single user's data set).
Data persistence: all user-entered data (accounts, expenses, allocations, transactions) must persist reliably between sessions.
Backup/export: ability to export data (CSV/JSON) for the user's own records — worth including given the sensitivity of financial data.

9Data Model (entities, high-level)

User: profile, main currency, auth credentials
Account: id, name, type, currency, balance, owner (user), credit limit (optional)
IncomeSource: id, receiving account, frequency, next expected pay date, minimum income value (conservative floor; no fixed/expected amount, since actual deposits vary)
AllocationRule: id, income source, target account, percentage or fixed amount
RecurringExpense: (always fixed) id, name, category, amount, currency, frequency, due day, source account
Transaction: id, account, date, amount, currency, category, type (income/expense/transfer), exchange rate used (if cross-currency), linked recurring expense (optional), linked income source (optional, for confirmed deposits)
ExchangeRateCache: currency pair, rate, last-fetched timestamp (short-lived cache backed by the live API)

10Open Questions to Resolve Before Build

Is bank-account sync (Plaid or similar) in scope, or fully manual entry for v1? (current assumption: manual entry, with transaction logging as described in section 3)
Single income source or multiple?
Multi-user/household support — now or later?
Budgeting/category targets — v1 or v2?
Which live exchange rate API/provider to use, and how often to refresh the cache (real-time vs. hourly/daily)?
Notification delivery channel for v2 — in-app, email, push, or a combination?

Resolved

Mobile-first platform; live exchange rates; recurring expenses are fixed-only; variable purchases are ad-hoc transactions; paycheck amounts vary and are user-confirmed per deposit, with a minimum income value used as the conservative floor for projections; manual transaction logging is in v1; reports/analytics and notifications are v2.

11Suggested Phasing

v1 (MVP) v1: Sections 1, 2, 3, 7, 8, 9 — accounts, income/allocation config (with per-deposit confirmation), fixed recurring expenses, manual transaction logging (variable expenses + deposit confirmations + recurring-expense confirmations), live exchange rate conversion, mobile-first dashboard with balances/next paycheck/upcoming bills/cash flow snapshot.
v2 v2: Notifications (6), Reports & Analytics (5).
v3 v3: Budgeting & Categorization (4), if still wanted beyond simple category tagging.