Anomaly Detection with AI: Catching Deviations Before They Cost You Money

Key Takeaways: Anomaly detection lets machine learning automatically spot unusual patterns in your data: a duplicate invoice, a leaking machine, a revenue dip in a single location or a sensor drifting before it breaks. It works without you having to think up every rule in advance, because the model learns for itself what is normal. An entry-level project typically costs between 12,000 and 40,000 euros, with payback periods of six to eighteen months. The biggest pitfall is not the technology but false alerts: without good calibration your team becomes desensitised and starts ignoring the real signals.

What anomaly detection is and why it works differently

Most companies monitor their data with fixed rules. Alert when an invoice exceeds 10,000 euros. Send a warning when a machine gets hotter than 80 degrees. Flag an order with more than five returns. Those rules work, but they have two fundamental limitations. They only catch what you thought of in advance, and they take no account of context. An invoice of 12,000 euros is suspicious from a supplier that normally sends 800 euros, but perfectly normal from a supplier that invoices hundreds of thousands every month.

Anomaly detection reverses that logic. Instead of you devising the rules, a machine-learning model learns for itself what the normal pattern is, per customer, per machine, per day of the week, per season. It then flags whenever something falls significantly outside that pattern. A deviation, or anomaly, is therefore not a fixed limit but a relative concept: unusual relative to the context.

That difference matters, because most damage does not come from things that are obviously wrong, but from subtle deviations no one notices. A bookkeeping error of a few hundred euros that repeats every month. A sensor that slowly drifts off. A supplier that quietly gets 4% more expensive. Each one too small for an alarm bell, but together good for tens of thousands of euros a year. Anomaly detection is precisely strong in that grey area, and fits well with broader data-driven decision-making.

Where you use it: four broad application areas

The first and best-known area is financial. Think of duplicate payments, unusual spending on a cost centre, anomalous expense claims or suspicious transaction patterns. A wholesaler with a few thousand purchase invoices a month routinely finds duplicate or unwarranted payments with anomaly detection that would never have stood out manually. For payment flows and transaction fraud specifically, this touches on fraud detection with AI, where the same techniques are applied at transaction level.

The second area is operational. A revenue dip in a single location, a sudden rise in returns on a product line, a conversion rate sagging on your webshop, or a lead time getting out of line. Often you only see such shifts in the monthly report, while a deviation could have warned you that same day.

The third area is IT and sensor data. Servers suddenly using strange amounts of memory, a production machine showing deviating vibration or temperature, energy consumption shooting up for no reason. This connects directly to predictive maintenance in manufacturing: an anomalous sensor pattern is often the earliest signal that a component will fail within weeks.

The fourth area is often forgotten but delivers surprisingly much: data quality. A field that is suddenly empty more often, a product code that abruptly appears in three spellings, an import that misses half the records. Anomaly detection on your own data flags quality problems before they pollute your reports, a natural complement to structurally improving data quality in SMEs.

How it works technically: supervised, unsupervised and thresholds

There are roughly two ways to learn to recognise deviations. With supervised learning you train a model on data in which known errors or fraud cases are labelled. The model then learns exactly which characteristics belong to those cases. That works excellently, but there is a catch: you need enough examples of what went wrong, and those are usually scarce. Most companies have hundreds of good months and a handful of incidents, and that is too little to train on reliably.

That is why anomaly detection in practice often starts unsupervised. The model is shown only the normal history and learns the pattern from it, without anyone having to point out in advance what a deviation is. Techniques such as isolation forests, autoencoders or clustering then determine how far a new data point lies from the normal. The advantage is that you need no labelled errors; the disadvantage is that the model gives you no reason, only a signal: this is unusual.

The core of a working system lies not in the model but in the threshold. Each deviation gets a score, and you decide from which score an alert goes out. Set the threshold low and you catch almost everything but drown in false alerts. Set it high and things stay quiet but you miss subtle cases. That trade-off between false alarm and missed deviations is not a technical detail but the most important design choice, and you make it together with the people who will respond to the alerts.

Honest about false positives and limits

