# Anomaly Detection for Business: Spotting Unusual Meter, Sensor, Payment and Log Data Before It Costs You

> What is anomaly detection and how does it work? Compare rule-based and machine learning methods, then follow seven steps to catch unusual data early.

Source: https://digitalbridge.com.tr/en/blog/anomaly-detection-guide.html
Publisher: Digital Bridge Teknoloji (https://digitalbridge.com.tr)
Topic: Artificial Intelligence
Published: 2026-10-14 · Updated: 2026-10-14

Anomaly detection is the automatic identification of records in transaction, meter, sensor or log data that deviate from normal behaviour. A well-built system learns what "normal" looks like for each machine, customer or user, scores every new record against it and sends suspicious ones, with a reason, to someone who can act. The goal is accurate alerts your team can actually review.

## The problem: the signal is in the data, but nobody sees it

An irregular expense claim, an illegal water connection, a bearing starting to fail, an administrator account logging in at 3 a.m. — each shows up first as a small deviation in data. The difficulty is not a lack of data but too much of it. A smart meter produces dozens of readings a day, an ERP tens of thousands of lines a month, a server hundreds of log entries a second. Finding the outlier by hand in that volume is not realistic. How deviations in server and application logs reach the IT team as meaningful alerts is covered in [AIOps for IT operations](https://digitalbridge.com.tr/en/blog/aiops-ai-for-it-operations.html).

So most organisations fall back on one of two approaches. They audit by random sampling — a handful of invoices, meters or machines each month — or they set fixed thresholds: "alarm if temperature exceeds 80 °C", "route to approval if the amount exceeds 50,000". Both have clear limits. Sampling misses whatever is not sampled. Fixed thresholds either fire constantly (a line that runs above 80 °C every summer afternoon) or never notice behaviour that is below the threshold but strange for that particular device. A system that sends false alarms for a few weeks gets muted, and when the real incident arrives nobody is looking.

## What late detection costs

The value of anomaly detection lies in catching a deviation before it becomes a breakdown, a loss or a breach. Evidence from three areas shows how large that gap can be.

> Siemens estimates that the world's 500 largest companies lose almost **$1.4 trillion a year** to unplanned downtime, equivalent to 11% of their revenues. ([Siemens — The True Cost of Downtime 2024](https://assets.new.siemens.com/siemens/assets/api/uuid:1b43afb5-2d07-47f7-9eb7-893fe7d0bc59/TCOD-2024_original.pdf))

For machinery, a long-standing reference comes from the US Department of Energy. Independent surveys cited in the [DOE Operations & Maintenance Best Practices Guide](https://www1.eere.energy.gov/femp/pdfs/OM_5.pdf) report that a functional predictive maintenance programme cuts downtime by 35–45% and maintenance costs by 25–30%. These are industry averages, not a promise for any single plant, but the direction is clear: sites that see deviations early stop less often.

Information security tells a similar story. According to [IBM's Cost of a Data Breach Report 2026](https://www.ibm.com/reports/data-breach), organisations making extensive use of security AI and automation saved an average of $1.93 million per breach compared with those using none. Part of that difference comes from unusual access and movement being flagged before a person would have noticed.

Data quality belongs in the same calculation, because a wrong or duplicated record is also an anomaly. Data quality expert Thomas C. Redman **estimates** the cost of bad data at 15% to 25% of revenue for most companies ([MIT Sloan Management Review, 2017](https://sloanreview.mit.edu/article/seizing-opportunity-in-data-quality/)).

## Which anomaly detection methods are used?

There is no single right method. The choice depends on the type of data, whether you have labelled past incidents, and how much explanation the reviewer needs.

| Method | How it works | Strength | Weakness |
|---|---|---|---|
| Fixed thresholds and rules | "Alarm if value exceeds X" | Simple, transparent | Misses new patterns, ignores seasonality |
| Statistical methods | Expected range from mean, variance, seasonality and trend | Works with little data, easy to explain | Struggles with multi-variable relationships |
| Unsupervised machine learning | Learns "normal" without labels and scores distant records | Can find never-seen-before cases | Needs careful thresholds and an explanation layer |
| Supervised classification | Trained on confirmed past incidents | High accuracy on known patterns | Needs labelled cases; weak on new types |
| Time-series forecasting | Predicts the next value and flags large gaps | Natural fit for sensors and meters | Sensitive to gaps in the data |

In practice the best results usually come from layers: a few plain rules for the obvious cases, a model on top that measures deviation from each device's or user's **own normal**, and a written answer to "why was this flagged?" beside every alert. A score with no explanation will not earn the trust of an auditor or a maintenance manager.

## Where anomaly detection is used

- **Meter and subscriber data:** a meter whose consumption drops well below similar customers nearby suggests tampering or a fault. With remotely read meters this check can run daily; we cover the infrastructure on our [automatic meter reading](https://digitalbridge.com.tr/en/industrial-products/osos-meter-reading.html) page, and network-side methods in our [water loss analysis](https://digitalbridge.com.tr/en/blog/water-loss-analysis.html) article.
- **Machine sensors:** a slow drift in vibration, temperature or current often precedes a failure; [vibration analysis for fault detection](https://digitalbridge.com.tr/en/blog/vibration-analysis-fault-detection.html) is the most common example. Our [predictive maintenance guide](https://digitalbridge.com.tr/en/blog/predictive-maintenance-guide.html) looks at this case in depth.
- **Energy consumption:** a drift in a site's ratio of reactive to active consumption is often the first sign of a fault in the power factor correction panel; left unnoticed until the bill arrives, it becomes a [reactive power penalty](https://digitalbridge.com.tr/en/blog/reactive-power-penalty.html). With hourly meter data the deviation can be caught the same day.
- **Field and land data:** on a crop health map built from drone or satellite imagery, a patch that stands out from its neighbours points to an irrigation, disease or pest problem; we explain the method in [drone NDVI analysis](https://digitalbridge.com.tr/en/blog/drone-ndvi-analysis.html). For other examples from field to packhouse, see [AI in agriculture](https://digitalbridge.com.tr/en/blog/ai-in-agriculture-use-cases.html).
- **Payments, expenses and stock movements:** payments approved outside working hours, repeated round-number expenses, a warehouse location that is always short at stock count. Unusual payments triggered by [fake invoice emails](https://digitalbridge.com.tr/en/blog/fake-invoice-email-scams.html) are caught here too.
- **Access and system logs:** badge reads at unusual hours or zones, logins from an unexpected country, a burst of failed sign-ins. The zone-by-zone entry records of an access control and time-and-attendance system such as [SmartPass](https://digitalbridge.com.tr/en/smartpass.html) are a ready-made data source for this analysis.
- **Production quality:** measurements drifting in one direction while still within tolerance — a sign that the process is degrading before defects appear. This is the AI counterpart of [SPC and Cpk control charts](https://digitalbridge.com.tr/en/blog/spc-cp-cpk-explained.html); for visual defects, [computer vision quality inspection](https://digitalbridge.com.tr/en/blog/computer-vision-quality-inspection.html) does the job.

## Seven steps to set up an anomaly detection system

1. **Start with one question.** Not "find every anomaly", but "which meters look like tampering?" or "which pump is heading for failure?".
2. **Decide who reviews alerts and how many they can handle.** Sending 300 alerts a day to an audit team that can investigate ten makes the system useless. Thresholds are set to match that capacity.
3. **Audit the data.** Missing readings, time-zone errors, unit mix-ups and [duplicate records](https://digitalbridge.com.tr/en/blog/data-quality-duplicates.html) must be cleaned first, or the model will report data errors as anomalies.
4. **Define normal.** Seasonality, shift patterns, public holidays and planned maintenance are given to the model as context.
5. **Back-test on known incidents.** If you have a few past events — a breakdown, a fraud case — check whether the system would have flagged them in time.
6. **Attach a reason to every alert.** For example: "consumption over the last 30 days is below the average of 40 similar customers and 60% lower than the same period last year".
7. **Feed the reviewer's verdict back in.** "Real case / false alarm" marks are the basis for the next round of tuning. Without this loop, accuracy decays.

If choosing a starting point is the hard part, our article on [where to start with AI in your business](https://digitalbridge.com.tr/en/blog/ai-in-business-where-to-start.html) explains how to keep a first project small and measurable.

Anomaly detection and forecasting complement each other: a good forecast defines what "normal" looks like, and an anomaly is a departure from it. We apply this to energy in [electricity load forecasting](https://digitalbridge.com.tr/en/blog/electricity-load-forecasting.html).

## Common mistakes

**Building a data lake first and looking for a question later.** Centralising data is useful, but an anomaly system without a question becomes a dashboard nobody owns.

**Measuring success with a single accuracy figure.** Anomalies are rare. If 99.9% of records are normal, a model that says "everything is fine" is 99.9% accurate. The useful measures are how many real cases were caught and how many alerts turned out to be real.

**Not connecting alerts to a workflow.** If alert emails pile up in an inbox, the system will be ignored. An alert should land as a maintenance work order, an audit task or an item in the security team's queue.

**Setting it up once and forgetting it.** A new line, a new tariff or a new supplier changes what "normal" means. Models need periodic review.

Typical energy applications include flagging compressed air flow that rises outside production hours ([compressed air leak detection](https://digitalbridge.com.tr/en/blog/compressed-air-leak-detection.html)) or solar strings producing below expectation ([solar power plant monitoring](https://digitalbridge.com.tr/en/blog/solar-plant-monitoring.html)).

The same method works on animals: deviation from each animal's normal activity and rumination flags illness before it is visible. We give the example in our article on the [livestock monitoring system](https://digitalbridge.com.tr/en/blog/livestock-monitoring-system.html).

## How we approach it at Digital Bridge

We treat anomaly detection as a project that starts from your data, not as a software licence:

- **Data assessment.** We establish together what data you have, its quality and whether it can answer your question. If the data is insufficient, or the problem can be solved with a simple rule set, we say so plainly. For the data side we draw on our [data governance and quality](https://digitalbridge.com.tr/en/data-analytics/data-governance-quality.html) work.
- **Model and threshold design.** Through our [anomaly detection service](https://digitalbridge.com.tr/en/technology-hardware/anomaly-detection.html) we build a system that learns each device's, customer's or user's normal from history, explains every alert and is tuned to your team's review capacity.
- **Connecting to existing systems.** It connects to your ERP, meters, sensors, access control or log sources without replacing your current software. Making alerts appear as work orders or tasks in the screens your staff already use is part of our [AI integration](https://digitalbridge.com.tr/en/technology-hardware/ai-integration.html) service.
- **A machine pilot.** For failure prediction, our [predictive maintenance](https://digitalbridge.com.tr/en/industry-40/predictive-maintenance.html) service starts with a pilot on one to three critical machines, with measurable value visible within the first 30–60 days. Because electronics and embedded software are developed by the same team, we can also build the data collection side if sensors are missing.
- **Security logs.** If you want to monitor unusual access and session behaviour, we design it together with our [cyber security consultancy](https://digitalbridge.com.tr/en/consultancy/cyber-security.html).

We apply the same method to power networks in our article on [electricity theft detection](https://digitalbridge.com.tr/en/blog/electricity-theft-detection-analytics.html): scoring suspect customers from meter and transformer data and planning field inspections around that score.

## Next step

You do not need a big preparation phase. Pick the one question you most want answered and six to twelve months of the related data — meter readings, sensor logs, a payment list or a log export. Then [get in touch](https://digitalbridge.com.tr/en/contact.html): we will review the data with you and set out in writing whether it is sufficient for anomaly detection and, if so, how a pilot would run. You can measure the pilot's return with the steps in our [guide to measuring AI project ROI](https://digitalbridge.com.tr/en/blog/measuring-ai-project-roi.html), and explore other use cases in our [complete Artificial Intelligence guide](https://digitalbridge.com.tr/en/blog/topic/yapay-zeka.html).

## Frequently Asked Questions

### What is anomaly detection, in simple terms?

Anomaly detection is a method for automatically finding records that differ markedly from expected behaviour in a stream of data. The system first learns a "normal" range for each machine, meter or user from historical data. It then scores every new record against that range and passes anything above the threshold to a reviewer, with a note explaining why it looks suspicious.

### How much historical data does anomaly detection need?

There is no fixed number; it depends on the data's natural cycle. A water or electricity meter with seasonal behaviour needs at least a year of data, because summer and winter consumption differ. A machine sensor read every minute may need only a few weeks of normal operation to get started. Whether your data is sufficient becomes clear during the data assessment.

### Can an anomaly detection model be built without labelled past incidents?

Yes. Unsupervised machine learning methods need no labels: they learn "normal" from the data itself and score records that sit far from it. As reviewers mark each alert as a real case or a false alarm, labels accumulate. Once there are enough of them, a supervised model that is more accurate on known incident types can be added.

### Is anomaly detection the same as predictive maintenance?

No. Predictive maintenance is one specific application of anomaly detection: finding deviations in machine data such as vibration, temperature and current that lead to failure. Anomaly detection covers a much wider range of data, including payments and expense claims, stock movements, meter readings, access control records and server logs.

### What does an anomaly detection system cost?

The main cost drivers are the number and cleanliness of data sources, whether new data collection hardware such as sensors is needed, which systems alerts must reach (ERP, maintenance software, a security team's queue) and whether the model runs on your own servers. The return should be measured in a limited pilot with a recorded baseline.

### What if anomaly detection produces too many false alarms?

False alarms are the most common reason anomaly detection systems are abandoned: after a few weeks, the team simply stops looking. To prevent this, thresholds are set to the team's daily review capacity, every alert carries a readable explanation, and the system is retuned regularly using reviewers' "real case / false alarm" feedback.

### Does our data have to leave the company for anomaly detection?

No. An anomaly detection model can be set up to run on your own servers, so the data never leaves your organisation. Where records contain personal data, such as access control logs or user sessions, obligations under Türkiye's personal data protection law (KVKK), notably privacy notices, purpose limitation and retention periods, are assessed at the start of the project.