Catch the red flags before an auditor does
A deterministic, offline scan of your books for the classic anomalies an auditor looks for — duplicates, round-figure and backdated entries, weekend vouchers and unusual ITC — each finding traced to the exact document for review.
Bill #A-4821 from Verma Pharma entered twice — double ITC ₹18,400.
ITC ₹4,300 claimed with no supplier GSTIN on bill #P-7723.
Cash payment of exactly ₹1,00,000 — high-value round amount.
Voucher dated 12 May entered on 3 Jun (22 days later).
Live product UI — sample data.
Duplicates that cost you
Flags duplicate vendor masters (same GSTIN / PAN / name), the same payment made twice in a short window, and a bill number entered more than once — the classic double-ITC and double-payment leaks.
Manual-manipulation signals
Surfaces suspiciously round high-value amounts, vouchers entered long after their document date (backdating), and purchases or payments dated on weekends — the patterns manual manipulation leaves behind.
ITC you can’t safely claim
Catches input tax credit claimed with no supplier GSTIN or at an impossible GST rate, so a shaky claim is reviewed before it is filed.
What this actually means in practice
Seven rules run over vouchers and masters you already hold, each with a stated threshold you can change. Two vendor masters sharing a GSTIN, a PAN or an identical name are flagged as one supplier recorded twice. The same vendor paid the same amount twice inside a seven-day window is a probable double payment. A bill number entered more than once against a supplier is the double-ITC case, and the finding names the credit at stake.
Three more read the shape of the entry rather than its content. An amount at or above ten thousand rupees landing on an exact thousand is the fingerprint of a figure invented rather than transcribed. A voucher created more than thirty days after the date it carries is backdating, and the finding states the lag. A purchase or payment dated on a Saturday or Sunday is not wrong — it is simply worth a second look in a trade that does not work weekends.
No model is involved anywhere in this, and that is the design, not a limitation. Every finding is a rule you can read, applied to rows you can open, producing the same result on every run — which is exactly what you need when explaining a correction to an auditor. Findings are ranked by severity and then by rupee value, each carrying the document type and id behind it. The engine reports; it never reverses, cancels or corrects anything.
| Check | What it catches | Default threshold |
|---|---|---|
| Duplicate vendor | One supplier entered twice under a shared GSTIN, PAN or name | Exact match after normalising |
| Duplicate payment | The same vendor paid the same amount twice in quick succession | Within seven days |
| Duplicate bill | A supplier's bill number entered more than once, doubling ITC | Any repeat |
| Round figure | A high-value amount landing on an exact round number | ₹10,000 and above, exact ₹1,000 steps |
| Backdated entry | A voucher created long after the date printed on it | More than thirty days' lag |
| Weekend voucher | A purchase, payment or expense dated on a Saturday or Sunday | Any occurrence |
| Unusual ITC | Credit with no supplier GSTIN, or an impossible effective rate | Above the highest notified slab |
What’s included
- Duplicate vendor / payment / bill detection
- Round-figure high-value flags
- Backdated-entry detection
- Weekend voucher flags
- Unusual-ITC checks (no GSTIN / impossible rate)
- Severity-ranked, traced to the source document
- Runs offline — guidance for review, never auto-action
What it does not do
- · It flags candidates, not verdicts. Two genuine identical same-day bills exist, and a round-figure advance is often just a round-figure advance — every finding is for a person to confirm.
- · The scan reads what is in LekhaPro. Cash dealings never entered, or a second set of books kept elsewhere, are outside its reach entirely.
- · Thresholds are fixed rules, not learnt from your trade. A business that genuinely bills in round thousands will see round-figure flags that are simply its business.
- · It reports and ranks; it never reverses a payment, cancels an invoice or edits a master. Deterministic scanning is in every plan from ₹249; only the conversational layer that discusses it is Enterprise.
Frequently asked
Does this use AI or send my data anywhere?
No. Fraud detection is a set of deterministic rules that run entirely on your machine over the books you already have — no LLM, no internet, no third-party service. Every re-run yields the same findings.
What does it actually check?
Duplicate vendors (shared GSTIN/PAN/name), duplicate payments and duplicate bill numbers, suspiciously round high-value amounts, backdated vouchers, weekend-dated purchases and payments, and ITC claimed with no GSTIN or an impossible rate.
Will it change my data automatically?
Never. Every finding is guidance for review, linked to the exact document — you decide what to do. Nothing is auto-corrected or auto-posted.
Why flag weekend entries at all?
Because in most Indian trades the purchase and payment desks do not sit on a Sunday, so a bill dated then is either a genuine exception or a date typed to fit a story. The check is deliberately low severity and costs nothing to dismiss. A business that genuinely trades seven days — a chemist, a restaurant — can simply ignore that group.
Can I run this before a statutory audit?
That is the intended use. Run it over the year you are about to hand across, work the high-severity findings first, and correct what needs correcting while the vouchers are still yours to amend. What you cannot do is present a clean run as assurance — it checks the patterns listed here and nothing else, and it is no substitute for an audit.
What exactly is included in AI · deterministic?
duplicate vendor / payment / bill detection, round-figure high-value flags, backdated-entry detection, weekend voucher flags, unusual-ITC checks (no GSTIN / impossible rate) and severity-ranked, traced to the source document, and 1 more. Every item on that list is a working screen you can open in the trial rather than a capability described in the abstract.
How is ai · deterministic handled differently here?
It rests on duplicates that cost you, manual-manipulation signals and ITC you can’t safely claim. The distinction that matters is that these are structural rather than cosmetic — the behaviour is built into how records are posted, not layered on as a report you have to remember to run.
Does AI · deterministic work offline?
On the Desktop edition, yes — completely. duplicate vendor / payment / bill detection and round-figure high-value flags run against a local database on your own machine, so the screens behave the same with the network unplugged as with it connected. AI and billing are the only two things that reach out. On the Cloud edition ai · deterministic runs in the browser and needs a connection.
Does AI · deterministic post to the real books?
Yes, and that is the whole reason it lives in this product rather than beside it. What duplicates that cost you records lands in the same posted double-entry ledger the Trial Balance, P&L and GST returns are built from — so there is no second set of ai · deterministic numbers to reconcile against the first.
How does AI · deterministic affect my GST?
It feeds it directly rather than sitting alongside it. CGST/SGST and IGST are split from HSN or SAC and place of supply as each document is raised, so whatever ai · deterministic produces is already correct when GSTR-1, 3B and 2B reconciliation are drawn off the same books. The return matches the accounts because it was never a separate exercise.
Catch red flags before an auditor does
Vouchers are scanned for duplicates, round-number patterns and after-hours edits.
- ₹18,400Duplicate billVerma Supplies
- ₹12,800Round-number entries6 vouchers
- After-hours edits3 invoices
Illustrative — sample scan.