How to reconcile an on-chain payment to an invoice

A bank wire carries a reference field. Someone types your invoice number into it, and reconciliation is mostly a matching exercise. A blockchain transfer carries three things: a sender address, an amount, and a transaction hash. None of them is your invoice number.

That gap is the single biggest operational difference between settling in stablecoins and settling by wire, and it is where most finance teams lose time. This article covers the four methods used to close it, the failure mode of each, and what to do about payments that arrive with no attribution at all.

Why can't the payer just add a reference?

Sometimes they can. The capability exists on most chains and is simply used inconsistently.

On Solana, the Memo program lets a transaction carry arbitrary text alongside the transfer, and it is visible to anyone reading the transaction. On EVM chains, a transfer can carry calldata, though a plain ERC-20 transfer from a wallet UI usually will not. Tron supports a note field on transfers.

The problem is not capability, it is the path the payment takes. If your customer pays from an exchange account rather than a self-custodial wallet, the exchange constructs the transaction. Most exchange withdrawal flows do not expose a memo field for ordinary token transfers, and the funds leave from the exchange's pooled hot wallet rather than from any address associated with your customer.

That produces the worst case: a payment arriving from an address you have never seen, with no reference, for an amount that may not match any single invoice. You cannot fix this after the fact. You fix it by choosing a method up front.

Method one: a dedicated address per customer

Give each customer their own deposit address. Attribution then comes from the address itself: anything arriving there is from that customer, regardless of which wallet or exchange sent it.

This is the most robust method and the one that survives exchange-originated payments, because it does not depend on anything the payer does beyond using the right address.

Where it breaks: it identifies the customer, not the invoice. A customer with four open invoices paying a round sum still leaves you to decide what it settles. It also requires address generation and lifecycle management, and you need a plan for customers who reuse an old address after you have rotated it.

Method two: a unique amount per invoice

Make the expected amount unique at the cent level. Invoice $12,480.07 rather than $12,480.00, with the trailing cents acting as an identifier.

It costs nothing to implement and works across every chain and every payer path.

Where it breaks: it is fragile under partial payment, overpayment, and any deduction the payer makes on their side. It also degrades as volume rises, because the chance of two open invoices colliding on the same amount grows. It works well for a few dozen open invoices and poorly for a few thousand.

Method three: the memo or reference field

Ask the payer to include the invoice number in the memo, and validate on receipt.

When it works it is the cleanest option, because attribution is explicit and machine-readable.

Where it breaks: compliance depends entirely on the payer. Exchange withdrawal flows frequently do not offer the field, payers paste the wrong value, and a memo is not validated by the chain, so a typo produces an unmatched payment rather than a rejection. Treat it as a fast path for cooperative counterparties, never as your only method.

Method four: match on amount, time and sender

The fallback. Take the amount, the settlement timestamp and the sender address, and match against open invoices.

Every team does some of this, because some payments arrive with nothing else to go on.

Where it breaks: it is manual, it gets slower as volume grows, and it produces ambiguous cases that need a human decision. The sender address is only useful once you have seen it before, which means the first payment from any counterparty is always the hardest to attribute.

What to do about the first payment from a new counterparty

The practical answer is to capture the sender address during vendor or customer onboarding, before money moves, and then verify it with a small test transfer.

That single step converts every subsequent payment from that counterparty into a method-one match. It also protects against address substitution, which is a real fraud vector covered in verifying vendor wallet addresses.

Where the counterparty pays from an exchange, ask them to send a small amount first and record whichever address it arrives from. It will be the exchange's hot wallet, which is shared across that exchange's users, so it identifies the venue rather than the customer. That is weaker evidence, and in those cases a dedicated receiving address is worth the setup effort.

Handling the cases that do not match cleanly

Partial payments. Record against the invoice and leave the balance open, the same as a short-paid wire. The complication is that the payer may send the remainder from a different address or venue, so keep the invoice open rather than closing on the expectation of a second transfer.

Overpayments. Common when a payer covers network fees on your behalf or rounds up. Decide in advance whether small overages are credited, refunded or written to a tolerance account, and set the threshold. Refunding an on-chain overpayment costs a transaction, so a tolerance is usually cheaper below some amount.

Fee deductions. The amount that arrives can be lower than the amount sent, depending on the rail and the payer's configuration. The invoice is not short-paid because the customer underpaid; it is short by the network fee. Treat these differently in your dunning logic or you will chase customers who paid in full.

Dust and unsolicited transfers. Addresses that appear in public records attract unsolicited token sends, including tokens engineered to resemble legitimate ones. These are not receipts and should not post to the ledger. Filter by known token contract address, not by displayed symbol, because symbol spoofing is trivial.

The structural fix: attribution at settlement

Every method above is a workaround for the same gap: the payment record and the financial record are created in different places, so somebody has to join them afterwards.

The alternative is for the payment and the record to be the same event. When money moves through a system that already knows the invoice, the counterparty and the purpose, the transaction posts with that context attached and reconciliation becomes a check rather than an investigation.

That is how Plaitr handles it. Payments move through the account, so each transaction carries counterparty and purpose and posts to the ledger as it settles, then exports to Xero, QuickBooks, NetSuite or CSV. See auto accounting for the mechanism, and recording stablecoin transactions in QuickBooks and Xero for the export side.

FAQ

Can you add an invoice number to a crypto payment?

On some chains, yes. Solana has a Memo program that attaches text to a transaction, EVM transfers can carry calldata, and Tron supports a note field. The limitation is the payer's path: most exchange withdrawal flows do not expose a memo field for ordinary token transfers, so payments from exchanges usually arrive with no reference at all.

How do you match a stablecoin payment with no reference?

By sender address if you have seen it before, by a unique invoice amount at the cent level, or by matching amount and timestamp against open invoices. The durable fix is to issue a dedicated receiving address per customer, so attribution comes from where the payment landed rather than from anything the payer remembered to include.

Why did the amount received differ from the invoice?

Usually a network fee deducted in transit, or a payer rounding. Check the on-chain amount against the amount sent before treating it as a short payment, because chasing a customer for a network fee they did not control damages the relationship and does not recover the money.

What do I do about random tokens arriving at our address?

Ignore them and keep them out of the ledger. Public addresses attract unsolicited transfers, some deliberately using token names and symbols that mimic real ones. Filter by the token's contract address rather than its displayed symbol, since symbols can be set to anything.

Is a transaction hash enough evidence of payment?

It proves a transfer of a specific amount between two addresses at a block height, which is stronger than a bank reference in some ways. What it does not prove is who controls either address or what the payment was for, which is why address ownership records and invoice attribution still matter. See how to prove a wallet belongs to your company.

What should you do next?

Pick one primary attribution method and one fallback, and capture counterparty addresses at onboarding rather than at first payment. Those two decisions remove most of the manual matching.

If reconciliation is consuming days at close, the structural answer is to stop joining two records after the fact. See how auto accounting keeps the payment and the record connected as money moves.