Connect an invoice to its reported USDC transfer — not a guess.
Stablecoin payroll and vendor payments leave two separate stories: a business invoice and an ERC-20 event. Match the CSV records you already have and identify exceptions without uploading either file. Built for review before month-end, not to certify that a transfer ever occurred.
Compare invoice records to a *self-reported* receipt export
Click Load invented example for a 4-invoice / 4-event demonstration with exact, partial, ambiguous reused-address and pending cases. You can replace the example with two CSVs you have authority to examine. No actual customer records are needed.
Free fictional 50-payment pilot rehearsal: download 50 invented invoice rows (CSV) and 50 invented reported ERC-20 transfer rows (CSV). Load both using the local file selectors below, then click Compare locally. Expected operator-reported results: 35 exact, 4 partial, 2 overpayments, 3 pending-only, 2 recipient mismatches and 4 with no allocated receipt; duplicate event rows 2 and unreferenced event rows 2 require manual review. These are ALL made-up addresses, hashes, invoices and amounts. No real money moved and no onchain receipt, customer, or accounting outcome is verified. A real paid 50-row pilot would require separate written customer authorization and scope.
invoice_id,recipient,amount_usdc,chain,token. One unique invoice ID per row. Chain eip155:8453, token contract must be canonical Base USDC.
invoice_id,tx_hash,log_index,recipient,amount_usdc,chain,token,status. Invoice ID may be empty. Status must explicitly say reported_finalized or pending.
Reported candidate matches — not confirmed onchain payments
| Invoice ID | Review state | Expected USDC | Reported USDC | Reported difference |
|---|
Events requiring manual review
An exact result means only that the two provided files align syntactically. It is NOT a settled onchain payment or cleared invoice. Manual review is necessary when a transfer is unreferenced or one payee address is shared across invoices.
Why we refuse to auto-match by address alone
Two vendor invoices can intentionally share one wallet, and a transaction hash can contain more than one ERC-20 transfer. We use chain_id:tx_hash:log_index as an event identity. Duplicate event rows are NOT counted twice. Without an explicit invoice ID in the source export, we emit candidates for human review rather than claiming to know which invoice was settled.
This tool does not call an RPC, query balance, validate contract events, identify a wallet owner, value FX at a historical rate, process bookkeeping, handle taxes, prevent real withdrawals, or reconcile merchant accounting. Those require independent verification and appropriately qualified operators. It is a local data-quality aid only. A malicious or inaccurate input CSV can produce a correspondingly misleading candidate report.
Want to check one actual public Base Circle USDC Transfer event against a transaction receipt instead of trusting an exported CSV status? Use the separate free, read-only RPC receipt checker. It only contacts public Base RPC after your explicit click and makes no invoice ownership or financial certification claims. This CSV tool itself remains offline with no network calls.
Four reproducible failure cases: our original technical walk-through on DEV Community explains partial payments, shared-address ambiguity, duplicate event identities and pending receipts. It uses the invented sample above and explicitly distinguishes a CSV match from actual onchain finality. The independent DEV link is educational; no customer testimonial or paid order is implied.
For exchange-to-wallet transfer pairing instead of vendor invoice matching, try the same human owner's separate free VM3 candidate transfer-pair checker; it also does not assert final settlement.
Need this adapted to your actual workflow?
We can discuss a conditional 49 USDC fixed-price first technical milestone: one anonymized/synthetic invoice CSV + one synthetic receipt CSV schema, a local-only format adapter, deterministic exception report and a short documented review checklist for up to 50 example invoice rows and one revision. This is an indicative proposal, NOT an active x402 automatic checkout, a paid order, legal advice or a promise to handle private live vendor data.
Before any work or funds, the one Korea-based human-owned studio and the buyer must agree in writing on exact input schema, acceptance tests, permitted AI tooling, licensed data, ownership of code, lawful Base-USDC payee, settlement terms, refund/cancellation and what neither party is certifying. No funds are required to use this free page.
Discuss one paid pilot scope by email ↗
Request a synthetic-data pilot scope / leave free feedback on GitHub ↗
Only have 30 seconds? Our existing voluntary project inquiry form can collect a nonconfidential feature request or synthetic column-header example. This is a Google-hosted form, separate from this offline checker; check the form’s privacy/sign-in information before submitting. Never include real invoice records, vendor identities, wallet keys, private addresses or other sensitive customer data. Sending feedback does not order or purchase anything.
Alternative: 29 USDC conditional standalone payout-list CSV adapter (a different simpler schema-conversion service), or free payout-list preflight. No past clients, sales or retention from these offers are implied.