Duplicates and re-importing

Re-importing a file you have already imported does not create duplicate transactions. Every row in an import is compared against what is already in your project, and repeats are flagged Duplicate and skipped. Overlapping date ranges are fine, the same file can be imported twice, and the usual rhythm — export from your broker every week or month and drop the whole file in — needs no manual trimming.

This article covers what the importer actually compares, what each row status does, how to force corrected values over transactions you already have, and what happens to rows that could not be imported.

What the importer compares

Two different comparisons, depending on the file. If the data carries a transaction reference — a unique ID the broker assigns to each operation — Capitally matches on asset, account and reference, so the quantity, the price and even the date can have changed and the row is still recognised as the one you already have. If there is no reference, it falls back to asset, account, transaction type, date, and quantity rounded to two decimal places. The transaction type has to match either way.

Quantity only counts for the types that have one: buys, sells, transfers, account balances and conversions. For a dividend, a fee or an interest payment with no reference, asset, account, type and date are the whole key — two payments of different amounts, on the same asset and the same day, look identical to the importer.

Reference matching is the precise one, and it is available for brokers that publish unique identifiers in their exports. The reference is a normal transaction property, so a custom preset can map it too — see the Transaction Properties Reference, where it is listed as Reference. Some built-in presets already do this where the broker publishes no identifier of its own: the Goldman Sachs TFI preset, for example, composes a reference out of the transaction type, the date and the number of units, so its conversions dedupe as precisely as an IBKR trade does.

Interactive Brokers is the clearest example: every row in a Flex Query carries one of IBKR's own identifiers, so every transaction imported from it has a reference. Trades take the TradeID, cash transactions take the TransactionID, and dividends take the ActionID — which is also what groups a dividend paid across several rows into one transaction in Capitally rather than five. Because the reference is what deduplication keys on, you can edit an imported IBKR transaction by hand, change its date for instance, and re-importing an overlapping range still will not duplicate it.

Duplicate, Update, and the rows that get skipped

Every row in the import review table carries a Status. Duplicate means the transaction is already in your project: the row is skipped and nothing changes. Create means it will be added. Update writes the row's values onto the transaction you already have. Excluded marks a row the importer could not turn into a transaction, usually because its asset or its transaction type did not resolve, and failed marks one that hit an error. Hover the info icon next to a status to see the reason for it.

You can change the status on any row. The dropdown offers create and ignore, plus update wherever an existing transaction was matched — so a row flagged Duplicate can be set to update, or forced in as a second, separate transaction with create. To change many rows at once, select them and set the value on any one of them; the change applies to the whole selection. Clicking a column header sorts the table, and sorting by Status also groups the rows under a header per status, which makes reviewing a long import much faster.

Automatic dividends behave slightly differently. When you upload broker data, Capitally removes its own dividend forecasts for the period, so importing dividends from your broker is the right thing to do. The exception is a forecast you have edited or confirmed yourself: that one is kept, and the incoming row is marked as a duplicate instead. The separate rule that stops automatic dividends being created next to a manual one is described in Tracking Dividends — it is a different mechanism from the transaction matching described here.

Forcing an update on transactions you already imported

Change the status of the affected rows from Duplicate to Update. Duplicate rows are skipped, so a corrected value in a fresh export — a withholding tax amount, a fee, a restated dividend — never reaches the existing transaction until you flip the status. Update rewrites the values on the transaction you already have rather than adding a second one.

1. Start the import again with the newest export from your broker.
2. On the review screen, click the Status column header to sort by status, so all the Duplicate rows sit together under one group header.
3. Select the whole group using the checkbox in the group header.
4. On any one of the selected rows, change the status to Update. The change is applied to every selected row.
5. Continue to the Summary step, where the final balances of every position you are importing are shown, and confirm the import.

This is also the answer after we fix an import preset: you do not need to delete anything or start a new project to pick the fix up. Re-import the same file and switch the Duplicate rows to Update.

When a real transaction is flagged as a duplicate

