Deep diveCustom Software Development
Reconciling Hedera transactions with the general ledger before an audit
On-chain activity and the general ledger describe the same events in different units, at different moments and with different ideas of what a transaction is. Reconciling them is an integration design problem: a source of truth, a key both sides share, posting rules for every kind of movement and an exceptions process. This page works through that design for Hedera, from mirror-node data to the evidence auditors ask for.
On this page
- Why on-chain records and the general ledger drift apart
- Terms finance and engineering need to share
- From consensus to a reconciled journal, message by message
- Mapping on-chain movements to journal entries
- Building the posting pipeline step by step
- Routing items in the exceptions queue
- Accounting pronouncements to raise with your auditors
- Audit evidence the integration should retain
- Questions and answers
- Sources
Why on-chain records and the general ledger drift apart
Drift rarely comes from one large error. It comes from small mismatches in how two systems see the same activity. Timing: a transfer reaches consensus just before midnight but is posted the next morning into the wrong period. Fees: every Hedera transaction charges a network fee to its payer, reducing the HBAR balance with no matching business event in the ERP. Units: token amounts are integers in the token's smallest unit, scaled by its decimals setting, and HBAR amounts are recorded in tinybars.
Some movements were never initiated by the ERP at all. A transaction that reaches consensus but fails is still charged a fee. Staking rewards can be paid into an account as part of an unrelated transaction. And the mirror node can return a successful transaction alongside duplicates sharing its transaction ID, each still charged network fees.2 An integration that ignores any of these will drift slowly, in ways that are tedious to unpick.
From consensus to a reconciled journal, message by message
- Hedera network
Orders transactions, charges fees and produces a record for each processed transaction.
- Mirror node
Stores records and serves them over the REST API, ordered and paginated by consensus timestamp.
- Integration service
Normalises units, splits and classifies movements, values them and posts with a key built from consensus timestamp, movement, token and account.
- ERP general ledger
Holds the journals, sub-ledgers and period controls finance already relies on.
- Reconciliation report
Compares on-chain and ledger balances per account and token, listing unmatched items.
- Hedera network to Mirror nodeRecords exported
- Integration service to Mirror nodeQuery by time window
- Mirror node to Integration serviceRecords and transfers
- Integration service to ERP general ledgerIdempotent journal post
- ERP general ledger to Integration serviceDocument number
- Mirror node to Reconciliation reportOn-chain balances
- ERP general ledger to Reconciliation reportLedger balances
- Reconciliation report to Integration serviceExceptions to resolve
Mapping on-chain movements to journal entries
The last column lists questions to settle, not accounting advice. Your finance team and auditors decide accounts and policies.
| Movement | Where it appears in the record | Posting question to agree |
|---|---|---|
| HBAR transfer | Transfer list, in tinybars, debiting one account and crediting another | Which asset account holds HBAR, and how is it valued at consensus time? |
| HTS token transfer | Token transfer list, in the token's smallest unit | Is the token an asset you hold, an obligation you issued, or neither? |
| Network fee | Fee charged to the payer, credited to node and network fee accounts | Which expense account, and per transaction or summarised daily? |
| Custom fee | Assessed custom fees, with collector account and amount | Revenue if collected, cost if paid, and how fractional fees round |
| Treasury mint or burn | Change in token supply, with the treasury account credited or debited | What does issued supply represent, and who approves mints? |
| Staking reward | Staking reward transfer inside another transaction's record | Income classification and recognition timing |
| Failed transaction | Non-success result with a fee still charged | Fee expense without a business event; review if frequent |
Building the posting pipeline step by step
Ingest by consensus time with a checkpoint
Query the mirror node for each treasury and operating account in consensus-timestamp order, follow pagination links, and store the last processed timestamp so a restart resumes exactly where it stopped.
Normalise units and identifiers
Convert tinybars and token units using each token's decimals, and store transaction IDs in one canonical format, because SDKs and the REST API write them differently.
Split and classify movements
Break each transaction into components such as transfer, network fee, custom fee and staking reward, so each posts to its own account.
Value at consensus time
Apply the rate source and timing agreed with finance, and store the rate and its source with each posting.
Post idempotently
Build the ERP idempotency key from the record's consensus timestamp, which is unique per record on the mirror node, or from the transaction ID plus nonce and scheduled flag. Then add the movement type, token ID and account, so every leg of a multi-transfer transaction posts once and a retry or replay finds the existing entry instead of creating another.
Reconcile balances daily
Compare each account's and token's on-chain balance with the ledger at the same cut-off, and send differences to the exceptions queue.
Routing items in the exceptions queue
An exceptions queue with named owners stops unexplained differences accumulating until audit fieldwork.
- If
An on-chain movement has no matching ledger entry.
ThenCheck first whether it is a fee, staking reward or duplicate; if it is a genuine business event, post it referencing the transaction ID.
Most unmatched on-chain items are system-generated movements with no business trigger.
- If
A ledger entry has no on-chain counterpart.
ThenConfirm whether the transaction failed, expired before consensus or was never submitted, then reverse or hold the entry.
Entries made at submission assume a success the network may never have confirmed.
- If
Amounts match apart from a small difference.
ThenLook for custom fees, fractional-fee rounding or inconsistent decimals before writing anything off.
Small differences usually have a systematic cause that will recur.
- If
A payment has to be undone.
ThenSubmit a new, compensating transaction on Hedera and post it as its own entry.
Consensus is final, so correction always takes a second transaction.
Accounting pronouncements to raise with your auditors
Audit evidence the integration should retain
Questions and answers
Can we reconcile against our own submission logs instead of the mirror node?
Use your logs to know what you submitted and the mirror node to know what the network did. Submissions can fail, expire before consensus or incur fees you did not expect, and staking rewards arrive with no submission at all. Reconciling against your own logs alone misses exactly the items auditors ask about. Many teams keep both and treat any difference between them as an exception.
Which timestamp should decide the accounting period for a Hedera transaction?
The consensus timestamp, converted to the time zone your reporting periods use. The time inside the transaction ID is chosen by the payer before submission and can fall in a different period from the moment the network ordered the transaction. Agree the conversion rule with finance, apply it in the integration, and show both the consensus time and the derived period in the evidence.
Should network fees be posted per transaction or as a daily summary?
Either works if it is agreed and applied consistently. Per-transaction posting gives the cleanest trail but can flood the ledger at high volume. Many teams post one daily summary per paying account and keep transaction-level detail in a sub-ledger or the integration's store, linked by consensus timestamp and transaction ID. The test is whether an auditor can trace any summary back to individual fees.
Does Hedera's finality make reconciliation easier?
It removes one problem: once a transaction reaches consensus it will not be reordered or reverted, so there are no confirmations to wait for and no chain reorganisations to handle. Fees, units, staking rewards, failed transactions, duplicates and period cut-off remain. Finality also means mistakes are corrected with a compensating transaction rather than a reversal, which the posting rules must handle.
Sources
- Mirror Node REST API — Hedera documentation · checked 10 October 2026
- Mirror Node REST API: Transactions — Hedera documentation · checked 10 October 2026
- Accounting Standards Update 2023-08, Intangibles—Goodwill and Other—Crypto Assets (Subtopic 350-60) — Financial Accounting Standards Board
- IFRIC Update June 2019: Holdings of cryptocurrencies — IFRS Foundation · checked 10 October 2026