The problem
Amount-spike anomalies are the easiest fraud and error pattern to describe and the hardest to catch with rules. "This Telia invoice is 30× the typical amount" is obvious in hindsight; at posting time, the AP clerk sees a four-digit number from a known supplier and doesn't think twice.
Static rules ("flag invoices above €10,000") catch the gross cases and miss the proportional anomalies — €1,200 from a supplier whose typical invoice is €30 is more suspicious than €1,200 from a supplier whose typical invoice is €1,000. The right threshold is conditional on the supplier and category, not absolute.
How it works
_estimate on amount conditioned on supplier × category returns the predicted amount band for this combination. The actual posted amount is compared. If it falls outside the predicted band at >85% confidence, surface as amount-spike anomaly with the predicted band, the actual amount, and the deviation factor.
The mechanism handles supplier diversity automatically. A supplier whose amounts span widely has a wide predicted band; one-off large invoices don't trigger false positives. A supplier whose amounts are tight has a narrow predicted band; even moderate deviations surface. The threshold is conditional on the supplier's own pattern.
{
"from": "invoices",
"where": {
"vendor": "Telia Finland Oyj",
"category": "telecom",
"month": "recent_12"
},
"estimate": "amount",
"select": ["$p", "$band_low", "$band_high"]
}For the full architecture, see the technology overview. For the broader narrative across multiple use cases, read The Predictive Application.
See it live
This use case runs in the 📋 ERP demo today. Click through to the live application and inspect the queries that produce the result. Source is on GitHub under Apache 2.0.
Frequently asked
What is the false-positive rate of amount-spike detection?
At >85% top-1 confidence and actual amount outside the predicted band, false positives sit in the 3-7% range on regular operational data. Tighter thresholds reduce false positives but miss subtler anomalies; looser thresholds flag more aggressively. Most deployments tune to balance reviewer workload.
Does this catch genuine business-event spikes (annual contract renewal, large one-off project)?
It surfaces them as anomalies; that's the correct behaviour. The reviewer confirms the spike as expected, the system records the confirmation, and similar future spikes for the same supplier × month pattern get higher predicted bands. Annual events with a year of history become predicted, not flagged.
How does this handle currency conversion or multi-currency suppliers?
Currency is a condition in the where clause; predicted band is per-currency. For suppliers invoicing in multiple currencies, the system maintains separate predicted bands. Conversion-rate fluctuations show up as wider bands, not as anomalies.
Can the spike detection use external benchmarks (market price data)?
Yes — add the external benchmark as a column or join. Predicted band conditions on benchmark price plus supplier × category history. "Above benchmark by X% AND outside supplier's typical band" is a stronger anomaly signal than either alone.
What is the typical time-to-detection?
Pre-posting. The anomaly check runs as part of the invoice-ingest pipeline; the amount-spike is flagged before the entry posts. Detection at posting time, remediation immediate — versus rule-based detection that often runs at month-end.
