AI Expense Management: What It Does, Where It Fails, and What UK Law Requires

AI in expense management does six things beyond reading a receipt: policy checking, duplicate detection, VAT determination, ledger coding, natural language reporting, and forecasting. Two of those, policy checking and duplicate detection, are deterministic: the same claim run through twice gets the same answer, because a rule either matches or it doesn’t. The rest produce an inference rather than a fact—a model’s best guess, not a certainty. That distinction, more than the six-item list itself, is what decides how much of your process can safely run without a person.

Whether you are evaluating an AI-assisted expense process or already running one, the question that eventually arrives is how much of it you can defend in a procurement review or an audit. So, with that in mind, we’ll cover what each capability actually is, how each one fails, what HMRC requires of the record underneath it, and the four safeguards UK law now attaches to any system that rejects a claim without a human involved. 

What AI actually does, beyond reading the receipt

AI in this market is not one technology. It is at least four, doing different jobs with different failure modes, and lumping them together is how the term avoids being specific. 

Field extraction is machine learning of a well-understood kind, trained on labelled receipt images. Duplicate detection is largely deterministic. Anomaly detection is statistics. Natural language querying is a large language model. They fail in completely different ways, and a control that catches one will not catch another. 

Policy checking and anomaly detection are not the same control

These get sold together and they answer different questions. Policy checking asks “does this break a rule we wrote down?” Anomaly detection asks “is this unlike what usually happens?” 

The structural weakness of anomaly detection in expenses is that it is trained on your own history, and your history includes whatever has been going wrong all along. If a regional manager has rounded up mileage by ten miles a trip for four years, that is his baseline and the model has no anomaly to report. 

Anomaly detection finds the sudden and the unusual, which in practice means it finds the careless rather than the deliberate. The deliberate ones are, by definition, the people who have worked out what does not get looked at. 

Policy checking is the stronger control, and it is barely AI at all. If your policy says receipts are required above £25 and hotels are capped at £150 outside London, those are rules a machine applies perfectly every time, which is more than most approvers manage on a Friday afternoon. The failure mode is not the engine, it is that nobody has updated the rules since the policy changed.

Duplicate and split-claim detection is the strongest case on the list

This is where automation genuinely beats people, and it is worth being clear about why. A human approver compares the claim in front of them against their memory. A machine compares every claim against every other claim in the system, across every claimant, across every month, including one submitted by a different person on a different card in a different currency. 

Split claims are the case people never catch manually. A £340 dinner broken into three £113 claims across three days sits under a £150 approval threshold and looks unremarkable one line at a time. Sequential merchant, near-identical amounts, adjacent dates and a common claimant is a pattern query , not a judgement call. 

If a vendor can only demonstrate one AI capability to you, make it this one, because it is the one you can verify in a demo with your own data.

VAT determination, and the four places it goes wrong

Automated VAT coding is the feature most likely to be oversold and the one with the most expensive failure mode, because an over-reclaim is recovered from you with interest. Four cases account for most errors: 

• Mixed-rate receipts: A supermarket receipt with hot food at 20% and cold food at 0% needs line-item extraction rather than a total. Many systems read the total, apply the VAT shown, and get it right by accident because the receipt did the arithmetic. Where the receipt does not break it out, a model guessing a rate is guessing. 
• Suppliers who are not VAT registered: A receipt with no VAT number is not a VAT receipt, and a gross figure divided by six is not input tax if the supplier never charged any. 
• Simplified invoices: For retail supplies under £250 these can omit detail a full invoice carries, so there is less on the page for the model to work from and more inference in the result. 
• Entertaining: Staff entertaining and client entertaining look identical on a restaurant receipt and are treated completely differently for VAT. No amount of image processing resolves this, because the distinguishing fact, who was at the table, is not on the receipt. It has to come from the claimant, which means the field has to be mandatory. 

Categorisation, and the mistake it inherits

Category matching learns from your history. That is its strength and its defect in one sentence. 

Feed it three years of ledger data in which subscriptions have been coded to office costs, and it will code subscriptions to office costs with high confidence and a green tick. The model is doing exactly what it was asked. It is reproducing you. 

Before you turn on automatic coding, run a sample of the last quarter’s claims past the categorisation you actually want rather than the one you have. The clean-up has to happen before the training, or it does not happen. 

Natural language querying

Ask “what did we spend on hotels in Manchester last quarter, by team” and get a table back in a few seconds instead of exporting to a spreadsheet and building a pivot. This is the genuinely new capability of the last two years, and it is the lowest-risk AI in the stack for one specific reason: it decides nothing about anybody. It reads. 

Two cautions apply to every product in this category. A language model answers the question it parsed, and “last quarter” is ambiguous across a calendar year, a financial year and a rolling ninety days. And fluency is not accuracy: the output reads like a finance analyst wrote it whether the underlying query was right or wrong. 

Before any figure from a conversational interface goes into a board pack, a statutory return or a budget conversation, click through to the transactions behind it. If the tool cannot show you the transactions behind it, that is the finding. 

Forecasting

