Nothing Watches the Write-Off
We built anomaly detection into this product. It watches for items selling below cost, on thin margins, or priced at zero — every one of them a question about money coming in. It has never once looked at stock going out, which is the direction things actually disappear in.
Somewhere in this product there is a service whose entire job is to notice when something looks wrong without anybody asking it to. It runs per organization, caches its results, and surfaces what it finds.
It watches three things: items being sold below what they cost, items on margins thin enough to be a mistake, and items priced at zero. Those are good things to watch. Each of them is a real error that occurs in real businesses and each is invisible until somebody adds up a month.
All three are about money arriving. None of them is about stock leaving. And stock leaving is the direction in which things are actually lost.
What a write-off pattern looks like, and why no single one shows it
Take any individual write-off in a busy operation and it will look reasonable, because it almost always is. Something broke. Something expired. A count was wrong and got corrected. Approve it and move on; the approver is right to.
Everything interesting about write-offs is in the aggregate, and specifically in comparisons that no one person is positioned to make. One warehouse writing off three times what a comparable one does. A reason code that was used eleven times last quarter and ninety this one. One person raising a share of the write-offs wildly out of proportion to the share of stock they handle. The same item written off repeatedly while nothing else in its category ever is. Losses clustering on a particular day of the week, or the week after a stock count.
No individual write-off is suspicious. That is precisely why the pattern is the only thing worth watching, and the pattern is what nothing computes.
Every one of those comparisons is computable from data we already hold. Adjustments carry a reason, a value, a location, a raiser, an approver and a date. Nothing is missing. The comparison has simply never been written.
Why we would rather frame this as detection than as theft
It is tempting to write about write-off monitoring as fraud detection, and we are going to avoid that, because it produces the wrong feature and insults most of the people it lands on.
The overwhelming majority of what a write-off pattern reveals is not dishonesty. It is a chiller that has been failing slowly for months. A supplier whose packaging changed and now arrives damaged. A picking face where two similar items sit next to each other. A conversion applied in one direction only, so every count of that item finds a shortfall that gets written off rather than investigated. A member of staff who was never properly trained on the receiving process and is quietly correcting their own errors.
Every one of those is worth finding, every one is fixable, and none of them is a person to be caught. A system that presents pattern detection as an accusation gets switched off by managers who like their teams. A system that presents it as "these four things are producing most of your losses" gets used.
Why this matters more across a spread-out group
Comparison is the mechanism, and comparison needs something to compare against. A single site has only itself and its own history. A group running warehouses and retail across several countries in this region has the one thing that makes anomaly detection actually work: peers. Sites doing the same job, at different scales, whose write-off rates should be broadly similar once you divide by throughput — and where a genuine outlier means something.
That is also exactly the structure in which no individual is positioned to notice. The branch manager sees their own numbers and has no idea whether they are high. The regional manager sees monthly totals in which a bad site is averaged with good ones. The comparison that would show it is one query, and nothing runs it.
What write-off monitoring should tell you, in the order we would build it
Every one of these is computable from data our adjustments already carry. None needs a new field.
Write-off value by site, as a share of stock handled
Make them prove it: Ask which of your locations is the outlier and by what multiple.
Reason codes trending against their own history
Make them prove it: Ask which reason is being used far more than last quarter.
Items written off repeatedly
Make them prove it: Ask which items were written off more than twice this year.
Concentration by person raising
Make them prove it: Ask for the distribution, not the list — and frame it as workload, not suspicion.
Timing clusters, particularly around counts
Make them prove it: Ask whether write-offs spike in the week after a stocktake.
Approver concentration
Make them prove it: Ask whether one approver clears most of the value.
The one on that list that catches the most and upsets the fewest
Reason codes trending against their own history. It needs no comparison between people, no peer group and no judgement about anybody — it just says this reason was used eleven times last quarter and ninety this one. Almost every real finding shows up there first, and it is impossible to read as an accusation, which is why it gets acted on rather than argued with.
Four questions about loss detection
Does your anomaly detection look at stock leaving, or only at pricing?
What a straight answer sounds like
A specific answer about scope. Ours is pricing only.
Why it matters
Anomaly detection is a checkbox on most feature lists. What it actually watches is never on the list.
Which of my sites writes off the most relative to what it handles?
What a straight answer sounds like
A ranked list. Ours cannot produce one.
Why it matters
Absolute totals always name your biggest site. The ratio is the only version that means anything.
Show me reason code usage this quarter against last.
What a straight answer sounds like
A comparison. Ours does not exist.
Why it matters
This single view catches most real findings and offends nobody, which makes it the best value in the whole category.
Will it alert me, or must I remember to look?
What a straight answer sounds like
Honesty about which. Ours requires you to look, and then to build it yourself.
Why it matters
A report nobody opens is the same as no report, which is the lesson our own dead stock scan was built on.
Two, and they are extensions rather than new machinery
The radar exists, runs and surfaces findings. Pointing it at a second class of data is a smaller job than building it was.
Write-off checks inside the existing radar
Rate by site against peers, reason codes against their own history, and repeat items. The service already handles running per organization, caching and presenting findings, so this is three new checks in a working frame rather than a new subsystem.
Normalisation by throughput
The part that makes site comparison honest. Without dividing by what a site actually handles, every comparison names your largest warehouse and is ignored within a month. This is the difference between a feature people trust and one they learn to dismiss.
We would present all of it as operational insight rather than as loss prevention. Same data, same findings, and it survives contact with the managers who have to act on it.
Talk to us about loss monitoringWhat AWRA OpsHub does today
- An anomaly radar, running per organization and cached, surfacing pricing problems without anybody running a report.
- Full adjustment data — reason, value, location, who raised it, who approved it, and when — on every write-off.
- Approval controls with separated duties above a value threshold you set.
- A dead stock scan that finds stock which has stopped moving, which is a related and genuinely automated detection.
What it does not do
- The anomaly radar never looks at stock movements. Its three checks are all about pricing.
- No comparison of write-off rates between locations, so an outlier site is invisible.
- No trend on reason codes, so a reason suddenly in heavy use looks exactly like one in steady use.
- No repeat-item view, so the same item written off every month is never surfaced.
- No concentration analysis by person raising or approving.
- No alerting on any of it — even the raw numbers must be assembled by hand from adjustment records.
Not ours, by choice
- Nothing here is a claim about any region or customer. Most write-off patterns are equipment, packaging, layout and training rather than dishonesty, and a vendor selling this as fraud detection is selling you a feature your managers will disable.
- We publish no shrinkage benchmark. What matters is your own sites compared with each other and with their own history, which needs no external figure.
The verdict
This is a scope failure rather than a missing capability, and those are the ones worth publishing because they are invisible on a feature list. We can honestly say the product has anomaly detection. What we should also say is that it is pointed entirely at pricing, and that the direction stock actually leaves in has nothing watching it at all. If you run several sites doing similar work, you have the raw material for the most valuable comparison in stock control and no way to run it inside the product today. Ask us — and everyone else — the scope question rather than the capability question. "Does it watch stock movements" is a different question from "do you have anomaly detection", and only one of them has a useful answer.
Send us a year of adjustments
From any system. We will run the site comparison, the reason trend and the repeat-item list by hand and show you what your own data says — which is a better argument for or against us than any demonstration.
Talk to us about stock losses