Vendor V-20931
Reason codes and their weight
- Address matches an employee record+30
- Bank details changed 3 days after creation+25
- Orders split just below the approval limit+20
- The same user created the vendor and the receipts+15
Catch the payment before it leaves.
Most fraud and payment errors look normal one transaction at a time. CompliBear tests every vendor, invoice and payment against 750+ proven patterns, every day, and flags the risky ones in time for your next payment run.
MONEY LINEPayments stopped or recovered, measured invoice by invoice, with the evidence attached.
01The problem
Payment fraud hides in plain sight
01
Each case is expensive
The average fraud case costs an organisation USD 1.7 Mn (ACFE). Most of it goes out as ordinary-looking payments.
02
Tips find more fraud than controls
Tips from employees and others uncover more fraud than any control does (ACFE). By then, the money has usually gone.
03
Duplicates are rarely identical
An extra space in the invoice number, a changed date, a second vendor code. Exact-match checks miss them.
02Why now
Fraud got smarter, more collusive and more convincing
01
Tech-powered
77% of anti-fraud professionals saw deepfake social engineering rise in two years (ACFE and SAS). Forged documents made with generative tools are rising too.
02
Collusive
More than half of frauds involve two to five people working together (KPMG). Segregation of duties stops one person, not a group.
03
Convincing
USD 25.6 million left a company in 15 transfers after a video call in which the CFO and colleagues were deepfakes (Hong Kong, 2024). Every approval looked valid.
Fraudsters adopted smart technology in two years. Only a quarter of anti-fraud teams have. Audit is still sampling.
03What we check
What we check, on every payment
- Bank details changed shortly before a payment
- Duplicate invoices, including near matches (similar numbers, amounts and dates)
- Duplicate vendors sharing a bank account, tax ID or address
- Payments to dormant, blocked or one-time vendors
- Direct payments that bypass the purchase order process
- Invoices with no purchase order or goods receipt
- Orders split to stay under approval limits
- One user who can both create a vendor and pay it
- Unusual manual journal entries: weekends, round amounts, just below thresholds
- Travel and expense claims: duplicate receipts, personal spend and policy breaches (SAP Concur pack)
- Vendor–employee matches on bank account, address, phone or tax ID
- Vendors created and paid within 30 days
- Prices above the contract or above peer prices
- Quantity invoiced above quantity received
- Payments outside the normal payment runs
- The same user raised the order and posted the goods receipt
4:16
04Every scheme leaves a footprint
Every fraud scheme leaves a footprint in the data
| Scheme | Footprint in the data | Where it lives |
|---|---|---|
| Fictitious or shell vendor | Created, bank details changed and paid within days; shares a bank account or address with staff | Vendor master, change log, HR master |
| Kickbacks and bid rigging | Prices creep above contract; the same supplier always wins; awards just below approval limits | Purchase orders, contracts, approvals |
| Duplicate or inflated invoices | Same vendor and amount with an altered invoice number; quantity billed above quantity received | Invoices, goods receipts |
| Inventory and scrap theft | Scrap rates out of line by plant or shift; write-offs just before stock counts | Material movements, stock counts |
| Expense and payroll fraud | Weekend or leave-day claims, round amounts, exited employees still paid | Travel and expenses, payroll |
| Channel and revenue schemes | Credit notes after period end; rebates above agreement; distributor outliers | Billing, credit notes, rebate terms |
05How it works
- 01Connect
Vendor master, invoices, payments, T&E
- 02Screen
750+ patterns before each payment run
- 03Alert
Ranked by amount at risk, with the reason
- 04Resolve
Hold, release or investigate, in OATS
- 05Recover
Evidence for recovery with ForenCity
06Machine learning, explained
How a model ranks a vendor, and explains why
- 01Features
40+ measures per vendor: payment timing, price against peers, master-data changes, links to staff.
- 02Model
Unsupervised first, because confirmed fraud labels are rare; supervised once outcomes are recorded.
- 03Score
Every vendor ranked from 0 to 100, every day.
- 04Reason codes
The top drivers of each score, in plain words.
- 05Feedback
Reviewer decisions retrain the model every quarter.
A synthetic example.
07Proof
PROOF
USD 103.68 Mn+ fraud prevented and USD 46.44 Mn+ detected across our clients · Case study: SAP Concur fraud detection
08The offer
Start with a 24-month payments look-back
We run the full payments library over two years of your vendor master, invoices and payments. You see valued findings (duplicates, risky changes and control gaps) in six weeks, before you commit to the platform.
No obligation. Read-only access to your data. You keep every finding.
09FAQ
Will we drown in false alerts?
No. Every alert is scored and ranked by the money at risk, and each one explains why it fired. Your team’s decisions train the next run. Not noise. Signal.
Can it stop a payment before it goes out?
It flags risky items before the payment run so your team can hold them. Holding a payment automatically depends on your ERP set-up.
What if the money has already gone?
The look-back finds past losses. ForenCity, our digital forensics product, and our investigators help you build the evidence to recover them.
Do you cover travel and expense?
Yes. Our SAP Concur pack tests every claim against your policy and known patterns of misuse.
How much is leaving by mistake?
Two years of payments, checked in six weeks.