Turnkey Development of a Crypto Fund Reporting System

Building a crypto fund reporting system: where the data breaks

A fund rarely keeps its accounting from a single point. Data comes from custody reports, exchange exports, wallet movements, bank accounts, and OTC trades that leave no trace on-chain.

Each source has its own file format, its own frequency, and its own ticker spelling — this is the first point where the fund's transaction accounting falls apart into disconnected pieces.

Then coherence breaks. A trade enters the journal as one entry, while the wallet movement enters as another, and there is no link between them: a transfer between own addresses looks like two operations and inflates turnover.

Fees, accrued and uncredited interest, and stuck transactions settle in source balance reconciliation as a discrepancy that is explained manually each time.

Source balance reconciliation is the most labor-intensive stage. Timestamps across sources do not match: an exchange records execution at the time of the trade, a custodian at settlement, and their end-of-day balances are legitimately different. To reconcile this, an analyst builds an asset mapping table and manually tags each discrepancy.

Period close at the fund turns into manual data transfer into spreadsheets. Formulas in the workbook depend on one another, an edit breaks prior sheets, and the trail from trade to journal entry is reconstructed from memory. Crypto fund reporting under IFRS requires this trail — an auditor asks for it first.

We break down how this is closed: a unified accounting model where a trade, wallet movement, and journal entry are linked by keys, and reconciliation runs by procedure rather than manually.

What changes after implementation: measurable effects

Implementation is measured not by the number of reports, but by the time the team spends on manual reconciliations. Below are five metrics that show accounting is working: we record them at the start to compare the state before and after.

The reporting period closes in hours, not days

Previously, exports were collected manually from exchange dashboards, wallets, and spreadsheets.

The system pulls data from nodes and trading interfaces on a schedule, maps it to a unified asset reference, and aggregates it at period end — month-end close shrinks from several days to several hours.

Transaction reconciliation runs automatically

Each transaction is matched to an internal accounting entry by a unique identifier, not by amount and date. The share of automatically reconciled transactions reaches 95% and above, and the remainder is handled as an exception.

A class of manual input discrepancies disappears

Transferring numbers between spreadsheets produces transpositions, duplicates, and lost rows. A single data source removes the operation itself, so the discrepancy “the wallet does not match the accounting” does not arise.

Asset completeness is confirmed

The system maintains a register of addresses, accounts, and exchange connections, including forgotten ones. If there is no data for an asset, the report simply will not assemble: the gap is visible during preparation, not during review.

Fund flows are traceable to the source

Any figure can be traced down to a transaction with date, counterparty, and purpose — an approach close to IFRS requirements for digital asset accounting. The reviewer receives not a summary but a chain of evidence from wallet to report line.

System architecture options: in-house, hybrid, service

The choice among the three modes is determined not by interface convenience, but by who is responsible for data completeness and how deeply one needs to go into the accounting methodology.

An in-house system gives maximum control, an external one gives minimal maintenance, and a hybrid covers funds with multiple strategies and manual adjustments.

The general rule for all options is the same: integrations are read-only — neither private keys nor rights to move funds are transferred into the reporting system, otherwise the audit loses independence.

In practice, the decision comes down to three questions: what depth of history is needed to calculate returns, who will be responsible for reconciliation discrepancies, and how critical data latency is. The answers determine the architecture — then we build the accounting system for it.

Project stages: from source discovery to system handover

Fund reporting breaks not on formulas but at the input: one venue gives incomplete history, another changes its export format, and transfers between own accounts double-count turnover.

That is why the system is assembled in a fixed order — each stage relies on the previous one, and the result is verified on data, not on words.

1. Data source inventory. A list of exchange and custody statements, bank accounts, on-chain addresses, and internal spreadsheets. For each source — format, history depth, time zone, and read-only access.
2. Data flow diagram. A single diagram shows what comes from where, where it is normalized, where the raw layer is stored, and where reporting marts are assembled. We agree on it before code: edits here are cheaper than edits in the calculation.
3. Transaction matching rules. How transfers between accounts and within the network are reconciled, how fees, accruals, and rebalancing are accounted for. We separately close double-counting on transfers between own accounts.
4. Calculation and reporting form setup. Balances as of date, fund flows, realized and unrealized result, and auditor disclosures. Each form is tied to accounting rules, not to manual adjustments.
5. Acceptance checks. A run on closed periods and reconciliation against reports the fund trusts. Separately — incomplete exports, stuck transactions, timing discrepancies, and history rebuild.
6. Period close procedure. Who launches what, in what order, where the control points are, and what to do on a discrepancy. This is an instruction for the fund's team, not “call the developer.”
7. System handover to the client. Role-based access, documentation on flows and calculations, training, and support during the first closes. After that, the system runs without us.

What we hand over: registers, reporting, procedures

A system cannot be considered delivered until its operation can be run without us. Therefore, along with the code, the client receives a set of artifacts: registers, diagrams, access rights, period close rules, and employee instructions.

