Crypto Accounting Platform Development: Exchange Import, DeFi, Taxes

Development of crypto accounting: where accounting breaks

An exchange statement and a blockchain wallet describe the same operation differently. The exchange provides aggregated records by its internal identifiers and rounds fees, while the network stores a complete log of transfers with exact time and addresses.

When importing exchange statements, these two sources do not reconcile in amounts, and crypto asset accounting diverges from actual balances already in the first report.

Transfers between own accounts behave worst of all. Funds go from a wallet to an exchange and back, in the statement these are two independent records, and a system that has not linked them sees a sale and a new purchase.

The cost basis of the asset is zeroed out, the tax base is overstated, and restoring the history retroactively is almost impossible — the primary data has already been overwritten.

Decentralized protocols add a third category of records: swap through a pool, liquidity deposit and withdrawal, reward accruals. Each operation is a separate contract call, and without explicit classification of operations they end up in the report as unidentified receipts.

Reconciliation of transactions in this form remains manual: matching addresses, hashes, and amounts is done by eye, and discrepancies accumulate from period to period.

It is at these three points — import, reconciliation, classification — that most attempts to build crypto asset accounting on their own fall apart.

We analyze how this is addressed in crypto accounting development: from the data model and transfer linking rules to the reconciliation of the report with balances.

Measurable effect: reconciliation, cost basis, period closing

After automation, it is not the reporting that changes, but the daily routine of the finance department: how many operations the accountant processes manually, how the cost basis is calculated, and when the period is closed.

Below are checkpoints that show that the implementation has delivered results, rather than just adding another export.

• History import from Binance and DeFi wallets runs on a schedule, automatic reconciliation of operations itself matches transfers between own accounts, swaps, and fees — only discrepancies remain manual.
• The cost basis of crypto assets is calculated by lots: the chosen method is fixed in the accounting policy, recalculation uses the same data as reporting, so figures do not diverge between reports.
• Unidentified transfers have a queue: status, comment, and responsible person, stuck operations are visible as a list, not by searching through statements for a year.
• Closing of the reporting period follows a regulation — reconciliation of balances across platforms, exchange rate differences, fees, and internal transfers are closed according to the calendar, not 'when it reconciles'.
• History completeness is preserved from the first transaction to the last: manual adjustments and change log allow restoring any amount during an audit.
• Tax registers are assembled from the same data set as accounting — the declaration and the ledger do not diverge because the source is the same.

These points are convenient to take as a checklist during acceptance: if for each one the before and after value is visible, automation is truly working.

Crypto accounting development: cloud, on-premises, hybrid

The deployment mode determines who is responsible for the safekeeping of access keys to exchanges and wallets — this is the main selection criterion, not interface convenience.

The cloud scheme is faster to put into operation and removes maintenance from your team, but moves data and access to an external perimeter. On-premises keeps everything inside, but adds operations overhead.

The hybrid resolves this contradiction: calculations and reference data live in one environment, sensitive keys and operations with them — in another, exchange goes according to pre-described rules.

Connecting data sources is built separately from the deployment mode: exchanges, wallets, and DeFi positions are fetched incrementally from the time of the last operation, the asset reference is updated via its own channel, and statements and files remain a backup reconciliation path.

Each transaction gets an external identifier, so re-uploading after a failure does not create duplicates, and a balance discrepancy is highlighted before the report is generated — you see the problem in the source, not in the finished tax declaration.

Implementation step by step: data audit, schema, testing, handover

Crypto accounting breaks not on tax calculation, but at the data input: an exchange has request limits, a wallet has multiple networks, for some operations the cost basis is not stored anywhere. Therefore, the work goes from inventory to code — in fixed steps.

1. Data source audit. We compile a list of exchanges, wallets, networks, and custodial services: what each provides via API or file, for what period history is available, where operations will have to be restored from statements.
2. Accounting rules schema. Before code, we fix the interpretation of transfers between own accounts, staking, fees, and rewards — one ambiguity later spreads across all reporting.
3. Data model and reconciliation. We design the operations storage with stable keys so that re-import does not create duplicates, and reconcile balances for each account with the source.
4. Control run. The full cycle — import, cost basis recalculation, report — is run on a labeled set of operations with known answers. We correct discrepancies before handover: changing rules is safer than a closed period.
5. Import failure testing. We reproduce source limitations, connection breaks, retries, and stuck operations: the system must continue from the stopping point and show what has not been pulled.
6. Handover to operation. We provide source configurations, the rules schema, the update regulation, and instructions for the accountant, train the customer's team, and run the first reporting cycle together with it.

Acceptance is based on reproducibility: the same set of operations produces the same report on re-run, and a discrepancy with the source is explained, not hushed up.

Data schemas, access policies, and period regulations

Code can be rewritten, but the fixed data schema, rights, and period closing procedure determine whether accounting will be reproducible.

Therefore, we deliver the documentation package together with the release: using it, a new engineer deploys the environment, an auditor traces an entry from source to report, and the accounting department closes the month without chatting.

