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
The supplier's purchase history, read with _search, gives its typical amount. The demo counts how many of the supplier's past POs were at least as large as this one, smoothed so that "none" is not zero, and scores the row (1 − p) × 100; 85 and above is high severity. The flag shows the supplier's average, the actual amount, and the ratio between them. There is no Aito prediction in the score; the history is the model.
The mechanism handles supplier diversity automatically. A supplier whose amounts span widely has many past POs at large amounts; one-off large invoices don't trigger false positives. A supplier whose amounts are tight has none; even moderate deviations surface. The threshold is conditional on the supplier's own pattern.
{
"from": "purchases",
"where": {
"supplier": "Neste Oyj"
},
"limit": 50000
}
// The supplier's whole purchase history. With n past POs, k of them
// at least this amount: p = (k + 1) / (n + 1), score = (1 - p) * 100.
// Neste: €9,800 against a €2,987 average, k = 0 of n = 477 → score 100.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.
Frequently asked
What is the false-positive rate of amount-spike detection?
The false-positive rate at a given threshold depends on how regular the vendor's amounts are; measure it on history before choosing the threshold. 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, and once confirmed spikes are in the history, a similar amount from the same supplier is no longer rare and scores lower.
How does this handle currency conversion or multi-currency suppliers?
Currency is a condition in the where clause; the comparison is per currency. For suppliers invoicing in multiple currencies, each currency has its own history to compare against. Conversion-rate fluctuations show up as a wider spread of amounts, not as anomalies.
Can the spike detection use external benchmarks (market price data)?
Yes — add the external benchmark as a column or join and compare against it as well as against the supplier's own history. "Above benchmark by X% AND rare for this supplier" 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.
