Expense Audit Agents: Flag the Weird Stuff Weekly

Nobody reads every expense line. In most companies, expense review is a sampling exercise: a manager skims the report total, approves it, and moves on. Finance runs a quarterly spot check if there is time. The result is predictable. Duplicate submissions slip through. A subscription gets expensed twice by two different people. Someone's "client dinner" pattern quietly drifts from $60 to $140. None of it is fraud, most of the time. It is just noise that nobody has the hours to look at.

This is exactly the shape of work an autonomous agent is good at: a repetitive read-heavy review, applied against a written policy, on a schedule, ending in a short report a human actually reads. This article walks through building an expense audit agent on Skopx, what it should and should not be allowed to do, and where this approach genuinely falls short of a human auditor.

What an expense audit agent actually does

Strip away the AI framing and the job is simple. Every week, the agent:

1. Pulls recent expense data from wherever it lives: a Postgres or MongoDB reporting database, a Google Sheet export, an Airtable base, or line items synced from Stripe.
2. Reads your expense policy, which lives in the agent's instructions in plain language, not in a rules engine.
3. Compares each line against the policy and against historical patterns it remembers from previous runs.
4. Writes a report that lists flagged items, and for each one, states the reason in a sentence a human can evaluate in five seconds.

The output is not "37 anomalies detected." It is "Line 4412: $214 ride-share on a Saturday with no linked trip or calendar event, submitted by the same employee who expensed a $198 ride-share the previous Saturday, also without a trip. Policy section on travel requires an associated trip. Suggest asking for context."

That last part matters. An audit flag without a reason is just more work for finance. An audit flag with a reason is a pre-drafted question.

If you have not built an agent before, the mechanics of describing one in chat are covered in how to create an AI agent. The rest of this article assumes the basics and focuses on the expense-specific decisions.

Why instructions beat rules engines for expense policy

Traditional expense tools let you configure hard rules: block anything over $500, require receipts above $25, cap meals at $75 per day. These rules are useful, and if your expense system has them, keep them. They are your first filter.

The problem is that hard rules only catch what you predicted. They cannot catch:

• A pattern across submissions. Five separate $70 meals in one week each pass a $75 cap, but together they might be worth a look.
• Context mismatches. A hotel charge in a city where the employee had no scheduled travel passes every amount threshold.
• Vendor drift. The team's software spend moving from one approved vendor to three unapproved lookalikes, each individually small.
• Duplicates across people. Two teammates each expensing the same team dinner.
• Judgment calls your policy states in prose. "Alcohol is reimbursable at client dinners but not internal ones" is trivial to write and nearly impossible to encode as a field-level rule.

An agent's instructions are plain language, so your policy goes in more or less as written. On Skopx, instructions are editable and versioned, which turns out to matter for audit work specifically: when finance asks "why did the agent flag this in March but not in May," you can see exactly which version of the policy text was in force for each run. There is more on writing instructions that hold up over time in the AI agent instructions guide.

A concrete instruction block for this agent might read:

Each Monday, review all expense lines submitted in the previous 7 days. Flag any line that: exceeds category norms by more than 2x compared to the employee's own 90-day history; has no receipt above $25; duplicates another line within 30 days by amount, vendor, and date proximity; is a travel expense with no corresponding calendar event that week; or is from a vendor not seen before in this category. For every flag, state the line, the amount, the rule or pattern it triggered, and a one-sentence suggested question. Do not flag lines under $10. Do not contact any employee. Never modify expense records.

Notice the last two sentences. Telling the agent what not to do is half the job.

Where the data comes from

Skopx agents can query connected data sources directly with SQL and aggregations, read-only with bound parameters. If your expense data lands in a Postgres reporting database or a MongoDB collection, the agent queries it the way an analyst would: pull the week's lines, compute per-employee and per-category aggregates, join against the vendor list. The read-only constraint is enforced at the platform level, which is the right place for it. An audit agent that could write to the data it audits would be a bad audit agent.

If your expenses live in tools rather than databases, the agent reaches them through integrations instead. Skopx connects to nearly a thousand tools through its integrations catalog, so the realistic paths look like:

• Google Sheets: many finance teams export expense reports to a shared sheet. The agent reads it directly.
• Airtable: same pattern, richer structure.
• Stripe: for companies auditing their own outbound spend on cards or invoices, the agent can read charge and invoice data.
• Gmail or Outlook: receipts and vendor invoices often arrive by email. The agent can search for a matching receipt when a line lacks one, before flagging it, which cuts false positives noticeably.

A reasonable v1 uses exactly one source. Start with the sheet or the database, get the report quality right, then add receipt-matching against email later. Every added source is an added way for the run to go sideways, and audit agents should be boring.

