How to reconcile crypto payments with your orders and your books

Reconciling crypto payments means checking that every order you invoiced is matched by money that actually reached you, in the right amount, and that your balance adds up to what your records say. In crypto this rarely happens by itself, because a blockchain transfer carries no order number and the amount often shifts on the way. Most of the work is done before the first payment arrives: tie each payment to its order when you create it, take the payment status from the payment service rather than the customer's browser, and record what was credited after fees rather than what was invoiced.

Three records that have to agree

Reconciliation is a check that two records of the same money tell the same story. A business that takes crypto keeps three such records, often without thinking of them that way:

• Your orders. Your shop, your sales system or a list of invoices shows who owes what, in which currency and for which order.
• Payment records. The payment service or the blockchain shows which transfer arrived, how much, in which coin and whether it is final.
• Your balance and withdrawals. The payment service shows what sits on your balance, and your own records show what you moved out to your wallet or bank.

When everything is in order, each order ties to exactly one completed payment, and the amounts credited, minus what you withdrew, explain the balance to the cent. Anything that doesn't fit is an exception. The point of reconciling regularly is to find exceptions while there are two of them, not two hundred.

Why crypto payments don't match orders on their own

A card payment reaches the merchant with the order number, the customer's name and a clean amount attached. A blockchain transfer arrives with a receiving address, an amount and a transaction hash, which is the transfer's unique ID on the network, and nothing else. The records drift apart in five places:

• No reference. The transfer doesn't say which order it pays for, so two customers who each owe 50 USDT send two transfers that look exactly alike.
• The amount shifts. A customer withdraws 100 USDT from an exchange, the exchange keeps its withdrawal fee, and 99 USDT arrives, which your records see as an underpayment.
• The currency changes. The invoice says 100 EUR, the customer pays in a coin, and the balance may be kept in yet another one, so a single order ends up described by three numbers.
• Fees come out in between. The payment service takes its cut, so less lands on your balance than the customer sent; it helps to know which fees a crypto payment carries and who pays each one.
• Status takes time. A transfer is visible on the network before it is confirmed, that is, before enough blocks have been added after it for it to count as final, and an order marked paid at that moment is marked too early.

How to set up reconciliation, step by step

Five steps cover most of it. The first three are set up once, when you connect payments; the last two are a routine.

Step 1. Put your order number on every payment

Tie each payment to its order at the moment the payment is created, so the order number travels with it to the end. Without that, payments are matched by amount and time, and the guessing starts with the second identical order.

If customers pay straight to your own wallet, the usual workaround is to give each order its own receiving address. That holds for a dozen orders a week and becomes a chore well before a hundred, which is one of the reasons businesses move to a payment service; the natural next question is what a crypto payment gateway costs and how to connect one.

At CryptumPay, an order created from your server can carry your internal order number, your user ID, the customer's email and a free-form note. All four come back in the webhook, the automatic message the service sends to your server, when the order is created. From the first message on, you know which of your orders a payment belongs to.

Step 2. Take the payment status from the payment service, not from the customer

A customer landing on your "thank you" page proves nothing: they may have closed their wallet without sending anything. An order counts as paid when the payment service confirms that the money was received, and your server should hear that from the service directly, not from the customer's browser.

CryptumPay sends a webhook at every change of an order's status:

• Created. The customer has chosen a coin and received an address, and the order is waiting for payment.
• Pending. The transfer is seen on the network and is waiting for confirmations.
• Crediting. There are enough confirmations, and the funds are being credited to the balance.
• Finished. The payment is complete, and only this message carries the amount credited after all fees.

When to hand over the goods is set in CryptumPay's documentation. An order may be fulfilled at either of two order statuses:

• Crediting. The payment has definitely been received, and crediting is in progress.
• Paid. The funds are credited to the balance.

An order that is still In progress or Under review is not fulfilled yet. Handing over the goods and recording the money are separate decisions, and the amount to record comes only with the finished webhook.

Your server can also ask CryptumPay for an order's state, and once the order reaches its final state, the answer includes its final financial summary. The merchant dashboard shows the same history of operations and statuses for a person to look through.

Webhooks from any payment service need a little care on your side. The same message can arrive more than once, and anyone who learns the address of your handler can send it a fake one, so the handler should trust only messages it can verify, and only once each. The details are in how to process crypto payment confirmations safely.

Step 3. Record what was credited, not only what was invoiced

For each order, keep three numbers side by side:

• The invoice amount. This is the price in the currency you set it in.
• What the customer paid. This is the coin, the amount and the transaction hash.
• What was credited. This is the amount that reached your balance after all fees.

Brought to one currency, the gap between the first and the third number is what accepting the payment cost you, fees and conversion together. Your balance is reconciled against the third number only; the first belongs in your sales report.

At CryptumPay, the invoice amount is set in one of 14 ordinary currencies such as US dollars or euros. Whatever coin the customer pays in is converted to USDT as soon as it arrives and credited to your USDT balance, so the balance side of reconciliation is kept in one currency instead of one per coin.

