ERP data quality does not fail at go-live. It fails in the two to three years after, through predictable mechanisms that finance teams rarely measure. By the time a company tries to layer AI or automation on top, the master data is already unreliable. The cost shows up in ITC blocks, reconciliation gaps, and close cycle delays, not in an error log.
Most ERP implementations pass data quality checks at go-live. The migration team validates records, the consultant signs off, and the system goes live with clean data. Three years later, the same data is wrong. Master data decays when no one is responsible for ongoing maintenance, and in most mid-market finance functions, no one is.
The finance team that ran its close on that vendor master last month does not know this yet. The ERP does not tell them. It processes transactions against whatever records are present, with no opinion on whether those records are still valid.
How ERP Master Data Degrades After Go-Live
Three mechanisms account for most post-go-live data decay in Indian mid-market finance functions.
Vendor record accumulation without deactivation. Vendors are added for a project, a one-time purchase, or a workaround during a system constraint. The transaction completes. The record stays. In a finance function processing 400 to 800 vendors, dormant but active records accumulate over years. None are flagged by the ERP. They sit in the master, available for payment processing, GSTIN mismatches, and duplicate invoice matches.
GSTIN and compliance status drift. A vendor’s GSTIN status can change, through suspension, cancellation, or migration to a new entity, without any notification to the buyer’s finance team. MSME registration lapses when a business crosses the turnover threshold or simply fails to renew. The vendor master carries the status as of the last time someone checked, which in most mid-market companies was at onboarding. As typically interpreted under CGST Act Section 16(2)(c), ITC is at risk when a supplier’s returns are unfiled, and that status changes monthly. A vendor master updated annually does not protect against a GSTIN that lapsed in month four.
Parallel record creation. Procurement creates a vendor record to raise a purchase order. AP creates a separate record to process the first invoice. Neither team knows the other has done it. The ERP allows both if deduplication logic relies on name matching rather than GSTIN or PAN. Two records, one vendor, no flag. The next automated payment run can pay both.
Three signals a finance controller can check without a data team: a GSTR-2B mismatch rate above 3 percent (legitimate exceptions cluster below 1 percent), vendor records with no transaction in 18 months still marked active, and more than one bank account per GSTIN in the master.
What Degraded ERP Data Actually Costs
The cost of stale master data is not a system cost. It lands on the P&L and on the compliance schedule.
Cancelled or suspended GSTINs transacting undetected block ITC under Section 16(2)(c) of the CGST Act, as typically interpreted. The payment goes out, the invoice is approved, and the ITC claim fails in GSTR-2B reconciliation months later. The finance team then spends close week tracing exceptions that originated in a vendor record nobody reviewed. For the specific mechanics of how cancelled GSTIN status creates ITC reversal liability, see Cancelled GSTIN in Your Vendor Master: The ITC Risk Your AP Team Is Not Tracking.
MSME registration status carries a separate consequence. As typically interpreted under Section 43B(h) of the Income Tax Act, payment to an eligible MSME vendor beyond the prescribed period disallows the deduction in that financial year. A vendor master that does not track current MSME registration status cannot support accurate 43B(h) compliance. The finance team that discovers this at year-end cannot retroactively fix the payment dates. For the calculation methodology, see MSME 43B(h): Calculating Your Company’s Actual Payment Exposure.
In vendor masters we have reviewed at Indian mid-market companies, the risk does not distribute evenly. Most of it sits in a small cluster: the cancelled GSTIN transacting for months without detection, the MSME vendor whose registration lapsed at the last renewal cycle, the duplicate record that survived onboarding because procurement and AP used different name formats. The ERP flagged none of them.
Close cycle delays follow the same pattern. Reconciliation exceptions during month-end close are routinely treated as transaction problems. Most trace to the master. Duplicate records produce duplicate payment lines; a GSTIN that no longer matches the PAN on file generates a GSTR-2B exception; a bank account updated in the ERP but not confirmed with the bank delays settlement. Each requires manual investigation that takes longer than the original transaction.
Why Finance Teams Cannot Layer AI on Dirty ERP Data
AI tools in finance inherit whatever is in the ERP master. They do not clean it. They process it at the speed and scale the tool was designed for.
Duplicate vendor records produce duplicate invoice matches in an AI-assisted processing queue. A stale GSTIN means an AI-approved payment that blocks ITC. When an MSME flag lapses after onboarding, the AI schedules a payment that creates a 43B(h) exposure the system cannot catch. The AI performed exactly as designed. The data was wrong.
This is why finance teams evaluating automation tools find accuracy numbers in demos that do not hold in production. The vendor’s benchmark ran on clean data. The company’s ERP did not have clean data. The gap is not in the tool. It is in the foundation the tool runs on.
What AI-ready ERP data looks like in practice is not complicated. Four fields carry most of the compliance and operational risk: GSTIN validity against the GST portal, MSME registration currency, duplicate detection by GSTIN and PAN rather than name, and verified bank details. For a structured approach to measuring all four, see Vendor Master Data Quality in India: What Good Looks Like When You Measure It.
A finance function that runs this check before an AI or automation implementation finds its actual error rate, not the rate the system reports. In every engagement where we have run this check, the gap between self-reported vendor master health and measured health has been material. The finance team that knows this before the implementation avoids the more expensive discovery of finding it after.
If you want to know what your ERP data actually contains before committing to an automation initiative, the IQSS Diagnostic is a five-day structured review of your vendor master and AP data layer that produces a measured baseline.
Key observations
- ERP master data degrades through three predictable mechanisms after go-live: vendor record accumulation without deactivation, GSTIN and compliance status drift, and parallel record creation by procurement and AP.
- The ERP does not detect or flag this decay. It processes transactions against whatever is in the master, whether or not those records remain valid.
- Stale master data creates direct compliance exposure: ITC blocks under CGST Section 16(2)(c) and potential deduction disallowances under Section 43B(h) of the Income Tax Act, as typically interpreted.
- AI and automation tools do not correct poor master data. They process it faster. Accuracy failures in production almost always trace to data quality, not tool capability.
- Four fields carry most of the risk in an Indian mid-market vendor master: GSTIN validity, MSME registration currency, duplicate rate by GSTIN and PAN, and bank detail verification.