A cashier who voids a few more transactions than usual every evening. A supplier invoice that arrives twice with a slightly different number. A batch of new accounts that all redeem the same voucher from one phone. None of these breaks an obvious rule, which is why they slip past manual checks and standard reports.
Anomaly detection is the use of statistics and machine learning to find records or events that do not fit the normal pattern, and to put them in front of a person for review. It does not prove fraud. It narrows thousands of transactions down to the handful worth a closer look, and it catches honest errors and broken data feeds along the way.
The techniques are well established. What decides success is the workflow around them: which losses you target, how alerts are reviewed, and how outcomes feed back into the system. This guide covers where anomalies hide in Indonesian businesses, how the main methods compare, and how to build something your finance, audit or operations team will trust.
Where anomalies hide in an Indonesian business
Most companies already hold the data needed to find anomalies in their POS, ERP, expense and logistics systems. These are common starting points:
| Area | Example anomaly | Data needed | Typical approach |
|---|---|---|---|
| Retail and F&B outlets | A cashier's voids, refunds or manual discounts far above their own usual level | POS logs with cashier and shift | Per-cashier baselines plus rules |
| E-commerce promotions | Many new accounts sharing a device, address or payment account to claim vouchers | Accounts, devices, orders, vouchers | Relationship (graph) analysis |
| Accounts payable | Duplicate invoices, invoices split just below an approval limit, sudden vendor bank account changes | AP ledger, vendor master, approval logs | Rules plus fuzzy matching |
| Expense claims | Repeated amounts, claims dated on leave days, one receipt used by two employees | Expense system, attendance, receipt images | Rules plus scoring |
| Logistics fleets | Fuel purchases that do not match the distance driven | Fuel card data, GPS trips | Ratio models per vehicle type |
| Operations data | A store suddenly reporting zero sales, sensor readings that drift | Time series from systems and devices | Seasonal baselines |
Two cautions apply. First, not every anomaly is fraud: many are data entry mistakes, a new process nobody announced, or legitimate events such as a large corporate order.
Second, normal behavior in Indonesia moves with the calendar. Ramadan and Lebaran arrive about 11 days earlier each year, payday weeks change spending, and shopping events such as 11.11 and 12.12 distort online sales. A baseline that ignores these patterns will flood reviewers with false alarms.
How the methods work, from simple to advanced
Rules and thresholds
Rules encode known patterns: flag any refund above Rp5,000,000, any invoice number seen twice for the same vendor, any expense claim dated on a public holiday. Rules are transparent and easy to audit, which finance teams value. Their weakness is that they only catch what someone already thought of, and fixed thresholds ignore context: a refund that is normal for a flagship store may be suspicious for a small outlet.
Statistical baselines
Statistical methods compare each value with what is normal for that entity and period. A cashier's void rate is compared with their own history and with peers in the same outlet on the same day of the week. Common tools include z-scores, the median absolute deviation (which is less distorted by extreme values than the mean) and seasonal models that learn weekly and yearly cycles. Auditors also use first-digit tests based on Benford's law, although they only suit certain kinds of financial data.
Unsupervised machine learning
Models such as Isolation Forest, Local Outlier Factor or autoencoders learn what normal records look like across many features at once, then score how unusual each new record is. They catch combinations nobody wrote a rule for, for example a normal amount at an unusual hour from an unusual terminal for that cashier. The trade-off is explanation: the model says "unusual", so you must add reason codes that tell a reviewer where to look.
Supervised models
When you have a history of confirmed cases, a supervised model such as gradient-boosted trees can learn what past fraud looked like. These models are often the most precise, but they need enough labeled examples and they miss new patterns. Confirmed fraud is also rare compared with normal transactions, which requires careful handling in training and evaluation.
Relationship analysis
Some fraud is only visible across records: dozens of accounts sharing one phone number, or an employee and a vendor sharing a bank account. Graph analysis links entities through shared attributes and flags clusters that look organized rather than coincidental.
In practice, the strongest setups layer these methods: rules for known patterns and policy requirements, baselines for context, and models to surface what nobody anticipated.
The part most projects get wrong: the alert workflow
An anomaly score is useless until someone acts on it, so design the workflow before tuning the model.
Match alert volume to review capacity. If your audit team can investigate 20 cases a day, the system should send its top 20, not 400. Set the threshold from capacity, then improve precision so those 20 are worth the time.
Explain every alert. "Refunds this shift are six times this cashier's median, mostly to one customer phone number" is actionable. A bare score is not.
Record outcomes. Each alert should close as a confirmed issue, an honest error or a false alarm, with a short note. These labels let you measure accuracy and train better models later.
Separate detection from judgment. An alert is a reason to look, not evidence of wrongdoing. When alerts concern employees, involve HR and follow your internal investigation procedure. Analyzing employee activity is also processing personal data under Indonesia's Personal Data Protection Law (Law No. 27 of 2022), so be transparent about what is monitored and why.
Choose the right speed. Payment and voucher abuse need scoring before the transaction completes. Expense audits and accounts payable reviews work well as overnight batches. Real-time processing adds cost and engineering effort, so use it only where a delay means a loss; our article on real-time dashboards explains the trade-offs.
Regulated financial institutions also have anti-money-laundering obligations under OJK and PPATK rules. An anomaly model can support that monitoring, but it does not replace the required processes and reports.
Building it step by step
- Pick one loss scenario with a business owner, for example refund abuse in outlets, owned by the head of retail operations. A narrow scope gives a clear measure of success
- Assemble and check the data. Missing cashier IDs, inconsistent outlet codes and duplicated records create false anomalies, so fix them first. Our guide on data quality covers the usual problems
- Write baseline rules with the people who know the process. They deliver early value and a benchmark for any model
- Add statistical or machine learning scoring for the patterns rules cannot express
- Backtest on history. Run the system over the past 6 to 12 months and check whether known incidents would have been caught, and how many alerts per day it would have produced
- Run in shadow mode for a few weeks: generate alerts and review a sample, but take no action yet
- Go live with a review queue and a dashboard that shows open alerts, outcomes and trends per outlet or department
- Monitor and retrain. Behavior changes, and so does fraud once people notice the controls. Review performance monthly
How to tell whether it works
Accuracy for anomaly detection is not one number. Our guide to evaluating AI accuracy before deployment explains the general approach; for this use case, track at least these measures:
| Metric | What it tells you | Watch out for |
|---|---|---|
| Alert precision | Share of reviewed alerts that were real issues | If it stays low, reviewers stop trusting the queue |
| Recall on known cases | Share of past confirmed incidents the system would have flagged | Only covers patterns you already know |
| Alerts per day | Whether volume fits review capacity | Spikes after holidays or system changes |
| Time to review | How quickly alerts are handled | Old alerts lose their value |
| Value found | Losses recovered or prevented, plus errors corrected | Count confirmed outcomes only |
How Weaveward can build this for you
We would start by choosing one loss scenario with you and pulling a sample of the relevant data from your POS, ERP or expense system to confirm what is feasible. The first deliverable would be a working detection pipeline with baseline rules, a scoring model and a review queue, backtested against your history and then run in shadow mode so your team can judge alert quality before anything goes live.
After that, we would connect the alerts to your existing dashboards and expand to the next scenario. Read more about our AI and machine learning solutions, or talk to our team about the losses or errors you want to catch first.