Month-end reconciliation sounds easy and feels endless. You set the money that actually moved beside the money that should have moved, find the gaps, and explain each one. On a small team, one person loses an afternoon to it, and it is the same lost afternoon every single month.

We gave that afternoon to an agent that runs on a schedule. Once a month it checks payments against invoices, points out anything that does not add up, and writes up a summary. Here is how we run it on Machine, from the connections to the steps to the limits we set.

The problem

Matching numbers is dull right up to the moment it matters. Nearly every line pairs off cleanly. What you are really hunting for is the small handful that will not: a payment that never arrived, a fee that leaves the totals off by a little, an invoice with no deposit to match it. You only find those by checking all of it, and doing one tedious comparison hundreds of times is slow and easy to get wrong.

A spreadsheet formula spots perfect matches and misses the almost-matches, which is exactly where trouble tends to sit. So you choose between a quick pass that lets things slip and a thorough one that swallows someone's whole day. Either way, it only gets done when someone finds the time.

What we built

A monthly cron wakes a reconciliation agent on Machine. Each run gets its own session: a fresh cloud computer (a sandbox) used for that run alone, with limited access to the three places reconciliation needs, Stripe, the bank feed and the Google Sheet where we keep our records. The agent pairs payments with invoices, flags anything that does not line up, writes a summary into the sheet, and passes whatever it cannot match to a person.

How it works

The pattern

Start the project with a monthly cron. Use scoped connectors so the agent can read Stripe and the bank feed and write to the sheet. Keep your reconciliation rules in skills and memory, and send every item it cannot match to a person.

Guardrails

Letting an agent near your financial systems is, before anything else, a security decision. Here is how Machine keeps it safe:

• Isolation. Every run happens in a private sandbox. The session can read the accounts it needs, and the summary it writes into the sheet is the only thing that leaves.
• Scoped secrets. The keys for Stripe, the bank and Sheets are stored encrypted in the Secrets Manager, passed into the sandbox when the run starts, and only handed to the agents you grant them to.
• Human approval gate. Items that will not match within the allowed slack go to a person instead of being forced to fit, and the agent never moves money.
• Everything is code. The agent's persona, skills and permissions are files in the repo, kept in version control. Changing them takes a reviewed change request, never a dashboard click.

The outcome

The afternoon once spent checking hundreds of lines now goes on sorting out the few the agent could not pair. Reconciliation happens every month, busy or not, and the summary is already in the sheet when your finance person opens it.

Four things hold it together: a private sandbox for each run, the Secrets Manager guarding the Stripe, bank and Sheets keys, a clear route to a person for anything unmatched, and memory that keeps known explanations from one month to the next.