Closing the books on stablecoin payout bots: the CSV your accountant will accept
GetAgentCap team · published 9/20/2026
Most writing about agent spend is about runaway loops and 3am bills. This one is about a duller problem that costs more hours: it is the end of the month, your payout bots have sent a few hundred USDC transfers across Base and Solana, and someone has to turn that into rows a bookkeeper will accept. If you have done this by hand, you already know where it goes wrong. Here is the shape of it, and what to fix first.
Why the block explorer is not the answer
An explorer gives you a chronological list of transfers from one address on one chain. Closing books needs something else: every payout across every wallet and both chains, in one table, with each row attributed to the bot that sent it and the counterparty that received it, denominated consistently, in a range that matches your accounting period.
Getting there manually means exporting per address, per chain, stitching two different transaction formats together, and hand-mapping addresses to names in a spreadsheet you recreate every month. It works at three wallets. At ten it is a day of someone's life, every month, and the error mode is silent — a missed wallet just makes the totals a little wrong.
Four things that break reconciliation, in order
Shared wallets. If two payout bots draw from one address, per-bot attribution is gone and no tool can recover it, because the chain records the address, not the intent. One wallet per bot is the single highest-leverage change you can make, and it is free. Do it before you buy anything.
Duplicate payments that look correct. A retry storm does not produce anomalous-looking rows. It produces 340 individually valid transfers to the same recipient. On a monthly total they hide inside a number that is merely high. Sorting by recipient concentration finds them; scanning the ledger does not.
Chain asymmetry. A Base USDC transfer and a Solana USDC transfer are the same economic event and completely different data structures. Anything that keeps them in separate reports pushes the merge onto you, monthly, forever.
Period boundaries. Chain timestamps are UTC and your accounting period probably is not. A transfer at 23:50 on the last day of the month lands in different months depending on who is looking. Pick one convention, write it down, and keep it — the specific choice matters far less than never changing it.
What AgentCap gives you
You paste a public address per wallet — no keys, no wallet connect, nothing that can be drained, and importantly nothing that needs the bot's author to cooperate. We read USDC transfers out of those wallets on Base and Solana, attribute each one to the agent you named, keep them in one view rather than two, and export CSV: timestamp, chain, sending agent, recipient address, amount, and transaction hash. The hash is the part your reviewer will care about, because every row can be independently checked against the chain by anyone who doubts it. That is a stronger audit position than most fiat payout reporting ever offers.
We also hold a rolling budget ceiling per wallet with a webhook when one crosses. That is not a books feature, but it is the reason a month closes cleanly instead of with a surprise in it.
What we do not do
We do not touch your money, we cannot stop a payment, and we do not do your accounting — no tax treatment, no fiat conversion at historical rates, no journal entries. We produce the attributed transaction record those things need as input. If your process currently starts with a person opening two explorers and a spreadsheet, this replaces that step and nothing after it.
Start here
Split your bots onto one wallet each. Then paste the addresses at getagentcap.com and pull a CSV for last month — it takes about a minute, it is free up to ten wallets, and comparing it against the spreadsheet you built by hand is the fastest way to find out how much that spreadsheet was missing.