Reconcile a USDC wallet statement before importing its CSV.

Keep a dated transfer record, check its coverage and balance arithmetic, then add the business context yourself. A wallet export is evidence of token movements; it does not identify an invoice, prove wallet ownership or decide how a transaction should be treated.

We may earn a commission from Apify referrals.

This workflow covers native USDC on Base only. It is informational record preparation, not accounting, financial, legal or tax advice. Provider gaps, errors and partial results remain unknown activity.

1. Fix the asset and the UTC window

Match both chain and contract. Circle lists native Base USDC at 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913; a matching ticker alone is insufficient. See Circle’s current contract list. This contract is a public identifier, not a wallet example or payment destination.

Use your own public wallet address and a past UTC range. SpendPreflight Statement uses start inclusive, end exclusive, with a maximum 90-day range. For example, November 1 means 2026-11-01T00:00:00Z through 2026-11-02T00:00:00Z. Adjacent non-overlapping windows share the end/start boundary. Do not mix local dates with UTC silently.

Keep a manifest beside the original export: chain eip155:8453, asset contract, wallet, requested start/end, observation time, opening/closing block identifiers, input and output format. The current OpenAPI schema is the request reference. Opening a guide or requesting a payment challenge does not produce a completed statement.

2. Read the evidence before importing rows

Retain the full JSON as well as any CSV. Check complete and reconciled are both true, coverage.missing is empty, and the opening and closing balances were observed. Preserve observed_at, coverage, completeness and disclaimer. A successful HTTP request, exit code or downloadable file alone is insufficient.

If either flag is false, coverage is missing, or the lookup errors, stop the import and label the range UNVERIFIED / PARTIAL. Do not replace unavailable transfers or balances with zero. Keep the original attempt and its outcome; a timeout or unknown payment outcome is a reason to inspect the same attempt before considering another paid request.

Even a complete, reconciled result means the configured RPCs returned logs that matched the observed balance change. It is not an independent cryptographic proof that every event was supplied. Provider availability and limits can prevent a requested range from completing.

3. Reconcile exact amounts and event identities

The ERC-20 standard defines token amounts and Transfer events. Keep atomic integer amounts alongside displayed decimals. This product uses six decimal places for native USDC; avoid rounding a row before reconciliation.

Identify a transfer by chain, asset contract, transaction hash and log_index. One transaction can contain multiple transfer events. If you combine exports, an overlapping event should appear once in the working ledger; retain both original files. A self-transfer remains visible but changes the wallet’s USDC balance by zero.

The check is opening balance + incoming − outgoing = closing balance, treating self-transfers as zero net change. Here is a hypothetical example, with invented labels rather than live wallets or transaction hashes:

In atomic units: 100000000 + 25125000 − 4005000 = 121120000. A matching closing balance is one check; it does not identify the business purpose of those transfers. Track fees, other assets and off-chain adjustments separately instead of forcing them into this USDC-transfer table.

4. Import a working copy and add context

Import address, transaction-hash and atomic-amount columns as text where your spreadsheet permits. Keep original decimal strings, UTC timestamps, direction, counterparty and log index. Preview the delimiter and quoted fields before accepting the import. Keep the original file unchanged and perform sorting, deduplication and annotation in a working copy.

Add your own internal reference and reviewed purpose in separate columns. A transfer from an address does not prove that a named customer paid an invoice, and a transfer to another wallet you control is not automatically revenue or an expense. The export does not supply those determinations.

If using the existing Apify Actor, distinguish its dataset row from the statement’s embedded transfer CSV. Apify supports JSON and CSV dataset exports; exporting a dataset as CSV may put a nested CSV string inside a cell. Inspect the result and decode that field into a separate file when needed. Preserve the full JSON and run identifier. Check the Store’s current availability and price before choosing a run; platform access does not guarantee a completed historical lookup.

5. Keep screening and record retention separate

You can inspect up to ten public identifiers with the free OFAC address check. Its dated exact-address SDN match is a separate observation. A non-match is not clearance, ownership proof, transaction-exposure analysis or certification; retain the source timestamp and scope if you use it.

Store exports under access controls appropriate to your records. Public chain identifiers can become sensitive when linked to names or invoices. Do not publish private transaction context, credentials or wallet secrets. SpendPreflight processes Books output transiently; your download, spreadsheet and an Apify dataset are separate copies under their own retention controls. See privacy by product.

Prepare a statement for a range you can review

Check the current scope and limits, choose your own past range, and authorize any paid execution explicitly. The HTTP Statement route currently costs 0.05 USDC for a completed statement; plain requests do not sign or pay automatically. This guide does not run a lookup, open a wallet or start an Actor.

Review Wallet Statement inputs, price and limits →

Written by SpendPreflight. Product behavior reviewed against the deployed Statement implementation and saved complete/partial evidence on November 2, 2026. The worked amounts above are illustrative. Successful observations do not guarantee future provider availability.