Transaction Reconciliation

Overview

A transaction hash is not always a complete match

Transaction reconciliation asks whether actual blockchain movements correspond to the payment records a business holds. In Bitcoin, the relevant output and amount may matter. On Ethereum and other contract chains, a single transaction can contain multiple token transfer events, some to different recipients. Therefore, matching invoice A to transaction hash H does not by itself prove that the amount assigned to A was correct. The matching unit must be specific enough to identify the relevant transfer or output.

How the underlying system works

For each matched transaction, retain the chain or network, asset, transaction identifier, receiving address, actual amount, confirmation observations and provider reference. Some blockchain transactions contain multiple relevant transfers or token events; a transaction hash may not uniquely identify one merchant payment line. The matching process therefore needs the correct output, log or transfer index where applicable.

Common exceptions include a missing deposit, a duplicated provider event, an amount mismatch and a payment that was sent to an unrelated address. Determine whether the problem is in blockchain observation, provider accounting or the merchant's own invoice mapping before correcting records. Corrections should be auditable and reversible.

Follow an incoming token transfer

Suppose a payment request expects 50 USDC on a particular Ethereum network. The monitoring service observes a transaction containing a Transfer event. The reconciler checks the network, official token contract, destination, numeric amount and event position, along with the transaction's execution success. It then compares those facts with the invoice instructions and provider record. If a second Transfer event inside the same transaction sends 30 tokens to another recipient, the system must not count that amount toward the invoice. Store event-level identifiers when needed, such as transaction hash plus log index, so that reprocessing does not double-credit the movement.

Handling timing, reversals and unknown deposits

A transfer may be detected before the application's required confidence level is reached. Chain reorganizations or indexer lag can also change what evidence is current. Record whether the source is observed, confirmed or finalized according to the relevant policy. Deposits that lack an invoice reference or use an unsupported token should be assigned for review rather than forced into the nearest matching order. If a customer sends two payments, record both and the rule used to allocate them. Reconciliation should reconstruct what happened, not manufacture a tidy result.

Further reading and related concepts

Reference documents: OxaPay — Payment History, Ethereum.org — Transactions.

Related glossary topics: Reconciliation, Transaction Hash, Blockchain Payment Monitoring.