How do duplicate and anomaly detection work on AP data - and which anomalies actually matter?

Exact matching compares key fields (vendor, invoice number, amount, date) and catches the obvious resubmission - the same invoice entered twice. It misses everything with a small variation. Fuzzy matching tolerates differences: a transposed invoice number, a vendor entered under two records, an amount off by a rounding cent, or the same charge split into two lines. The trade-off is the false-positive rate - looser matching catches more real duplicates but flags more legitimate look-alikes (recurring monthly invoices, legitimate partial billings). Good systems run checks at multiple points in the lifecycle, not just at entry, because duplicates often arrive days apart.

Anomaly detection baselines normal behavior per vendor and category, then flags deviations: a unit price rising faster than history, invoices clustered just under an approval threshold (a split-to-avoid-review signal), unusual round numbers, or out-of-pattern submission timing. The failure mode is alert fatigue - fire too often and the team ignores everything, including the real ones. Tune by raising thresholds until the alert volume is something a human will actually investigate, prioritizing by dollars at risk, and suppressing the known-benign patterns (a vendor whose invoices are legitimately round). A credible alert program flags few things and is right most of the time; a noisy one trains the team to click "dismiss."

Match progressively: first exact (vendor + invoice number + amount), then relaxed (same vendor + amount within a window, ignoring invoice-number formatting), then fuzzy on vendor name to catch duplicate vendor records. Expect a high false-positive rate on the loosest pass - recurring invoices and legitimate partials dominate - so review candidates by dollar value first. A first audit on years of history commonly surfaces real recoveries; the value is in the recovery plus the control gap it reveals.

Recovery-audit literature commonly cites duplicate and erroneous payments in the range of a few hundredths of a percent up to roughly half a percent of disbursements, depending on control maturity and whether prevention runs at entry. Treat these as ranges, not promises - the rate depends entirely on how well duplicates are blocked before payment. The trend that matters is your own blocked-vs-paid ratio over time.

Track unit prices at line grain per vendor over time - quiet increases hide in line detail while the invoice total looks normal because quantities vary. Flag any line where unit price rose more than a threshold versus its trailing average for the same item or description. This requires line-item capture; header-only data can't see price creep because it never sees the price.

The pattern: multiple invoices from one vendor, close in time, each just under a threshold that one combined invoice would have exceeded. Detect by aggregating same-vendor invoices within a rolling window and comparing the sum to your thresholds. The control response is upstream - threshold logic that considers cumulative vendor activity, not just the single invoice - because detecting splits after payment only documents the problem.

For services, reconcile invoices against receiving or approval evidence - invoices with no corresponding receipt or sign-off in service categories are the candidates. For subscription waste, trend per-seat software invoices against headcount and flag where seats exceed active employees, then reconcile licenses to the current roster. Both are recurring scans, not one-time projects; the spend regenerates.

Rules are transparent, controllable, and easy to explain to auditors, but brittle - they catch only what you anticipated and need constant tuning. ML detection finds patterns you didn't specify but is harder to explain and prone to noisy false positives until tuned. Use rules for known, high-stakes patterns (threshold splitting, duplicate keys) where explainability matters, and ML as a supplement for the unknown-unknowns - with a human gate, because an unexplainable flag on a financial transaction is hard to action.

Benford's law (the expected frequency of leading digits in natural datasets) is a real screening tool for large invoice populations - deviations can indicate fabricated or manipulated amounts. It's a population-level smoke detector, not a per-invoice flag: useful for an annual analytical review or directing audit attention, not for catching a single bad invoice in the flow. Practical as one input among several, misleading if treated as proof on its own.

Stampli builds these signals into the invoice workflow rather than running them as a separate audit. Stampli AI flags duplicates, variances, and compliance risks proactively as part of processing - duplicate checks can run at multiple points in the lifecycle, and unusual-amount and new-vendor signals surface in context so AP applies scrutiny where exposure is highest instead of reviewing every invoice equally. Because the checks live where the work happens and every signal and resolution is captured on an immutable audit trail, the controls are both proactive and defensible.