Keep the import history with your portfolio

A File Is A Dated Claim

An API connection and a file import look similar on a portfolio screen and are entirely different kinds of evidence. The connection answers a question you ask now. The file answered a question somebody asked at the moment the export ran, and it will keep answering that same question forever, no matter how long it sits in the workspace.

CVEST supports importing a full transaction-history export from TradingView. It is worth being blunt about what that is, because the name of the source invites the wrong assumption: this is a file you produce and upload. There is no TradingView account connection anywhere in the product, and nothing about the import will ever refresh on its own.

Handled with that understanding, imports are genuinely useful. They bring holdings and cash flows that no other connection covers into the same workspace as the rest of your record. Handled as though they were live, they become the most confident wrong number on the screen.

What The Import Accepts

The parser is deliberately narrow, and knowing its boundaries saves a frustrating afternoon. A file must be no larger than two megabytes and must contain no more than twenty thousand transactions. Six columns are required: the symbol, the side, the quantity, the fill price, the commission and the closing time. A file missing any of them is rejected rather than partially interpreted.

The accepted sides go beyond trading, which is what makes a full history usable rather than just a trade list. Buys and sells are joined by dividends, splits, deposits, withdrawals, taxes and fees. That coverage is the reason to export the complete history rather than a filtered view: the cash flows are what let holdings be derived at all.

One rule catches people out. A row whose symbol is the cash marker must carry a cash-only side. A cash row claiming to be a buy is a contradiction in the source data, and the import treats it as one rather than guessing which field was meant.

What It Produces, And What It Refuses To Infer

A successful import produces two things: holdings, and cash flows separated by currency. It does not produce a valuation. No current net asset value is calculated, and no foreign-exchange conversion is inferred from the file, because neither is present in it. A transaction history records what happened at each fill price; it says nothing about what anything is worth today.

Two warnings are attached to every import, without exception, and they are attached by the code rather than by an author who might forget. The first states that imported holdings and cash flows are not live market valuations and that no current valuation or currency conversion is inferred. The second states that the holdings assume the export contains the complete transaction history, and that the result is not reconciled against any connected broker.

The second warning is the one that actually bites. A partial export does not produce a partial answer. It produces a complete-looking answer to a different question.

Imported figures are also kept out of the venue equity totals entirely. They are never summed into the combined workspace equity, which means an import can never silently inflate a number that other parts of the system treat as a live account balance.

The Parse Is Re-Derived, Not Trusted

There is a detail in how an import is saved that is worth understanding, because it explains why the stored result can be relied on later. The raw file is kept, and when the import is persisted the parse is performed again from that raw content. The freshly derived result is compared against what is about to be stored, and if the two disagree the write is rejected.

That check closes the gap between what you were shown in the preview and what ends up in the record. Without it, a stored import would be a claim about a file. With it, the stored import is reproducible from the file itself, and anyone reviewing it later can regenerate the same holdings from the same bytes.

The write itself happens under a lock, so two imports cannot interleave and produce a mixed state, and it is written into the journal as its own recorded event. The import is not a settings change. It is a thing that happened, with a time attached.

Versions Accumulate On Purpose

Import the same account twice a month apart and you will have two imports, not one updated import. This is not an oversight in the interface. The stored imports sit in a table that the database itself refuses to update or delete: a trigger raises an error on any attempt at either. The same protection covers observations, order intents and the raw external records from every venue.

The consequence is that the natural instinct — to replace the old file with the better one — is simply not available, and that turns out to be the feature. Two versions of the same account let you ask why they differ. One version, repeatedly overwritten, can only tell you what somebody believed most recently.

Raw venue records follow the same discipline from the other direction. They are stored uniquely by account scope, source, external identifier and a content hash, so a record that arrives again unchanged does not duplicate, while a record that arrives changed is kept alongside the original rather than replacing it.

Reading Two Versions Against Each Other

The table below is a reading aid for what a difference between two imports can and cannot tell you. It is not a reconciliation procedure and it is not exhaustive; it is a way to avoid attributing a difference to the wrong cause.

Note how often the third column says the difference poses a question rather than answering one. That is the honest position for a file-based source, and it is why keeping both versions matters more than getting any single import perfect.

Reconcile At The Boundary, Not Inside It

When an imported holding disagrees with a connected account, resolve it at the boundary between the two sources rather than by adjusting either one. The import is a file you produced at a moment; the connection is a reading taken within the last few minutes. They are answering different questions, and forcing them to agree destroys the information in the disagreement.

In practice this means writing down which source you are treating as authoritative for which fact, and why. Position quantities from the broker connection; historical cash flows from the import; current valuation from neither, unless the venue supplied one. That division is more durable than any single reconciled total, because it survives the next import.

First Steps

1. Export the complete transaction history rather than a date-filtered view, and confirm the six required columns are present before uploading.
2. After importing, read the two attached warnings deliberately rather than dismissing them, and write down the export date beside the holdings you intend to use.
3. When you import the same account again, note that only the current version is listed; read the earlier one from the research export and account for every difference before you rely on either.

Keep The File, Keep The Date

An import earns its place in a portfolio record by being honest about its own age. The product enforces most of that honesty for you: it will not value the holdings, it will not fold them into venue equity, it will not let the stored parse drift from the file, and it will not let you erase the previous version.

What remains yours is the discipline of reading the date. A holding derived from a file exported in March is a fact about March. Kept with its date and its predecessor, it is part of a record. Read as a current position, it is a number that stopped being true some time ago and never said so.