Expense Categorisation with AI Agents: How It Works

TL;DR

• Expense categorisation is a good fit for agents: high volume, repetitive, and easy to check against historical decisions.
• A practical design uses three agents in parallel (categoriser, department assigner, anomaly detector) with human oversight for edge cases.
• Labelled historical transactions are the biggest accelerator: they give you a validation set and, if you want it, fine-tuning data.
• Start in shadow mode, auto-apply only high-confidence results, and widen autonomy as the finance team builds trust.

# Walkthrough: Automating Expense Categorisation with a Multi-Agent System

This is a hypothetical walkthrough of how a finance team at a company using a corporate card platform such as Ramp, Brex or Expensify might automate most of its expense categorisation. The numbers you get will depend on your data; the design choices and failure modes are the useful part.

The Problem

Manual expense categorisation is a classic bottleneck:

• Every transaction needs an accounting category and a department.
• Complex cases (international charges, new vendors, ambiguous merchants) take the most time.
• Month-end close waits on categorisation being finished.
• Miscategorisation shows up later as wrong budgets, audit findings and tax issues.

The work is repetitive, rule-heavy and checkable against past decisions, which makes it a strong candidate for agents.

Solution Architecture

A three-agent parallel execution system works well here:

Agent 1: Expense Categoriser

• Task: Assign accounting category (software, ads, travel, meals, office, contractor, other)
• Input: Merchant name, amount, description, date
• Model: A capable LLM, either prompted with examples or fine-tuned on labelled historical transactions
• Output: Category + confidence score

Agent 2: Department Assigner

• Task: Attribute expense to department (engineering, sales, marketing, ops)
• Input: Transaction + employee data (title, department, manager)
• Model: LLM with few-shot examples
• Output: Department + reasoning

Agent 3: Anomaly Detector

• Task: Flag unusual patterns (duplicates, unusually large amounts, new vendors, international charges)
• Input: Transaction + recent spending history
• Model: LLM + rule-based checks
• Output: Anomaly flags with explanation

Orchestrator:

• Runs the three agents in parallel (they don't depend on each other, so this cuts latency)
• Aggregates results
• If any agent's confidence is below your threshold OR an anomaly is flagged → escalate to a human
• Otherwise: auto-categorise and update the accounting system (QuickBooks, Xero, NetSuite)

How the Build Might Run

Phase 1: Data preparation and design

• Export transaction history
• Hand-label a validation set the team trusts
• Design the agent architecture (parallel rather than sequential, since the agents are independent)
• Choose between fine-tuning and RAG (a stable category taxonomy with plenty of labelled data favours fine-tuning; otherwise start with RAG or few-shot prompting)

Phase 2: Build

• Build the categoriser (prompted or fine-tuned)
• Build orchestrator logic with parallel execution
• Integrate with the expense platform and accounting system APIs
• Implement a human approval queue for low-confidence cases

Phase 3: Shadow mode and iteration

• Agents categorise but don't write to the accounting system; the finance team reviews
• Measure accuracy against the validation set
• Iterate on prompts and edge-case handling until accuracy matches or beats the team's own
• Load test at realistic volumes

Phase 4: Gradual rollout

• Enable auto-categorisation for a small slice of transactions
• Monitor for errors and drift
• Expand as accuracy holds

Technical Insights

Fine-tuning or RAG:

RAG (retrieve similar past transactions and include them in the prompt) is the quicker start. Fine-tuning makes sense when:

• The category taxonomy is stable and rarely changes
• You have a large set of labelled examples
• You want the lowest latency, since RAG adds a vector search step
• It measurably beats RAG on your validation set

Parallel vs sequential execution:

A sequential design (categorise → assign department → detect anomalies) is easier to reason about, but the agents don't need each other's outputs. Running them in parallel cuts end-to-end latency for a small increase in implementation complexity.

Human-in-the-loop design:

Tier 1 (autonomous): High confidence, no anomalies. Auto-categorised.

Tier 2 (notify): Medium confidence. Auto-categorised, but the finance team is notified.

Tier 3 (approve): Low confidence OR anomaly flagged. Requires human review before categorising.

A tiered approach builds trust: the finance team can see the agent isn't blindly categorising everything.

Common Challenges & Solutions

Challenge 1: International merchant names

Problem: Non-English merchant names (e.g., "株式会社ABC" instead of "ABC Corporation") are harder to categorise.

Solution: Add a translation step: detect language, translate to English, then categorise.

Challenge 2: Ambiguous merchants

Problem: "Amazon" could be AWS (software), Amazon Business (office supplies), or Amazon Marketplace (various).

Solution: Give the model hints based on amount patterns (small amounts are more often office supplies, large recurring amounts more often cloud spend) and check the employee's department (engineers → more likely AWS, ops → more likely supplies).

Challenge 3: New vendor false positives

Problem: A naive anomaly detector flags every new vendor as suspicious.

Solution: Flag a new vendor only when it's combined with another signal, such as a large amount.

Challenge 4: Finance team scepticism

Problem: "AI will make mistakes, I'll have to fix them anyway."

Solution:

• Run shadow mode first and show accuracy against the team's own work
• Position it as "handles the boring stuff, you focus on complex cases"
• Redeploy time to financial analysis rather than framing it as headcount reduction

Key Lessons

1. Historical data is gold

Labelled historical transactions make evaluation possible and fine-tuning an option. Without them, start with RAG or few-shot prompting and build a labelled dataset as the team reviews escalations.

2. Start with high confidence only

In the first weeks of production, auto-categorise only the highest-confidence transactions. Lower the threshold gradually as the team gains trust.

3. Anomaly detection needs domain rules

Pure LLM anomaly detection tends to produce too many false positives. A hybrid of LLM judgement and rule-based checks is more usable.

4. Parallel execution is worth the complexity

Lower latency makes the review experience noticeably better.

5. Regular accuracy reviews are essential

Review a random sample of transactions every month to catch drift, and retrain or adjust prompts when accuracy slips.

Replication Guide

Requirements:

• A labelled set of historical transactions (for fine-tuning) OR start with RAG
• API access to your expense system (Ramp, Brex, Expensify, etc.)
• API access to your accounting system (QuickBooks, Xero, NetSuite)

Team:

• One or two engineers
• A finance lead, part-time, for requirements and validation

Timeline:

• A RAG-based version is quicker to ship; fine-tuning adds data preparation and training time.

Conclusion

Expense categorisation shows that AI agents can handle high-volume, judgement-based workflows when implemented thoughtfully.

Key success factors:

• Enough labelled data to evaluate against
• Human-in-the-loop for edge cases
• Parallel execution for performance
• Continuous monitoring and retraining

If you're considering similar automation: Start with shadow mode, measure accuracy rigorously, and expand autonomy gradually as trust builds.

The technology works. The challenge is implementation discipline.

---

Frequently Asked Questions

Q: What's the typical ROI timeline for AI agent implementations?

It depends on volume and how much manual work the workflow replaces. Gains usually grow over time as teams optimise prompts and workflows based on production experience.

Q: How do AI agents handle errors and edge cases?

Well-designed agent systems include fallback mechanisms, human-in-the-loop escalation, and retry logic. The key is defining clear boundaries for autonomous action versus requiring human approval for sensitive or unusual situations.

Q: How long does it take to implement an AI agent workflow?

Implementation timelines vary based on complexity, but most teams see initial results within 2-4 weeks for simple workflows. More sophisticated multi-agent systems typically require 6-12 weeks for full deployment with proper testing and governance.