Help · Methodology

How suggested trades are computed

From RangefinderInvest's built-in help · applies to version 0.49.3

Suggested trades come straight from drift, measured per fund: each fund in a slice carries its own share of the slice's target, and its row is that fund's current dollars minus that target. The slice's drift is never divided up after the fact, and there is no per-broker fund list. Every account assigned the model uses the same one. Two knobs keep the list practical:

  • Drift threshold: a row within this many percentage points of target shows Hold: close enough that trading it buys nothing.
  • Minimum trade size: orders smaller than this show Hold ("below minimum") so the page never nags about a $40 trade. Zero disables the floor.

Reading the table

  • When any action exists, the first view shows Add, Reduce, Close and Deploy. Holds remain available through the plainly labelled Show N holds control; every chip can still be combined. While untouched, this action-first default follows the live rows when thresholds, minimum trade, models, holdings, account selection or the open database changes. Changing any action filter, including Show all, marks it custom and preserves that selection for the rest of the session, including across a database switch.
  • The compact Order summary is computed from all rows in the selected accounts, not the current action filter. Filtering the table therefore never changes the order count, add/reduce totals, closure count, deployable cash or tax estimate above it.
  • Add / Reduce are directions, not orders. They are illustrative dollar amounts toward target, with a suggested order string you can adapt.
  • Close is a Reduce all the way to zero: the model holds none of this, so the whole position would go. It reads differently from a trim on purpose. A model you adopt closes everything it doesn't include, and that is the number to see before you commit.
  • Deploy rows are uninvested core cash: cash counts toward the account total and is available to buy into the model, but it is never "sold", so it's surfaced separately from Add/Reduce.
  • If your model holds a cash slice, that same row carries its target, and your core cash is what fills it. There is nothing to buy. Above target it reads Deploy for the excess only; below target it reads Raise, funded by the Reduce rows above it; within the drift threshold it sits On model. A model with no cash slice targets 0% cash, so any balance is always flagged to deploy, however small.
  • The Dashboard's Est. rebalance chip is half the gross two-sided volume: buys plus sells, divided by two. That equals the buy side only when the two match; deploying cash or closing a position makes them differ, and the halved figure then understates the larger side. The Rebalancing page's own turnover banner shows the gross sell side for that reason, and both read louder when the plan would close positions: a full liquidation is not a routine trim, so it should not look like one.
  • Est. realized tax is the lot-level gain those sells would trigger, at your assumed long- and short-term rates (the same estimate the Withdraw mode uses). The summary shows an Unknown result with cost basis needed until every named sale can be estimated, never a false $0.

The combined Action / order column stays pinned at the right edge while middle columns scroll. A Close row has its own full-exit treatment; ordinary reductions stay neutral so the warning remains meaningful. Review opens the row facts and source explanation without making the table row itself pretend to be a button.

Export CSV · visible rows follows the current account and action filters. Hidden actions and Holds are omitted because the label says they are; use Show all first when you want every row. Numeric cells stay raw for formulas.

When there's nothing to trade

Only after the page has a mode-eligible account, a valid assigned model, an executable allocation and usable holding values can it conclude that there is nothing to do. If every usable row sits within the drift threshold, the page says Nothing to trade because the account already matches its model. Rows held only because they fall below the minimum trade are identified as below minimum; they are not described as on target. Missing prerequisites instead name the problem and link directly to Accounts, Target Models, Holdings or Settings price data.

This is exactly what you see right after building a model from your current holdings: the model is your holdings, so nothing has drifted yet. A model built from an account that holds individual stocks folds them into a self-directed slice, which tracks the slice's size and leaves your own picks alone. It stays "nothing to trade" until the slice's overall weight drifts, never because one of your stocks ran ahead.

One honest caveat

If the same ticker fills two slices in one model, the full account holding is counted in each row (the app can't know which shares "belong" to which slice), so those rows' Current and Drift figures overlap, so they're flagged with a ⚠ rather than silently split.

These are estimates from your latest downloaded prices, not advice and not executable orders. Verify against live quotes before trading.