Stablecoin invoices: what to include for reliable payment and reconciliation

A stablecoin invoice needs more payment detail than a conventional bank invoice. Giving the customer an amount and wallet address is not enough: the invoice must also identify the exact asset, blockchain network, payment deadline and rules for handling incorrect amounts.

These details matter because sending USDC or USDT over the wrong network can make a payment difficult or impossible to recover. Clear instructions also make it possible to match blockchain transactions to invoices without relying on screenshots or manual wallet searches.

Stablerail supports invoices and payment links alongside business USDC and USDT accounts. Payments can be received across supported networks including Ethereum, Base, Arbitrum, Polygon, Tron, BNB Chain, Optimism and Solana, subject to asset and account availability. This guide explains how to structure each payment request.

Required fields on a stablecoin invoice

A stablecoin invoice still needs the commercial and tax information required for an ordinary invoice. Exact legal requirements depend on the supplier’s and customer’s jurisdictions, but finance teams will generally need the following:

• Supplier details: legal entity name, registered address, company number and applicable tax identification number.
• Customer details: legal entity name, billing address and tax identification number where required.
• Invoice details: a unique invoice number, issue date and contractual due date.
• Goods or services: a clear description, quantity or billing period, unit price and any purchase order reference.
• Accounting amounts: subtotal, discounts, tax rate, tax amount and total in the invoice’s accounting currency.
• Payment instructions: settlement asset, blockchain network, amount, receiving address or payment link, expiry time and fee policy.
• Payment reference: a unique reference that connects the blockchain transaction to the invoice record.
• Contact and dispute information: where the customer should report a delayed, failed or incorrect payment.

Do not replace the accounting currency with a token amount unless local accounting and tax rules permit it. A company may price services at USD 10,000 while accepting a specified amount of USDC as settlement. The invoice should show both amounts and explain how the token amount was calculated.

Specify the asset and network separately

“Pay in USDT” is incomplete. USDT exists on multiple blockchains, and a USDT transfer on Tron is not the same as a USDT transfer on Ethereum. The same principle applies to USDC.

Where practical, include the token’s verified contract or mint address in the underlying payment request. This is especially useful when multiple tokens use the same name or ticker. Contract details should come from a maintained internal asset list rather than being copied from a search result.

A payment link or QR code can reduce copying errors, but the invoice should still display the asset and network in plain text. Never tell a customer to “choose the cheapest network” unless every possible option is supported and monitored.

Set an expiry for the payment request

The invoice due date and payment-request expiry serve different purposes. The due date is the commercial deadline. The expiry controls how long a quoted token amount and receiving instruction remain valid.

For an invoice denominated and settled in the same unit, the payment request might remain valid for 24 to 72 hours or until the invoice due date. A shorter window, such as 15 to 60 minutes, may be appropriate when the settlement amount is converted from EUR, GBP or another currency using a live rate. These are policy examples, not guaranteed processing times.

The request should state:

• the exact expiry date, time and time zone;
• whether a transaction submitted before expiry but confirmed afterward is accepted;
• what the payer must do after expiry;
• whether a new quote or payment link will be issued; and
• how exchange-rate changes will be handled.

Avoid accepting expired quotes automatically. A stablecoin can trade above or below its reference currency, and the exchange rate between the invoice currency and settlement asset may have changed.

Define overpayment and underpayment rules

Wallet transfers do not always arrive at the requested amount. A customer may round the payment, an exchange may deduct a withdrawal charge, or the sender may accidentally submit the payment twice.

Set both a percentage tolerance and an absolute cap. For example, a 0.1% tolerance on a USD 10,000 invoice would permit a difference of up to USD 10. That may be reasonable for some supplier payments but inappropriate for payroll, tax or regulated fees, where the required amount should normally be exact.

The invoice should also say whether the payer must ensure the full invoiced amount arrives. Blockchain gas is usually paid separately by the sender, but some exchanges deduct withdrawal fees from the amount being sent.

Make reconciliation automatic

Automatic reconciliation starts before payment. Each stablecoin invoice should create a structured record containing the invoice ID, customer, asset, network, expected amount, address, expiry and tolerance.

Use a unique payment link or receiving instruction wherever possible. If the network supports a reference or memo, include it, but do not rely on free-text notes alone. Many wallets and exchanges omit them.

When a transaction is detected, capture:

• the transaction hash and blockchain network;
• the token contract or mint address;
• the raw token amount and decimal precision;
• the sending and receiving addresses;
• the first-seen and confirmation timestamps;
• the confirmation status;
• the matched invoice ID; and
• any screening or reconciliation exception.

Marking a payment as final should depend on the relevant network’s confirmation policy, not simply on seeing a pending transaction. The accounting entry should preserve both the stablecoin amount and the value recorded in the company’s functional currency.

Wallet screening can also be applied when funds arrive. If a source address triggers a sanctions or risk alert, the payment should move to an exception queue rather than being treated as an ordinary settled invoice.

A practical invoice workflow

• Create the invoice in the accounting currency with the required tax information.
• Select USDC or USDT and an explicitly supported network.
• Generate the token amount, receiving instruction and unique payment reference.
• Set the expiry, confirmation rule and overpayment or underpayment tolerance.
• Send the customer an invoice and payment link through an approved channel.
• Monitor the network and match the transaction using structured payment data.
• Post the confirmed payment to the ledger and route exceptions for review.
• Store the invoice, transaction hash, approval history and exchange-rate evidence together.

Finance teams can learn more about receiving USDC and USDT through stablecoin payment requests. For operational questions about supported assets and networks, consult the current information in the help centre before issuing an invoice.

The central rule for crypto invoicing is simple: make the payment instruction unambiguous. An exact asset, exact network, expiry and documented tolerance turn a blockchain transfer into a payment that finance teams can identify, approve and reconcile.