Set that row's status to create before confirming the import. Deduplication applies to every import and there is no setting that switches it off; the control you have is the status on the row, and create imports it as a new, additional transaction instead of skipping it.

It is worth being sure first. Deliberately skipping a row that really is a repeat costs nothing, while forcing in a row that was correctly flagged records the same transaction twice.

False duplicates across two accounts at one broker

Set the wrongly flagged rows to create before confirming, then split the two accounts so it stops recurring. Two accounts at the same broker imported into one Capitally account collide whenever a fee or a transaction shares the same date, asset and type in both. The second one is skipped, and that account's balance ends up short by exactly that amount.

The same thing happens on a first import from a source whose single export covers two accounts — a Robinhood file containing both the brokerage account and the Roth IRA, for example.

There is no switch that turns matching off, so the permanent fix is to change one of the three things the importer compares before the date and the quantity: the account, the asset, or the reference.

• The account. Keep one Capitally account per real account — see Organizing portfolio. Once the two sets of rows land in different accounts they stop colliding at all. Give each account its own preset variant and the split happens on every later import without you thinking about it — preset variants are covered in Import from a broker or app.
• The asset. If you would rather keep both real accounts under one Capitally account, give each of them its own cash asset — two EUR cash assets rather than one shared one. The asset is compared before anything else, so the two sets of fees stop looking identical. See Tracking Cash.
• The reference. In a saved preset, map the Reference property to something that differs between the two accounts — an account number column, or a formula combining it with the date. Where both sides carry a reference, the reference is what decides, so two distinct references never collide. See Importing in advanced mode.

Rows with a transaction type that is not supported

A warning that a transaction type is not supported means the preset has not seen that type in a sample file yet — not that Capitally cannot model it. That row is skipped and every other row in the file still imports, so the import is not wasted. Nothing is stored for a skipped row, which is why re-importing the same file later is safe.

What to do with them:

1. Note the type named in the warning on the review screen — the message quotes it, as in "Cash transactions of type X are currently not supported" — and email the file to support@mycapitally.com, naming your broker. If the file contains data you would rather not send, use the anonymized export described in Getting help.
2. We typically add support for a new type within a few days.
3. Import the same file again. Only the previously missing rows are added; everything else comes back as Duplicate and is skipped.

The same applies to rows you skip deliberately, or mark as ignored during the import: they exist only inside that import session and are never stored. Once whatever blocked them is resolved — an asset added to our database, cash tracking enabled on the account — re-import the file and they come in.

When a fix does not seem to take effect

Two causes, in this order. Your app may still be running a version older than the one carrying the fix. If the version is current, you are most likely continuing an import session that was started before the fix shipped, so it is still running the old preset logic from beginning to end.

1. Check the app version in the top-right menu. If it is older than the version with the fix, wait a little and refresh.
2. Discard the import that is in progress.
3. Start a brand new import from scratch, with a fresh export from your broker, so the updated preset is applied from the first row.
4. If the incorrect data is already in your project, re-import and switch the Duplicate rows to Update, as described above, so the corrected values overwrite what is there.

More on version checks and refreshing the app is in Troubleshooting the app.

Importing several files in order

Import the oldest file first and work forwards. You do not need to combine files — import them individually, in chronological order, and let the ranges overlap where they do. Interactive Brokers exports a maximum of one year at a time, so a ten-year history arrives as ten files rather than one.

After the history is in, re-export and import whenever you have traded; weekly or monthly is a normal cadence. Prices for listed assets update on their own, so an import is only needed when transactions actually happened. Configuring the Flex Query itself is described on the import screen, next to the IBKR preset; Interactive Brokers covers what goes wrong with the export it produces.

Undoing an import

Every import can be undone in full. Immediately after one, use the toast that appears. Later, open History from the top-right menu: all the changes belonging to one import are grouped into a single entry, which you can expand to see the individual changes it made.

From there you can select the whole group and delete it, or select only some of the changes within it — and anything you delete can be restored again from the same screen. The details are in Changes History. If you would rather start clean, create a new project and import from scratch — that is worth doing when you plan to import a lot more data from the same brokers.