Inspect the sample before you rely on the format.

Start with the header and period

The sample concerns one abbreviated synthetic wallet, Ethereum and USDC, during January 2026 in Europe/Zurich. Its UTC interval begins at 23:00 on 31 December and ends just before 23:00 on 31 January. The different calendar dates illustrate why an explicit timezone and boundary convention belong beside every reporting period.

The opening block and included block range are invented markers, not claimed historical mappings. In a real report those boundaries would need supporting block observations. The statement identifier includes the selected scenario, so switching between agreement and a difference cannot quietly leave an apparently identical file label. No usable client address or real transaction hash is hidden in the example.

Follow the ten movements in token units

Begin with 1,000.000000 USDC. Five incoming movements total 7,700.000000 USDC, and five outgoing movements total 2,300.000000 USDC. The calculated closing quantity is therefore 6,400.000000 USDC. Each row retains a sample reference and running balance so a reviewer can follow the arithmetic without treating an aggregate as unexplained evidence.

The structured model stores exact atomic amounts as integer strings with six decimals. Decimal formatting is for reading; it does not replace those quantities with floating-point approximations. The evidence links in the table open an explanation of the sample references. They deliberately do not point to a fabricated transaction on a real explorer. Actual payment evidence would need its own verifiable network reference.

Check the gas schedule separately

The second movement has an associated wallet-paid gas fee of 0.001050000000000000 ETH. Its synthetic CHF value is 2.63 using an invented CHF 2,500 per ETH quotation and an explicit rounding rule. The fee does not reduce the USDC ledger. Other outgoing sample movements are described as third-party initiated, so they do not invent additional wallet-paid fees.

This separation is important for a real review. Transfer direction and transaction initiation are different facts. A token can leave a wallet through a transaction sent by another party. Conversely, a failed wallet-initiated transaction can spend native gas without completing a token payment. A production fee schedule would require complete receipt evidence for its own stated transaction scope.

Inspect the excluded counterfeit and missing price

The “Not included” section shows a fictional contract labelled USDC with 999,000 units. It is an intentionally counterfeit example and is not added to the approved USDC quantity, incoming total or closing balance. Its identifier is abbreviated and synthetic. A real unknown contract would be labelled unverified until reviewed; unknown does not automatically mean fraudulent.

One movement also lacks a CHF quotation. Its price, value, source and quotation time remain null in JSON and blank in CSV. The readable statement marks it unknown. That gap does not change the token quantity, but it prevents an honest claim that the complete fiat value is known. All other sample quotations are invented too; none should be reused as a historical market price.

Switch from agreement to the difference case

The default comparison observes a synthetic closing balance of 6,400 USDC, agreeing with the calculated quantity. Switch to the difference case and the observed value becomes 6,350 USDC. The residual is observed minus calculated, therefore negative 50 USDC. The example flags missing blocks 24000016–24000017 as an interval to investigate.

The rows are not rewritten to manufacture agreement. A possible missing outflow is an investigation hypothesis, not a newly asserted payment. The status, explanation, coverage, identifier, hash and download targets change together. A freeze observation has not been checked in this example. Even if one were present, it would not independently explain why recorded movements and state differ.

Compare all three export views

Statement is the readable summary; CSV exposes one row per movement and repeats the selected comparison context; JSON retains the fuller model, including coverage, exact amounts, price metadata, fees and exclusions. Without JavaScript all three views remain available in sequence. With JavaScript, keyboard-accessible tabs organise the same content without sending a network request.

Each download corresponds to the currently selected scenario. PDF is a static two-page sample with a visible synthetic-data watermark, not a generated customer report. The JSON content fingerprint is computed from the canonical sample model with the hash field itself excluded. PDF and CSV carry that same fingerprint so a reviewer can check which underlying scenario they describe, rather than mistake a filename for a content guarantee.

Use the preview as a discovery instrument

A useful first review does not ask whether the page looks convincing. Ask whether a fiduciary can identify the asset, explain the period, trace a payment, separate a fee and decide what further evidence a discrepancy requires. Note which field labels they would change and whether the file is readable in their ordinary review process.

The intended next step is a personal demonstration to five fiduciaries before implementing the real service. Ask for the exact software version and import profile they would need, not a general wish for accounting compatibility. Keep the example synthetic during that conversation. Feedback should guide contract verification, valuation policy, evidence retention and future integration work; the polished preview does not itself validate those product assumptions.

Questions

Primary references

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

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