Three Alarms and the Cost They Use
There is an anomaly detector in this product and everything it watches is a price: items selling below cost, items under a five per cent margin, and items priced at nothing. It refreshes every fifteen minutes. And the cost it compares against is not the cost your ledger uses.
Most pricing errors are not decisions. They are a decimal point, a cost that moved, or a line somebody forgot in a repricing pass. They are invisible individually and expensive in aggregate, which is exactly the shape a detector is for.
We have one. It is worth knowing precisely what it looks at, because two of its three tests are more useful than they first appear and one detail underneath all three is worth understanding.
The three tests
Below cost. Items whose selling price is lower than their cost, ordered worst first. Flagged high severity whenever there is one, which is right — this is not a warning, it is a business selling at a loss without meaning to.
Thin margin. Items priced at or above cost but with a margin under five per cent, ordered thinnest first. Flagged medium. The threshold is fixed rather than configurable.
Zero price. Items whose selling price is missing or zero. The classic outcome of a bulk import or a mistyped edit, and the one that will be discovered by a customer if it is not discovered by this.
The whole radar is cached for fifteen minutes per organisation, so it is cheap to look at repeatedly and it is not real-time. Fifteen minutes is the right order of magnitude for a pricing problem.
Three tests, all about price, one of them ordered worst-first so the list is useful before you have read it.
The cost it compares against
This is the detail worth taking away, and it is not obvious from any screen.
All three tests compare the selling price against the item's buying price — the last purchase price recorded on the item master.
Everything else in the product that talks about cost uses a different figure: the weighted average cost, falling back to the buying price only where an item has never been costed. That is what the point-of-sale journal posts, what margin analytics computes on, what the accounting integrity check reconciles against, and what stock is valued at.
So the alarm and the ledger can disagree, and they disagree in a predictable direction.
| Situation | Buying price | Weighted average | What the radar does |
|---|---|---|---|
| Prices stable, stock turning | Close together | Close together | Agrees with the ledger |
| You just bought at a higher price | Jumps immediately | Rises gradually | Flags items the ledger still shows as profitable |
| You just bought at a lower price | Drops immediately | Falls gradually | Misses items the ledger shows as thin |
| Item never purchased in this system | Whatever was typed | Zero, so the fallback applies | Both use the same figure |
| Old stock, new purchase price | Reflects the new price | Reflects what you actually hold | Warns early, which is arguably right |
The second row is not necessarily a defect. An early warning against the replacement price is, for a business that has to buy the stock again, arguably the more useful signal. But it is a different question from the one the ledger answers, and you should know which one you are looking at.
Why a Malian trader gets more value from this than most
Because in a trading business with long, expensive resupply, the cost that matters commercially is what it will cost to replace the item, not what the one on the shelf cost you.
Read that way, the radar is pointed at exactly the right number by accident. An item whose replacement cost has risen above its selling price is one you should stop selling at that price today, regardless of what the stock on the floor originally cost.
Which makes the practical advice unusually simple: keep buying prices current and the radar becomes a replacement-cost alarm, which is the alarm a trader actually wants. Let buying prices go stale and it becomes noise — and it will also degrade the weighted average, because the fallback for an uncosted item is the buying price.
What it does not watch
Everything that is not a price on an item.
It does not look at stock leaving the building — no write-off pattern, no unusual user, no reason code spiking. That is argued in full in Nothing Watches the Write-Off, and it is the largest thing missing.
It also does not know about customers. A price given to one customer that is far below what everybody else pays is not an anomaly here, because there is no expected price per customer for it to be below — see One Price for Everybody. And it does not look at discounts at the till, which are recorded as amounts with a free-text description and no reason code.
What AWRA OpsHub does today
- Three pricing checks per organisation — below cost, margin under five per cent, and missing or zero price — with severity and worst-first ordering.
- Cached for fifteen minutes, so it is cheap to consult and not real-time.
- A single cost basis shared by the point of sale, the journal, margin analytics and the stock integrity check, so those four cannot disagree with each other.
What it does not do
- Any configuration. The five per cent threshold is fixed and the three checks cannot be turned off or added to.
- Comparison against the weighted average cost. All three checks use the item master's buying price.
- Any detection on stock movement, write-offs, discounts or customer-level pricing.
- Alerting. The radar is a screen you visit, not a notification that finds you.
- History. It reports the current state; nothing records what it said last week.
Not ours, by choice
- Comparing against the buying price is a difference from the ledger rather than an error, and for a trader it is arguably the more useful comparison. Know which question you are asking.
- A radar nobody opens is worth nothing. This is a screen, not an alert, and the difference decides whether it works.
- Nothing here is Malian. It is what a replacement-cost signal is worth; long expensive resupply is where it is worth the most.
What is not built for the CFA franc zone today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in the CFA franc zone. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a national e-invoicing pipeline, a French interface, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
National tax pipelines and a clean handoff to your ledger
Electronic invoicing against your administration's published interface, and a defined monthly export mapped to your expert-comptable's chart of accounts — with retries, a failure queue and a reconciliation report rather than a black box. The statutory ledger itself stays with them, by design; what we build is the pipe to it.
Mobile money, banks and French interface
Wave, Orange Money and bank statement feeds into the Payments Register, plus French interface text and document templates.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
National income tax and social security schedules produced in the layout your filing body expects, generated from live payroll records rather than rebuilt each month.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedOur position
Keep buying prices current and open the radar the day after every repricing pass. Those two habits together turn three fixed tests into a genuine replacement-cost alarm, and they also improve the weighted average cost that everything else in the product depends on. Do not expect it to find anything that is not a price on an item — it will not, and it is not trying to.
Three questions about any anomaly detection
Which cost figure does "below cost" use?
A good answer sounds like
A named field, and how it relates to the ledger.
What it actually means
Ours uses the buying price while the ledger uses the weighted average. Two definitions of cost in one product is normal and worth knowing about.
Is it a screen or an alert?
A good answer sounds like
One or the other, plainly.
What it actually means
Ours is a screen. A detector nobody is pushed towards is found by whoever was already looking, which is the person who least needed it.
Can I change the thresholds?
A good answer sounds like
Yes, per organisation.
What it actually means
Ours cannot. Five per cent is right for some catalogues and absurd for others, and a fixed threshold means the list is either empty or unusable.
Open the radar after your next price change
The day after, not the week after. It is the only automated check on a repricing pass, and its findings are most interpretable while you still remember what you changed.
Review your pricingFrequently asked questions
Why does an item show as below cost when my margin report says otherwise?
Because they use different cost figures. The radar compares against the item's buying price; margin analytics and the ledger use the weighted average cost. After a purchase at a higher price the two diverge until the average catches up, and the radar is warning you about the replacement cost.
Can I be emailed when something appears?
Not from the radar itself — it is a screen refreshed every fifteen minutes rather than an alerting job. The practical substitute is a habit: check it after every price change and once a week otherwise.
What if five per cent is the wrong threshold for my business?
Then the thin-margin list will be either empty or overwhelming, and there is no setting to adjust it. Use the below-cost and zero-price lists, which are unambiguous at any margin structure, and treat the thin-margin list as a rough sort rather than a definition.
