AI Expense Report Review: Flag Exceptions, People Decide

AI expense report review works best when the agent does the reading and comparing, and people keep the decision. The agent checks each line against your written policy, attaches the evidence for anything that does not fit, and hands finance staff a clear summary. Finance then approves, rejects or asks a question. The agent never pays, approves or rejects anything on its own.

Key takeaways

• Write the policy as rules that can be checked. An agent can only compare a claim with rules that exist in plain language.
• Every flag should carry its evidence: the receipt, the policy clause and the specific mismatch, so a reviewer can decide quickly.
• Keep three outcomes separate: clear, needs a question, and possible violation. None of them is an approval.
• Give the agent read access and a review queue, not payment or approval rights, and treat receipts and free-text notes as untrusted input.
• Review the flags themselves on a schedule. False alarms and missed exceptions show where the rules need work.

What does AI expense report review actually do?

Expense review is repetitive comparison work. Someone opens a report, reads each line, finds the receipt, checks the category, compares the amount with the limit and wonders whether the same meal was claimed twice. An agent can do that reading consistently on every report. What it cannot know is that the sales lead was hosting a prospect who changed plans at the last minute, and it should not pretend to.

So the split is simple. The agent prepares: it extracts fields from receipts, matches them to the claim, applies the policy and writes down what it found. People decide: they approve, reject, request more information or grant an exception. The split matters because a wrong automatic approval or a wrong automatic rejection lands on an employee or on the company, and neither should be settled by a model's guess.

The pattern is the same one used for supplier bills, which we describe in invoice intake with human approval. Expense reports differ mainly because the claimant is a colleague. Tone, context and trust matter more, which is another reason a person should own the outcome.

What needs to be in place before the agent reads its first report?

Most disappointing expense automation fails before any model is involved. The policy is vague, the evidence requirements are unwritten and nobody owns the rules. Prepare these items first:

• A written policy with categories, limits, exclusions and approval levels. Where the policy says reasonable or appropriate, either add examples or mark that rule as judgment, which means it always goes to a person.
• A list of expected evidence per category, such as an itemized receipt for meals, a booking confirmation for travel, and attendee names for client entertainment.
• A named owner in finance who answers policy questions and approves any change to the rules.
• Defined outcomes and routes: who sees a possible violation, who sees a missing document, and who covers when the usual reviewer is away.
• A sample of past reports together with the decisions finance made, so you can test the agent before it touches live work.

The last item is the most useful. Past decisions show where your real policy differs from the written one, and those gaps are better found in a test than in front of an employee.

How does the agent check a line against policy?

A reliable review follows a fixed order, so every report gets the same treatment. Here is a step-by-step plan you can adapt.

• Step 1, intake: collect the report, its line items, the attached receipts, the claimant, the cost center and any trip or event reference. This step is read-only.
• Step 2, extraction: read the date, merchant, total, currency, tax and itemization from each receipt. Where something cannot be read, record that fact instead of guessing.
• Step 3, matching: compare the extracted values with what the claimant entered. Differences in date, merchant, currency or total are noted line by line.
• Step 4, policy check: apply each relevant rule and cite the clause used. Rules marked as judgment are not scored, only surfaced.
• Step 5, duplicate and pattern check: look for the same merchant, date and total inside the report and across other reports, repeated round-number claims, and amounts that sit just under an approval threshold.
• Step 6, classification: label each line as clear, needs a question, or possible violation, and give the reason in one sentence.
• Step 7, hand-off: place the report in the finance review queue with a summary at the top and the flagged lines first.

Two cautions apply. First, the agent checks facts and rules, not motives. It can say that a receipt includes an excluded item. It should not say that someone tried to hide it. Second, an unreadable receipt is a finding, not a failure. Recording it honestly is what lets a person fix it.

What should a flag contain so a person can decide quickly?

A flag without evidence is an accusation. A flag with evidence is a question a reviewer can answer. Each flag should include:

• The line: claimant, date, merchant, amount and category as claimed.
• The rule: the policy clause, named or quoted exactly as written in the policy document.
• The evidence: what the receipt shows, with a link to the file and a note on which part was read.
• The mismatch: one plain sentence describing the difference between the claim and the rule.
• The gaps: anything missing or unreadable that limits the check.
• A suggested next step, such as asking the claimant for an attendee list. This is a suggestion, not an action.
• An optional draft message to the claimant, unsent, written in the tone finance would use.

