# BRSR Data Quality - Filing Issues & How They Are Handled Why BRSR ESG filings carry data-quality noise, the classes of issue found across the Nifty Total Market universe, the two-layer (algorithmic + printed-PDF) validation, and the honest bottom line: reliable for aggregates, verify specific company cells against the PDF. Source data: VIGIL BRSR consistency checks + PDF validation over SEBI BRSR XBRL filings. Last updated: 2026-07-02. Interactive tool: https://vigil.tigzig.com/brsr Every BRSR value is self-reported by the company in its SEBI XBRL filing. The XBRL format enforces structure, but individual numbers are not independently verified at source - so VIGIL runs a layered set of consistency checks and publishes the results openly. This page documents the data-quality framework and the classes of issue found; the full per-company registry (which changes with every data refresh) lives in the live BRSR Data Quality Explorer. [Open the live VIGIL BRSR Data Quality Explorer](https://vigil.tigzig.com/brsr) for the current per-company / per-cell flags. ## Bottom line The consistency checks have flagged **785 individual cell-level issues across 250 of 712 filers** - roughly **one in three** Nifty Total Market BRSR filings carries at least one cell the algorithmic checks consider questionable, spanning 52 distinct fields (revenue/unit confusions, wage-format errors, complaint-count anomalies, turnover-rate format issues, POSH inconsistencies, workforce subtotal-tie failures, and more). Coverage is partial and a lower bound: not every taxonomy field has an algorithmic check yet, and each new check tends to surface another batch, so the share of filers with a flag is likely to rise above ~40%. A companion **PDF validation** layer catches a different class - cells that pass every algorithmic check but are wrong when read against the printed BRSR PDF the filer signed (Adani Ports' wage table is the headline example: every cell is plausibly shaped but materially different from the PDF). Across both layers, the share of filers with at least one issue somewhere is likely approaching half the universe - meaningfully higher than in other regulated XBRL filings (quarterly results, prospectuses), which suggests the BRSR filing pipeline is worth fixing at the source. **What this means:** aggregate, sector and directional analysis remains highly reliable - 1-3% cell-level noise does not distort distribution shapes, year-on-year comparisons, or peer benchmarking. But for a specific company-level number used for a specific decision, validate it against the printed PDF first. ## Classes of issue (and how each is handled) - **Revenue unit inconsistency (69 companies).** The taxonomy requires Turnover in rupees, but ~10% file in lakhs or crores while still declaring INR (e.g. Dr Reddy's filed "231,154" meaning Rs 23,115 Cr, i.e. lakhs). Detected by cross-referencing each company's BRSR Turnover against the sum of its 4 quarterly XBRL filings and a magnitude/decimals check; resolved by applying the right multiplier (38 in crores, 31 in lakhs) or falling back to the TotalRevenueOfTheCompany tag. - **Unusually high complaint counts.** Some companies count safety observations or near-miss reports as "complaints" - e.g. Tata Power reported 606,260 health & safety "complaints" against 105,369 workers. Displayed as reported; distribution charts surface the outliers. - **Turnover-rate format (8 companies, 10 cells).** Attrition should be a 0-1 decimal; some filed whole-number percentages or impossible values (LLOYDSENGG 287%). Routed to a dedicated amber "DQ" bar and excluded from medians (a per-cell filter rejects rate over 1.0). - **Wage unit acknowledgement (97 companies, 161 category flags).** Some file median wages in lakhs or as monthly amounts rather than annual rupees - but both female and male are in the same wrong unit, so the F/M ratio (what the wage-gap chart uses) stays valid. These stay inside the distribution with an info marker rather than being excluded. - **POSH / sexual-harassment anomalies.** A few filings show impossible patterns (e.g. narrow POSH count exceeding the broader sexual-harassment count, or an upheld count of 100 against 1-5 filed). Nonsensical values are excluded from the upheld-rate aggregate; smaller inconsistencies are kept but flagged. - **Workforce subtotal-tie.** A structured plausibility suite over 699 filings; five of six checks were clean, the sixth (Permanent + Other-than-Permanent = Total) found one company (INDIAMART) with a mathematically impossible Section A table. Logged in the registry. - **Cross-tag denominator differences (~330 filers, informational).** The taxonomy stores total headcount in more than one place, and Principle 3/5 disclosures often restate their own "Total" (the population eligible for performance reviews, union membership, etc.), which legitimately excludes contractors or probationers. This is a scope difference permitted by the taxonomy, not an error - no company is flagged; percentages should be read on the denominator disclosed under that Principle. - **Extreme outliers excluded from aggregates.** A handful of values so extreme they would distort medians (e.g. an LTIFR of 1,851 vs a typical 0-20, or single-digit "median wages") are moved to a separate DQ bucket and excluded from aggregate medians, but still shown on the company page with a warning icon. ## The source-filing-error registry Companies whose XBRL contains nonsensical, impossible, or internally inconsistent values are catalogued in a data-quality registry (source errors in the filing, not extraction issues). Values are displayed as reported but flagged with a warning icon in chart drilldowns, and each entry records the company, section, type (unit mismatch / unit correction / unit acknowledged / nonsensical value / missing data / outlier), severity, description and detection date. Detection combines automated scans (e.g. wage F/M ratios over 5x) with manual investigation against the raw XBRL. The full, current registry is in the live Data Quality Explorer. [Open the live VIGIL BRSR Data Quality Explorer on TIGZIG](https://vigil.tigzig.com/brsr), or see the [BRSR methodology](/vigil/brsr-methodology) page and [all VIGIL data sources](/vigil/data-sources). --- Source: https://www.tigzig.com/vigil/brsr-data-quality