Understand your import results

What this does

Explains the panel that appears when an import finishes. Reading it correctly is the difference between a solved problem and a support ticket, because two of its outcomes are successes that look like failures.

The counts

Detected format. Which parser VEXA matched your file to. If this names a broker you do not trade with, the file was misread and the rest of the numbers are not trustworthy.

Imported: N closed trades. Round trips that opened and closed inside the data VEXA now holds. This is the number that shows up in Journal and Metrics.

Open positions: N saved. Fills that opened a position VEXA has not seen closed yet. They are held and matched against the next import.

Already in your account: N trades from previous uploads. VEXA recognised these from an earlier import and skipped them. This is the deduplication working.

Closed: N swing positions. Positions that were open before this import and were closed by fills inside it.

Errors: N rows. Rows VEXA could not read. The panel lists up to five of them with a reason, then says how many more there were.

Processed N executions from M rows. The footer. M is every line in the file including headers, summaries and cash movements. N is the fills VEXA kept. A large gap between them is normal for statement exports, which carry a lot besides trades.

The two messages that look like failures

“All N trades in this file were already imported from previous uploads.” Nothing went wrong. You uploaded a file whose trades VEXA already holds. This is the expected result of re-uploading, and of uploading an overlapping date range.

“No trades were found in this file.” This one is real, and it nearly always means the export was the wrong one rather than the file being broken. The usual causes:

• The wrong report type. MetaTrader 4’s Normal report instead of the Detailed report, MetaTrader 5’s Positions or Orders view instead of Deals, Coinbase’s Gain and Loss report instead of Transaction History.
• The wrong file format. Interactive Brokers offers XML, and manual upload does not read it.
• A cash-only section of a statement, with no trade rows in it.

The open-positions warning box

When an import leaves positions open, the panel lists each symbol with LONG or SHORT and a quantity, and says: these positions will complete when you upload the closing executions.

Read that list. It is the earliest warning that your export was cut short. If it names a position you know you closed, the closing fills were outside the date range you exported, and the fix is a wider export rather than anything on VEXA’s side.

The row-errors box

Errors are reported, not swallowed. A row with no quantity, an unreadable timestamp or an asset type VEXA does not recognise is rejected with a reason rather than silently dropped. If the count is small, the affected rows are usually summary lines the parser did not need. If the count is most of the file, the format is wrong.

What you should see

Counts that roughly match what you expect from the file, and a detected format that names your broker. Then trades in Journal and Metrics, and a recalculated score within a minute or so.

If it doesn’t work

• Imported is zero and duplicates is zero and errors is zero. VEXA read the file and found no trades in it. Take the export the broker’s article names, then see My import said success but nothing appeared.
• Imported is far lower than the trades in the file. Check the open-positions box first, then check whether your broker exports per segment or per product.
• Everything imported but the numbers are wrong. Contract multipliers and commission handling are the usual causes, and they are broker-specific. Start with your broker’s article.