Anomaly Radar: Finding the Odd Transaction Nobody Would Look For
The transactions that cost you money are rarely the ones you would think to look for. They are ordinary, individually small, and buried among thousands of correct ones. What an anomaly radar actually watches, why it is rules rather than magic, and how to stop it becoming another ignored notification.
A business with ten thousand transactions a month does not have a data problem. It has an attention problem. Everything is recorded, nothing is hidden, and the item being sold below cost since a price update in March is sitting in plain sight in a report nobody opens.
Anomaly detection is the unglamorous answer to that: a small set of standing questions asked continuously against your own data, so that the odd transaction finds you rather than waiting for you to go looking. It is far less clever than the name suggests, and considerably more useful.
Rules, not intuition — and that is the point
It would be more impressive to say a model learns your business and surfaces what is unusual. It would also be much harder to act on, because when a black box flags a transaction the first question — why? — has no answer, and a flag you cannot explain is a flag people learn to dismiss.
So what runs is a set of explicit rules, each with a stated definition and a threshold you can see. When something is flagged you know exactly why, which means you can either fix it or change the threshold. Both are progress; a mysterious alert is neither.
What the pricing radar watches
The first cluster is about margin, because margin errors are silent by nature. Nothing fails. The sale goes through, the customer is happy, the cashier has no idea, and the loss only appears in a month-end figure that gets explained as "a slow month".
| Signal | What it means | Usual root cause |
|---|---|---|
| Selling below cost | The selling price is lower than the recorded cost of the item | A cost update after a price rise, or an old price left on a new supplier's stock |
| Thin margin | The margin is positive but far below where it should be | Landed costs never added — freight and duty absorbed silently |
| Missing selling price | An item has no price at all | A new item created in a hurry, usually during a stock intake |
None of these is exotic and all three are common. The below-cost case in particular has a characteristic shape in import-heavy businesses: the goods cost more once landed, the cost field was updated, the price list was not, and every subsequent sale loses money enthusiastically. The arithmetic behind that gap is worked through in landed cost.
Selling below cost never fails. The sale completes, the customer is delighted, and the only evidence is a month-end figure somebody explains as a slow month.
What the financial radar watches
The second cluster is about size. An expense entry is compared against the recent average for expense accounts, and entries that sit well above that average are surfaced with the deviation shown as a percentage.
This is intentionally crude, and it is worth being clear about what crude means here. A large entry is not suspicious — most large entries are rent, salaries or a legitimate bulk purchase. What the radar gives you is a short list of the biggest departures from your own normal in the last month, which takes about ninety seconds to read and occasionally contains something you would not have found for a quarter.
The threshold is a multiplier you control
The comparison is against your own recent average, scaled by a multiplier you can set. Raise it in a business with genuinely lumpy expenses; lower it where spending is regular and you want tighter attention. A threshold that flags everything and a threshold that flags nothing fail in exactly the same way — nobody reads the output.
The standing operational alerts
Alongside the two radars there is a set of operational alerts that answer the questions a diligent manager would ask every morning if they had time — and that nobody asks on the mornings that matter.
- Low stock — items under their threshold now.
- Stockout risk — items whose cover runs out inside a week at current velocity.
- Overdue invoices — receivables past their due date, with a grace period you set.
- Delayed purchase orders — orders that should have arrived and have not.
- Pending adjustments — stock changes awaiting an approval that nobody has given.
- Margin risk items — the pricing radar surfaced next to everything else that needs a decision.
The pending-adjustments alert is the sleeper. An adjustment waiting for approval is a discrepancy that somebody has already noticed and nobody has resolved, and the longer it waits the less recoverable the explanation becomes. In most organizations that queue is the single best indicator of whether stock control is actually being run.
The failure mode: alerts nobody reads
Every alerting feature dies the same death. It is switched on, it produces forty items on day one because the backlog of real problems is forty items deep, everybody agrees it is very useful, nobody clears it, and within a month the badge with a number on it has become part of the furniture.
-
Clear the backlog before you start watching
The first run is a stocktake of accumulated problems, not a daily signal. Work it to zero once — it is usually one focused afternoon — and only then treat new items as news.
-
Give each signal an owner by name
Margin items belong to whoever sets prices; overdue invoices to whoever chases; pending adjustments to the stock controller. An alert owned by "the team" is owned by nobody.
-
Tune thresholds until the daily list is short
A list of three that gets actioned beats a list of forty that gets scrolled past. If a rule always fires for a good reason, the rule is wrong for your business — change the threshold rather than training people to ignore it.
-
Review the rules quarterly
Thresholds that were right at twenty staff are wrong at sixty. This takes ten minutes and is the difference between a system that stays useful and one that quietly stops being read.
What we do and do not do
What AWRA OpsHub does today
- A pricing radar flagging below-cost sales, thin margins and items with no selling price, cached and refreshable.
- A financial radar surfacing the largest recent expense entries against your own average, with the deviation shown.
- Standing operational alerts for low stock, seven-day stockout risk, overdue invoices, delayed purchase orders, pending adjustments and margin risk.
- Procurement risk signals including spend concentration and suppliers whose reliability is declining.
- Thresholds you control — grace days, multipliers and sensitivities live in your AI settings rather than in our code.
- A plain-language narrative over the computed signals where an AI provider is configured.
What it does not do
- No learned baseline of "normal" for your business. Every rule is an explicit definition against a threshold, not a model of your behaviour.
- No duplicate-payment or duplicate-invoice detection. That is a distinct control and it is not what these radars do.
- No behavioural fraud detection. Nothing watches for unusual patterns of user activity, and the audit log is not monitored by a rule engine.
- No per-signal alert routing. Signals appear where they are surfaced in the product; there is no rule that pages a named person when a specific threshold trips.
Read the second and third lines carefully if you are buying with fraud in mind. What these tools reliably catch is error — mispriced items, unlanded costs, unapproved adjustments — which is where most of the money actually goes.
Error is the bigger number anyway
Businesses tend to buy detection because they are worried about theft, and then find that the value arrives somewhere else entirely. Deliberate theft in a small business is usually a handful of incidents. Systematic error — a below-cost price running for four months, freight never landed onto cost, adjustments approved by nobody — runs continuously, affects every transaction it touches, and nobody is hiding it.
Which is the honest argument for a radar built out of visible rules rather than clever inference. You are not hunting a person. You are looking for the settings that quietly went wrong, and for those, a rule with a threshold you can read beats a model you cannot.
Our take
Clear the first backlog in one sitting, give each signal a named owner, and tune the thresholds until the daily list is short enough that someone genuinely reads it. Expect the returns to come from pricing and cost errors rather than from catching anyone — that is where the money is, and it is the part these rules are actually good at.
See the predictive radar and smart alerts
Pricing and financial anomaly radars, seven-day stockout risk, overdue receivables, delayed orders and pending approvals — with thresholds in your hands.
Explore the radarFrequently asked questions
Is this AI or is it rules?
Rules, with explicit thresholds — and we would rather say so than borrow the word. Every signal has a definition you can read: below cost means price under cost, stockout risk means less than seven days of cover, a large expense means above your own recent average by a multiplier you set. Where an AI provider is configured it writes a plain-language summary over those computed signals, but it does not decide what is anomalous. The advantage is that when something is flagged you can always answer "why", which is what makes it actionable.
Will it catch fraud?
Sometimes, indirectly, and it is not designed to. There is no behavioural monitoring of user activity and no rule engine watching the audit log. What it reliably catches is error — mispriced items, costs never landed, adjustments sitting unapproved — and in most small businesses that is a far larger number than theft. For fraud specifically, segregation of duties and a monthly read of the audit log do more than any radar.
How do we stop it becoming noise?
Clear the initial backlog in one sitting so you are looking at news rather than history, then tune thresholds until the daily list is short. The test is simple: if a signal fires most days for a legitimate reason, the threshold is wrong for your business and the honest fix is to change it. Training people to ignore a category of alert is the failure mode, and once it happens it applies to the alerts that matter too.
Why does it keep flagging our promotional items as thin margin?
Because on the numbers they are, and the rule cannot know a deliberate loss-leader from an accidental one — that context lives with you. If a promotion is running, either accept the flags for its duration or lift the threshold temporarily. It is worth noticing how often "that one is deliberate" turns out to be true for two items and news for the third.
Can we get alerted when a specific threshold trips?
Not as per-signal routing to a named person — signals surface where they are shown in the product rather than paging someone. In practice the workable pattern is a scheduled report or a standing five-minute morning review by the owner of each signal. If genuine routing matters to you, that is an automation question worth raising during evaluation rather than an assumption to carry into it.