The biggest risk of anomaly detection is not that it finds too little, but that it finds too much. A fresh model that is set loosely can easily generate fifty or a hundred alerts a day in the first week, the vast majority of them harmless: a seasonal peak, a one-off large order, a planned maintenance check. If your team notices after three days that nine out of ten alerts are spurious, they will start ignoring the tenth too. Then you have built an expensive system that actively does harm.

The solution is not a more perfect model but a realistic working process. You start with a deliberately tight threshold, for example five to fifteen alerts a day, a number a human can actually assess. Every assessment, justified or not, feeds the model. After a few weeks the share of false alerts typically drops from more than half to under twenty percent. Don't count on zero: a deviation is by definition something unusual, and not every unusual thing is a problem.

Be honest too about what it cannot do. Anomaly detection finds that something deviates, not why. It does not replace domain knowledge; someone still has to interpret the alert. And it works poorly on data that is itself messy or incomplete. A reliable system stands or falls with a decent data foundation, and once it is running it requires maintenance, because patterns shift. Without a serious MLOps approach to keep models in production, a model loses its edge after half a year.

Costs, ROI and what you do with it

Costs vary strongly with your situation. A well-defined project on a single data source, for example deviations in purchase invoices or in a set of sensors, typically costs between 12,000 and 25,000 euros for analysis, model and a first dashboard. A broader system that combines multiple sources and is integrated into your daily processes is more likely to be between 25,000 and 40,000 euros. On top of that come ongoing costs for hosting, monitoring and periodic retraining, roughly 200 to 1,000 euros a month, depending on volume and complexity.

The payback period depends on what you are currently missing out on. If a system on purchase invoices finds 15,000 euros a year in duplicate or unwarranted payments, then a 20,000-euro project pays for itself within just over a year and is pure profit after that. In maintenance the calculation is often more favourable: a single prevented failure on a production line quickly runs into the tens of thousands of euros in downtime. In practice we see payback periods between six and eighteen months, with the shortest times where much is still checked manually.

The most important thing is what you do with an alert. A deviation only has value when an action is attached to it: an invoice held back for review, a technician sent out preventively, a data field cleaned up before the report goes out. Without that agreed follow-up, anomaly detection is an expensive alarm bell no one responds to. The development of such a custom model also often falls under the WBSO, which lowers the wage costs of the development track by around 30% on average.

Stratalytic and anomaly detection

We don't start with the model but with the question of which deviation really costs you money and what you would do about it:

• Scan: together we determine where deviations cause the most damage, financially, operationally, in IT or in data quality.
• Build: a model that fits your situation, usually starting unsupervised and adding supervised once there are labels.
• Calibration: we set thresholds at a workable number of alerts and tune on feedback from your team.
• Embedding: every alert gets a concrete follow-up in your process, with MLOps so the model stays sharp.
• Subsidy: where it concerns custom work, we incorporate the WBSO as standard.

Schedule a 30-min intro call and in half an hour we'll determine which deviations are costing your business the most right now.

Frequently asked questions

What is the difference between anomaly detection and a simple threshold in Excel? A fixed threshold knows only one limit and lacks context. Anomaly detection learns what is normal per customer, day, season or machine, and only flags something when it truly falls outside that pattern. That way you catch subtle deviations a fixed rule misses, with fewer false alerts on peaks that are simply normal.

How much data do I need for anomaly detection? For unsupervised methods, a few months to a year of history is often enough, because the model learns what is normal. For supervised models you need labelled examples of errors or fraud, and those are scarce. In practice you therefore usually start unsupervised and build up labels along the way.

Won't I get hundreds of false alerts a day? That risk exists, and it is the main reason projects fail. A good system scores each deviation and only forwards the highest ones. By setting thresholds at a workable number of alerts and tuning the model on feedback, the false-positive rate drops sharply after a few weeks.

Does anomaly detection replace my controllers or analysts? No. The system filters out the noise so that people focus their attention on the few cases that really matter. The final judgement, especially with fraud or blocking transactions, remains human work, also because the GDPR requires human intervention for far-reaching decisions.