Expense report anomaly detection: what actually works without an employee-level history
Per-employee spending history sounds like the obvious way to catch inflated expense reports. Here is what a system can honestly detect before that tracking exists — and why it's still worth building.
The pitch for expense-fraud detection often goes straight to "we compare this expense against the employee's history." It's a good idea — and it requires a system to actually know WHO submitted a given expense, which is a specific piece of tracking that many document-processing pipelines don't have, because the document itself (a receipt, an expense claim) usually doesn't carry a reliable "submitted by" field the way an invoice carries a vendor name. Building that tracking properly is its own project. Here's what's honestly detectable before it exists — and it's more than nothing.
Category-level anomaly detection, without needing a name
Even without knowing which specific person submitted an expense, a system can categorize it — meals, lodging, transport, supplies — from the merchant name alone, using keyword matching that requires no additional data entry. Once expenses are categorized, comparing a new expense's amount to the account's own historical median FOR THAT CATEGORY is a real, useful signal: a $45 lunch against a $30 median for meals isn't remarkable; a $450 lunch against that same median is exactly the kind of outlier worth a second look, independent of who submitted it.
Round-number detection
Expense amounts that fall suspiciously often on exact multiples of a round number — $100.00, $150.00, $200.00 — are a real, well-documented signal in fraud literature: genuine receipts rarely land on perfectly round figures, while a reconstructed-from-memory or fabricated expense often does, because a person estimating an amount tends toward round numbers in a way an actual point-of-sale transaction doesn't. This check requires no history at all — it evaluates a single expense against a simple, math-only pattern.
Threshold-evasion detection
A reimbursement policy with an approval cap creates a predictable incentive: submit just under the cap rather than over it, to avoid triggering extra approval. An expense sitting suspiciously close to — but just under — a configured cap is a recognized pattern worth flagging on its own, and again requires no per-employee history to detect, just the cap itself and the submitted amount.
What these three checks do NOT catch
They don't catch a genuinely fabricated receipt for a real, reasonably-priced item — nothing about a $40, non-round meal expense at a real restaurant looks anomalous on any of these three checks, even if the meal never happened. Category-median and round-number checks catch STATISTICAL outliers, not every instance of fraud; a careful fabrication that mimics normal spending patterns is a different problem, one that genuinely does need either per-employee history, corroborating evidence (a calendar entry, a corporate card feed), or a human who happens to know the circumstances.
Why building the simpler version first is still the right call
A system that waits to ship expense controls until it has full per-employee tracking ships nothing in the meantime — and category-level anomaly detection, round-number flagging, and threshold-evasion detection are all real, statistically grounded checks that catch a meaningful share of the more common (and less sophisticated) patterns, without requiring the larger data-model investment first. The honest position is describing exactly what's detected and what isn't, rather than describing the aspirational full system as if it were already built.
| Check | Needs a name attached to the expense? | Needs history? | Catches |
|-------|------------------------------------------|-----------------|---------|
| Category-median anomaly | No — merchant-name keyword match only | Yes, 5+ comparable expenses | Amounts well outside the account's own norm for that category |
| Round-number detection | No | No | Amounts suspiciously landing on exact round figures |
| Threshold-evasion detection | No | No | Amounts sitting just under an approval cap |
| Per-employee history (not yet built) | Yes | Yes | A pattern specific to one person's behavior |
Related reading
- Detecting invoice fraud: what AI actually sees and your team misses
- How a document trust score actually works: what passes, what fails, and why
FAQ
Is category-level detection less useful than per-employee detection would be?
It's less precise — a per-employee baseline would catch a pattern specific to one person's behavior that a category-wide median might miss — but it's still a real signal, not a placeholder. The two aren't mutually exclusive; a mature system layers per-employee tracking on top of category-level checks once that data exists, rather than replacing one with the other.
How many historical expenses are needed before category-median comparison is meaningful?
Comparing against a thin history produces noisy, unreliable medians — a defensible system requires a minimum sample size (several comparable expenses in that category) before it will flag anything on this basis, and stays silent rather than flagging on statistically meaningless data.
Does round-number detection produce a lot of false positives?
It can, on categories where round numbers are genuinely common for legitimate reasons (a $50 parking pass, a flat-rate service fee) — which is why it should be treated as a low-confidence, worth-a-glance signal rather than an automatic rejection, distinct from a higher-confidence flag like an invalid legal identifier.