Spend forecasting from claim history is arithmetic dressed as intelligence. It extrapolates. It is useful for spotting that Q3 travel is tracking 30% above Q3 last year, and useless for anything structural, because it has no knowledge of the contract you won, the office you closed or the field team you are about to hire. Treat it as a monitoring tool , not a planning one. 

Where a human has to stay in the loop

Here’s the sentence worth keeping: an AI that approves or rejects with no record of why is a system you can’t defend later.

That’s a different claim to “AI should never approve or reject anything,” and it’s worth being precise about the difference. Every control described above is a filter, and filters have a false negative rate. That’s true whether a person or a machine applies them. The risk is not automation making a call. It is automation making a call against a rule nobody can point to, with no trail back to who set it, and no way for the employee on the other end to challenge it.

So the useful question for any system, including your own, isn’t “does AI ever decide anything?” It’s “when it decides, can we show what rule it applied, and can the person affected ask a human to look again?”

Extraction, matching, coding, checking, and flagging can all run without a person and carry very little risk, because nothing has happened to anyone yet. Once a system moves to approving, rejecting or paying automatically, that’s a decision with a consequence attached, which is fine as long as it’s happening against a written rule, it’s logged against that rule, and the safeguards below are actually available if someone wants to contest it.

What HMRC requires of the record 

This is the question that decides whether AI extraction is a convenience or a compliance risk, and it has a clean answer. 

The extracted value is not the record. The image is. 

HMRC’s position on scanned documents gives the example of a business whose software scans invoices and puts the information into its ledger: if the image is retained and contains all the detail required for VAT purposes, the business does not need to keep the original invoice unless it is required for another purpose. 

Read that carefully, because it contains the whole rule. The image has to be retained, and the image has to contain all the detail required for VAT purposes. That detail means supplier name, address and VAT registration number, a description of the goods or services, quantity and unit price, the rate and amount of VAT, and the date of supply, with some of it able to be omitted on a simplified invoice for retail supplies under £250. 

So a system that reads a receipt, writes seven fields to a database and discards the photograph has destroyed your evidence and kept a summary of it. If HMRC asks you to support an input tax claim, “our software extracted £4.17 of VAT” is not evidence. The legible image showing the supplier’s VAT number is. 

Any system you buy has to retain the original image for at least six years and produce it on demand against the transaction. 

There is a second rule that needs to be under consideration too. Under Making Tax Digital for VAT, cutting and pasting data is not an acceptable digital link. That kills the workflow where somebody photographs a receipt, an AI tool reads it, and a person retypes or copies the result into a spreadsheet before it reaches the VAT return. The extraction being automated does not help if the handoff after it is manual. 

The practical test for a vendor is short. Ask them to show you a transaction from eighteen months ago, open the original image behind it, and export both together. If any part of that is difficult in a demo, it will be impossible in an enquiry.

What UK data protection law now requires

UK GDPR Articles 22A to 22D came into force on 5 February 2026, and they change what you owe an employee when a system makes a decision about them without a person involved. 

If your expense system rejects or reduces a claim automatically, that is a decision about an individual, taken by automated means. Where that decision has a legal effect on the employee, or similarly significantly affects them—which an automatic rejection or reduction of pay ordinarily will—four safeguards attach to it:

• Information about the decision, provided to the employee. 
• A way to make representations about it. 
• Human intervention on request. 
• A route to contest the decision. 

If you cannot evidence all four, the safer position is to put a person back into that step. Keeping a human on rejections is the single control that keeps you clear of the automated decision rules altogether, and it costs very little, because the volume of rejected claims in most organisations is small. 

Automate the evidence, keep the judgement

Separate those two halves and most of this gets simpler. Everything that gathers evidence, matches, codes, checks and flags is genuinely worth automating, and that is where almost all of the hours are. Of what’s left, automate the clear-cut decisions—the ones being made against a rule you can point to, with a trail back to it—and send the exceptions, the ambiguous cases and anything contested to a person. That’s a small share of the hours, but it’s where the judgement lives.

If you are evaluating a product, a few demo requests will tell you more than any feature list. Ask it to find a split claim in your own data. Ask it to open the original receipt image behind a transaction from eighteen months ago and export both together. And ask what happens, technically and legally, when it rejects a claim without a person. And, if you already have one running, the check worth doing this month is simpler still: find out which steps in your process currently run without a human, and whether anybody signed that off. Configuration changes move that line quietly, and the first time most organisations look at it properly is when somebody asks who approved a claim that should not have been. 

Capture Expense is built around that split, with smart AI features that work for your teams. Receipt capture through WhatsApp, Teams or Slack, category and VAT coding against your own setup, card reconciliation, duplicate and split-claim detection, and AI-generated receipt detection all run without a person, and that is the evidence half. Smart Audit then applies your own rules on top: reasoning through context and history, moving forward what clearly checks out, and flagging what doesn’t for a person to look at. The part worth checking, on any system including this one, is whether the four safeguards below are switched on for the claims it does resolve automatically. Want to see it in action? Book a demo with our team to see our platform in action!