How to let an AI agent approve low-value expense claims

Low-value expense claims are a good first depth 3 capability. Let it approve claims under a cap the finance controller sets, only where a legible receipt matches the claim, the category is in policy and no pattern flags the claimant. Anything else goes to a person, and the agent never approves a claim from its own approver chain.

What is being approved, and who owns the decision?

An expense management tool holds claims, receipt images, card transactions and the approval chain. Approving a claim does two things: it confirms the spend was a business expense under policy, and it queues the reimbursement for payroll or the next payment run. Money moves later, through a separate step, which is what makes approval reversible for a short window.

Most organisations have two approvals: the line manager confirms the spend was for the business, and finance confirms it meets policy. The agent replaces the finance check for low-value claims. The line manager's approval stays where the policy requires it, because only the manager knows whether the trip happened for work. The finance controller owns the policy and the cap.

Whether an agent may reject claims, and the wider case, is set out in can an AI agent approve or reject expense claims. The bounds that apply to every finance agent are in AI agents for finance.

Which capabilities do you grant, and at what depth?

1. Agent, depth 1: reads claims, receipts, card feed and policy. The policy library is the only source of rules it may cite.
2. Agent, depth 1: checks each claim. Receipt amount, date and merchant against the claim; category against policy; per diem and mileage rates; duplicates across claimants and periods.
3. Agent, depth 3: approves in-policy claims under the cap. After the line manager has approved, where the policy requires a manager.
4. Agent, depth 2: returns incomplete claims. Drafts a message asking for the missing receipt or business purpose; under certification, standard messages can be sent at depth 3.
5. Agent, held: anything over the cap, out of policy or flagged. Goes to the finance reviewer with the finding.
6. Agent, refused: rejecting a claim outright. A rejection affects a person's pay and can become an HR matter; a person decides.
7. Person, finance reviewer: decides held claims.

What makes a claim "low value" in practice?

A single cap per claim is not enough. Set three bounds and let the lowest win: a cap per claim, a cap per claimant per month for agent-approved claims, and a category list. Meals, taxis and parking can sit inside the class; entertainment of third parties, gifts, alcohol and anything with tax consequences for the employee should be outside it, whatever the amount, because those need a judgement about who benefited.

Receipts are external evidence. An image uploaded by the claimant tells you what the claimant says it shows. A matching corporate card transaction from the card issuer's feed is much stronger. Where a claim has both, the agent can approve under the cap. Where it has only an image, consider a lower cap. Detail on reading receipts is in reviewing employee expense claims with an AI agent.

How do you hold, revoke and record?

Held claims carry the reason in plain words: "receipt shows a different date", "second claim for the same dinner by another attendee", "category not in the agent's class". The reviewer sees the receipt, the policy clause and the claimant's history in one view.

Revocation should be granular. The controller can withdraw the approval capability for one category, one entity or everyone, and claims return to the human queue without breaking anything else. If the agent's certification run clears no depth, approval stops the same day and checks continue at depth 1.

Each verdict is filed with the claim version, receipt reference, policy version, the bound that decided and the approver identity. That record answers the question auditors ask most often about expenses: who approved this, under which rule.

Which controls matter, and what evidence does each leave?

Approver independence. The agent never approves a claim from someone who manages its configuration or approves its bounds. Evidence: an exclusion list on the role scope.

Policy citation. Every approval and every hold cites the clause. Evidence: policy version on each verdict.

Threshold-splitting check. Several claims just under the cap for the same event are held together. Evidence: linked claims in the held record.

Sampling of agent approvals. A reviewer checks a sample of approved claims each month. Evidence: the sample, findings and sign-off.

What should you measure?

• Sampled approvals found out of policy. The number that matters most.
• Claims returned for information, and how many come back complete.
• Held claims by reason. Persistent reasons may mean the policy is unclear.
• Time from submission to reimbursement for in-class claims.
• Claims per claimant just under the cap.

Where does it usually go wrong?

The cap becomes a target. Claimants learn the threshold and claims cluster below it. Keep the cap unpublished internally if your policy allows, and watch the distribution.

Policy is ambiguous. "Reasonable" meal costs mean whatever the reader thinks. The agent applies a number only if the policy states one; otherwise it holds. Fix the wording, as whether an AI agent can enforce an expense policy explains.

Manager approval skipped. The tool is configured so the agent approves before the manager, and the manager rubber-stamps an approved claim. Order the chain so the manager goes first.

The connection is too broad. The agent's account in the expense tool can edit policy settings. Scope it as described in connecting an AI agent to your expense management tool.