The finished webhook from CryptumPay carries the amount credited after all fees, which fills in the third number for you. CryptumPay charges 1% per successful payment, from 0.5% at higher volumes, and the fee can be passed on to the customer.

Step 4. Go through the exceptions on a schedule

Once a day, or once a week if orders are few, pull out everything that didn't close cleanly:

• Orders without a completed payment. The invoice expired and no final status came.
• Payments without an order. A transfer arrived that none of your orders claims.
• Amounts that don't match. The customer paid noticeably less or more than the invoice, beyond the small gap you agreed to accept.
• Payments stuck before the final status. The transfer was seen but hasn't been confirmed for longer than is normal for its network.

A short list each day takes minutes to clear. The same list after a quarter is an investigation, because customers no longer remember what they sent and why.

Step 5. Close the month on the balance

At the end of the month, check one equation: opening balance + credited during the month − withdrawn during the month = closing balance. If the two sides differ, three places are worth checking first:

• A credit missing from your records. A payment was completed, but the order system never marked it.
• A withdrawal nobody wrote down. Money left the balance, and the record of it lives only in someone's inbox.
• A payment that changed status after the export. The data was pulled while a transfer was still waiting for confirmations.

A withdrawal is not part of any payment, so give each one its own line in your records, down to the amount that actually reached your wallet or bank. Once several people approve withdrawals and convert them to ordinary money, this becomes a process of its own, with controls for USDT payments, conversion and withdrawals across a finance team.

What to do with each kind of mismatch

The exceptions from your daily list fall into a handful of types. Each type has its own fix, and each needs one before the order is closed in your records:

• Underpaid. The customer sent a little less, for example because an exchange or wallet took a fee on the way. Decide in advance how big a gap you write off and from what size you ask the customer to top up.
• Overpaid. The customer sent more than the invoice. The order is paid, and the extra belongs to the customer until it is returned or both sides agree to count it toward the next order.
• Paid twice. The customer sent the payment again because the first one seemed slow. Treat the second transfer as an overpayment of the whole amount.
• A payment without an order. The transfer went to an old address or arrived after the invoice closed. Find it by its transaction hash, reach the customer, and either attach it to a new order or send it back, following the rules for returning overpayments, underpayments and mistaken transfers.
• Stuck before the final status. The transfer is seen but unconfirmed for much longer than usual. Keep the order unpaid and look the transfer up on a block explorer, a public website that shows any transaction by its hash, along with how many confirmations it has.

At CryptumPay, underpayments and overpayments are mostly settled in the payment window itself, the page where the customer pays. You set a tolerance in percent: a difference within it confirms the payment automatically, and beyond it the payment window asks the customer to top up, with up to two top-up attempts. If the customer overpays, they request the extra back from the same payment window, and CryptumPay handles the return.

When a customer writes "I paid" and you see nothing on your side, ask for the transaction hash first. If the transfer went on another network or to an old address, the hash shows that at once. With it you see the transfer exactly as the network recorded it, and the walk-through of what to look at is in how to check a crypto payment by its hash, network, amount and status.

Where reconciliation ends and accounting begins

Reconciliation answers one question: did the money arrive, and does it match the order. Bookkeeping asks a different one, how that money is recorded and taxed, and the answer depends on where and how your business is registered. The two meet once a month, when your records go to whoever keeps the books.

What reconciliation can do is hand your accountant a clean file, and it only needs two parts:

• The orders. For each one: the invoice amount and currency, the date the payment reached its final status, the coin, the transaction hash and the amount credited.
• The withdrawals. For each one: the date, the amount sent, the transaction hash and the amount that arrived.

With that file, the accountant works from facts instead of screenshots and chat messages, and nobody has to rebuild a month from memory or from a wallet's history. What happens to those numbers next, from the exchange rate to the tax line, is covered in how a business accounts for crypto it gets paid in.

In short

Reconciling crypto payments is less about reading the blockchain and more about what you attach to each payment before it is sent. With the order number on the payment, the status coming from the payment service and the credited amount in your records, the daily check is a short list and the month closes on one equation. The bookkeeping that follows starts from a file that is already clean.

Questions people ask next

Do I need dedicated software to reconcile crypto payments?

At a small business's volume, usually not. If each payment already carries your order number and the payment service reports the amount credited, an export into a spreadsheet and a monthly balance check are enough. Dedicated reconciliation tools are built for finance teams whose money moves across many wallets, exchanges and networks at once, and they pay off at that scale.

How often should I reconcile?

Check exceptions daily if orders come in every day, and weekly if there are a few a week. Check the balance once a month, at close. The working rule is to look often enough that a customer who underpaid still remembers the order when you write to them.

Is the transaction hash enough to match a payment to an order?

The hash proves that a transfer happened: how much went to which address, when and on which network. It doesn't say which order the transfer pays for, unless the address was issued for that one order. That is why the order number has to be attached when the payment is created rather than pieced together afterwards.

Who should do the reconciliation: me or my accountant?

The daily exception check belongs to whoever handles orders and customers, because most exceptions are fixed by writing to the customer. The month-end balance check can go to the accountant, as long as they get the file with orders and withdrawals described above.

This article is general information, not legal, tax or accounting advice.