Investment Trade Conversion#

Investment trade conversion bridges the gap between raw synced investment transactions and properly structured trade records that drive portfolio tracking (holdings, cost basis, total return). Synced data from providers (SnapTrade, IBKR, Trading212, IndexaCapital) arrives as Transaction entries; conversion ensures security-level activity is stored as Trade entries with qty, price, and security_id so the portfolio engine can calculate accurate holdings. 1

Sure's data model uses Rails delegated types: an Entry (date, amount, account) points to one of Transaction, Trade, or Valuation. Both Transaction and Trade share the investment_activity_label field drawn from the canonical set in Transaction::ACTIVITY_LABELS 2.

Activity Label Assignment#

Each provider processor maps its native type strings to Sure's canonical labels via a hash constant before persisting entries through Account::ProviderImportAdapter.

Each processor also routes activity to either import_trade (security-level, e.g. BUY/SELL/REI) or import_transaction (cash flows, e.g. DIVIDEND/CONTRIBUTION/FEE) using TRADE_TYPES and CASH_TYPES constants. 3

The adapter auto-detects obvious labels from the transaction name when none is passed, and defaults Trade entries to "Buy" / "Sell" based on qty sign when no explicit label is provided. 4

In the transaction list UI, the category column is replaced by a color-coded quick-edit activity label badge for all accounts where supports_trades? returns true. 2

Dividend and Interest Handling#

Dividends and interest recorded manually are always stored as Trade records (not Transaction), with qty: 0 and price: 0 so they don't affect share counts — only the cash balance. 5

• Dividend trades require a security (the holding the income is attributed to). 6
• Interest trades allow an optional security; if omitted, the Security.cash_for(account) synthetic cash security is used. 5
• SnapTrade-synced dividends and interest arrive as Transaction entries (in CASH_TYPES), not Trade entries — a key distinction from manually entered income. 6

Critical bug fixed in PR #2673: Income trades (qty: 0) were feeding price: 0 into PortfolioCache#load_prices, overriding market prices and wiping holdings to $0. The fix filters qty == 0 trades out of trade price sources and separates them from regular trades in Balance::BaseCalculator#flows_for_date. 7

Manual Conversion (Transaction → Trade)#

A user-facing Convert to Trade flow lets users upgrade synced Transaction entries into proper Trade records when the transaction represents a security buy or sell.

Entry points:

• The quick-edit badge carries a convert_url pointing to convert_to_trade_transaction_path. 2
• GET /transactions/:id/convert_to_trade renders a modal with ticker/qty/price fields. 8
• POST /transactions/:id/create_trade_from_transaction processes the conversion: resolves the security via Security::Resolver, calculates missing qty or price from the transaction amount, creates a new Entry with a Trade entryable, marks it user-modified and import-locked, then marks the original Transaction as excluded: true. 9

The trade type (Buy/Sell) is inferred from the transaction amount sign: negative amount = money in = sell. 10

Provider Sign Normalization#

Sure's internal convention: inflows to an asset account are stored as negative amounts; outflows as positive. This is asserted in Entry#classification (amount.negative? ? "income" : "expense"), Transfer::Creator#inflow_transaction, and Balance::ForwardCalculator#signed_entry_flows. 11

Each provider processor normalizes raw amounts before calling the adapter. Two known sign bugs affect the SnapTrade and IndexaCapital processors:

SnapTrade — bare TRANSFER type (#2756)#

SnaptradeAccount::ActivitiesProcessor#normalize_cash_amount handles TRANSFER_IN and TRANSFER_OUT explicitly but has no branch for bare TRANSFER. Fidelity 401k contributions sent as type: "TRANSFER" with a positive amount fall through to the else branch, storing the provider's raw amount unchanged (positive) — which Sure's convention interprets as an outflow, producing a declining balance chart and negative display. 12

The suggested fix: add a when "TRANSFER" branch that inverts the provider's sign (-amount) since SnapTrade uses positive = money-in for this type. 12 A PR is in progress.

User-modified entries will not self-heal — entries edited by the user have user_modified: true set and are skipped on re-sync. The transaction detail page's unlock control (POST /transactions/:id/unlock) clears this flag. 12

IndexaCapital — inverted convention (#2793)#

IndexaCapitalAccount::ActivitiesProcessor#normalize_cash_amount applies the opposite sign convention: money-in types (CONTRIBUTION, DIVIDEND, INTEREST) get amount.abs (positive) and money-out types get -amount.abs (negative) — the reverse of SnapTrade and of Sure's stated convention. 11

This is currently latent (not user-facing): Provider::IndexaCapital#get_activities returns nothing, so raw_activities_payload is always blank for Indexa accounts and the processor never runs on real data. The scaffolding is also missing an activities_processor_test.rb. 11

Key Source Files#

Related KB articles: Broker Activity Import · Provider Import Adapter · Investment Activity Labels · Dividend and DRIP Modeling