Importing a supported Fidelity or Schwab transaction-history export gives an account a trade ledger, cost basis, realized gains, income, and daily value history. CSV support follows the explicit broker format, not a custom institution name.
- Export the right date range. Before a file is chosen, the drawer says where this account's history ends and which date to export from. Overlap is harmless: rows already in the account are recognised and skipped, so a monthly export can safely start a little before the last one ended. A complete-history account begins at an explicit
$0opening date; a later file into it is checked against the whole ledger, so a sale of shares an earlier file bought is not read as a deficit. An opening-statement account names the first newer-transaction date; rows on or before its prior-day observation are skipped so the sources cannot double-count. Rows dated before the account's own starting point are left out for the same reason, and the import result says how many. A file whose first new row falls long after the account's last recorded transaction warns before import; a file that overlaps the ledger never does. - Confirm the file. On Accounts, open the account's Import CSV action and choose the file. A broker export carries no account identity inside it, so the drawer reads two other things. First the file's rows against the account's ledger: rows already stored in this account are near-proof the file is this account's, and the next step opens at once under one green line, File confirmed (with a Not this file? way back); rows inside the ledger's date range that match nothing and name securities the account has never held are refused as another account's export. The facts behind a confirmed file sit under Details: how many of the file's rows the account already holds, how many of its securities the account has ever held (a security new to the account is ordinary and is named), for a Fidelity export whether its cash balance matches, and the file-name match. A warning is never folded away: a sale of a security the account has never held (the wrong account, or missing history) or a cash difference shows beneath the line, and inside the question when the drawer has to ask. Second the account number brokers put in the file name (Schwab's
XXX242, Fidelity'sHistory_for_Account_…) against every file already imported: a number this account's earlier imports carried also skips the question, and a number only ever imported into a different account is refused, as is a file in another broker's format. When neither can tell, the drawer shows the file's format and date range and asks Is this the right file for this account?, with a caution if the account has activity in the file's range that the file does not contain. Choose another file picks again. - Read what the import will add. One section, titled with the count of transactions the account does not have yet (the only ones the import adds), their date range and types, lists exactly those rows; beneath it, how many rows are already in the account, fall before its starting point, or could not be read. The Import button carries the same count. A file whose every row is already stored says Nothing new to import and cannot be imported; neither can a completed import be run a second time. Unknown tickers among the new rows are stubbed rather than dropped.
- Review every core-cash change. A candidate requires opposing same-day, equal-value legs between two money-market vehicles. Confirm change makes the pair traceable, zero-value internal movement and records the dated cash-vehicle lineage. Not a core change imports the rows ordinarily and leaves lineage unchanged. The former fund's own start is dated at the first row the import can see. Once the account's history shows a fund in use earlier, any later import, whatever it contains, says so beforehand (X was the core cash fund before its recorded start) and moves that start back to the fund's own first activity, so the account's cash history (checkpoints, the register's cash balance) counts the earlier activity too. It never moves it onto days the fund before it was still in use, or into a stretch you dated as regular cash or an unknown vehicle. A start you set or edited yourself is never moved. Whatever the import can't cover, the review warns about, and the fix is the account's Cash vehicle history on Account details.
- Resolve the current answer. If the newest confirmed change conflicts with setup, choose the imported vehicle, keep setup with a later effective date, or leave it unresolved. History still imports; the choice controls today's grouping.
- Read the cash result. A broker checkpoint that matches is the evidence block's green Cash line; one that does not produces a card with the exact difference. Import with warning preserves that discrepancy; it never labels the account reconciled. An export that carries no checkpoint, as Schwab's never do, shows no cash card at all.
- Review opening observations and compare with the broker. Missing opening positions or cash remain findable from the Overview and Accounts until resolved. Reconcile shares and the one logical cash pool against the broker.
Confirmed old-to-new transfer legs contribute no deposit, withdrawal, purchase, sale, income, lot, or performance flow. Later dividends or corrections from a former vehicle still enter cash without making it current again.
T-bills and CDs in the file are recovered as instruments and appear on Fixed Income.
A purchase whose settlement date the broker leaves blank, as Fidelity does on Treasury bills until settlement posts months later, is dated instead by the core-cash movement that paid for it. Exporting the same period again once that date has filled in gives the same purchase a different date, and the import recognises it as the row you already have rather than adding it a second time. One catch applies to a ledger imported before this version: it holds no record of which of its dates were derived that way. Import the original export once more first. It adds nothing, and the later one then reconciles against it.
Any line the file contains but the import cannot use is listed by reason and line number before you import, including the export's own header and disclaimer text. A file that yields nothing therefore says why instead of reporting a clean import of no rows.
Previous imports, collapsed beneath the CSV flow in the account's Import drawer with its run count, undoes one run, removing the rows only that import stands behind. Rows a later, overlapping import also reported are kept and handed to that import; the Undo count is what will actually be deleted. Import-owned cash periods go with their run unless surviving rows still rest on them, and a start the import moved back stays with the import that first recorded it. A cash period you manually edited is detached from that disposable import provenance and always survives.