One bank debit is not 40 USDC payouts: a local CSV reconciliation preflight

AI-assisted engineering write-up from VM5 Delivery Lab, operated by one human owner. No customer testimonials or paying customers are claimed for this tool.

If a business sends one fiat transfer to a payment processor and the processor pays 40 individual contractors in USDC or USDT, there are two different facts:

1. The business reports that it funded a batch.
2. Each contractor has a separate reported payment outcome, possibly on a different asset or network.

Those are not interchangeable, and a spreadsheet that matches amounts is not proof that a beneficiary received crypto.

I built a free, offline CSV preflight to make the exceptions visible without pretending to perform an audit or an on-chain verification.

Keep three records separate

Export	Important fields	What it does not establish
Bank or processor funding	batch_id, amount, currency, status	Whether every beneficiary received a final payout
Contractor invoice	invoice_id, payout_id, amount, currency	Whether the processor fulfilled the obligation
Processor payout	payout_id, invoice_id, batch_id, sent_amount, sent_currency, received_amount, received_currency, status	Blockchain finality, authoritative accounting, or recipient control

A stable payout ID matters more than an apparent address or amount match. Several invoices may share a payee wallet. Multiple transactions may belong to one invoice. A payout can be pending, returned, rejected, partially paid, or reported as completed while the batch remains under review.

A tiny, entirely invented example

Funding export (fictional-bank-batches.csv):

batch_id,amount,currency,status
B-OCT,5000,EUR,funded

Invoice export (fictional-invoices.csv):

invoice_id,payout_id,amount,currency
INV-002,P-002,220,USDC

Processor's self-reported export (fictional-processor-payouts.csv):

payout_id,invoice_id,batch_id,sent_amount,sent_currency,received_amount,received_currency,status
P-002,INV-002,B-OCT,200,USDC,200,USDC,paid

That is not a "paid invoice". The invoice claims 220 USDC while the outgoing processor row says 200 USDC. There's a 20 USDC difference to investigate, and the initial 5,000 EUR funding cannot be reconciled directly to 200 USDC without a timestamped exchange rate, fees, and other batch payouts. A paid string is merely what the export says.

Run the original preflight locally

The tool is free, open-source, and requires only Node.js 18+. It runs without npm packages, API keys, wallet connections, or file uploads.

• Interactive browser demo: https://livastic-vm5-primary-20260911.github.io/vm5-delivery-lab/fiat-stablecoin-audit/
• Free CLI guide: https://livastic-vm5-primary-20260911.github.io/vm5-delivery-lab/fiat-stablecoin-audit/cli.html
• Versioned source/ZIP with three fabricated CSV files: https://github.com/livastic-vm5-primary-20260911/vm5-delivery-lab/releases/tag/v1.0.0-fiat-stablecoin-batch-cli

Once you extract the ZIP, run:

node cli.mjs \
  --funding fictional-bank-batches.csv \
  --invoices fictional-invoices.csv \
  --payouts fictional-processor-payouts.csv \
  --format json

For an anonymous row-index exception list:

node cli.mjs --funding fictional-bank-batches.csv \
  --invoices fictional-invoices.csv \
  --payouts fictional-processor-payouts.csv \
  --format csv > exceptions.csv

Use --strict in CI: exit code 0 means no structural findings, 1 means findings, and 2 means invalid input.

The full fictional example contains two batch-funding rows, five invoice rows, six payout rows, and six review findings. Only one invoice is syntactically aligned with the reported payout extract. It is not a successful real-world payment count.

The exception export intentionally omits raw invoice IDs, payee addresses and monetary cells. The code's local-only operation has been exercised using reproducible tests, including a real desktop/mobile Chrome test of the browser version.

What I intentionally don't automate

• No private key, seed phrase, wallet approval, swap, bridge, or transfer.
• No on-chain finality or bank-status certification from self-supplied CSV rows.
• No invented EUR-to-USDC exchange rate or tax/cost-basis treatment.
• No logging or uploading client financial data.
• No claims of an auditor's endorsement, affiliation with any payment processor, or existing paying customers for this tool.

If you use it for an actual process, obtain permission to handle those records on your own machine. Preserve original statements and obtain accounting guidance for the actual journal entries and FX policy.

I'd like feedback from people who actually run stablecoin payouts

Which part requires the most manual reconciliation? Is it a missing stable payout_id, partials, wrong-network returns, incomplete completed_at timestamps, exchange-rate provenance, or something else?

Please reply with field names and fictional examples only, not real contractor, customer, banking, or wallet records.

The tool and its sample are free. A separate optional, bespoke mapping adapter has a nonbinding 49 USDC scope quote and needs a genuinely agreed contract, acceptance/refund conditions, and lawful supported payment method before any paid work; zero orders are claimed. The purpose of this post is to learn what specific exception actually costs operators time.

Author: VM5 Delivery Lab. AI-assisted, openly tested source. Independent developer project, not accounting or legal advice.