Stablecoin treasury operations sit between accounting and crypto-native operations, and the daily reconciliation workflow is where most teams discover their tooling gap. Card-network treasury closes the day from a batch settlement file. Stablecoin treasury closes the day from a wallet balance, a gas log, a slippage report, an FX capture, and a multi-sig approval trail. This piece walks the end-of-day SOP a treasury team actually runs in 2026, what Modern Treasury and Fireblocks do for it, and where the manual work still lives.
​

Five reconciliation lines: wallet balance versus ledger balance per chain, gas spent versus budget, swap or bridge slippage versus expected, FX rate captured at execution versus market reference, and multi-sig signer logs versus approved transactions. Plus pending versus confirmed bridge transfers. The SOP closes the day when all five lines tie and the deltas are documented. Most teams run it on a 24-hour cadence; high-volume treasuries run it intraday.
​

The treasury ledger tracks every expected inbound and outbound: customer payments received, vendor payouts sent, internal transfers between wallets, fee captures. End of day, the wallet balance on each chain should equal the opening balance plus the net of those movements. Mismatches signal one of: a transaction that did not confirm, a transaction the ledger missed (stale webhook, dropped indexer event), or an unauthorized movement.
​

The tooling: a blockchain indexer (Fireblocks, Modern Treasury, or self-hosted via Etherscan API and Solana RPC) pulls the actual movements. The treasury system holds the expected movements. A reconciliation job diffs them. Modern Treasury's product is built around exactly this pattern, treating stablecoin movements as a native payment_type alongside ACH and Wire so the same reconciliation engine handles both. Fireblocks' policy engine adds the approval-log dimension on top.
​

Gas is overhead, not COGS, and most teams underestimate the budget the first quarter they operate on Ethereum or other L1s. The daily gas log captures: total gas spent per chain, average gas price, transactions executed, and the average cost per transaction. Anomalies (a single transaction costing 10x normal) trigger a review.
​

On Base, Polygon, Solana, gas is cents to fractions of cents and rarely material. On Ethereum mainnet, a busy treasury can spend hundreds of dollars per day on gas alone. Many teams batch transactions or migrate volume to L2s specifically to compress the gas line.
​

If the treasury swapped USDC for USDT (or any other pair) during the day, slippage is the difference between the expected execution rate (mid-market at quote time) and the actual execution rate. Liquid pairs on Uniswap or 1inch see slippage in the single basis points. Illiquid pairs see hundreds of basis points. The daily log captures the absolute dollar slippage and flags any execution outside policy bounds.
​

Bridges add a second slippage dimension: the difference between source chain amount sent and destination chain amount received. Native bridges (Circle CCTP, official wrapped asset bridges) have near-zero slippage. Liquidity-pool bridges (anything routing through Hop, Across, Stargate) have measurable slippage. The treasury log captures the bridge used, the source amount, and the destination amount.
​

Any conversion between USDC and a non-USD-denominated asset (USDC to EUR, USDC to MXN, USDC to a payout in local currency) needs an FX rate capture at execution. The captured rate becomes the accounting basis for the transaction. Modern Treasury and Bridge handle this in the API response (the payout call returns the FX rate used). Self-built integrations need to capture and store the rate explicitly.
​

For US accounting (US GAAP), the FX rate must be tied to a publicly available reference (typically the rate at the moment of transaction execution from a reputable source). The daily reconciliation confirms that every cross-currency movement has a captured rate stored against it.
​

Every outbound transaction from the treasury wallet should have a corresponding signer log: who approved the transaction, what policy rule applied, and what the transaction amount and destination were. Fireblocks' policy engine generates this log natively. Safe wallets generate a similar log through the Safe transaction service.
​

The reconciliation step: every onchain outbound has a matching signer log, every signer log has a matching onchain transaction. Mismatches (a signed transaction that never broadcast, a broadcast that no signer log accounts for) are red-flag events.
​

Bridge transfers can take seconds (CCTP) or hours (some optimistic bridges). At end of day, some funds may be in flight: sent from the source chain, not yet credited on the destination. The reconciliation accounts for these as a separate ledger line, in-flight balance, and confirms each one resolves on the next day's open.
​

Same applies to pending vendor payouts that have been signed but not yet broadcast (the signer log shows the approval, the chain has not seen the transaction). Treasury treats these as authorized-but-unsettled until the chain confirms.
​

Modern Treasury treats stablecoin movements as a native payment_type and exposes the same Ledger and Reconciliation primitives it uses for ACH and Wire. The team writes the same Ledger entries; Modern Treasury reconciles against the chain rather than against a bank statement. The product supports USDC on Base, Ethereum, and Solana per its public changelog.
​

Fireblocks Treasury Management focuses on the custody and policy layer. The Policy Engine defines who can move what, under what conditions, with what approval flow. The Treasury Management product layers reporting on top: balance reports, transaction reports, signer logs. Reconciliation against an external ledger is typically a connector or a manual export.
​

Most production treasuries in 2026 use both: Fireblocks (or Anchorage, or self-hosted Safe) for custody and policy, Modern Treasury for the ledger and reconciliation engine. Direct integrations between custody platforms and treasury ledgers continue to mature; most teams bridge them with internal ETL.
​

Three places. First, mapping vendor payout descriptions to ledger lines when the gateway does not return a clean memo. Second, investigating gas spikes when a transaction costs unexpectedly more (usually a network congestion event). Third, the multi-sig approval choreography when a signer is on vacation and a transaction needs an alternate approver. None of these scale linearly with volume; they scale with policy complexity.
​

If reconciliation is a spreadsheet today, the highest-leverage move is wiring the wallet-balance-vs-ledger reconciliation into the same engine that handles ACH reconciliation. Modern Treasury, Sage Intacct connectors, and self-built Postgres ledgers all support the pattern. The savings: 30 minutes a day, and a defensible audit trail.
​