A USDC statement starts with the contract.

Use an issuer reference, not a symbol search

The planned Ethereum asset reference is 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48, with six decimals: {{TODO: verify}}. This is a public contract reference, not a customer address. Verify the chain, deployment and decimals against Circle’s current contract registry before configuring a real service. A copied address without its network context is not enough.

The BNB Smart Chain target needs a separate representation decision: {{TODO: verify contract, custodian or bridge, decimals and redemption context}}. Do not describe a Binance-Peg or other bridged asset as Circle-native simply because its symbol is USDC. The statement must name the representation it actually measures, and an approval list must be versioned when the supported asset scope changes.

Understand the bridge boundary

Moving value through a bridge can create a different token contract on the destination chain. That representation may depend on custody, collateral or a bridge mechanism separate from the native issuer deployment. A genuine bridge asset is not automatically a counterfeit; it is a distinct identity with different evidence and operational assumptions.

For reporting, keep source-chain and destination-chain movements separate until a matching workflow has sufficient evidence to connect them. Two transfers of the same nominal amount are not, by themselves, proof of one internal move. If your statement includes only Ethereum USDC, a destination-chain balance remains outside its scope. A future multi-chain view should preserve those boundaries rather than flatten all USDC labels into a single undifferentiated balance.

Record payments as exact token movements

ERC-20 quantities are integers in the token’s smallest units. For a six-decimal asset, 1,250,000 atomic units represent 1.250000 USDC. Keep the integer string and decimals in structured records; format decimal amounts for readers without routing large quantities through floating-point arithmetic. Rounding a report display must not alter the underlying ledger.

Retain transaction and event identifiers, network, contract, timestamp and counterparties for each movement. An invoice reference is separate business evidence. A transfer may settle an invoice, refund a customer, move funds between controlled wallets or interact with a service. The token event alone does not establish which interpretation is correct. The receiving accountant should be able to inspect both the observation and the client’s explanation.

Reconcile one asset over one defined period

Read an opening state immediately before the period and a closing state at the selected cutoff. Add the incoming USDC movements and subtract outgoing USDC movements within the same bounds. Compare that result with the closing observation. The website sample starts with 1,000 USDC, receives 7,700 and sends 2,300, producing a calculated closing quantity of 6,400.

Switching the sample to the difference case changes the observed closing state to 6,350 and leaves a residual of negative 50 USDC. It also flags a missing interval. No payment is invented to fill the gap. A zero residual with incomplete coverage would still require an incomplete result, because coincidental agreement is not evidence that every required record was checked.

Keep ETH fees out of the USDC arithmetic

On Ethereum, a wallet-initiated transaction may consume ETH for gas even when the transferred asset is USDC. Record the fee in ETH, using the receipt and fee-payer context, and attach a separate price observation if a CHF valuation is needed. Subtracting that ETH amount from USDC creates a ledger that no longer describes either asset correctly.

A transfer out of the wallet is not always initiated by the wallet itself. A third-party transaction can execute an approved token transfer, and a service may sponsor fees. The sample deliberately distinguishes one wallet-paid fee from other third-party-initiated outflows. A real implementation must derive that distinction from supported transaction evidence rather than charging a gas fee to every outgoing token event.

Keep issuer controls and unknown tokens in context

Issuer-controlled token deployments can include administrative restrictions such as address blocking. The relevant contract, version and current state must be checked before making claims about a particular address. A statement can preserve a verified restriction observation separately from the arithmetic record. The website example has not checked freeze status and says so explicitly.

A freeze may affect whether an asset can move; it is not, by itself, a valid explanation for a mismatch between recorded movements and state. Check omitted events, wrong bounds and unsupported token behaviour first. Same-name unknown tokens belong in an unverified list, not in the approved USDC total. Their exclusion does not establish that every unknown contract is fraudulent.

Prepare valuations and a practical handover

CHF values need timestamped price evidence, a source, quote currency and a rounding policy. A dollar reference does not provide the CHF amount automatically. In the sample, rates are invented and one price remains null. This demonstrates how an unresolved valuation should remain visible without changing the exact USDC quantity or inventing a complete fiat total.

The proposed PDF, CSV and JSON identify the same statement content and scenario. Use the PDF for review, the CSV for controlled row-level analysis and the JSON for retained technical context. Before booking, link the appropriate commercial documents and apply the agreed accounting policy. Real USDC reporting, historical queries and price integration remain planned; the current preview is an offline explanation of the intended workflow.

Questions

Primary references

• Circle: USDC contract registry
• SIX: Swiss Payment Standards cash-management guidelines

Continue with Stablecoin Statements, the shareable example and the accounting workflow.