Reconciling on-chain payments
A bank deposit usually arrives with a reference. An on-chain payment arrives as a transaction hash, an amount and two addresses, and nothing else unless you planned for it. Reconciliation is far easier when you decide up front how each payment will identify its invoice.
Key points
- The transaction hash is the permanent anchor that ties a payment to an invoice.
- Give each invoice a unique on-chain identifier: a dedicated address, a unique amount or a memo where the network supports one.
- Write tolerance rules for partial, over- and late payments before the first exception arrives.
- At month-end, reconcile units held as well as CAD values.
What an on-chain payment actually tells you
Every confirmed payment on a public ledger carries a small, fixed set of facts: a transaction hash, the sending and receiving addresses, the asset and amount in units, the network, the block it was included in and its time. It does not carry the payer's name or your invoice number unless the payer or your system put one there.
Those facts are public and permanent. Anyone with the hash can look up the payment, which makes it strong evidence for an auditor. It also means a payment cannot be edited after the fact, so a mismatch has to be resolved in your records, not on the ledger. On-chain settlement and finality explains when a payment can be treated as settled.
Three ways to tie a payment to an invoice
You can combine these methods, for example a dedicated address as the primary key with the amount as a cross-check. A payment request that encodes both the address and the exact amount reduces typing errors; see payment request standards.
| Method | How it works | Watch for |
|---|---|---|
| Dedicated address per invoice | A fresh receiving address is generated for each invoice, so anything arriving there belongs to that invoice. | More addresses to monitor, and moving funds out of many addresses costs network fees. |
| Unique amount | Each open invoice gets a total no other open invoice shares. | Breaks when a payer's wallet deducts its fee from the amount sent or the payer rounds. |
| Memo or reference field | The payer includes the invoice number in a memo or tag field. | Not every network or wallet supports memos, and payers forget them. |
A matching routine, step by step
Whether you run it daily by hand or automate it with webhooks and payment events, the routine is the same.
- Pull new transactions to your receiving addresses from your wallet software, a provider export or your own node.
- Mark anything below your confirmation threshold as pending rather than paid.
- Match on receiving address first, then on asset, network and amount, then on any memo.
- Record the transaction hash, units, CAD value at the time of the transaction and block time against the invoice.
- Mark the invoice paid, part-paid or over-paid according to your written tolerance rules.
- Send anything unmatched to an exceptions queue with a named owner and a due date.
Partial payments, over-payments and wrong assets
Take an Ontario invoice for $1,000 plus $130 HST, a total of $1,130. If the customer pays in a USD-referenced stablecoin and we assume one unit is worth $1.37 CAD when the invoice is issued, the crypto receipt record tool shows 824.82 units due. That rate is illustrative, not a current exchange rate.
Now suppose 800 units arrive. The invoice is short by 24.82 units. Your policy decides what happens next, and it should be decided before it happens, not by whoever is on shift.
- Tolerance band: a small shortfall you accept and write off as a payment cost, stated in units or CAD.
- Partial payment: keep the invoice open, record the payment and request the balance with a fresh payment request.
- Over-payment: hold the excess as a customer credit or refund it. A refund is a new outgoing payment with its own network fee; see refunds on-chain.
- Late payment: if the quote has expired, re-price the balance at the current value under your stated terms.
- Wrong asset or network: funds sent on an unsupported network may be difficult or impossible to recover; document what you can and escalate.
Why the CAD value can drift from the invoice
When you invoice in CAD and quote in units, the CAD value of those units can move before payment arrives. With a USD-referenced stablecoin the movement comes mainly from the USD/CAD exchange rate; with a native crypto-asset it can be much larger.
For tax records, the CRA uses the fair market value in CAD at the time of the transaction, so record the value at payment time even if it differs from the quote. Treat the difference as a separate line rather than editing the sale. Accounting for crypto receipts walks through the entries.
Month-end close checklist
On-chain balances are easy to verify because the ledger is public. The work is making sure your books agree with it.
- Units held per address or account agree with your clearing account in units.
- Every paid invoice has a transaction hash recorded against it.
- Pending payments below your confirmation threshold are listed separately.
- Exceptions are aged, with owners and next actions.
- Conversions agree with CAD deposits in your bank account, including fees.
- Network fees paid are recorded as expenses.
- Evidence of the fair market value source is filed for each receipt.
If your business is a FINTRAC reporting entity, such as a money services business, FINTRAC's record-keeping rules apply; for virtual currency transfers of $1,000 or more, records include sending and receiving addresses and the transaction hash. See record keeping.
Controls that prevent reconciliation problems
Many exceptions can be prevented before a payment is ever sent. A few controls catch them early.
- Generate receiving addresses in your system, never by copying from an email or chat.
- Treat any request to change a payment address as suspicious until verified through a known channel; address-swap fraud is covered in crypto payment scams.
- Separate the person who issues payment requests from the person who approves refunds.
- Confirm payments on the ledger, not from screenshots or emailed confirmations.
You cannot pull back a payment sent to the wrong address or a mistaken over-payment. Corrections are new payments, so verify before you send.
Questions people ask
Is a transaction hash enough proof of payment?
It proves that a transfer happened on the ledger between two addresses. You still need your own records to show which invoice it settles and who the payer was.
Should I reuse one receiving address for all customers?
It is simpler to set up but harder to reconcile, because every payment lands in the same place and must be matched on amount or memo alone. A dedicated address per invoice makes matching more reliable.
How do I handle a payment that arrives after the quote expired?
Follow the terms you stated on the invoice. A common approach is to record the payment at its value at the time it arrived and request or refund the difference.
How often should I reconcile?
Daily matching keeps exceptions small, and a full reconciliation of units and CAD at month-end supports your financial statements.
Sources
- FINTRAC — Record keeping requirements for money services businesses
- CRA — Income from crypto-asset transactions
- bitcoin.org — Developer guide: block chain
Reviewed October 30, 2026. Educational information only; not financial, legal, tax or investment advice. This site does not process payments or hold funds.