• Data schema description: transactions, transfers between own accounts, accruals and adjustments, idempotency keys, and deduplication rules for re-import from an exchange or network.
• Role matrix and access policies: who sees wallet addresses, who edits the asset reference, who confirms a manual entry; separation of 'enter' and 'approve' plus an action log.
• Import regulation: polling intervals for exchanges and nodes, behavior on connection loss, storage of raw responses — so that any figure can be reassembled from scratch.
• Reconciliation regulation: matching balances across exchanges, wallets, and the internal ledger, a list of typical discrepancies and the procedure for resolving them before closing.
• Period closing procedure: blocking retroactive edits, adjustments in a separate period, fixing the rate at the time of the operation.
• Accounting documentation: rules for recognizing income and expenses, cost basis valuation method, compliance of entries with reporting forms.
• Recovery regulation: what to do on import failure, how to replay the queue, where backup points are, and in what time the environment returns to a working state.

Case study: import of exchanges and DeFi without manual reconciliation

The client is a crypto asset tax reporting service: several exchanges, own wallets, and tens of thousands of operations per month.

Reconciliation was done by exporting to spreadsheets: the accountant manually matched trades, transfers between own accounts, and accruals; period closing stretched to two weeks and depended on one person.

What was changed

We built connectors to exchange APIs — read-only keys, paginated export with cursor continuation.

Each operation is assigned an external identifier, so re-import does not create duplicates: if the connection breaks, we catch up from the break point, not re-upload the entire history.

We parse DeFi not from statements, but from on-chain events: swaps, liquidity deposits and withdrawals, fees go into a common journal, where Uniswap operations and transfers between own wallets are collapsed into a single economic meaning.

Valuation is taken at the time of the operation, cost basis write-off — by FIFO and average, so that the tax calculation is not reassembled manually.

What changed in numbers

Manual work remained where it is appropriate: the system flags disputed operations in a separate list and stores the history of edits. Accounting policy rules are moved to configuration, so changing the write-off method does not require code changes.

What to do if accounting is already done in spreadsheets?

Spreadsheets do not need to be rewritten manually — the history of operations is transferred as is.

We start with an inventory: a list of exchanges, wallets, and OTC deals, the boundaries of the period for which reporting has already been filed, and a list of manual adjustments applied to the spreadsheet. Without this step, the transfer results in double-counted balances and lost transfers.

Next — import of history from exchange exports and public wallet addresses with mandatory matching of transfers between own accounts. In manual spreadsheets, it is precisely on these that a taxable event most often arises where there was none.

Cost basis is calculated using a single write-off method across the entire history, not by average within each spreadsheet.

Operations that are not exported anywhere are entered manually — but with a source note and a link to a supporting document. Thus, a manual entry becomes an exception with a clear origin, not the main method of accounting.

Parallel period: for one or two reporting cycles, data goes both into the old spreadsheet and into the system. We reconcile three things — asset balances at the end of the period, realized result, and the number of unidentified transfers. Discrepancies do not stop the transition: they turn into a list of rules that need to be adjusted.

When reconciliation matches, the spreadsheets are switched to read-only mode, and double entry stops.

Data continuity is preserved: the operations database on which previous reporting was built remains the same, and past reports can be recalculated and confirmed with primary data.

Technical concerns: data accuracy, access, gaps

Before starting crypto accounting development, the technical team and the financial department have the same set of questions: where is the boundary between calculation and primary data, what to do with gaps in history, and does the system need private keys.

The answers determine the storage schema and how well the result will withstand an audit. We answer point by point — as it is arranged in projects.

Is access to private keys needed?

No. Accounting is built on public addresses and read-only connections, and transaction signing remains outside the accounting environment.

Keys do not leave the customer's infrastructure — the system stores addresses, ownership marks, and operation identifiers; this is sufficient both for calculation and for confirming the source.

What to do if the operation history is incomplete?

Exchanges provide data for a limited window, and transfers between own wallets are often not visible in exports.

We collect history from multiple sources, mark periods with incomplete data, and introduce adjusting entries with an explicitly fixed methodology — the report shows which amounts are calculated and which are confirmed by the primary source.

Let's discuss the task: what we need from you to start

To come back not with general words, but with a scope estimate and a work plan, we need a minimal set of input data. Some points are usually resolved right during the discussion, the rest we clarify during the analysis.

• List of platforms: exchanges, wallets, networks, and DeFi protocols from which we pull operations. For each — access method (file export or read-only key) and history depth.
• Reporting composition: jurisdictions and tax regimes, forms in which the report is filed, required export format for accounting and tax authorities.
• Accounting methodology: how we calculate cost basis (FIFO, LIFO, average), how we interpret transfers between own wallets, fees, staking rewards — the rules on which the tax base is built.
• Data volume: number of accounts, wallets, and addresses, approximate number of operations per month, whether recalculation for past periods is needed.
• Access and materials: test exports for a couple of periods, access to a test environment, an example of an already filed report, if available.
• Integrations and roles: where we deliver the result — declaration files, accounting systems, external API; how many users and how we delineate rights.
• Person responsible for methodology on your side: with whom we reconcile disputed cases — exchange between own accounts, refunds, lost assets.

This is enough to fix the boundaries of the task and estimate the scope. Describe the task and send what you have already collected — we will return with an estimate and a staged work plan.