Reconciling a stablecoin transaction means being able to walk from any one record of a payment to the others: your own, your provider's, and the external evidence on a bank statement and on the blockchain. It breaks for a reason that has nothing to do with blockchains, which is that a single payment produces several records, written by different systems, at different moments, in different currencies. The payment your customer sees, the conversion that happened in the middle, and the fee that came out of it are three facts about one event, and if your ledger stores them as one line you will spend every month end reconstructing the other two.
Getting this right is mostly a set of decisions made before the first transaction, not a process applied afterwards. What the underlying system exposes is covered in what a stablecoin API is; this is what to do with it.
The three records that have to agree
The first is yours: the invoice, the order, the payroll line, whatever the payment exists to settle. The second is the provider's: the transaction, its states, and the receipt it produces when it completes. The third is external: the bank statement on the fiat side and the blockchain record on the stablecoin side.
Reconciliation is the discipline of being able to walk from any one of those to the other two. Most teams can walk from their own record to the provider's, because they have an identifier. Far fewer can walk backwards from a line on a bank statement to the order it settled, and that is the direction an auditor will ask you to go.
There is also a legal floor under this in Brazil, and it is broader than people expect. Law 9.613 of March 3, 1998 obliges the institutions it covers to keep a record of every transaction above the limit set by the competent authority, and its Article 10 was amended by Law 14.478 of December 21, 2022 to name virtual assets explicitly alongside national currency, foreign currency and securities. Record keeping here is a regulatory obligation that happens to also be an accounting convenience.
Carry your own reference from the first call
The cheapest thing you will ever do for reconciliation is attach your own identifier to the transaction when you create it, and the most expensive thing is deciding to do it later.
Providers generally allow arbitrary metadata on a transaction, and that field is where your order number, invoice number or payroll run identifier belongs. It then comes back on every response and every event about that transaction, so the mapping between your world and theirs exists without a lookup table that has to be maintained. Put the identifier that means something to your business there, not a copy of the provider's identifier, which you already have.
Separately, use an idempotency key on every creating call. Its first job is to stop a retry from producing a second payment, and its second job is reconciliation: it is the thing that lets you prove that the payment you think you sent once was in fact sent once. Keys typically expire, often in twenty-four hours, so a job that resumes days later needs its own way of knowing what it already did.
Only one state is final, and it is not the one you get first
A stablecoin payment moves through several states, and it is normal for it to sit in the middle ones for a while. An off-ramp typically moves the stablecoin, converts it, then transfers fiat, and each of those is a state you can observe. A collection waits for funds, then transfers, then trades, then credits.
The accounting consequence is that only the terminal state should produce a ledger entry that says the money arrived. Teams that post on the first event get a book that shows completed payments which are still in flight, and then a correcting entry when one fails. Teams that post on the terminal event have a boring close.
Build for the states that are not success as well: failure, and, for collections, expiry when the expected money never arrived. An expected collection that expires is not an error in your system, it is a customer who did not pay, and the two need different handling in your receivables.
The receipt is where the money is actually explained
When a converting transaction completes, the useful record is not the amount you requested. It is the receipt: the source amount, the base exchange rate, the amount that rate implies, each fee itemized with its rate and its total, the final amount delivered, and the effective rate after fees.
Store all of it. The difference between the base rate and the effective rate is the cost of the transaction, and it is the number your finance team will eventually be asked to explain. If your ledger keeps only the amount sent and the amount received, that cost exists in your business and nowhere in your records, and reconstructing it a year later means recomputing rates you no longer have.
On the stablecoin leg, the receipt also carries the transaction hash, which is the link to the external record. That is what turns "our provider says it paid" into something an auditor can verify without asking us.
My first question about any new flow is which field carries the cost, and it comes from a habit rather than from a principle. For a long stretch the fee was implicit in the difference between two rates we had stored separately from the transactions, which put the number in the business and in no single field of the record. A ledger in that shape reconciles to the cent and still cannot say what moving money cost. Nothing is wrong and nothing can be shown to be right, which is a worse position than an error. So if the answer to which field carries the cost is a subtraction between two other fields, I treat that as a gap rather than as an answer.
Timing differences are the normal case
The conversion, the fiat movement and the blockchain confirmation do not happen at the same moment, and they do not have to fall in the same accounting period. A payment created on the last day of the month and settled on the first of the next appears in one period in your ledger and another on the bank statement, which is an ordinary cut-off difference and needs an ordinary cut-off policy.
Two details make it sharper than in domestic payments. Provider timestamps are usually in UTC while your ledger probably runs on a local calendar, so a payment at 21:00 in São Paulo is already the next day in the record. And rails differ: Pix (Brazil's instant payment system, run by the Central Bank) settles continuously including weekends, while wires and batch rails settle on business days, so the same payment run produces different cut-off behaviour by country. A marketplace paying sellers in several countries at once sees all of this in a single run, which is why marketplace payouts across LATAM is where it usually surfaces first.
Collections have their own version of the problem. When money arrives into an account in your customer's own name, the name on the deposit is what makes the match possible, and what a named virtual account is explains why that is worth having.
What reconciliation will not fix
It will not tell you how to classify the assets. Whether a stablecoin balance is cash, a cash equivalent, an intangible or something else in your reporting framework is a question for your auditor, and the answer differs by jurisdiction and by framework. A clean transaction record makes that conversation short; it does not decide it.
It will not fix an architecture where one payment cannot be traced to one obligation. If your platform pools funds and settles internally, no amount of reconciliation logic reconstructs which customer's money moved, because that fact was never recorded anywhere.
And it will not survive being bolted on. A system that did not carry references and did not store receipts can be reconciled for the current period by hand, and cannot be reconciled for last year at all.
Reconciling on Lumx
Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.
Every transaction accepts a free-form metadata object, which is where your own order or invoice reference goes. It is returned on the transaction and on every webhook about it, so the join between your ledger and ours needs no lookup table. Creating calls take an idempotency key: reusing one with a different body is rejected outright, a replayed response is flagged as cached, and keys expire after twenty-four hours.
The states are explicit and documented per transaction type. A collection runs from awaiting funds through the fiat transfer, the trade and the stablecoin transfer to success, and a payout runs the same path in reverse; failure is a state, and an unpaid collection expires rather than lingering. Each status change is delivered as an event carrying its own event identifier alongside the transaction, which is what lets you make delivery idempotent on your side.
On success the receipt carries the source amount, the base exchange rate, the base target amount, each fee with its rate and total, the final amount, the effective rate after fees, and the blockchain transaction hash with a link to a block explorer. That is the whole cost of the transaction in one object, which is the thing worth persisting. Payouts also accept a memo that travels with the wire as a reference on the receiving statement. Changes to any of these shapes are published in the dated changelog, and how the pieces fit across countries is in global payments.
Verified on September 24, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Jeyakumaran Mayooresan on Unsplash.
What identifier should I use to match payments to invoices?
Your own. Attach your order or invoice reference to the transaction as metadata when you create it, so it comes back on every response and event. Relying on the provider's identifier alone means maintaining a mapping table, and relying on amounts and dates means guessing when two payments are similar.
When should a payment be posted to the ledger?
On the terminal state, when the money has actually arrived. Posting on the first event produces a ledger that shows completed payments that are still in flight, followed by corrections when some of them fail. The intermediate states are useful for operations dashboards rather than for accounting entries.
How do I account for the exchange rate and fees?
Store the full receipt rather than the net amount. The base rate, the itemized fees and the effective rate after fees are what let you explain the cost of moving money, and the difference between the base and effective rates is that cost. If you keep only the amount sent and received, the cost is real in your business and absent from your records.
Does a stablecoin balance count as cash in my accounts?
That depends on your reporting framework and your jurisdiction, and it is a question for your auditor rather than for your payments provider. What you can control is the quality of the underlying record: complete transactions, itemized costs, and a traceable link to the external evidence on both the fiat and the blockchain side.
