My import came in short or wrong

A CSV went in and the result is not what you expected — fewer trades than the file had rows, dates a day out, or nothing visible on the dashboard afterwards. Each of those has a different cause and they are easy to tell apart.

The commonest cause: the wrong export

Alltra reads two shapes of file. A ROUND-TRIP export prints one row per completed trade, with an entry price and time. A FILL export prints one row per execution, with a price and a time. Both are normal and both work, and a per-trade export is not a lesser file — Tradovate’s Performance export is one of the layouts Alltra recognises by its header. What cannot be read is an account summary or a monthly statement, which have collapsed the trades themselves into totals.

If your trade count came in far short of what you traded, look at the date range on the export before anything else — most platforms default to a short window. Where the platform offers a choice, executions or fills carry the most detail, so prefer them; a trade-level export still imports.

Rows the preview will not take

Every rejection names the field it is about, and quotes the cell where the value itself is the problem, so the file does not need to be perfect for the import to be useful. The reasons you can actually meet are these.

• No symbol — the row has nothing to attach to an instrument.
• A side that is not a buy or a sell — the cell is quoted back to you, so a platform-specific word is obvious.
• A quantity that is not a positive number — zero and blank both fail here rather than at commit.
• An unreadable price or date — including a date format nothing can parse.
• Half a close — an exit price with no exit time, or an exit time with no exit price. Importing either would put a real number beside an invented one, straight into the P&L.
• An exit before the entry — usually a column mapped the wrong way round.
• A currency cell that is not a three-letter code — the row is quoted back.

When EVERY row fails at once and the preview is a table of dashes, it is not a file full of bad rows — it is one column Alltra declined to guess at. A header like “Filled Time” could be the open, the close or the execution, so auto-detect leaves it unmapped rather than picking, and without an entry time no row can be built at all. The mapping is a control, not a verdict: set the column yourself and re-check the same file.

Dates landing on the wrong day

A CSV rarely says what timezone its times are in, so the import carries one and every cell without its own zone is read against it. Where the file DOES carry a zone, that wins: a numeric offset always, and a trailing abbreviation only where Alltra recognises it. An abbreviation it does not recognise is not guessed at — the cell falls back to the import’s own zone, because the same three letters name different zones on different continents.

If everything is out by the same number of hours, or a set of evening trades sits on the following day, the import’s timezone is the thing to change and re-run.

Why the dashboard has not moved yet

A commit is three stages, not one. The fills are written first; the trades are then derived from them; the dashboards fold those trades in last. An import can honestly report itself committed while the trades it produced are still being built, and a dashboard refreshed in that window shows the numbers it had before. Give it a moment and reload.

What to check, in order

1. 1What kind of export it was — a summary or performance report cannot produce trades. This is the first thing to rule out, and the easiest to fix.
2. 2The rejected rows in the preview — each one names the field it failed on. Fixing the file and re-uploading is usually quicker than unticking.
3. 3The column mapping — a known broker layout is recognised automatically; an unfamiliar one asks you to map it once and remembers the answer for next time. A mapping one column out is a file of half-closes and reversed dates.
4. 4The import’s timezone — if the rows are right and the days are not.
5. 5Which accounts you imported against — one file imported against three accounts writes three separate sets of fills. That is a fan-out, not a copy — check you did not mean one.
6. 6“Already imported” over rows you know are new — a file counts as already imported only when every account you are targeting already holds its fills. If you added a new account to the selection, those rows are new work and should be offered.
7. 7The fee columns — fees are read as amounts regardless of how your broker signs them, because exports print a charge as a negative about half the time. A fee that appears doubled or cancelled out is worth telling us about with the file.
8. 8The file itself — CSV only, up to 10 MB each, up to twenty files in one import. A spreadsheet saved as XLSX is the usual rejection.

Importing twice

It is safe. Where your broker supplies its own execution ids, a repeat is structurally impossible to double-count; where it does not, Alltra fingerprints each fill from the account, instrument, side, quantity, price and time. So an overlapping export — the usual way to close a gap — adds what is new and ignores what is not. The default when a duplicate is found is to keep what you already have.

When to tell us

When the preview accepted the rows, the commit finished, and the trades still are not there an hour later. Send the platform the export came from and a few rows of the file with the numbers changed if you would rather — the header is usually the diagnostic part.