Using Data Analytics to Detect Fraud in the Ledger: Benford's Law, Duplicate Tests and Journal-Entry Testing

Data analytics detects fraud in the ledger by testing every transaction, rather than a sample, against patterns that genuine business activity rarely produces. The most widely used tests are Benford's law analysis of digit frequencies, duplicate and near-duplicate payment tests, journal-entry testing, and matching the vendor master against the employee master. None of these proves fraud on its own; each narrows millions of records down to a manageable set of exceptions for an investigator to examine.

This post explains how each method works, what it can and cannot tell you, and how to use the results in an Indian investigation.

Why use analytics instead of sampling?

Statutory audits rely largely on samples because they aim at material misstatement. Fraud is deliberately hidden and often sits in small, repeated transactions that sampling is unlikely to pick up.

The ACFE's Occupational Fraud 2026: A Report to the Nations found that a typical fraud lasted 12 months before detection, and that a lack of internal controls was the primary weakness in 33% of cases, with override of existing controls in another 19%. Full-population analytics looks precisely for the footprints those weaknesses leave.

Before running any test, secure a complete extract, reconcile it to the trial balance and record how it was obtained. Analytics on incomplete data produces false comfort.

How does Benford's law work?

Benford's law describes the frequency of leading digits in many naturally occurring sets of numbers. Smaller leading digits occur far more often than larger ones. The expected proportion of numbers with first digit d is log10(1 + 1/d), which gives:

Frank Benford documented the pattern in 1938 across thousands of observations from unrelated sources. Invoice amounts, expense claims and payment values often follow it closely, because they result from multiplying quantities by prices across several orders of magnitude.

When is Benford analysis useful?

It works best on large populations (ideally thousands of records) of transaction amounts that span several orders of magnitude and are not assigned or capped. It is unsuitable for:

• assigned numbers such as invoice, cheque or employee numbers;
• data with built-in minimums or maximums, such as fixed allowances;
• small populations, where random variation dominates.

What do deviations mean?

Investigators usually go beyond the first digit to the first-two-digit test (10 to 99), which is more precise. Typical findings include:

• Spikes just below approval limits. If purchases above INR 50,000 need a second approval, an excess of amounts starting 48 and 49 may indicate split purchases or amounts set to stay under the limit.
• Excess round numbers in expense claims or journal entries, suggesting estimates or invented figures.
• Unusual distributions for a single user or vendor, compared with the population.

A deviation is a lead, not a finding. Pricing policies or recurring fixed fees can explain it. Each spike must be drilled down to transactions and documents.

How do duplicate tests work?

Duplicate payments can be errors or fraud: a vendor resubmits an invoice, or an insider pays the same invoice twice and diverts the second payment. Exact-match tests (same vendor, invoice number, amount and date) catch the simplest cases. Fraud usually requires fuzzier matching:

1. Same vendor, same amount, different invoice number within a short period.
2. Altered invoice numbers: "INV-1023", "INV1023", "1023A", or leading zeros removed. Normalising strings before matching catches these.
3. Same invoice number and amount, different vendor codes, often because the same supplier exists twice in the vendor master.
4. Same amount and date paid to different vendors sharing a bank account.
5. Split transactions: several payments to one vendor on the same day that together exceed an approval limit.

In India, matching on GSTIN and PAN alongside vendor name is especially effective, because names are often spelt inconsistently while tax identifiers should not be. Each match should then be checked against goods receipts and contracts.

What is journal-entry testing?

Journal entries are the route by which management can adjust the books outside routine processes. SA 240 treats the risk of management override of controls as present in every entity and requires auditors to test the appropriateness of journal entries. Forensic accountants apply the same logic more intensively.

Common criteria for selecting entries:

• Who: entries posted by senior staff who do not normally post, by generic or IT accounts, or by users who have left.
• When: entries posted on weekends, public holidays, late at night, or just before or after period close.
• Timing gaps: back-dated entries, where the posting date differs significantly from the document date.
• What: entries to rarely used accounts, suspense accounts, or revenue and cash accounts that normally receive only system entries.
• How much: round amounts, amounts just below thresholds, or unusually large entries.
• Description: blank, vague or repeated narrations such as "adjustment" or "as per discussion".
• Pattern: entries reversed shortly after period end, or the same entry recurring every quarter.

Each criterion produces exceptions; entries that hit several criteria at once deserve priority. Testing is most useful when combined with segregation of duties analysis showing who can create, approve and post entries.

Journal-entry anomalies often point to financial statement fraud. For how this fits into a wider investigation, see forensic audit vs statutory audit.

How does vendor-master and employee-master matching work?

This test compares the attributes of every vendor with every employee (and, where available, employees' declared relatives) to find links that should not exist. Fields to match:

Normalise addresses (remove punctuation, standardise abbreviations) and use fuzzy matching on names, as exact matches miss most real cases.

Related vendor-master tests include:

• vendors created and paid within days;
• vendors with no GSTIN, PAN or physical address;
• dormant vendors reactivated and paid shortly afterwards;
• frequent changes to a vendor's bank account, especially just before a payment run;
• vendors created and approved by the same user.

These tests target vendor fraud and asset misappropriation, and identify undisclosed conflicts of interest. For red flags across the purchasing cycle, see procurement fraud red flags.

What are the common pitfalls?

Analytics projects fail more often from poor preparation than from poor tests. Watch for:

• Incomplete extracts. Data that excludes a company code, a period or manual payments gives a misleading picture. Always reconcile to the ledger.
• Uncalibrated thresholds. Tests copied from another organisation can produce thousands of false positives. Tune parameters to your own approval limits and business patterns.
• Treating exceptions as findings. An exception is a question. Only documents, corroboration and explanations turn it into a finding.
• Tipping off. Running queries through the IT team of the function under review can alert the people involved. Restrict knowledge of the work to those who need it.
• Poor documentation. If the logic and parameters are not recorded, results cannot be reproduced or defended later in a dispute.

How should analytics results be used?

Analytics produces exceptions, which still have to be explained or proved from documents. A disciplined process:

1. Triage exceptions by value, number of tests hit and risk.
2. Document review for each priority exception: purchase orders, receipts, contracts, approvals.
3. Corroborate with email, registry searches and, where justified, interviews.
4. Record the logic of each test, parameters and results, so the work can be reproduced and defended.
5. Feed back into internal controls, for example by adding system blocks on duplicate invoice numbers.

Employee data used in matching should be limited to what the test needs and access-controlled. The Digital Personal Data Protection Act 2023 treats processing for employment purposes, including safeguarding the employer from loss, as a legitimate use, and most obligations under the DPDP Rules 2025 apply from about 13 May 2027.

Our guide to procurement fraud red flags covers the purchasing-cycle checks that complement these tests. Analytics is a core part of forensic accounting and of any forensic audit.

How Spectra Forensics can help

Our forensic accounting and data analytics service covers ERP data extraction and reconciliation, Benford and duplicate testing, journal-entry analysis, master-data matching and the follow-up work needed to turn exceptions into evidence. Where analytics points to misconduct, our fraud and whistleblower investigation team takes the matter forward. To discuss a data review, contact us.