How we process vendor invoices as they land
The accounts payable agent we run on Kortix — connected to Gmail, Google Sheets, and Slack. Every 15 minutes it pulls new invoices from the inbox, extracts vendor, amount, and line items, matches them against POs and the ledger, and routes anything clean or flagged to Slack for approval — never scheduling or marking a payment itself.
Vendor invoices arrive by email all day, on no schedule anyone controls, and each one needs the same handling: open the attachment, read off the vendor and the amount and the line items, check it against the purchase order, check it isn't a duplicate of something already in the ledger, and check the price is what was agreed. Done by hand, that's five minutes of careful reading per invoice, and the five minutes is where duplicates and overcharges slip through — not because anyone is careless, but because checking against every prior invoice and every open PO doesn't scale to a person's afternoon.
We run an accounts-payable agent on Kortix that checks the inbox every 15 minutes, extracts every new invoice, matches it against POs and the AP ledger, and posts it to Slack for approval — flagged if it's a duplicate, an overcharge, or missing a PO. It records; it never pays.
The problem
An invoice by itself is just a number. Whether it's right depends on comparing it against things that live elsewhere: the PO that authorized the purchase, the price that was agreed, and every invoice from that vendor already in the ledger. A person doing this by hand checks the easy cases — is there a PO, is the total plausible — and the checks that actually catch problems, like a vendor resending last month's invoice or padding a line item by a few percent, get skipped when the inbox is long and the afternoon is short.
The common shortcuts don't fix this. Paying on receipt catches nothing. A monthly batch review catches duplicates and overcharges after the fact, sometimes after the payment has already gone out. Neither one checks every invoice against every PO and every prior invoice at the moment it arrives.
What we built
On Kortix, a cron fires every 15 minutes. Each firing spawns a fresh agent session — a cloud sandbox with no memory of the last run, because the AP ledger in Google Sheets is the record. The agent checks a Gmail label for new invoice emails, extracts the vendor, amount, and line items from each attachment, matches it against the known POs and prior invoices tracked in the sheet, flags anything that's a duplicate, an overcharge, or missing a PO, and records every invoice in the ledger. It then posts the batch to Slack for a person to approve. It never schedules a payment or marks anything paid.
How it works
Run every 15 minutes, fresh
A cron trigger fires the agent every 15 minutes. Each firing spawns a fresh session in its own sandbox — nothing carries over in the agent's own memory. The AP ledger in Google Sheets is the continuity: every run reads it before doing anything, so duplicate and overcharge checks are judged against the same record every time.
Give the agent the AP rules
How we extract, match, and flag lives as a skill loaded into every session: what counts as a duplicate, the tolerance allowed before a line item counts as an overcharge, and what to do when no PO matches at all. The agent works to that standard instead of improvising it invoice by invoice.
Connect what invoice processing needs
Through scoped connectors, brokered server-side so no raw token reaches the model, the agent can:
- Read Gmail — new invoice emails and their attachments in the watched label.
- Read and append to Google Sheets — the POs and the AP ledger it matches against, and the new rows it records.
- Post to Slack — the batch of processed invoices, flagged or clean, for approval.
Set the guardrails
The agent's only write is an appended row in the AP ledger and a Slack post. It has no access to a payment rail, and nothing in its instructions lets it schedule or mark an invoice as paid — that action belongs to a person, every time, with no exception for a clean match. Credentials are encrypted in the secrets manager and injected at runtime, never shown to the model or written to logs.
Route the batch for approval
With that in place, every 15 minutes any new invoices are already extracted, matched, and recorded by the time a person looks at Slack — each one marked clean, duplicate, overcharge, or missing-PO, with the PO and prior-invoice references attached. A person reviews the batch and approves it for payment through the normal AP process. The agent's part ends at the Slack post.
The pattern
A cron every 15 minutes spawns a fresh session; the Google Sheet ledger is the memory. The agent reads Gmail, matches against POs and prior invoices through connectors, records every invoice in the sheet, and posts the batch to Slack. It never schedules or marks a payment as paid — that's a human, always.
Guardrails
Accounts payable is where a mistake costs real money, so the agent's access is scoped to match:
- Isolation. Every run happens in its own microVM sandbox. The session can reach only Gmail, the AP sheet, and Slack, and nothing else leaves it.
- Scoped secrets. The Gmail, Sheets, and Slack credentials are encrypted in the secrets manager and injected into the sandbox at runtime, never exposed to the model or the logs.
- No payment action, ever. The agent has no connector, tool, or instruction that schedules a payment or marks an invoice as paid. Every invoice, clean or flagged, is routed to a person for that decision.
- Flag, don't discard. Duplicates, overcharges, and missing-PO invoices are recorded and flagged in the ledger, never silently dropped or auto-approved.
- Everything is code. The agent's matching rules, skill, and per-system permissions are files in the repo, versioned and changed through a reviewed change request rather than a dashboard setting.
The outcome
The five careful minutes an invoice used to wait for now happen automatically, every 15 minutes, against the full history in the ledger rather than whatever a person remembers. What used to reach the payment step unchecked now arrives flagged, with the PO and the prior invoice it conflicts with already attached — and the decision to pay stays exactly where it was: with a person.
Read more
How we handle GDPR data-subject requests on a deadline
The GDPR-DSAR agent we run on Kortix — it verifies each incoming access or deletion request, locates the subject's data across our product database, compiles the report inside the SLA, and flags it for legal to review before anything goes out.
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.
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