Accointing integration: where crypto transaction accounting breaks
Accointing collects transaction history from exchanges and wallets: some platforms connect via read-only keys, while others provide a file export.
The failure starts at this step — one exchange records transaction time in UTC, another in local time, fees are listed on a separate line, and some trading pairs are unrecognized.
The import completes without errors, but crypto transaction accounting does not reconcile, and discrepancies in transactions surface only during reconciliation.
Worse is the case with transfers between your own wallets. If a platform does not mark a withdrawal as internal, the service reads it as a sale and the deposit as a purchase. Turnover that did not exist is included in the report, and a liability is calculated on it.
This is remedied by manually tagging each "debit — credit" pair, but until that is done, the figures in the declaration are incorrect.
Double-counting of staking income is the third typical failure. The accrual is recorded as income at market price on the receipt date, and the subsequent sale of the same asset is recorded again, now as a trade.
Without configuring the accounting method, both operations are added together, and the tax base grows multiple times.
All of this converges at one point — manual reconciliation on the eve of the reporting period in Germany, when the transfer of transaction history must be closed out, while discrepancies accumulate over several years. Below, we break down how this is resolved technically.
What well-established crypto asset transaction accounting provides
Importing history from exchanges and wallets into Accointing is not a one-time export but a continuous stream: trades, transfers, and accruals enter the accounting records as they occur. Below is what changes in reporting preparation once this stream is configured and tagged.
Automatic transaction classification
Matching rules tag transfers between your own wallets, exchange operations, accruals, and fees without manual input. On a typical portfolio, 85–95% of transactions are allocated automatically, leaving a short list of disputed cases for review. Matching keys are configured once and reused across all periods.
Period preparation speed
The period closes in hours instead of days: the data is already tagged, and only exceptions need checking. A repeated export does not overwrite manual edits, so each subsequent period is prepared faster than the previous one.
Eliminated error classes
"Double-counted income" disappears when an accrual and its deposit are linked as one operation rather than two. A "lost transfer" disappears when both sides of a transfer between your own wallets match by transaction ID.
Portfolio data quality
The balance on any date reconciles with the actual wallet balance, so discrepancies are visible before the report is filed, not after a request. Acquisition cost is stored for each asset — recalculation for a partial sale does not require manually searching for old trades.
Data transfer methods: comparing connection options
The four methods differ not in convenience but in what exactly ends up in the report and how verifiable the result is. The choice depends on the setup: assets on a platform, in self-custody, or both at once.
| Option | When it fits | Limitations |
|---|---|---|
| Import statements via files | Archive periods, one-off uploads, platforms without programmatic access | Each source has its own format and delimiters; duplicates appear on repeated upload |
| Reading public wallet addresses | Self-custody, multiple addresses per asset | Only on-chain movements are visible; transfers between your own addresses must be tagged manually |
| Direct connection to a platform | Regular trading, dozens or hundreds of transactions per period | Read-only keys are required; some platforms provide incomplete history |
| Manual transaction entry | Single trades, over-the-counter settlements, filling gaps | No one will catch input errors automatically; labor costs grow with volume |
How the option for your setup is chosen
We start with an inventory: a list of platforms, wallets, and transaction types for the reporting period.
Then, for each source, we take the method with the fewest manual edits, and Accointing acts as the assembly point — heterogeneous sources at the input, one consistent set of transactions at the output.
Where the options conflict with each other
One transaction often arrives via two paths: a withdrawal from a platform appears both in the statement and in the movement on the wallet address. Without a source priority rule, this turns into double accounting and a discrepancy in total amounts.
Therefore, we check source compatibility separately: we reconcile control sums for the period and record which source is considered primary for each transaction type.
Accointing integration: implementation and verification stages
The work order is the same for any set of sources: first, inventory what already exists, then the linking scheme, and only then automation. A skipped stage is most costly at the output — when a discrepancy surfaces during reporting preparation rather than during reconciliation.
- Data source audit. We collect exchanges, wallets, bank exports, staking operations, and payouts. We record formats, export frequency, period completeness, and obvious duplicates.
- Transaction matching scheme. We determine how transactions from each source map to accounts and assets, where transfers between your own addresses are, where fees are, and where the real result is.
- Allocation rule setup. We define categories and priorities, describe the tax logic for each transaction type, and close out rules for cases previously handled manually.
- Test reconciliation on historical data. We run the full previous period and compare the totals with prior calculations — this way, errors are visible before the reporting campaign starts.
- Discrepancy review. Each residual is assigned a reason: unrecorded transaction, duplicate transfer, different rate on the date. Rules are corrected based on facts, not guesses.
- Regulation recording. We describe what to do when connecting a new source, how to update rules, and who is responsible for data integrity.
- Handover to operation. We provide access and instructions, conduct training, and support the first reporting cycle.
Control reconciliations at every step
Without them, automation turns into transferring old errors into a new tool. At each stage, three values reconcile: the number of transactions for the period, the amounts of deposits and withdrawals, and balances on the control date.
A discrepancy is not "written off" — it is either explained by a specific transaction or becomes a task for refining the rules.
After the first reporting cycle, the rules are reviewed: practice shows where manual intervention is still required, and those points are closed in a targeted manner.
Accounting schemes, reference guides, and reconciliation regulations
(body)
After integration, the client retains not only a working data exchange but also a set of artifacts by which accounting is maintained and verified without our involvement.
Each document answers its own question: where the data comes from, how a transaction is interpreted, and what to do in case of a discrepancy.
- Source and wallet map — exchanges, custodial and self-custody addresses with the setup marked, the data retrieval method (API, file export), and the person responsible for access.
- Transaction category reference — mapping transaction types to report tax categories: trading, transfer between your own accounts, staking income, accrued rewards.
- Fee handling rules — how network fees and platform commissions reduce the base, which transaction they are attached to, and what to do if a debit arrives as a separate transaction without a pair.
- History top-up instructions — the procedure for loading a missed period and protection against duplicates when re-importing the same export.
- Periodic reconciliation regulation — frequency, control sums (final balance, number of transactions), and the discrepancy threshold after which an engineer is engaged.
- Change log — versions of tagging rules and authorship of edits, so that reporting for past periods remains reproducible.
What your accountants and auditors read
Accounting needs the source map, category reference, and fee rules — they determine which report line a transaction falls under.
For an auditor, traceability matters more: the path from a line in Accointing to a specific on-chain transaction, so we format reference guides as tables with identifiers rather than text descriptions.
Case study: how transaction reconciliation reduced manual work
Before automation, accounting was maintained through disparate exports: exchanges, custodial wallets, and the internal system provided different formats, timestamps did not match, and fees were either included in the trade amount or listed on a separate line.
The accountant closed the period manually, and discrepancies from prior years dragged on as an unresolved tail. Preparing the reporting period took about 30 hours, and less than half of transactions were classified automatically.
Allocation rules were described formally: a transfer between your own addresses is not considered a disposal, staking rewards are recognized as income on the receipt date, and the fee is treated as a separate expense.
A loading pipeline was built for them — it brings formats and amounts to a single reporting currency, categorizes transactions, and flags disputed ones for a human. The finished register goes into Accointing, where reporting is generated.
How we reviewed historical discrepancies
Past periods had to be cleaned up separately: the rules there changed, and some transactions were entered manually.
Old exports were matched against the current register by transaction ID and time; duplicates and gaps were found; disputed lines were compiled into a list indicating why the automation had not picked them up.
Of 340 discrepancies, 12 remained for manual resolution — the rest were closed by rules or category clarification.
As a result, the share of automatically allocated transactions grew from 40% to 96%, period preparation was reduced by about six times, and reconciliation happens during loading rather than as a separate stage at the end.
How does manual statement import differ from direct connection?
The difference is who initiates the data exchange. With manual statement import, you periodically export a table from the platform and upload it to the accounting system: time passes between exports, and everything that happened in that window remains invisible.
Direct connection works the opposite way — the system retrieves new transactions itself, and this is what Accointing integration with platforms and wallets is built on.
Completeness of transaction history is the second divide. A tabular export is almost always truncated: platforms provide the last few months, while earlier trades, internal transfers, accruals, and fees are not included.
Direct connection retrieves all available history for the account, including transactions absent from the export — and these are most often what breaks the base calculation.
The modes differ in fault tolerance. A connection survives access key changes and export format changes: the system reports a gap and backfills what was missed after permissions are restored.
Manual mode provides no such safeguard — a missed period becomes a hole in the chronology, which is filled retroactively from archives.
Ongoing accounting maintenance differs in labor costs. Manual mode is regular work: export, upload, balance reconciliation, and discrepancy review in every reporting period. Direct connection is configured once and thereafter requires only monitoring of exchange errors.
A mixed mode is justified when part of the history is unavailable through the interface: closed accounts, old wallets, unsupported assets — these are covered by a one-time export.
Common technical concerns about crypto transaction accounting
Discrepancies in crypto transaction accounting are almost never arithmetic — they arise at the junction of sources. Exchange exports, wallet history, and manual edits do not always reconcile by time and format.
Below are five concerns we most often address when integrating Accointing into reporting for Germany.
Why do discrepancies remain after manual accounting?
A manual edit changes one line but does not recalculate the disposal queue and the rate on the transaction date. Therefore, the base is calculated from the original transactions, not from intermediate totals.
Is a transfer between your own wallets a sale?
No, if both sides are matched by hash, amount, and time. Then the transfer is marked as a movement and does not enter the tax base.
When should rewards and staking be recognized?
At the moment the accrual becomes available for disposal. This way, the valuation date is correct, and income is separated from the subsequent sale of the asset.
What should be done if the export format changes?
The loading scheme is described by configuration, not by code for a specific file. We edit the description and run the history, reconciling amounts with the previous calculation.
What platform access do you request?
Read-only access to transaction and trading history without withdrawal of funds. Keys are stored in a secrets manager with environment separation and an access log.
Let's discuss the task: what to clarify before starting work
Before estimating the scope, we need to remove uncertainty around input data: the import scheme, transaction matching rules, and debugging labor costs all depend on it. Below is what we clarify during the first review of the statement of work.
If some answers are not yet known, that is also a valid input: we allocate a separate stage for clarification rather than "clarifying as we go."
- Statement of work: what result is needed in reporting — reconciliation of account balances, calculation of the base for each asset, or an export that the accountant transfers to the declaration.
- Scope of work: the list of exchanges, wallets, and networks in accounting, including those no longer used but containing historical movements.
- History depth: from which period we raise the data and whether there are gaps that will have to be restored from external sources and tagged manually.
- Transaction composition: trading, transfers between your own accounts, staking, accruals, fees — each type needs its own rule; otherwise, a transfer between your own addresses turns into false income.
- Accounting requirements: report format, breakdown by periods, whether a traceable link is needed from each amount to the source transaction.
- Implementation plan: phasing — first historical import into Accointing, then regular synchronization and discrepancy control via reconciliation reports.
Next, we record this in the scope of work description and return with an estimate, stage timelines, and an implementation plan.
Describe your task — which platforms and wallets are in accounting, for which period history is needed, and what accounting expects — and we will return with an analysis and proposal.