Catch what internal control lists were designed to catch — before month-end does
Duplicate vendor masters, mis-classified expenses, invoices booked against cancelled GSTINs, cash-out-of-envelope events. The copilot runs the scans continuously and cites the exact vouchers it wants you to review.
AI anomaly detection watches your ERP data continuously and flags the specific patterns that lose Indian businesses money — duplicate vendor masters with fuzzy match on PAN and GSTIN, expense entries mis-classified against your own historical baseline, invoices booked against cancelled buyer GSTINs, cash movements outside the normal envelope for the ledger group. Every flag names the offending vouchers or DocTypes and proposes a concrete fix. Runs on TallyPrime through the on-prem bridge, on Zoho through Marketplace OAuth, on ERPNext through Frappe webhooks, and on custom ERPs through the mapped ingestion. Autonomous acknowledgement or write-back is off by default and gated per-role.
Last updated 2026-07-02 · Part of the AI Copilot for ERPs early access
What this capability does
The vendor paid twice this month, the expense mis-classified into the wrong ledger, the invoice booked against a cancelled GSTIN, the ₹28 lakh outflow that does not fit the ledger's history — anomalies rarely announce themselves. They surface at month-end when a controller reviews a variance, or worse, at year-end when a statutory auditor asks pointed questions. AI anomaly detection watches your ERP data continuously and flags these patterns as they emerge. On TallyPrime the scanner runs against ledger vouchers updated through the local bridge; on Zoho it consumes Books-side change events through Marketplace OAuth; on ERPNext it hooks into Frappe webhooks for Sales Invoice, Purchase Invoice, Payment Entry, and any Custom DocType you nominate. On custom ERPs the scanner runs against the mapped ingestion. Every flag names the offending voucher, ties it to a historical baseline it violates, and proposes a concrete resolution — merge the duplicate vendor masters keeping the higher-quality one, reclassify the expense to the correct ledger, re-issue the invoice against the corrected buyer GSTIN. Autonomous write-back is off by default. The copilot flags; a human reviewer approves before any change hits the ERP.
How it works
End to end, from question to grounded action.
Baseline learning
During the first 2–4 weeks the copilot builds a baseline from your own historical data — expense category distributions per ledger group, vendor payment cadence, cash movement envelope per bank account, GSTIN validity for every buyer and supplier. No baselines are shared across customers.
Continuous scan
As new vouchers land, the copilot compares them against the baseline. Duplicate vendor detection uses fuzzy match on PAN and GSTIN plus normalised name similarity. Expense anomalies compare against your ledger group's own historical distribution, not a generic peer set. GSTIN validity is checked against a rolling refresh of the cancellation registry.
Grounded alert
Each anomaly produces an alert naming the offending voucher, the historical baseline it violates, and a proposed resolution. Alerts route to the WhatsApp / Slack / email channel your ops or finance lead chose during onboarding.
Human-in-the-loop resolution
Autonomous write-back is off by default. A human reviewer approves, edits, or dismisses each alert. Approved resolutions can be pushed back into the ERP as a merge, a reclassification, or a re-issued voucher — every write logged as an ERPNext Communication, a Zoho Note, or a Tally voucher narration.
How this shows up on each ERP
Same capability, tuned to each ERP's data model.
Runs against the on-prem bridge. Fuzzy vendor matching against your party master; expense anomalies scoped per Tally ledger group and per company. Multi-company installations get separate baselines per company.
Consumes Books change events through Marketplace OAuth. Cross-module anomalies — an unusual Books expense with no matching Zoho Inventory receipt, or a CRM deal closed at a discount larger than your historical envelope — are surfaced as first-class flags.
Frappe webhook stream drives continuous scanning. Manufacturing anomalies (Work Order BOM consumption vs baseline) and Selling-cycle anomalies (invoicing lag against production) run alongside the standard expense and vendor scans.
Baselines learn from the fields you exported during onboarding. Schema-drift alerts protect the anomaly workload — if a mapped field is renamed, the scan pauses until you remap rather than firing false flags.
What this looks like in practice
Real question-and-answer patterns from pilot deployments.
“Detected: vendor "Kumar Traders" (GSTIN 27ABCPT1234M1Z9) and "Kumar & Sons Traders" (GSTIN 27ABCPT1234M1Z9) share a GSTIN.”
Two party masters with the same GSTIN and 4 paid vouchers across both. Recommended fix: merge into "Kumar Traders" (higher voucher count, cleaner address). Draft merge voucher is ready for your approval.
“Detected: expense ₹4.8 lakh booked to "Office Supplies" — 34× your rolling 6-month median for this ledger.”
Voucher #EXP/2026/1108 dated 3 July. Suggested reclassification: "Capex — IT Equipment" based on line-item description ("bulk laptop purchase") and vendor category. One-click reclassification queued for your review.
“Detected: Sales Invoice against buyer GSTIN 07AABCT1332M1Z9 — GSTIN status "cancelled" since 12 June 2026.”
Invoice SI-2026-1234 posted 24 July for ₹6.2 lakh. Two more invoices to this buyer in draft. Recommended fix: pause the drafts, contact the buyer for their active GSTIN, or move existing invoice to B2C-Large if the buyer is a consumer.
Why this matters
Caught before month-end
Continuous scan, not batch overnight.
Cites the offending voucher
Every alert names the exact record and the fix.
Trained on your history
Baselines learn from your ledger, not other customers.
Off-by-default write-back
Autonomous fixes disabled until you approve each one.
Frequently asked questions
How is this different from ERPNext's built-in duplicate check?+
ERPNext's built-in duplicate check compares whole-string matches on specific fields (Naming Series, exact vendor name). The AI Copilot layer runs fuzzy match on PAN and GSTIN with normalised name similarity — it catches "Kumar Traders" vs "Kumar & Sons Traders" sharing a GSTIN, which the exact-match rule misses. It also correlates expense anomalies across your ledger history, which no rule-based check does.
Won't I get flooded with false positives during the baseline window?+
The scanner runs in shadow mode during the 2–4 week baseline window. Flags are visible in the dashboard for your review but no alerts are sent to WhatsApp / Slack / email. During shadow you calibrate the sensitivity per anomaly type. Live alerts only start once your ops lead signs off. Pilot customers typically start with duplicate-vendor and cancelled-GSTIN alerts live, and hold expense anomalies in shadow for one more cycle.
How does the GSTIN cancellation check work?+
The copilot maintains a rolling refresh of the GST portal's cancellation registry through the same integration used by our GST-Portal connectors. Every buyer GSTIN on new invoices is checked. If a buyer whose GSTIN was active at booking gets cancelled later, existing invoices to that buyer are flagged for review — this is the classic B2B ITC reversal trap that shows up at GSTR-2A reconciliation.
Does anomaly detection train on other customers' data?+
No. Every baseline is customer-specific and derived from your own historical ledgers. The model does not fine-tune on data from other customers, and none of your ledger content flows to a shared training set. This is a hard architectural constraint — pilot customers frequently ask because it matters to their internal control team, and we validate it in the DPA.
What about the alerts that turn out to be legitimate?+
Every dismissal is recorded — vendor "Kumar & Sons Traders" is genuinely a separate entity that happens to share a partner's GSTIN, or the ₹4.8 lakh expense is a real one-off capex. The copilot learns from dismissals — the same pattern is not re-flagged. Dismissal reasons are part of the audit trail so a statutory auditor can review why a flag was closed.
Can I add my own anomaly rules?+
Yes. On top of the built-in scans (duplicate vendor, expense envelope, GSTIN validity, cash movement envelope, Selling-cycle lag on ERPNext) you can define custom rules — say, any Purchase Order to a new vendor above ₹10 lakh, or any Payment Entry to a related party — through a rule editor in the ERPPlugs dashboard. Custom rules produce alerts through the same channels and follow the same human-in-the-loop write-back policy.
Related AI Copilot capabilities
Every capability composes with the others.
Available today on these ERPs
Each edition uses the same connectivity ERPPlugs already ships.
Want this capability running on your ERP?
Join the AI Copilot early-access pilot. We calibrate against your own data during the first 2–4 weeks and lock in early-adopter terms before general availability.
Join Early Access