Why AI agents that handle money need a rules engine

What goes wrong when the model decides

It is tempting to give an AI agent a policy document and a pile of bills and ask it to approve or reject each claim. In testing, three problems show up quickly:

• Inconsistency. The same bill, submitted twice, can get two different answers. Language models produce likely text, not guaranteed results.
• Loose reasoning. The model may find a policy clause that is about hotels and treat it as permission to pay a hotel bill, even if that clause sets no amount at all. A clause being on the right topic is not the same as a clause that authorises a payment.
• Weak explanations. When a finance team asks why something was paid, "the model thought so" is not an answer an auditor will accept.

Split the job: the model reads, code decides

The fix is to give each part of the job to the tool that is good at it.

1. The model reads. It takes messy inputs, such as photographed bills, PDFs and emails, and extracts clean fields: date, amount, category, city, vendor.
2. A rules engine decides. Plain code applies the policy limits to those fields. A hotel night in a given city class has a maximum; a meal has a daily cap; a missing receipt above a threshold is not paid. The same input always gives the same result.
3. The model explains. Once the rules engine has decided, the model writes a short, readable explanation for the employee and the approver.

Three outcomes, not two

Most manual processes have only approve and reject. An agent needs a third outcome: hold for a person. Use it whenever information is missing, a bill cannot be read clearly, or a case falls outside the written rules. Held items go to a human with everything the agent found, so the review takes minutes rather than starting from scratch.

A good agent holds more often at first. That is a feature: it shows you exactly where your policy is unclear.

Every decision cites a clause

Each limit in the rules engine should point to the policy clause it comes from. Every approved, rejected or held line then carries that clause reference. We also add a start-up check: when the agent starts, it confirms that every limit in the code matches a clause in the current policy, and refuses to run if they have drifted apart.

Test it like any other software

Build a fixed set of sample claims with known correct outcomes, including awkward ones: duplicate bills, foreign currency, missing receipts, weekend travel. Run them every time the code, the prompt or the model changes. If a result changes, a person decides whether the change is right before it goes live.

Where else this pattern fits

• Insurance claims checks
• Matching invoices to purchase orders
• Refund and return approvals
• Pre-checks for loan or credit applications
• Vendor onboarding document checks

In each case the documents are messy and the decision must be consistent and explainable. We built an expense-claim agent on this design; it is described in our case studies.