For teams thinking about the data-analysis side more broadly, AI agents for data analysis covers how agents work with SQL sources in more depth.

Memory: why the second run is better than the first

The single biggest quality difference between a one-off "review my expenses" chat prompt and a real audit agent is memory.

Skopx agents keep memory that persists between runs: cursors, baselines, and whatever the agent decides is worth carrying forward. For an expense auditor, that means:

• A cursor marking the last line reviewed, so runs never re-audit or skip a window.
• Baselines per employee and per category: typical meal spend, typical travel cadence, known recurring vendors. "2x above the employee's own norm" only works if the agent knows the norm.
• A flag history, so the agent can say "this is the third consecutive week this pattern appeared" instead of treating each week as day one. It also stops the agent from re-flagging an item finance already reviewed and cleared.

The practical effect is that first runs are broad and a little noisy, because the agent has no baselines yet, and second runs produce delta reports: what changed, what is new, what recurred. Delta runs are also typically cheaper, since the agent is not re-deriving everything from scratch. The mechanics of this are covered in AI agent memory explained.

Expect to spend the first two or three weekly reports tuning. You will see flags you do not care about, and you edit the instructions to say so: "Do not flag recurring SaaS charges under $50 that appeared in the prior month." The agent's instructions become a living, versioned policy document, which is arguably worth more than the audit itself.

Guardrails: this agent should be almost powerless

Here is the design decision that makes expense auditing one of the safest agent use cases: the agent needs read access to almost everything and write access to almost nothing.

On Skopx, every integration grant carries a tier: runs automatically, asks first every time, or agent decides when to ask, plus a drafts-only mode for communication tools. For an expense auditor, the sane configuration is:

Write-shaped actions that are granted under "asks first" park as pending approvals showing the exact call and its arguments. Approving executes exactly that parked call once. Rejecting executes nothing. Reads flow without approval even under approval-required mode, so the audit itself never stalls waiting for a human, only the optional outbound message does.

The "never email an employee" line deserves emphasis. An expense flag is a question, not an accusation, and the difference is entirely in delivery. A model that writes "your Saturday ride-share appears to violate policy section 4.2" to a teammate has damaged trust in a way that no amount of audit accuracy repairs. Keep the human in that loop permanently, not just during a trial period. The broader pattern of gating agent actions behind humans is covered in AI agents with human approval.

Budgets back all of this up. Each Skopx agent carries token-per-run and token-per-day limits, a max step count, and a minute cap, and three budget failures auto-pause the agent. For a weekly read-and-report job, generous defaults are fine; the budgets exist so that a malformed query loop burns a run, not a day.

Setting it up on Skopx: a walkthrough

Here is what the build looks like in practice, framed as an example rather than a transcript.

You open Create Agent and describe the job in chat: "Build me a weekly expense auditor. It reads the expenses table in our Postgres reporting database every Monday at 8:00 UTC, applies the policy I will paste in, and produces a report of flagged lines with reasons. It should never modify anything or contact anyone."

The chat assembles the agent from that description. No code, no canvas, no node graph. You then paste your expense policy into the instructions and tighten the flagging criteria as shown earlier. You pick the pieces:

• Trigger: a schedule, "Every Monday at 8:00 UTC." Scheduled triggers suit audit work because the value is in the rhythm; a report that arrives every Monday gets read, a report that arrives whenever gets ignored. Alternatives are covered in the AI agent triggers guide.
• Grants: the database connection (read-only by construction), calendar read, email read. Slack posting in drafts-only mode if you want the summary pushed to a finance channel.
• Budgets: defaults are fine to start; tighten after you see real run sizes.
• Success criteria: this is where audit agents differ from most. A good criterion set here is something like "every flagged line includes an amount, a stated reason tied to a policy clause or a pattern, and a suggested question; the report states how many lines were reviewed in total; zero write operations occurred." Every run's report is evaluated against these criteria, so a run that reviewed 400 lines and says so is distinguishable from a run that silently only got through 40.
• Model: you pick per agent. Expense auditing is mostly structured reading and comparison, so a fast, cheaper model is a reasonable default, with the option to switch if report quality disappoints. Skopx supports Claude, GPT, Gemini, Kimi and more, on your own keys with zero markup or on the $16 per seat Team plan.

Then you run it manually once before trusting the schedule. Watch the step timeline: every query it ran, every aggregate it computed, each step with a humanized label you can expand into the raw result. If the first report is noisy, edit the instructions and run again. Only when a manual run produces a report you would forward unedited do you let the schedule take over.

Reading the weekly report

A Skopx run ends in a markdown report rendered as a document, and for this agent the report is the entire product. A good weekly expense audit report has four sections:

