Cryptocurrency portfolio tracker: where position accounting breaks
Manual crypto asset accounting holds only as long as everything is in one place and there are few trades.
As soon as two or three exchanges, a hardware wallet, staking, and a couple of networks appear, the position summary in a spreadsheet starts diverging from reality — and the discrepancy grows faster than the number of rows.
The first source is manual exports. Each venue returns history in its own format and with its own granularity: somewhere individual trades, somewhere fund movements, somewhere a daily aggregate.
Time in exports follows a single standard, while a person reconciles in their own time zone, so a trade at the day boundary falls into different periods on the two sides — and balance discrepancies appear out of nowhere.
The second is transfers between one's own addresses. Such a transfer appears both as a debit and as a credit and is counted twice in naive accounting; the network fee goes to a third party, so the value of assets on the way out and on the way in does not match. The position summary overstates turnover and distorts the total.
The third is the valuation point. One venue provides value at the time of the trade, another at the time of export, and in between the price has time to move.
While accounting is manual, these discrepancies add up and mask each other: it is unclear where there is an input error and where there is real movement of funds.
Next we examine exactly where accounting breaks systematically and how automatic reconciliation closes this.
Measurable effect: cryptocurrency accounting accuracy and reconciliation speed
Previously the consolidated balance was assembled manually: exports from venues and wallets were consolidated into a spreadsheet, positions recalculated at the rate from an open tab. Collection took half a day, and the result still diverged from actual balances.
A cryptocurrency portfolio tracker removes this work: the balance is calculated from a single data model across all connected accounts.
Quote freshness is maintained automatically. Rates come from several independent sources; discrepancy between them is flagged as an anomaly rather than silently averaged.
For rare pairs, a separate policy is set: if there is no fresh price, the position is valued at the last confirmed one, and this is visible in the report.
Reconciliation with venues proceeds without manual row matching. The tracker retrieves transaction history and matches records by ID, time, volume, and price, closing matches itself.
Only discrepancies go into review, and each has a stated cause — from a missing record to a fee discrepancy.
This eliminates a whole class of input errors: duplicated trades, lost fees, flipped signs, truncated periods.
Each transaction stores its source and reconciliation status; the transaction history is complete — portfolio state can be reconstructed as of any date rather than reassembled from balances.
In practice this looks like: the consolidated balance across all venues is obtained in seconds instead of hours, the share of automatically reconciled transactions stays above ninety percent, and the manual remainder contains only what requires the owner's decision.
Architecture options: own index, ready-made aggregators, hybrid
The price collection scheme determines what the user will see during a venue or aggregator failure and how much effort goes into maintaining the source. There is a choice among three options, and each has its own limitations.
| Option | When it fits | Limitations |
|---|---|---|
| Proprietary quote index | Pairs and venues not available in aggregators are needed, or a proprietary weighted-average price methodology with outlier filtering | We maintain polling of dozens of exchanges ourselves: different response formats, request limits, ticker renames, delistings — each source needs its own handler |
| Ready-made aggregators | Broad coin coverage and fast launch are needed, and rare assets do not occur in the portfolio | External provider is a single point of failure; update latency is not controlled, and price cannot be recalculated using your own methodology |
| Hybrid scheme | Portfolio value is calculated using your own methodology, but coverage needs to be wider than one set of exchanges | The most complex: source priority logic, reconciliation of discrepancies, conflict resolution between them |
The main trade-off is immediately visible: a proprietary index gives control and coverage, ready-made aggregators give speed of launch, and a hybrid gives balance at the cost of maintenance complexity.
Fault tolerance is designed separately: polling preserves the last reliable quote with a timestamp so that no gaps appear in the history, and when source discrepancy exceeds a threshold, the calculation stops rather than taking the first value received.
CoinGecko in a hybrid scheme covers the long tail of coins, while the proprietary index covers assets where accuracy matters more than coverage.
Work sequence: from source audit to handover of the system
The tracker diverges from reality not on the chart but in the data: a venue and a wallet record trade time, fees, and transfers between one's own accounts differently — the position gets duplicated.
Therefore the work sequence is the reverse of the usual one: first sources and the normalization scheme, then assembly and interface.
- Data source audit. We look at what each venue and wallet provides: trade streams, exports for past periods, history depth, and request limits. Where history is incomplete, we immediately plan a backup channel.
- Asset mapping. We map coins, networks, and tickers to a single reference: the same asset on different venues gets a common identifier, while wrapped versions and staking get separate attributes. Otherwise the position value is calculated incorrectly.
- Normalization scheme. We bring time, fees, partial fills, and transfers between one's own accounts to a common form so that internal movement does not double the position. Change history is stored — any period can be recalculated retroactively.
- Assembly and discrepancy checking. Balances are calculated in two independent ways — from venue data and from our model; a discrepancy goes into the report with an indication of the source. This closes missing trades and an incorrect rate on the date.
- Historical run. We run the system on accumulated data across several market cycles: we measure recalculation speed, behavior during a channel break, and correctness of recovery after a failure.
- Update regulations and handover. We describe connecting a new venue or asset, the procedure for editing the reference, and discrepancy review. Monitoring shows stream latency and the share of source failures before the user notices them.
What remains with the customer: configurations, data schemas, regulations
The customer receives not an archive of source code but a kit by which the system can be operated and developed without the authors.
We hand it over together with the portfolio tracker release: each artifact covers its own class of tasks — deployment, incident analysis, connecting a new source.
- Configuration files — quote sources, polling intervals, exchange request limits, and environment parameters: deployment is reproduced with a single command, without manual edits on the server.
- Data schema — tables of trades, transfers, and value snapshots, asset reference, indexes for period queries, and versioned migrations: history recalculation does not break current reports.
- Access policies — owner, analyst, and support roles with separate rights, service accounts, exchange API key rotation, and an action log.
- Maintenance regulations — which metrics to monitor, alert thresholds (balance discrepancy with the exchange, stale rate, silence from a source), recovery procedure from a backup, and incident response window.
- Procedure for connecting new sources — adapter contract, ticker normalization, validation against historical data, and rollout without stopping the service: a new exchange or network is added without core changes.
- API and data model documentation — methods, error codes, rate limits, and examples for customer-side integrations.
- Acceptance scenarios — checks for history import, return recalculation, and rate correctness that are run with every update.
The kit is handed over in your environment with owner rights; secrets remain in your vault. If we provide maintenance, we work according to the same regulations — the rules are the same for both parties and do not depend on who is on duty.
Case study: how a consolidated balance across networks replaced manual spreadsheets
The client is a small management team with a portfolio across several networks: some assets on an exchange, some in cold wallets, some in staking.
The consolidated balance was assembled manually — exporting transactions for each network, consolidating into spreadsheets, recalculating balances. A report took 6–8 hours of analyst work per month, and almost every run found discrepancies on 3–5 positions.
What was before implementation
The problem was not speed but trust in the numbers. Manual reconciliation did not catch missed accruals and counted transfers between one's own addresses as separate transactions, causing the portfolio value to diverge from reality.
The error was usually noticed after the report had been sent, when restoring the history of fund movements was difficult.
What was changed
We built an indexer that pulls transactions across all addresses and brings them to a single base accounting unit.
The consolidated balance is calculated on a network state snapshot fixed at a single block height: data across different networks is consistent, and internal transfers are recognized and not duplicated.
Rates are taken from an independent source — we took CoinGecko as the reference and reconcile it with exchange quotes.
What became after
Assembling the consolidated balance takes minutes instead of hours; reconciliation automation compares balances with exchange statements and flags a discrepancy above a set threshold.
The number of position discrepancies decreased from 3–5 to zero or one per period, and each is investigated as an incident with a clear cause.
Correctness control is based on recalculating closed periods: the historical balance matched previously submitted reports down to the last position, and discrepancies now surface at the time of reconciliation rather than months later.
Technical concerns: discrepancies, limits, and access
A venue without a software interface does not stump the tracker but changes the method of retrieving history. If an interface exists, we poll on a schedule taking into account the source's limits, batching small trades so as not to hit the request quota.
If not, we parse the transaction export, and for closed accounts we leave manual input with a source tag so that it does not blur the other calculations.
Each transaction goes into immutable history with the source, timestamp, and a snapshot of the original response.
Therefore a discrepancy is not “fixed” manually but reproduced: we retrieve the raw response, compare it with the calculation, and find the cause — usually a mismatch between the trade moment and the rate fixation moment.
We take the rate at the time of the trade; for market quotes, the reference is CoinGecko, but we also save the venue response.
One of the services has no API at all — what should be done with it?
We write an adapter for the export: a fixed-format transaction file, column parsing, and the same validation as for an API. If there is no export either, transactions are entered manually and accounted for separately as "declared" so as not to distort reconciliation. Later the source is replaced by an adapter without rewriting the calculation core.
Who owns the data, and what about access after handover?
Data, transaction history, and schema remain with you. Exchange keys are issued read-only, stored encrypted, and do not leave your environment.
When handing over the project, we provide the repository, migrations, data model description, source update regulations, and deployment instructions — maintenance is possible, but the project is not technically tied to us.
What to do if accounting is already deployed in spreadsheets and wallets?
Deploying new accounting on top of the old one with a one-time switch is a bad idea: if in the evening the spreadsheets stop being the source of truth and reconciliation does not match, you will lose both the numbers and time.
Therefore we launch a second system alongside: it reads the same sources as the current one but calculates independently, and the switch occurs only after discrepancies are explained.
Accounting migration begins with an inventory: where the data comes from — exports from trading venues, wallet addresses, manual rows in spreadsheets. Then everything is brought to a unified transaction schema: asset, quantity, entry price, fee, time, source.
Transfers between one's own addresses are marked as internal — otherwise volume is doubled, average entry price is distorted, and the report shows nonexistent profit.
History transfer proceeds by transactions, not by final totals: we pull statements for past periods, load wallets by addresses, and recalculate cost basis using the chosen method — average price or lot order (FIFO).
Rows in spreadsheets where the source cannot be restored are marked as unverified: they are visible in accounting but do not enter reporting or the taxable base calculation until confirmed.
Parallel operation is built on control snapshots: both systems calculate balances and result for the same date; a discrepancy above a set threshold goes into review — usually a missed fee, unaccounted transfer, or duplicated trade.
Gradual implementation proceeds one segment at a time: first the portfolio on one venue, then the remaining wallets and accounts. The old system remains operational until the end of the transition, so rollback does not require data restoration.
The timeline and scope of work depend on the number of sources and the quality of history — in our experience this is the most variable stage. Describe what you already track and in what form, and we will return with an estimate and a transition plan without stopping accounting.
Let's discuss the task: where to start and what will be required from you
For the conversation to move to an estimate rather than a week-long correspondence, a minimal set of input data is needed. A ready-made technical specification is not required at this step — what is already at hand is enough.
- which networks and venues should be included in the first stage: public wallet addresses, read-only keys, paper trades;
- where transaction history comes from — account exports, manual input, file import;
- what counts as the portfolio: one account, several wallets, assets locked in staking;
- which reports are needed: position value, realized result, fund movement by period;
- which platforms the client uses — web, mobile, view-only without trading actions;
- access requirements: who sees the data, whether roles are needed, and second-factor login confirmation.
In response we will return a staged scope of work, a data and connection scheme, and a first-stage plan with checkpoints.
We start with the core — transaction accounting and position recalculation — so that you see correct numbers on your data before reporting and interface are added to the project. Then we expand: connecting venues, analytics, notifications.
Describe the task in free form, and we will return with an estimate and a plan showing what we do in the first stage and what will be required from your side.