Anomaly Detection in Transactions, Explained for Finance Teams

The problem with rules alone

Most finance teams already have controls. Payments over ten thousand pounds need two approvals. Journals posted on a Sunday get flagged. New suppliers need a bank detail check. These rules are necessary and they catch the obvious cases.

What they miss is the transaction that is unusual for its context rather than unusual in absolute terms. A 900 pound invoice is ordinary, except from a cleaning supplier that has billed 240 pounds a month for three years. A journal is ordinary, except when posted by someone who has never touched that cost centre. Rules cannot express normal-for-this-supplier. Anomaly detection models can.

How the models work, without the maths

An anomaly detection model learns what normal looks like from your history, then scores new transactions by how far they sit from normal. There is no label saying this one was fraud; the model is not told what bad looks like. That is both its strength and its weakness.

For most mid-sized finance functions, per-entity baselines combined with an isolation forest are the right starting point. They are explainable, which matters when an auditor asks why something was or was not flagged.

What it actually finds

In practice, far more errors than fraud. That is worth saying plainly because anomaly detection is often sold as a fraud tool, and a finance director expecting weekly fraud catches will be disappointed.

• Invoices keyed with an extra zero or in the wrong currency
• Costs coded to the wrong nominal account or cost centre
• Suppliers suddenly billing more often than their contract implies
• Expense claims with unusual combinations, such as weekend mileage to a regular client
• Journals posted by users outside their normal accounts or hours
• Bank detail changes followed closely by an unusually large payment

The last pattern is the one that genuinely points at fraud, specifically payment diversion. We cover the process controls for that in invoice fraud prevention, and a model is a useful second line behind those controls rather than a replacement.

False positives decide whether it survives

Every anomaly system produces alerts that turn out to be fine. A year-end bonus run is unusual. A one-off equipment purchase is unusual. If the team gets two hundred alerts a week and nearly all of them are explainable, they will stop looking within a month.

1. Agree a review budget first: say, thirty alerts a week for one person
2. Set the threshold so the model produces roughly that number
3. Give every alert a reason in plain language, not just a score
4. Let reviewers mark alerts as expected, and feed that back to suppress repeats
5. Review the threshold monthly against what was actually found

Working backwards from the review capacity feels unscientific. It is the only approach we have seen keep these systems in use.

A realistic setup for a mid-sized business

Take a group with four entities, around 3,000 supplier invoices and 800 expense claims a month on Xero or a similar ledger. A nightly job pulls the day's transactions, scores them, and posts the top items to a review queue with the reason: amount is five times this supplier's median, first payment to changed bank details, expense category unusual for this employee.

The reviewer clears most in a few seconds each. The interesting ones get a query raised before the payment run, which is the whole point. Catching a duplicate or miscoded invoice after month-end costs a reversal and an awkward conversation; catching it before payment costs nothing.

When anomaly detection is overkill

If your transaction volumes are small enough that someone genuinely reads every line, a model adds little. Likewise if your biggest control gap is basic segregation of duties, fix that first. No model compensates for one person being able to create a supplier and pay it.

It is also a poor fit when history is messy: a recent system migration, a chart of accounts that changed last year, or entities that were merged. The model's idea of normal will be confused. Give it six clean months before judging results.

How SpiderHunts would build it

At SpiderHunts we start with a backtest on a year of your historical data, showing what would have been flagged and letting your team judge whether those flags were useful. That exercise costs a fraction of a full build and tells you whether to continue.

If it is worth continuing, the system is a scheduled job, a scoring model and a review screen, connected to your accounting system through its API. Our data science team builds the models; the review workflow is ordinary custom software. For a broader operational view, see our guide to anomaly detection for business operations.

Frequently asked questions