// Importing
How to Fix an Import That Looks Wrong
Rows set aside, sells with no shares behind them, splits, transfers, and duplicate warnings each have a specific cause. Here is what the preview is telling you and what to do about it.
Almost everything the import preview flags is one of six situations, and each has a specific answer. None of them mean the file is broken — they mean the importer found something it refuses to guess at.
// 01 · the trap
Zero warnings proves nothing
A clean run means no check tripped. It does not mean the totals match your broker — a file can import perfectly and still be missing an entire statement window, or carry fees the export never listed.
After a large import, verify in this order:
- Open positions and share counts against your broker’s.
- The account’s realized total against the statement’s.
- A couple of individual round trips end to end, including commissions.
// 02 · dedup
Duplicates and overlapping windows
Rows already recorded in the account are recognized and skipped, so importing January–June after already importing January–March adds only the new months. The preview says how many it recognized.
Skipping them avoids double-counting, and nothing already in your account is lost or rewritten. The alternative — importing everything — is a deliberate override for when you genuinely want the repeats.
// 03 · dropped
Rows that were set aside
Broker exports carry activity that isn’t a trade and carries nothing importable — journal entries, interest and fee lines, cancelled trades, transfers with no value, rows missing a usable date or quantity, and similar. The importer counts these and sets them aside rather than inventing trades from them, and says so in a notice on the preview.
The banner has a View link that names each bucket and the rows behind it, so “N rows were set aside” is inspectable instead of something you have to take on trust. Read it once — if something you needed is in there, that’s worth telling us about.
// 04 · stocks
Sells with no shares behind them
A sell can only reduce shares the account actually holds. When a file contains a sell whose opening buy is neither in the file nor already in your account, that row fails rather than conjuring a position — and it fails alone, leaving the rest of the import intact.
| Why it happened | What to do |
|---|---|
| The opening buy is in an earlier statement | Import that statement first, then re-run this one. The sell then finds its shares. |
| It was actually a short sale | Turn on short selling for the account — see the short-selling guide. |
| The shares were transferred in from another broker | Confirm the transfer in the preview and give it a carryover cost; the importer opens the lot for you. |
// 05 · options
Closes with no matching open
The same situation on the options side is handled differently, because a closing option fill is unambiguous: the importer matches it against the real open contracts already in your account, and the preview tells you which existing positions the import will close.
A close that still finds nothing to match is reported rather than dropped. The usual cause is the same as above — the opening trade lives in a statement you haven’t imported yet.
// 06 · corporate
Splits, transfers, and renames
Three kinds of row change a position instead of adding a trade. Two of them ask you something in the preview; the third tells you:
- Splits rescale the open position, and the ratio is always yours to confirm before the import can run. Applying one twice is prevented — see recording a stock split.
- Share transfers in have no cost in the file, because activity exports never carry it. The preview asks you for the carryover cost; unconfirmed transfers are simply skipped.
- Ticker renames are applied to the existing position and its trades rather than starting a new one. There is nothing to decide, so the preview announces the rename rather than asking — renaming existing data should never be a surprise.
// 07 · retry
Re-importing safely
Can I just run it again?
Yes. With duplicate handling on Skip, a re-import adds only what isn’t already there. That makes the safe fix for most problems “import the missing earlier statement, then re-run this one” — the previously failed rows find what they needed and land, and everything that already succeeded is recognized and skipped.
What if the mapping was wrong?
Before committing: the preview has an Adjust column mapping link that jumps back to the Map step, even when the wizard skipped it because the mapping looked complete.
After committing: rows written from a wrong mapping are ordinary trades — delete them and import again with the mapping corrected. Nothing about an import is special-cased against editing or deleting afterwards.