The problem
Unknown-vendor detection is the slowest fraud and shadow-spend pattern to surface in a typical AP system. A new vendor is added; one or two invoices go through; nobody notices for months until quarterly vendor-review surfaces an unfamiliar name. By then there's a vendor-master entry, several posted invoices, and possibly a small expense pattern that bypassed procurement.
The signal is available at entry time. A vendor with no prior history in the database is, by definition, unknown. A lookup finds no prior purchase; the system says "first PO from this vendor." That should be a flag at entry, not a discovery at quarterly review.
How it works
The check is a lookup against the purchase history: a supplier with no prior PO is unknown by definition. In a deployment the same absence shows up as low-confidence predictions on the entry, since there is no history to condition on. Either way the PO is flagged for manual review.
The mechanism composes with the broader anomaly pattern. Inverse-prediction anomaly catches misrouted invoices from known vendors; unknown-vendor anomaly catches the rest. Together they form the anomaly trio (with amount-spike), shown in one view and scored on one scale: (1 − p) × 100, where p is how likely the history makes the flagged value. For a first-time vendor, p is 1 / (N + 1) over all N purchases on file.
{
"from": "purchases",
"where": {
"supplier": "Harjula Consulting"
},
"limit": 1
}
// total = 0 → first PO from this vendor. A vendor with any history
// is not flagged here. p = 1 / (N + 1) over all N purchases on file,
// score = (1 - p) * 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
How is this different from a procurement-policy vendor-master rule?
Procurement policy enforces "new vendors require approval before first invoice." Unknown-vendor detection enforces "first invoice from any vendor surfaces for review, regardless of whether the vendor was pre-approved." The two layers compose; the unknown-vendor detection catches the edge cases where the policy was bypassed.
Does this work in multi-tenant deployments?
Yes. Conditional probability is scoped per tenant via customer_id. A vendor known to one tenant is treated as unknown to another tenant the first time it appears there. Multi-tenant accounting deployments at accounting.aito.ai run this pattern across 255 tenants.
What threshold defines "unknown" vs "low-confidence-known"?
In the ERP demo, unknown means no purchase on file names the vendor; one prior purchase makes it known. A deployment can add a confidence bar on the entry's predictions for vendors with thin history; measure where to set it on your own data.
Can the detection be tuned per category or amount?
Yes. Stricter thresholds for high-amount or high-stakes categories; looser for routine spend. "Unknown-vendor + amount > €5,000" is the strictest cell; "unknown-vendor + amount < €100" can be looser. Application-level configuration on top of the prediction.
Does the system learn from approved unknown-vendor cases?
Yes. Once the vendor's first invoice is approved and posted, the data enters the index and the vendor is no longer unknown. How quickly its predictions become confident depends on how regular its purchases are. The transition from unknown to known is automatic.
