Sometimes a data source never records a fund's share split. The price series then shows a cliff. A fund may appear to have "fallen" 75% overnight on a 4:1 split, and every return computed across that date is garbage.
A manual split is the repair: you record the date and ratio, and the app applies the correction as a read-time price factor on the split's side of history. The stored downloads stay exactly as the source delivered them.
Why read-time, not rewrite
- The raw series remains a faithful copy of the source, so re-downloading or switching price sources can never double-apply a correction that was baked into the rows.
- The fix is reversible and auditable: delete the manual split and you're back to exactly what the feed said.
The app can also detect likely missed splits from your own ledger. The signal is a trade's execution price against the stored close for that day: a trade fills at the as-traded price, so a close that is a suspiciously round multiple smaller (or larger, for a reverse split) says a split is missing from the feed. A reinvested distribution can corroborate the ratio at the moment the split is recorded, but it is not what finds one. The Dashboard banner shows the date and ratio it derived and asks you to confirm before writing it.
Dismissal means "hide this evidence for now," not "this ticker is fixed." The exact candidate is hidden for 180 days using an opaque SHA-256 database scope plus all of the detector evidence; the saved value never exposes the portfolio file path. A changed ratio, date, compared price or corroborating sample, or the same ticker in another database, remains a different visible candidate. Legacy ticker-only dismissals are discarded so an old broad choice cannot hide new evidence.
A detected split is recorded a little differently from one you type in yourself: it scales share counts but leaves the close alone (the source already adjusted the price but missed the split row), and it is kept through a price rebuild, because a re-fetch can never restore a split the provider never reported. The trade-off is that it doesn't appear in the Manual splits list on Ticker Metadata, so there's no one-click undo. That is why the Dashboard asks first.
When a date is already taken
A date can hold only one split. If the one you type falls on a date that already carries a downloaded or detected split, that row is left alone and the save says so, naming the date and which kind of split is sitting there. The rest of your list still saves. This is deliberate: the three kinds correct prices differently, so silently replacing one with another would change every value on that side of history, and a detected split can never be downloaded back once it's gone. Either remove that date from your list, or delete the existing split first and then record yours.
Don't "fix" a missed split by editing prices or share counts directly: the correction then lives in two places, and the next data refresh quietly breaks one of them. The manual-split row is the one designed home for it.