1. Coverage: "Reviewed 412 lines totaling $38,240 submitted between Aug 3 and Aug 9. All lines within window were processed."
2. Flags: each with line reference, amount, reason, and a suggested question. Ordered by how much money is at stake, not by how confident the agent is.
3. Deltas: what changed since last week. New vendors, resolved flags, recurring patterns entering their second or third week.
4. Non-findings: "No duplicates detected this week. Travel expenses all matched calendar events." Explicit non-findings are what let finance skim in ninety seconds and trust the skim.

Because run history is append-only and every run keeps its full step timeline, duration, and token count, the reports double as an audit trail about the audit itself. When someone asks how a conclusion was reached, the answer is not "the AI said so," it is a specific expandable step showing the exact query and the exact rows that came back. For finance work, that transparency is not a nice-to-have; it is the difference between a tool the controller trusts and one they quietly ignore. More on this in AI agent run transparency.

Honest limits: what this agent will miss

Candor time. An expense audit agent is a screening layer, not an auditor, and there are real gaps.

It cannot verify the world. The agent sees the data. It cannot know whether the client dinner had a client at it. It catches inconsistency between records, not dishonesty that is internally consistent.

Receipts are hard. If receipts are image attachments, verifying that the receipt image matches the claimed amount is unreliable enough that you should treat receipt presence, not receipt content, as the checkable signal in v1.

Baselines take time. For the first several weeks, "unusual for this employee" means little. Expect early reports to lean on absolute policy rules and get pattern-smart gradually.

False positives are a tax you tune, not eliminate. A conference week will look wildly anomalous. Instructions can tell the agent about known exceptions ("flag less aggressively during weeks with a company event on the calendar"), but some noise persists, which is exactly why flags are questions rather than actions.

It does not replace controls. Approval chains, card limits, and your expense tool's hard rules stay. The agent sits above them and catches what falls between them, which is precisely the layer that today has zero coverage in most companies.

Small teams may not need it. If your company has fifteen people and the founder sees every expense anyway, a weekly audit agent is overhead. This use case earns its keep somewhere around the point where no single human reads every line anymore.

FAQ

Can the agent automatically reject or approve expenses?

It should not, and in the setup described here it cannot, because the expense system write grant is simply never given. Skopx grants are per integration and per tier, so an agent with no write grant to your expense tool has no path to modify a record regardless of what its instructions say. The agent flags, a human decides. If you later want the agent to draft a rejection note, drafts-only mode on your email integration lets it write the message without the ability to send it.

What data access does the agent actually need?

Minimum viable: read access to one expense source, either a database connection (which Skopx queries read-only with bound parameters) or a tool integration like Google Sheets or Airtable. Useful additions: calendar read for travel matching and email read for receipt lookup. Nothing else. Credentials for connected tools are encrypted, and the platform has security controls in place, but the strongest control is the one you apply yourself: grant reads, withhold writes.

How is this different from the anomaly detection built into expense software?

Built-in detection runs hard rules and statistical thresholds on fields the vendor chose. It is good at what it does and you should keep it on. The agent layer differs in three ways: it applies your policy as written prose rather than configurable fields, it correlates across systems the expense tool cannot see (calendar, email, other spend sources), and it explains every flag in language a reviewer can act on. Think of it as the difference between an alarm and a first-pass reviewer.

What does a run cost, and what stops costs from growing?

Skopx does not hide model costs behind markup: you bring your own API key across any of eight providers and pay the provider directly, or use the Team plan at $16 per seat with included tokens. Per-run cost depends on your data volume and model choice, so we will not quote figures. What keeps it bounded is structural: budgets cap tokens per run and per day plus steps and minutes, three budget failures auto-pause the agent, and memory makes later runs cheaper because delta reviews reread only what changed. Details in AI agent token budgets.

Can I stop it mid-run if something looks wrong?

Yes. Runs can be stopped mid-flight from the run view, and pausing the agent acts as a kill switch for anything queued. Since the audit configuration is read-only, the blast radius of a bad run is a bad report, not bad data, which is part of why this use case is a good first agent for a finance team.

Start with one week of data

The way to build this is not to design the perfect audit policy first. Paste your existing expense policy into an agent's instructions, point it at last week's lines, run it manually, and read the report. It will be imperfect in specific, visible ways, and each imperfection is one instruction edit away from fixed. After three or four cycles you will have something better than the policy document you started with: a policy that actually gets applied, every Monday, to every line, with reasons attached.

That is the honest pitch for AI expense management done this way. Not intelligence replacing judgment, but coverage replacing sampling, with every judgment call still parked in front of a human.