• Unified transaction register — wallet and exchange account movements in one structure with immutable identifiers. The register reconciles with statements, and a discrepancy is visible at the level of a specific transaction.
• Access matrix — roles are tied to actions: view, prepare journal entry, approve, export. Rights are granted to a role, not to a person, so replacing an employee does not open extra access.
• Period close procedure — the order of reconciliation, rate fixing, and period locking. After close, data is not edited retroactively: corrections go as a separate operation with a reason and author.
• Data flow diagrams — from source (exchange, network node, storage wallet) to report line: where data is cleaned, enriched with rates, and checked.
• Documentation handover — a description of the data model, reference data, and transaction classification rules; a new engineer is onboarded from documents, not from retellings.
• Employee instructions — checklists for each role: how to process a correction, a disputed transaction, or a new asset type.
• Change procedure — how to add a report or source without breaking reconciliation of prior periods.

The set makes the system auditable: the audit runs on documents, not on the memory of those who built it.

Case study: consolidated data from four sources into one register

The fund collects data from four sources: custodian Fireblocks, two exchanges, and a bank account. Every week, exports were reconciled manually — different formats, time zones, and rounding rules, and the rate had to be reconstructed from trade history.

Month-end close stretched to ten business days, and discrepancies surfaced in the already finished report.

We started with the data model: each operation receives an end-to-end key “source + external ID,” time is brought to a single time zone, and the rate at execution time is linked to the trade.

Then matching runs by rules — amount, direction, wallet address — and only the remainder goes to manual review.

What we changed

• A unified transaction register instead of four exports, with change history for each record.
• Cross-source reconciliation at input: a balance mismatch blocks loading and goes to the responsible person.
• Control sums for each source at end of day — a discrepancy is visible when it appears, not a month later.

What we achieved

Manual work decreased not because controls were weakened, but because disputed transactions are separated from the flow. The report is assembled from the register, so its figures match custodian and exchange data without re-reconciliation.

What to do if accounting is already scattered across others' spreadsheets?

First, take inventory of the spreadsheets. We list all sources: exports from exchanges and custodians, wallet addresses, manual trade registers, and files that someone keeps “for themselves” bypassing the common process.

For each, four answers are needed: who owns it, what period of data exists, what format it is in, and what is unique in it. The last point usually cuts out most of the work.

Migration of existing accounting is built on the rule “the primary source is more important than a manual record.” If an operation can be reconstructed from an exchange export or network data, we do not transfer the manual copy — it adds no information but is guaranteed to diverge from the original at the first reconciliation.

Only what cannot be reconstructed goes into the new system: off-exchange agreements, transactions between own accounts, and accruals that were never recorded automatically anywhere.

We transfer historical periods not in a continuous sweep, but by control points — reporting close dates. At each point, we reconcile balances by position and the total balance.

Discrepancies are recorded in a separate list with a reason, rather than adjusting figures to the expected result: adjusted history will later surface at the first review.

Preservation of old data is solved with a snapshot. We do not delete or overwrite the source files — they are fixed as an immutable read-only archive, with a checksum and a clear folder structure.

New accounting starts from the cut-off date, and everything before it is reproducible from the archive: a report for any past period can be assembled, even if those operations are not in the new system.

The transition plan includes a parallel period: the old and new systems run simultaneously, and discrepancies are resolved before the switch.

Only when both sides agree at the control points is the old process closed — otherwise what is transferred is not accounting but the same errors in a new wrapper.

Technical concerns: access, reconciliations, recovery

We collect the questions most often raised in a technical review: where the fund's data comes from, who sees what inside the system, what to do on a balance discrepancy, and how it survives a failure. Below are direct answers, without generalities.

How are access rights separated?

Roles are described to match the fund's structure: analyst, accountant, auditor, administrator. Rights are checked on the service side, not in the interface — a direct data request will not bypass them.

The auditor sees closed-period snapshots read-only, and manual edits are marked with author and time.

The report does not reconcile with the exchange — what next?

A balance discrepancy is a working scenario, not an emergency. The system breaks it down by cause: unrecorded fee, export delay, accrual outside the snapshot, or exchange rate difference at the time of recording.

Each discrepancy enters a queue with source and time, and the responsible person sees the records that produced it.

What happens after a failure?

The change log is append-only — the history of an operation cannot be rewritten. Daily state snapshots plus log replay provide full recovery in minutes, and reports for past periods are rebuilt deterministically: the same input data gives the same result.

Let's discuss the task: we'll show the diagram and come back with an estimate

To come back with an estimate rather than generalities, in the conversation we work through three things: where the data comes from, how the result is calculated, and who confirms the correctness of the figures on the client's side.

A list of sources is enough — exchange exports, custody accounts, wallets, bank receipts — along with a description of the reporting forms the fund submits to investors and the auditor.

We clarify integration details ourselves: access to a test environment is needed already at the prototype stage, not at launch.

After the conversation, you receive:

• A data flow diagram: from source to report line, with reconciliation points and storage of raw exports for audit.
• An implementation stage plan: source connection, transaction normalization, asset value and return calculation, reporting forms, and reconciliation over historical periods.
• A timeline estimate for each stage — with notes where the timeline depends on how quickly counterparties respond.
• Team composition: who handles integrations, who handles calculation logic, who handles acceptance and post-launch support.
• A data risk register — rate discrepancies, missed periods, manual adjustments — and how each is closed.
• A draft access model: what investors, the manager, and the auditor see, and how rights are separated.
• A conversation protocol with recorded assumptions so the estimate does not blur by the next iteration.

Work on accounting starts with one source and one reporting form: we use them to verify convergence with the fund's current figures, then expand the system. Describe the task in general terms — we will come back with a diagram, a stage plan, and a timeline estimate.