The reviewer should be able to open the flag, see everything needed and record a decision without opening three other systems. If they have to hunt for the receipt, the flag has failed, however accurate it was.

Keep the volume honest too. If the agent flags most lines, reviewers will stop reading flags. It is better to flag fewer lines with strong evidence and to list the clear lines in a compact summary that can be sampled.

What does one report look like in practice? An illustrative scenario

This scenario is illustrative, not a real case. An operations manager submits a report after a short trip: a hotel stay, two taxi rides, a few meals and a team dinner.

The agent reads every receipt and finds that the hotel and one taxi ride match the claim and the policy. Those lines are marked clear and grouped in the summary.

One meal receipt is itemized, and one line on it is an alcoholic drink. The policy excludes alcohol from reimbursable meals. The agent flags it as a possible violation, cites the clause and links the receipt. It does not subtract anything. Finance decides whether to deduct that line, approve the whole meal under a known exception, or ask the claimant.

The team dinner has a total but no attendee names, which the policy requires for group meals. The agent labels it needs a question and prepares an unsent draft asking the claimant for the names.

A second taxi receipt shows the same date, merchant and total as a line in a colleague's report from the same trip. The ride may have been shared and claimed twice, or the colleagues may have split it. The agent flags it as a possible duplicate, references both reports and stops there.

The finance reviewer reads three flags, answers each in a short time, and approves the report. The agent has paid nothing and decided nothing.

How do you keep approval with finance staff?

Decision rights should be enforced by the system, not only promised in a prompt. A few controls do most of the work:

• Limit permissions. Give the agent read access to reports and receipts and write access only to a review queue or notes field. It should have no ability to mark a report approved or release a payment. The [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) on least privilege is a sound reference for this.
• Treat documents as untrusted. A receipt, a PDF or a free-text description can contain text that tries to instruct the agent, such as a line telling it to approve the claim. Content read from documents is data, never instructions. The [OWASP prompt injection prevention cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) describes defenses worth applying.
• Route to the right person. Approval authority usually depends on amount, department and the claimant's manager. The agent can suggest the route, but the routing rules belong to finance. AI approval workflow routing covers how to set that up.
• Keep decisions separate from findings. Record what the agent read, which version of the rules it applied and what it flagged. Record the reviewer's decision separately, with their name. A clean audit trail makes later questions easy to answer.
• Review messages to employees. Draft notes to claimants should be sent by a person, at least until finance trusts the wording.

These controls also protect the claimant. A colleague who receives a question grounded in a receipt and a clause is treated far better than one who receives an unexplained rejection.

How do you know it works, and how does Be Human run it?

Measure the review, not just the volume. Useful signals include how often reviewers agree with a flag, how often they dismiss one, which exceptions were found later on lines the agent called clear, and how reviewers feel about the time each report takes. Test before launch by running the agent on past reports and comparing its flags with what finance actually decided. The approach in evaluating AI agents on real business tasks applies directly.

Be Human treats this as one defined role: an expense report reviewer. A first engagement sets the policy rules it checks, the memory and tools it needs (read access to the expense system and receipts, plus a review queue), the approval boundaries (it never approves or pays) and a success criterion that finance can observe. Under managed operations, Be Human monitors the workflow, runs recurring evaluations against reviewed samples, reviews permissions, maintains the integrations and applies policy changes through a controlled change that finance signs off.

Frequently asked questions

Can AI approve small expenses automatically? It can be built that way, but we recommend keeping approval with people, especially at the start. If your company later wants a low-risk lane, finance should define it in writing, sample it regularly and be able to switch it off. The decision about what counts as low-risk belongs to the company, not the tool.

What happens when a receipt is blurry, handwritten or in another language? The agent records what it could and could not read and flags the line as needing a question or a better copy. It should not fill gaps with assumptions. A reviewer can then ask the claimant for a clearer document or accept the evidence that exists.

Do we need to replace our expense tool? Usually not. The agent works alongside the tool you already use, reading reports and receipts and writing findings to a review queue or notes field. What matters is that the tool exposes the data and permissions the agent needs, and that the agent cannot change approval status.

How should we start? Pick one report type or one team, write down the rules that apply, and run the agent on past reports without showing results to employees. Compare its flags with what finance decided, fix the rules where they disagree, and then move to a live review queue with a finance owner reading every flag at first.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.