Duplicate payments
Not just matching invoice numbers — a statement re-sent as an invoice, a vendor changing numbering mid-year, the same work billed under two group entities.
AI capability
A threshold rule catches transactions over $10,000. It misses the vendor whose monthly invoice has crept up eleven percent over two years, the duplicate that arrived with a different invoice number, and the account pairing that has never occurred before. Those are the ones that cost money, and they are only visible against your own history.
What it does
Not just matching invoice numbers — a statement re-sent as an invoice, a vendor changing numbering mid-year, the same work billed under two group entities.
A vendor whose unit price has moved above the agreed schedule gradually enough that no single invoice looks wrong. Compared against the contract every time.
A debit and credit combination that has never occurred in your ledger before. Frequently a keying error, occasionally something more interesting.
A new vendor sharing bank details with an existing one, a remit-to that changed this month, or an address matching an employee record.
Spend clustering just under an approval threshold, invoices always arriving on the last day of a period, or activity outside normal hours.
A 3% variance on $2M matters more than 40% on $400. Flags are ranked by amount at risk rather than by percentage deviation.
Almost every finance function has a rule that routes transactions over some amount to a reviewer. It is a reasonable control and it is calibrated to the wrong variable, because size and irregularity are only loosely related.
The expensive errors we find in engagements are rarely large single transactions. They are a duplicate paid eight months ago, a rate that drifted, a recurring charge for a service cancelled in the spring, a subscription renewing for seats nobody uses. Each is individually below any sensible threshold and collectively material.
A flag that says "this looks unusual" is an interruption. A flag that says "this vendor has invoiced between $3,900 and $4,300 monthly for nineteen months; this one is $6,740" is a decision someone can make in four seconds.
So every flag carries the baseline it was measured against and the specific deviation. That also makes the detector auditable — you can disagree with a flag and see exactly why it fired, which is what stops the list from becoming noise people stop reading.
We are asked whether this catches fraud, and the honest answer is: sometimes, incidentally, and you should not buy it for that. The patterns it detects — duplicate vendors, bank detail changes, threshold-adjacent clustering — do overlap with common fraud schemes, and surfacing them has real value.
But an insider constructing transactions to resemble normal activity is specifically defeating the mechanism this uses. Segregation of duties, approval controls, and payment release remaining human are the actual fraud controls, and anomaly detection is a supplement rather than a substitute.
Limits
Every capability page on this site carries one of these, because a feature described without its boundaries is a claim rather than a description.
It detects the unusual, which catches error far more often than intent. Fraud deliberately constructed to look routine will look routine, and we would rather say that than have you rely on it.
Anomaly is defined against a baseline. In the first two months there is not much baseline, so it is quieter and less useful than it will be in month six.
A genuinely unusual but legitimate transaction gets flagged. We report the flag-to-action ratio rather than hiding it, because a detector nobody trusts gets ignored.
Questions
A year of AP detail is enough to show you duplicates, drift, and irregularities you have already paid for.