The Three-Way Reconciliation Model
Crypto payment reconciliation requires matching records across three distinct systems that each maintain their own version of the same events: the blockchain (on-chain reality), the payment gateway (operational record), and the merchant's own system (accounting and order management). A complete reconciliation confirms that all three agree on every transaction that occurred within a period.
● Blockchain ↔ Gateway: Every confirmed transaction to a gateway-monitored address should appear in the gateway's records with the correct amount, currency, TXID, and timestamp. Discrepancies here indicate missed payments, monitoring failures, or indexing errors.
● Gateway ↔ Merchant system: Every payment the gateway has marked as confirmed should have a corresponding status update in the merchant's order management system, triggered by a webhook. Discrepancies indicate missed webhooks, failed status updates, or order management bugs.
● Gateway settlement ↔ Bank statement: Every settlement transfer the gateway has initiated should appear as a credit on the merchant's bank statement with a matching amount and reference. Discrepancies indicate bank transfer failures, timing differences around month-end, or fee deductions not reflected in the gateway's net amount.
Timing Differences and How to Handle Them
Timing differences are a persistent source of reconciliation complexity in crypto payments. A customer's payment may confirm on-chain on 31 March at 23:58, but the gateway's webhook may not fire until 1 April at 00:02 due to processing delay. The merchant's order system records the payment on 1 April. The gateway's settlement for March includes the payment because it was confirmed in March. The merchant's revenue report for March does not include it because the order update happened in April. The bank receives the settlement in April.
Consistent treatment of timing differences — documented in the merchant's accounting policy — is essential for clean month-end reporting. The most common approach is to recognise revenue on the blockchain confirmation timestamp (the on-chain record), not the gateway processing timestamp or the webhook receipt timestamp. This aligns crypto revenue recognition with the economic event (payment received) rather than the administrative event (system updated).
Automation vs. Manual Reconciliation
Manual reconciliation of crypto payments at scale is not feasible. A merchant processing 200 transactions per day would need to manually cross-reference 6,000 records per month across three systems — a process that takes days and introduces human error at each step. Automated reconciliation tools compare gateway CSV exports against the merchant's ERP transaction file and flag discrepancies for human review, reducing the manual workload to exception handling.
Payment gateways support automated reconciliation through: standardised CSV/JSON exports with consistent field names; real-time webhook events that feed directly into ERP systems; API endpoints for querying transaction status by date range or Order ID; and settlement reports that provide fiat conversion rates alongside crypto amounts. Merchants should verify that their chosen gateway's export format is compatible with their accounting software before going live, and test the import process with sample data.
Failed Transactions and Their Accounting Treatment
Not all payment attempts result in confirmed transactions. Expired invoices, underpaid transactions, and transactions that remain unconfirmed for 72 hours before being dropped from the mempool all represent payment attempts that must be handled in accounting records. Expired or failed payment attempts should be recorded as closed orders with zero revenue — they must not remain as open receivables in the merchant's accounting system, which would overstate accounts receivable.
Refunded transactions require a reversal entry: the original payment receipt is recorded as income, and the refund is recorded as an expense or revenue reduction. The crypto amount and fiat value of the refund may differ from the original payment if the refund occurs at a different market rate, creating a currency conversion difference that must be recorded as a gain or loss. Gateways that provide both the original receipt rate and the refund rate in their transaction data make this accounting entry straightforward.
Compliance Note: This glossary entry is provided for general educational purposes only and does not constitute financial, investment, legal, or tax advice. Industry terminology may vary across jurisdictions and providers; definitions herein may not directly reflect the specific features, terms, or specifications of Finassets' services. For details on Finassets' offerings, please refer to official product documentation or contact our team directly.