Our thinking · Stage 03 · Detection
Fraud Analytics Should Start With a Hypothesis, Not a Dashboard
Dashboards of red flags generate noise that nobody follows up. How to build analytics around specific schemes, and turn exceptions into findings.
Spectra Forensics5 min read
The questions boards and CFOs ask
- 01
Which analytics tests should we run first?
Start with the schemes rated highest in your fraud risk assessment. For most companies that means vendor master data (duplicates, employee matches, recently created vendors receiving large payments), payments (duplicates, splits below approval limits, round amounts), manual journals (outside hours, by unusual users, to sensitive accounts) and sales-side adjustments (credit notes, discounts and scheme payouts by distributor).
- 02
Do we need specialist software?
Not to start. Most of the tests that matter can be run on ERP extracts with standard tools. What matters more is clean, complete data, a clear understanding of how the business records transactions, and people who can tell an anomaly from a quirk of the system.
- 03
How do we stop red flags from overwhelming the team?
Tune each test to your data before running it routinely, combine weak indicators into a risk score rather than reporting each one, set thresholds by materiality, and assign every exception to someone who must close it with a reason. Review the closure reasons periodically; they show which tests need refining.
- 04
Can analytics be used as evidence in an investigation?
Analytics usually points to where to look; the evidence is the underlying documents, records and interviews. Where analytics output is relied upon, the method, data source and extraction steps should be documented so that the work can be repeated and explained, and electronic records should be preserved in a way that supports a certificate under s. 63 of the Bharatiya Sakshya Adhiniyam 2023.
Fraud analytics is often sold as a dashboard: dozens of red-flag tests, run monthly, with exceptions highlighted in colour. In practice the first run produces thousands of exceptions, most of them explained by the way the business records transactions. The team clears a few, the rest age, and within a year nobody opens the dashboard.
The problem is not the technology. It is that the tests were chosen because they are standard, not because they look for something specific.
Why hypothesis-led analytics works
A useful test answers a question: "Is anyone in procurement splitting purchase orders to stay under their approval limit?" That question comes from the fraud risk assessment, which names the scheme, the process and the people who could commit it. It tells you what data to use, what a hit looks like and who must explain it.
A generic test, such as "transactions with round amounts", answers no particular question. It flags thousands of legitimate entries and a few that matter, with no way to tell them apart.
The prize is speed. The ACFE's Occupational Fraud 2026 report found that a typical fraud lasted 12 months before detection. Full-population analytics, aimed at the right schemes, can find the footprints much sooner.
What good looks like
1. Link each test to a scheme
For each high-rated scheme in the assessment, write the test that would detect it. Examples:
| Scheme | Test |
|---|---|
| Fictitious or connected vendor | Vendors sharing bank accounts, addresses, phone numbers or PAN details with employees or other vendors; vendors created and paid within a short period |
| Split purchases to avoid approval | Multiple orders to the same vendor on the same or adjacent days, each just below a limit |
| Duplicate payment | Same vendor, amount and invoice number, or near matches |
| Inflated distributor claims | Scheme claims growing faster than purchases; claims clustering just before period end |
| Manipulated results | Manual journals posted outside working hours, by unusual users or to revenue and provision accounts near period end |
| Inventory leakage | Write-offs and scrap sales concentrated by location, buyer or approver |
Our article on using data analytics to detect fraud in the ledger describes the standard techniques, including Benford's law, duplicate tests and journal-entry testing.
2. Understand the data before you trust it
Every ERP has quirks: dummy vendors for one-time payments, batch postings by system users, legacy codes from a migration. Run each test once, investigate a sample of exceptions with the process owner, and tune the logic. A test that has not been tuned will be ignored.
3. Score, do not just flag
Individually weak indicators, such as a new vendor, a round-sum invoice and an approval by the requester's manager, become meaningful together. Combining them into a simple risk score per vendor, distributor or employee focuses effort on the few that light up on several tests.
4. Make someone close every exception
Each exception needs an owner and a closure reason. Review the reasons quarterly. If most exceptions from a test are closed as "system behaviour", fix the test; if closures are vague, review them.
5. Escalate properly
When analytics finds something that looks like fraud rather than error, stop analysing and start preserving. Secure the data extracts, record how they were produced and bring in the people who will run the investigation. Electronic records relied on in proceedings will need to meet the conditions in s. 63 of the Bharatiya Sakshya Adhiniyam 2023, which is far easier if the chain of custody starts at extraction.
Decision points
- Continuous or periodic? Run payment and master data tests continuously where possible; run deeper tests on journals and claims quarterly.
- Internal or external? Internal audit can run routine tests; an external team adds value for initial design, tuning and investigation of hits involving senior people.
- Who sees the results? Exceptions involving senior management should go to internal audit and the audit committee, not to the line management concerned.
Common mistakes
- Starting with the tool. Buying software before deciding what to look for produces expensive dashboards.
- Too many tests. Fifty untuned tests are worse than ten good ones.
- No owner for exceptions. Unowned exceptions age into irrelevance.
- Analysing only payables. Revenue-side schemes, such as distributor claims, credit notes and discounts, are often larger and less tested.
- Treating a hit as a finding. An exception is a question. The answer comes from documents, people and context.
Where we can help
Our forensic accounting and data analytics team designs and tunes scheme-based tests, runs them on full populations and investigates the exceptions that matter. When findings depend on email and devices, our digital forensics team preserves and reviews them to evidential standards. Speak to us in confidence.
Sources
Newsletter
Get new insights by email
About one email a week with new articles on fraud, investigations and compliance in India. Unsubscribe with one click.
Our thinking