Crypto payment reconciliation means proving which verified receipts belong to which orders, then explaining every remaining difference. A wallet balance alone cannot tell you what you sold, which customer paid, or whether a transfer was a sale at all.
Use three linked records: the order, the provider's payment record, and the transfer received by your business. This guide gives small merchant teams a daily close procedure, not accounting or tax advice. The controls are recommendations for your own records; they are not claims that Yolfi automatically exports, reconciles or books payments.
Keep orders, payment records and transfers separate
An order describes the commercial agreement. A payment record describes the request and its processing. A blockchain transfer is evidence of asset movement. They are related, but not interchangeable.
One order may have multiple payment attempts. One transaction may contain multiple token transfers. A move between your own wallets is not another customer payment. Store these relationships instead of forcing every row into a one-order, one-hash model.
| Record | Minimum fields to retain | Question it answers |
|---|---|---|
| Order | Order reference, customer reference, invoice currency and amount, order state | What did the customer owe? |
| Payment request | Provider reference, linked order, requested asset and network, destination, amount and expiry if applicable | What instructions were issued? |
| Verified transfer | Network, asset identifier, transaction hash, transfer position where applicable, recipient, amount, block and confirmation evidence | What actually arrived? |
| Allocation | Transfer reference, order reference, amount applied, reviewer and time | Which receipt settled which obligation? |
| Adjustment | Refund or internal-transfer reference, reason, approval and related record | Why does movement differ from sales? |
Keep personal customer data in access-controlled business records, not public blockchain notes. Never store private keys or recovery phrases in a reconciliation sheet.
Identify the transfer, not just the ticker or hash
For tokens, retain the network and verified contract or mint address as well as the ticker. A label saying USDC is not enough to distinguish assets across chains or an unrelated token using the same symbol. Confirm identifiers against an authoritative asset source before accepting receipts.
For an EVM token transfer, a practical unique reference is the chain identifier, transaction hash and log index, together with the verified token contract. A transaction hash by itself is too coarse when a transaction emits several transfer events. Other chains need their own appropriate instruction or event identifiers; do not impose the EVM format everywhere.
The Ethereum JSON-RPC documentation distinguishes transaction receipts, status and logs. For an ERC-20 payment, inspect the relevant token transfer event: the transaction's top-level recipient can be a contract rather than the merchant's receiving address. A successful transaction is not, by itself, proof that your expected asset and amount arrived.
If you use a transfer-history service, retain the query scope and all pages. The Etherscan token-transfer endpoint exposes chain, address, contract, block-range and pagination filters. A first page is not a complete day's ledger. Explorer data is supporting evidence, not a substitute for order allocation.
Run this daily close in a fixed order
1. Set the cutoff and collect the records
Choose a business timezone and an exact reporting interval, with an inclusive start and exclusive end. Record both that interval and the UTC timestamps used in queries. State whether your report groups transfers by block time, provider confirmation time or another documented basis.
Collect orders and payment records for the period, plus older open items. Obtain the transfers for each business receiving address and supported network through your available records or verified blockchain data. Do not assume a dashboard or API has a particular export feature unless you have checked it.
Preserve retrieval time and block range. A transfer seen near cutoff may satisfy your confirmation policy only later; keep it pending rather than changing the prior day's evidence without explanation.
2. Normalize without losing precision
Keep asset quantities separate from invoice values in local currency. Store token amounts in exact base units or exact decimals with verified precision. Do not add USDC on different networks into a single unexplained balance, or mix USDT with USDC merely because both target a dollar value.
If your books need a local-currency value, record the valuation source, timestamp and method required by your accounting policy. A stablecoin ticker is not an instruction to book every receipt at exactly one US dollar. Ask your accountant how to treat fees and value changes in your jurisdiction.
3. Match and allocate once
Start with reliable order and provider references. Verify the asset, network, recipient, amount and confirmation evidence before allocating a receipt. If several orders request the same amount, amount and time alone do not prove the customer identity.
Enforce uniqueness for each transfer record and keep allocations within its available amount. Several approved allocations may share a receipt only when your business process supports it and the sum is controlled. Receiving the same notification twice must not create a second receipt or release the order twice.
4. Separate exceptions from the closing totals
Keep unmatched receipts, unpaid orders and pending confirmations visible. Assign an owner, reason and next action to each difference. Use the underpayment and overpayment playbook for amount disputes rather than improvising another full payment request.
Route asset or chain mismatches to the wrong-network payment guide. An exception is not resolved just because somebody changed its spreadsheet colour.
5. Reconcile movement and sign off
For each asset on each network, bridge opening and closing balances using verified inflows and outflows. Classify sales receipts, refunds, internal transfers and other movements separately. Record network fees in the asset actually spent; do not silently deduct a native-coin gas fee from the stablecoin receipt.
Use this balance bridge as a completeness check, not a revenue calculation. A positive bridge does not prove every order was allocated correctly, and recognized revenue may follow different accounting rules.
A worked close without invented customer data
This illustrative example concerns one USDC asset on one network. All movements satisfy the chosen cutoff and confirmation policy.
| Movement | USDC |
|---|---|
| Opening balance | 400 |
| Verified customer receipts | +250 |
| Transfer from another business wallet | +100 |
| Approved customer refund | -20 |
| Transfer to another business wallet | -150 |
| Closing balance | 580 |
The balance rose by 180 USDC, but customer receipts were 250 USDC. Neither figure automatically equals recognized revenue. The internal transfers change this wallet's balance without creating sales; the refund remains linked to its original order. Native-coin network fees belong in that asset's separate bridge.
A reviewer should also check that every part of the 250 USDC has an order allocation or an explicit unresolved classification. Agreement between opening and closing balances does not catch a receipt allocated to the wrong customer.
Where Yolfi fits in the record chain
Yolfi's payment links page describes creating payment links, tracking payments and receiving funds directly in your wallet. That gives a merchant a payment-request context alongside wallet receipts; it does not remove the need to connect those records to orders.
Before accepting a live payment, check the asset, network and receiving address offered in your actual setup. Retain the payment reference available to you and your own order reference. Verify what records your current integration exposes before designing an automated reconciliation process. Do not infer export formats, accounting integrations or matching rules from a public marketing page.
For service businesses taking deposits or milestone payments, the freelancer payment-link guide explains the commercial side. Keep that scope alongside the payment evidence so a deposit is not mistaken for a fully paid project.
FAQ
Can I reconcile using wallet balances alone?
No. Balances can support a movement check, but cannot explain order ownership, internal transfers, pending obligations or whether a receipt represents revenue.
Is one transaction hash always one payment?
No. A transaction can include multiple transfers. Keep the network and the chain-appropriate transfer identifier, then allocate the relevant receipt to the correct order.
What if a payment confirms after the daily cutoff?
Keep the original observation and move the item through your documented pending-to-confirmed process. Apply a consistent reporting basis and retain a correction trail instead of silently rewriting a closed period.
Does reconciliation require automatic accounting software?
Not necessarily. A controlled spreadsheet may work at low volume if it preserves exact amounts, unique references, evidence and review history. Move to a database or accounting integration when volume or error risk makes manual controls unreliable.
Close with evidence, not a forced zero
A useful daily close ends with matched receipts, classified wallet movements and a short owned exception list. It does not require hiding unresolved items. Start with clear payment-link instructions, retain the order relationship, and let verified transfer evidence decide what can be closed.
