Month-End Close With a Stablecoin Treasury: A Practical Checklist

A stablecoin treasury adds several moving parts to the month end close: balances across wallets and networks, fiat accounts, transactions still in flight, blockchain fees and foreign exchange movements. The objective is the same as for any treasury close: prove that recorded balances exist, apply a consistent valuation policy and document every reconciling item.

This treasury close checklist is designed for finance teams holding or moving USDC and USDT. It assumes the company has already agreed its accounting treatment with its advisers. Stablecoins may be classified differently depending on the reporting framework, jurisdiction, redemption rights and company policy, so the checklist focuses on operational mechanics rather than prescribing an accounting conclusion.

Before close: define the scope and cut-off

Start with a complete register of the accounts included in the close. Stablecoin balances should be listed by legal entity, token, network and wallet rather than recorded as one consolidated balance.

• Fiat accounts: EUR, USD, GBP and other balances, including virtual IBANs.
• Stablecoin vaults: USDC and USDT held on Ethereum, Base, Arbitrum, Polygon, Tron, BNB Chain, Optimism or Solana.
• Gas balances: native assets such as ETH, TRX, BNB, POL or SOL used to pay network fees.
• External venues: exchanges, custodians, payment processors and yield providers.
• Operational balances: card funding, payroll, payout and collection accounts.

Set one cut-off time for the reporting entity, including the time zone. For example, “23:59:59 UTC on the final calendar day” is more precise than “end of day.” Record the block number or blockchain timestamp used for each network snapshot.

Bank transfers must be treated according to their actual status at cut-off. ACH, Fedwire, SEPA, SEPA Instant, SWIFT, Faster Payments, CHAPS and BACS have different processing windows. A payment instruction created before month-end is not necessarily a completed payment.

Five-day treasury close checklist

This schedule is illustrative. A business with high transaction volumes may need automated daily reconciliation so that month end is primarily an exception review.

1. Capture and prove every closing balance

Export the closing ledger balance for every account and compare it with an independent source. For fiat, use the account statement or transaction export. For self-custodial stablecoins, compare the ledger with the relevant wallet address and blockchain record.

A self-custodial MPC vault uses multiple cryptographic key shares to authorise transactions rather than relying on one private key. Quorum signing determines how many authorised shares must approve a transfer. These controls protect transaction execution, but the finance team must still reconcile the resulting on-chain activity.

• Confirm that the token contract is the approved USDC or USDT contract for that network.
• Record token balances using the correct decimal precision.
• Reconcile native gas assets separately from stablecoins.
• Identify unknown deposits, failed transactions and duplicate ledger entries.
• Confirm that all active wallet addresses appear in the treasury register.

Stablerail business accounts can combine stablecoin vaults with fiat rails and multi-currency balances. The close should still preserve the underlying detail rather than netting fiat, USDC and USDT into one figure. Teams operating mainly in USDC can review the structure of a USDC business account; USDT-focused teams can use the equivalent USDT business account overview.

2. Reconcile transfers in transit

Match every treasury movement to both sides of the transaction. An internal transfer from one company wallet to another should not create income or expense, but it may remain unmatched if it crossed the reporting cut-off.

• Blockchain transfers: record the transaction hash, source, destination, amount, network and status.
• Fiat-to-stablecoin conversions: match the fiat debit, stablecoin receipt, quoted rate and service fee.
• Stablecoin-to-fiat conversions: match the token disposal, fiat credit and associated fees.
• Bank payments: distinguish initiated, pending, rejected, returned and settled items.
• Cross-chain movements: reconcile the asset leaving one network with the asset arriving on another.

Do not clear an item merely because it settled after month-end. Determine whether it was cash in transit, a payable, a receivable or an unexecuted instruction at the reporting cut-off.

3. Calculate unrealised FX consistently

USDC and USDT are generally designed to track the US dollar, but a company whose functional currency is EUR, GBP or another currency will still have foreign exchange exposure. Even a USD-functional entity may need a valuation policy for deviations between a token’s observable price and its reference value.

For each balance, retain the quantity, closing rate, rate timestamp, source and resulting functional-currency value. Apply the approved policy consistently across wallets and networks.

Closing value = token quantity × token-to-USD rate × USD-to-functional-currency rate.

The unrealised FX entry is normally the difference between the closing carrying value and the value before remeasurement, adjusted for additions and disposals. The exact journal treatment depends on the asset classification and applicable accounting framework.

• Use an approved, reproducible rate source.
• Use the same cut-off time as the balance snapshot where practicable.
• Document whether the policy assumes one token equals one dollar or uses an observable market rate.
• Escalate material depegs rather than applying an automatic one-dollar assumption.
• Keep realised gains or losses on conversions separate from unrealised remeasurement.

4. Record fees and month-end accruals

Stablecoin activity can generate several fee types. Record them separately so finance can explain the cost of each payment corridor and avoid understating expenses by netting fees into transfer amounts.

• Blockchain gas paid in native assets.
• On-ramp and off-ramp service fees.
• Bank transfer, correspondent bank and receiving bank charges.
• Foreign exchange spreads or separately stated conversion fees.
• Card fees and posted card transactions.
• Payout, payroll or payment-link charges.
• Exchange, custody or yield-provider fees.

Accrue fees when the service has been received but the charge has not yet posted, subject to the company’s accounting policy and materiality threshold. Keep the supporting calculation, expected settlement date and eventual reversal or true-up.

For corporate cards, separate posted transactions from pending authorisations. A pending authorisation may reduce available spending power without yet representing a final ledger entry. Review refunds, reversals and late-presented transactions as part of the cut-off process.

5. Reconcile payouts, collections and yield

For batch vendor, contractor or payroll payments, reconcile the approved batch total to individual recipients and on-chain or bank settlement. Failed and returned payments should remain on an exception report until resolved. The stablecoin payouts workflow is relevant where teams need transaction-level records across multiple supported networks.

For invoices and payment links, match customer receipts to the correct invoice, entity, wallet and network. Unidentified receipts should not be automatically recognised as revenue.

If idle treasury assets earn yield, reconcile opening principal, additions, withdrawals, earned amounts, fees and closing principal. Document whether yield is accrued or recognised only when credited, together with liquidity restrictions, counterparty exposure and any lock-up or withdrawal notice.

6. Build the close evidence pack

The final evidence pack should allow a reviewer to reproduce the balances and journals without relying on screenshots alone.

• Account and wallet register, including legal entity ownership.
• Fiat statements and stablecoin balance exports.
• Blockchain addresses, transaction hashes and cut-off references.
• Ledger-to-source reconciliations with explained differences.
• Unrealised FX calculations and approved rate sources.
• Fee invoices, accrual schedules and true-up entries.
• Lists of pending, failed, returned and in-transit transactions.
• Journal entries with preparer and reviewer approval.
• Audit logs for payment approvals, allowlist changes and quorum signing.
• Evidence that material exceptions were resolved or formally carried forward.

Final review questions

• Does every ledger balance agree to a bank, platform or blockchain source?
• Are USDC and USDT separated by network and legal entity?
• Have internal transfers been eliminated without hiding in-transit items?
• Are realised and unrealised FX recorded separately?
• Have gas, banking, conversion, card and service fees been captured?
• Are pending card authorisations and failed payouts treated correctly?
• Can a reviewer reproduce every material journal from the evidence pack?

A reliable crypto accounting close does not require treating stablecoins as a special exception to normal finance discipline. It requires better source data: exact timestamps, wallet-level balances, transaction hashes, explicit fee records and a documented valuation policy. When those records are collected continuously, month end becomes a controlled reconciliation rather than a search across wallets, bank portals and spreadsheets.