How we reconcile expenses every month
The finance agent we run on Kortix — connected to Stripe, the bank feed, and Google Sheets. Each month it matches transactions against invoices, flags mismatches, and posts a summary, escalating anything it can't match.
Monthly reconciliation is the kind of task that's simple to describe and tedious to do: line up what came in and went out against what was supposed to, find the things that don't match, and explain them. On a small team it lands on one person for an afternoon, and it's the same afternoon every month.
We handle this with a scheduled agent. Once a month it reconciles transactions against invoices, flags what doesn't line up, and posts a summary. This writes up how we run that on Kortix — the connections, the steps, and the guardrails.
The problem
Reconciliation is mechanical until it isn't. Most lines match cleanly, and the value is entirely in the handful that don't: a payment that never landed, a fee that doesn't tie out, an invoice with no matching deposit. Finding those means going through everything, which is slow and easy to get wrong when it's the same repetitive comparison hundreds of times.
A spreadsheet formula catches the exact matches but not the near ones, and the near ones are where the problems hide. So the check either runs shallow and misses things, or runs deep and eats a person's day. Either way it only happens as often as someone has time for it.
What we built
On Kortix, a monthly cron triggers a reconciliation agent. Each run spawns its own isolated session — a cloud sandbox — with scoped access to what reconciliation needs: Stripe, the bank feed, and the Google Sheet we track in. It matches transactions against invoices, flags the mismatches, posts a summary to the sheet, and escalates anything it can't match to a person.
How it works
Connect a monthly cron as the trigger
A cron trigger fires the project on a schedule — once a month, after the period closes. Each firing spawns a fresh session in its own sandbox. One run, one session, one disposable machine, with nothing carried over from the last month's run.
Give the agent our reconciliation rules
How we reconcile lives as skills and memory loaded into every session: what counts as a match, the tolerances we allow on fees and timing, the accounts we track, and mismatches we've explained before. The agent works to that standard rather than inventing one, and the memory updates as patterns recur.
Connect what reconciliation can touch
Through scoped connectors, brokered server-side so no raw token reaches the model, the agent can:
- Read Stripe — charges, payouts, and fees for the period.
- Read the bank feed — deposits and withdrawals to match against Stripe and invoices.
- Read and write the Google Sheet — the ledger it reconciles against and the summary it posts back.
Set the guardrails
The agent reads the financial systems and writes only to the tracking sheet — it never moves money or touches Stripe or the bank beyond reading. Anything it can't match within tolerance is escalated to a person rather than force-fit or written off. Credentials are encrypted in the secrets manager and injected at runtime, never shown to the model or written to logs.
Let each month run
With that in place, the monthly run produces a reconciled sheet and a summary without anyone starting it. Clean matches tie out silently. A payout that's short by a fee gets explained. An invoice with no matching deposit gets flagged and sent to a person to chase, with the two records it couldn't reconcile attached.
The pattern
Fire the project on a monthly cron, give the agent read access to Stripe and the bank feed and write access to the sheet through scoped connectors, encode the reconciliation rules as skills and memory, and escalate anything it can't match to a person.
Guardrails
Giving an agent access to financial systems is a security question first. The relevant controls on Kortix:
- Isolation. Each run happens in its own microVM sandbox. The session can read the accounts it needs, and only the summary it writes to the sheet leaves the sandbox.
- Scoped secrets. The Stripe, bank, and Sheets credentials are encrypted in the secrets manager and injected into the sandbox at runtime, never exposed to the model or the logs.
- Human approval gate. Anything the agent can't match within tolerance is escalated to a person rather than force-fit, and the agent never moves money.
- Everything is code. The agent's persona, skills, and permissions are files in the repo — versioned and changed through a reviewed change request, not a dashboard setting.
The outcome
The afternoon that used to go to comparing hundreds of lines now goes to resolving the few the agent couldn't match. The reconciliation runs every month whether or not anyone has time, and the summary is waiting when the finance person opens the sheet.
The setup relies on four pieces: sandbox isolation per run, a secrets manager to broker the Stripe, bank, and Sheets tokens, an escalation path for anything unmatched, and memory that carries recurring explanations forward month to month.
Read more
How we keep our docs in sync with the code
The docs agent we run on Kortix — connected to GitHub and our codebase. Once a day it checks the code that landed since its last run and updates the docs those changes affected, opening a PR for review.
How we QA every pull request automatically
The QA agent we run on Kortix — connected to GitHub and our test environment. It checks out each PR, runs the suite, exercises the change, and posts the result.
How we run operations from Slack
A single agent reachable from Slack, with scoped access to our database, Stripe, Linear, and GitHub. Ask in a thread and it runs the task across whatever platforms it needs.
Engineer your first loop
Give your company a workforce of agents that run on a schedule, ship real deliverables, and improve one reviewed change at a time. Free to self-host, managed cloud from $20.
Open source · SSO · RBAC · on-prem · no lock-in