Stablecoin Statements / usdt statement
PlannedUSDT records with their network identity intact.
USDT can appear in wallet software under a familiar name while representing different token deployments on different networks. A dependable statement identifies the actual contract, defines a reporting period and explains how quantities were checked. This guide describes the intended USDT statement model. It is a planning and evidence guide, rather than a live report generator or a promise that every USDT representation is supported.
Verify the deployment on each intended network
For Ethereum, the intended public USDT reference is 0xdAC17F958D2ee523a2206206994597C13D831ec7, with six decimals: {{TODO: verify}}. Confirm that deployment through Tether’s current supported-protocol information and deployment-specific evidence before a production configuration is approved. A static website reference is not a substitute for that release check.
For BNB Smart Chain, the asset representation, contract and decimals remain {{TODO: verify contract, custodian or bridge and decimals}}. Do not infer issuer-native USD₮ support from another token listed for the same chain. In particular, a protocol list may contain different Tether products; the asset name and contract must be read together. A supported network name alone does not settle the identity of the USDT being reported.
Separate a native issuer token from a representation
A bridged or custodian-backed token can use a USDT-like name while depending on a different issuance or custody arrangement. It should have its own asset record and documentation. Including it requires a deliberate scope decision, not a case-insensitive match on the display symbol. An unverified representation is not automatically malicious, but neither is it automatically interchangeable with a native issuer token.
Keep chain-specific quantities separate when preparing a client file. A transfer into a bridge and a later receipt elsewhere may be related, but an amount match alone does not establish that relationship. Preserve both transactions and the evidence used to connect them. If the workflow cannot support a particular representation, show it as outside scope instead of quietly adding it to a combined USDT balance.
Define movements and transaction evidence precisely
For supported token activity, retain the exact atomic amount, decimals, contract, network, event position and transaction reference. Several events can occur in one transaction; a transaction hash alone may not uniquely identify a statement row. Counterparty addresses and timestamps help trace a record but do not establish the legal identity of the payer or the business purpose of the payment.
A practical export should let the accountant attach an invoice, repayment schedule or treasury instruction without overwriting the original observation. Distinguish incoming and outgoing movements for the selected wallet, and define how self-transfers or multiple relevant events are handled. Do not count a failed transaction as a completed token transfer merely because the wallet attempted to send a payment.
Test the quantity against historical state
A period-based USDT statement needs an opening balance before the first included block, a bounded set of relevant movements, and a closing balance read at the selected end block. The opening-plus-incoming-minus-outgoing calculation and the observed closing state must use the same token and wallet. Store the boundary rule and timezone alongside the block numbers.
If the two values differ, keep the residual visible. An incomplete event interval, an incorrect boundary or unsupported contract behaviour needs investigation, not an invented adjustment. If state cannot be retrieved, use an unknown result. If no movements are found but the opening state is nonzero, the statement may correctly show an unchanged holding. No activity does not mean no asset.
Record fees in the asset actually spent
USDT transfers on Ethereum may involve ETH network fees; on the planned BNB Smart Chain scope, native gas would be BNB. Those are separate assets, with separate quantities and valuation inputs. A stablecoin transfer of 350 USDT does not become 349.99 USDT because a network fee was paid in another token.
Only fees attributable to the relevant wallet belong in its native-asset fee schedule. Some token outflows can be initiated by another address under an allowance or service arrangement. Capture the fee payer and transaction evidence rather than assuming every outgoing row consumes the client’s gas. Failed wallet-initiated transactions can still cost gas even when they produce no completed token movement, so fee completeness has its own scope.
Document restrictions and suspicious same-name assets
The issuer and particular contract may have administrative controls that affect transfers. Verify the deployment’s behaviour and any address-specific observation before annotating a report. A restriction flag is a separate statement fact, not a general explanation for an arithmetic residual and not a conclusion about ownership or recoverability.
Unknown contracts that reuse “USDT” belong in an exclusion or unverified section. Preserve the network, contract and reason, and avoid interacting with unsolicited tokens just to investigate them. The sample uses a clearly fictional counterfeit to demonstrate separation. In real data, lack of approval establishes only that the asset is not included in the approved ledger; a fraud conclusion requires additional evidence and an appropriate review process.
Hand over quantities and CHF evidence without conflating them
A US-dollar reference is not a CHF valuation record. Keep the observation time, price source, quote currency and applicable conversion rule with every valued movement. Missing quotations remain null, not zero. A partial set of CHF values must not be labelled a complete transaction total. Year-end valuations can also follow a different policy from payment-time observations.
The planned export set consists of PDF for reading, CSV for row-level comparison and JSON for structured evidence. The USDC website sample demonstrates the format; it is not presented as an actual USDT result. Before using USDT records in a real client file, confirm the asset configuration, historical coverage and accounting policy. camt.053 and accounting-software mappings remain further investigations, with no automatic-import compatibility claimed.
Questions
Is the interactive sample a real USDT statement?
No. It is an explicitly synthetic Ethereum USDC example of the proposed document structure. No USDT wallet has been queried.
Can six decimals be assumed on every chain?
No. Verify decimals for the exact contract and representation on each chain. Never copy an Ethereum setting to an unverified deployment.
Primary references
Continue with Stablecoin Statements, the shareable example and the accounting workflow.
Join the private-beta waitlist
Tell us what you want to build. Your requirements will help shape the private beta.
Submission is not enabled. The contact page provides the email alternative.