Reconciling USDC Spend for AI Agent Wallets

A new operational guide describes how teams should record and reconcile USDC spent by AI agents. The document frames agent wallets as prepaid budgets and sets out steps for logging payment requests, linking transfers to internal accounts, and handling settlement states.

The guide warns that relying on an on-chain batch transaction hash alone can obscure multiple microspends. Circle’s nanopayments return a per-transfer identifier and a batch txHash for a group of transfers. The guidance says the correct primary key for accounting is the per-transfer id combined with the stored x402 payload rather than the batch hash.

Teams are instructed to persist the x402 payment requirement before the wallet signs a request. Persistent data should include the service URL, amount, network, scheme and the policy decision that allowed or blocked the request. The x402 exchange and its headers are described as the source document; logging only after a PAYMENT-RESPONSE arrives will omit failed or blocked attempts.

When a PAYMENT-RESPONSE arrives, the response should be joined to the pre-signed record. Each completed spend should be attributed to an agent id, a KYA (know-your-agent) principal and the cost center that funded the call. The guidance notes that a single prepaid wallet can fund multiple agents but each agent’s consumption requires its own ledger line.

Settlement states require specific handling. A settlement_pending status indicates a facilitator has broadcast a settlement but not confirmed receipt; the guide classifies that status as an open reconciling item rather than a definitive failure. It advises against retrying the same payment before confirmation to avoid duplicate charges. On-chain USDC transfers that reach finality cannot be reversed; refunds must be issued as new outbound payments and require human approval. Agents are advised not to issue refunds autonomously.

The guide outlines a daily close process that reconciles three figures: the wallet USDC balance, any gateway or nanopayment float, and the internal general ledger total for the agent. If those three balances do not match, the guidance directs teams to freeze the session and revoke signing authority until the discrepancy is resolved. A wallet described as “almost reconciled” is treated as still active and not closed.

The document lists conditions under which teams should avoid funding an agent wallet. Funding is not recommended when an allowlist and cost-center mapping cannot be enforced, because unattributable spend can become a write-off. The guidance also advises against using an agent wallet for tasks equivalent to a single human invoice or when relying on a chain explorer as the sole ERP, citing gasless batching and pending settlements as causes of opaque fund flows.

The guidance groups reconciliation into three ledgers: wallet/chain balances and batch hashes; facilitator nanopayment records with per-transfer statuses; and the internal general ledger with cost centers and KYA principals. It recommends keying entries on the per-transfer id plus the stored 402 payload, logging both approvals and refusals, treating settlement_pending as an open item, and requiring human approval for refunds.