Your Company Receives a Stablecoin Payment: What Data Should You Capture from Day One?
A customer settles an invoice in USDC, EURC or another stablecoin. The tokens appear in the company wallet and the transaction is visible on-chain. But what information should the company retain so that the payment can be accounted for, reconciled and evidenced months later?
Receiving stablecoin payments creates three layers of evidence that must be connected: commercial evidence, on-chain evidence and accounting evidence. The invoice, client identity, stablecoin, network, addresses, transaction hash, valuation and accounting entry should form one audit trail.
A stablecoin payment creates three layers of evidence
To explain the transaction several months later, the company must connect three sets of information: commercial evidence — why was the payment received?; on-chain evidence — what transaction actually occurred?; and accounting evidence — how was the receipt valued, reconciled and recorded?
The quality of the control framework depends less on the amount of data collected than on the ability to establish the chain: INVOICE → CLIENT → TRANSACTION → WALLET → VALUATION → ACCOUNTING. The best time to build that chain is when the payment is received.
What data should a company retain when receiving stablecoins?
Identify the invoice and client
The blockchain proves a transaction, not its commercial context. An on-chain transaction can generally provide technical information such as the network, addresses, transferred asset, quantity, block, timestamp and transaction identifier. It does not know the company’s invoice number.
The first layer of the file is therefore commercial. For each receipt, the company should be able to retrieve the client, related invoice, invoice currency and amount, expected payment, agreed stablecoin and purpose of payment. If one transfer settles several invoices or only part of an invoice, that allocation should also be documented.
Identify the stablecoin and network
A record stating only ‘payment received in USDC’ is not enough. Record the stablecoin, network, quantity actually received, observable source address, destination address, transaction identifier, available block and timestamp information, and transaction status. Where relevant, retain the technical asset identifier used on that network.
Source address and client identity are different data points
The source address is the observable technical origin of the transaction. It does not, by itself, establish the legal identity of the client. A payer may use its own wallet, an exchange, a crypto-asset service provider, a custodian or payment infrastructure.
The file should therefore retain the commercial identity of the client and the observable source address separately. Additional information explaining the relationship between them can be retained as context, but it should not be inferred solely from the blockchain.
The transaction hash is the technical reference
The transaction hash allows the event to be retrieved on the relevant network. It is a central piece of evidence, but it does not replace the invoice, client identification or the information supporting valuation and accounting treatment.
What can the blockchain tell you later?
Depending on the network and infrastructure, the hash, addresses, token, transferred quantity, block and certain time information can generally be retrieved later. The blockchain will not necessarily preserve the related invoice, legal client identity, business purpose, valuation method, price source, explanation of a difference, internal approval or accounting reference.
Those data points belong to the company’s systems. Waiting until closing to reconstruct them turns a relatively simple collection process into an investigation.
Keep the relevant dates separate
A stablecoin receipt may involve several moments: invoice date, payment initiation date when known, on-chain timestamp, the point at which the company considers the transfer sufficiently final, and accounting date. These dates should not automatically be treated as identical. Internal policy should define which event is used for each treatment and apply it consistently.
How should a stablecoin payment valuation be documented?
Where the invoice currency and the asset received are not exactly the same unit of account, the file should allow another person to understand how the recorded value was calculated. The logic to document is generally: quantity received × reference value or exchange rate = value used for the transaction.
Retain the relevant source, rate or price and, where it affects valuation, the relevant date or time. The objective is not to accumulate screenshots; it is to make the calculation reproducible.
French accounting framework
For French companies, ANC Regulation No. 2026-01 of 9 January 2026 changes the accounting framework for crypto-assets and introduces specific accounts for electronic money tokens. It is mandatory for financial years beginning on or after 1 January 2027 and may be applied early under the conditions set out in the regulation.
This article does not determine the accounting treatment applicable to every stablecoin. Its purpose is upstream: to preserve the data required to evidence, account for and control the receipt.
How should fees and payment differences be handled?
An invoice for €20,000 does not necessarily produce exactly 20,000 units available in the company wallet. Depending on the payment architecture, relevant figures may include the invoiced amount, quantity sent when known, quantity actually received, network fees, provider fees, conversion costs and net amount available.
Not every field applies to every transaction. The point is to avoid collapsing all components into a single amount when fees or conversions explain a difference.
Reconciliation with the invoice should produce a status
Receiving the payment does not complete the control. The company must determine what the payment does to the corresponding receivable. The result can be: invoice settled, partially settled, overpaid, explained difference or difference requiring investigation.
Consider a simplified example. A €20,000 invoice results in receipt of 20,000 USDC. Under the valuation method applicable to the company, the illustrative recorded value is €19,982. The €18 difference should not be hidden. Its origin and treatment should be documented.
This is the step that turns blockchain data collection into an accounting reconciliation.
Build the audit trail from payment to accounting
As volumes increase, manually searching for an invoice in the ERP, an address in a wallet register and a hash in a blockchain explorer quickly becomes inefficient. A practical approach is to assign a unique internal identifier to each receipt.
That identifier creates the chain: INVOICE ↔ CLIENT ↔ PAYMENT ↔ WALLET ↔ TRANSACTION ↔ VALUATION ↔ ACCOUNTING ENTRY. The same identifier can then be used in reconciliation and controls.
The minimum stablecoin payment record
A minimum record can cover: commercial transaction — client, invoice, currency and amount; asset — stablecoin, network and quantity; origin — source address and known context; destination — company address or wallet; blockchain — transaction hash, block, timestamp and status; valuation — source, rate or price and calculated value; fees — nature and amount when identifiable; reconciliation — settled, partial, difference or anomaly; accounting — date and accounting-entry reference; control — internal identifier, supporting evidence and observations.
This is a BECTRA corporate traceability framework. It should not be presented as a universal list of information legally required from every company.
Regulatory context: company records are not the same as CASP obligations
EU Regulation 2023/1113 imposes specific requirements on relevant crypto-asset service providers concerning information accompanying transfers of crypto-assets. It includes information concerning the originator and beneficiary, distributed-ledger addresses and, where they exist, crypto-asset account identifiers.
It also contains specific provisions for transfers involving self-hosted addresses. For certain transfers above €1,000, additional measures apply to the relevant service provider. Those obligations should not be converted into identical obligations for every company receiving a stablecoin payment.
What should the company be able to reconstruct six months later?
A reviewer who did not process the payment should be able to follow: INVOICE → CLIENT → EXPECTED PAYMENT → TECHNICAL ORIGIN → ON-CHAIN TRANSACTION → DESTINATION WALLET → AMOUNT RECEIVED → VALUATION → RECONCILIATION → ACCOUNTING ENTRY.
If one of those links depends only on an old email, a personal spreadsheet or the memory of the employee who processed the transaction, the audit trail remains fragile.
The blockchain records the transfer. The company must preserve its business and accounting context.
Comments