BRSR Section A Pre-fill Workflow — Source Systems, Reconciliation, and Year-on-Year Carry-Over

Why Section A is “the easy section that’s actually hard”

BRSR Section A — General Disclosures — looks simple on paper: entity profile, products and services, operational footprint, workforce, holding structure, CSR, transparency mechanisms, material responsible business conduct issues. No emission factors, no PPP-adjusted denominators, no Scope 3 categories. Just basic data.

In practice, Section A is where the largest reconciliation effort goes in any first-year BRSR engagement. The data exists — but it commonly draws on multiple source systems used in practice, each with its own internal taxonomy that doesn’t natively map to the BRSR field structure. CIN and paid-up capital sit in MCA21; products sit in GST sales registers (HSN / SAC codes); workforce counts sit in the HRIS (with the entity’s own employee categorisation, which doesn’t natively differentiate “employees” vs “workers” the way BRSR asks); CSR data sits in the Section 135 CSR Annual Report; complaints data sits across POSH register, consumer complaints log, and other principle-specific registers; subsidiary structure sits in the consolidated financials and ROC filings.

BRSR Section A is best treated as a reconciliation workflow: the listed entity can cross-reference information already disclosed in its Annual Report, and the remaining fields are assembled by mapping MCA21, HR, CSR, and complaints data into the BRSR format.

The “pre-fill” framing used throughout this guide is operational shorthand for that reconciliation workflow — it is not SEBI terminology. The SEBI BRSR Format does not prescribe a specific data-assembly method; it specifies the disclosure fields and lets each entity choose its own preparation workflow. This guide describes a workflow that has emerged as common practice across BRSR engagements.

What Section A covers

Per the SEBI BRSR Format Annexure I, Section A — General Disclosures — covers the listed entity’s basic profile, products / services, operations, employees, holding / subsidiary / associate structure, CSR details, transparency and disclosure compliances, and material responsible business conduct issues. The exact field list and any updates flow from the latest SEBI BRSR Format Annexure I — refer to it for the precise field-by-field wording and any subsequent SEBI amendments. The below table is a high-level mapping of Section A blocks to the source systems that commonly feed each block in practice:

Block (per Annexure I structure)	What it covers	Source systems commonly used in practice
Details of the listed entity	CIN, name, year of incorporation, registered office, corporate office, stock exchange listings, paid-up capital, contact for BRSR	MCA21 master data + entity register
Products / services	Activities (NIC codes), products / services contributing materially to turnover	GST sales register (HSN / SAC) reconciled to NIC; Annual Report products section
Operations	Number of plants, offices, operational locations	Fixed asset register; operations register
Employees and Workers	Permanent / other-than-permanent employees and workers, gender split, differently-abled split	HRIS / payroll register at year-end
Holding, Subsidiary, Associate structure	List of holding, subsidiary, associate companies (incl. JVs); whether each contributes to BRSR scope	Consolidated financials; ROC filings; corporate structure register
CSR	Whether Section 135 of the Companies Act 2013 applies (per the Act’s threshold tests); CSR spend; CSR activities under Schedule VII	Section 135 CSR Annual Report
Transparency & Disclosures	Complaints / grievances on each NGRBC Principle (volume, resolved, pending)	POSH register; consumer complaints register; whistle-blower register; other principle-specific registers
Material responsible business conduct issues	Material ESG / responsible-business issues identified, with management approach disclosure	Materiality assessment working file; risk register

The block ordering and exact field wording shifts across BRSR Format versions; the above is a mapping to source systems, not a substitute for the Annexure I itself. Refer to the latest SEBI BRSR Format Annexure I for the current field structure.

The source systems commonly used in the Section A workflow

Each Section A field maps to one or more pre-existing source systems. This is operational practice, not a SEBI-prescribed source list — the Format itself only specifies the disclosure fields. The reconciliation workflow starts by mapping each Section A field to its primary source, with prior-year BRSR as the secondary source for fields that change slowly.

1. MCA21 master data

Pre-fills: CIN, registered office, year of incorporation, paid-up capital, list of subsidiaries / holding (cross-checked against ROC filings).

The MCA21 Master Data viewer (publicly available via the MCA portal’s company-search function) provides the authoritative version of these fields. The entity’s own corporate register should reconcile to MCA21; any divergence indicates a record-update lag that should be resolved before the BRSR is finalised.

2. Annual Report

Pre-fills: Products / services description, business segments, geographic operations, named directors, top management, holding-subsidiary-associate structure, audited financial figures referenced in BRSR Section A.

The Annual Report is typically signed off shortly before the BRSR is filed (BRSR is filed with or alongside the Annual Report), so the Annual Report is the most timely cross-reference for Section A’s qualitative narrative blocks.

3. GST sales register / HSN-SAC database

Pre-fills: Products and services breakdown by NIC code, after the HSN / SAC → NIC mapping exercise.

Multi-product entities often maintain a sales-cube or BI dataset that aggregates sales by HSN / SAC; the BRSR mapping consumes this aggregated view. Single-product or single-service entities can derive directly from the GST returns.

4. HRIS / payroll register

Source for: Headcount by gender, by employment type (permanent / other-than-permanent), by category (employees vs workers as those terms are used in BRSR), by differently-abled status.

The HRIS rarely uses the BRSR employee / worker categorisation natively. A common implementation convention observed in BRSR engagements is to maintain an employee-category mapping table that translates the entity’s payroll categories to the BRSR field structure, and to apply this consistently year-on-year. This mapping convention is an internal workflow artefact, not a SEBI requirement — but it is typically reviewed by the assurance partner where workforce-related KPIs are in scope.

5. Section 135 CSR Annual Report

Source for: CSR applicability and CSR-related disclosures.

The applicability test, the spend obligation, and the qualifying activity scope are all governed by Section 135 of the Companies Act 2013 and the Companies (CSR Policy) Rules, 2014 (with subsequent amendments). The Section A CSR block draws on the entity’s own Section 135 working — the BRSR is not the place to re-derive the applicability test or the spend calculation; it cross-references the Sec 135 CSR Annual Report. Where Section 135 does not apply to the entity (sub-threshold), the Section A block discloses the non-applicability explicitly. Refer to Section 135 of the Companies Act 2013, the Companies (CSR Policy) Rules, and the latest MCA notifications for the current threshold tests, spend calculation basis, and Schedule VII activity scope.

6. Prior year’s BRSR

Pre-fills: Every field that changes slowly or not at all — CIN, registered office, year of incorporation, products narrative (where stable), top management names, BRSR contact person.

The prior-year BRSR is the workflow accelerator: most Section A fields are either static or slowly-changing. Year-on-year, the entity carries forward the prior-year BRSR Section A as a starting template, then runs a delta exercise: which fields changed, what’s the new value, what evidence supports the change.

Reconciliation patterns that recur

These are common practice patterns observed in BRSR Section A engagements — not SEBI-recognised categories of finding. Each is framed as an observation, not a categorical rule.

Pattern 1 — HRIS employee categorisation does not natively match BRSR taxonomy

The single most common Section A reconciliation issue. The entity’s HRIS may categorise the workforce as Officer / Workman / Manager / Trainee / Contract; BRSR asks for Employees vs Workers, with sub-splits by Permanent / Non-Permanent and by Gender. Building an employee-category mapping table is the typical remediation. The mapping should be applied consistently year-on-year; a mid-cycle re-mapping is itself a year-on-year disclosure event.

Pattern 2 — Contract-labour scope is an entity-policy decision

Whether contract-labour engaged through a contractor counts as the entity’s “workers” for BRSR purposes is an implementation matter rather than a source-defined audit category. Different entities take different approaches: some include contract-labour in the workers count with disclosure of the basis; some exclude with disclosure; some include in a separately-disclosed bucket. The chosen treatment should be documented and applied consistently. Recent SEBI Industry Standards on BRSR Core have clarified scope for several workforce disclosures — refer to the latest applicable circular for the current basis.

Pattern 3 — HSN-to-NIC mapping requires a documented digit-level convention

Sales registers carry HSN (8-digit for goods) or SAC (6-digit for services). NIC (the National Industrial Classification used in BRSR Section A) operates at NIC 2 / NIC 3 / NIC 4 / NIC 5 levels depending on granularity. The mapping convention applied (which NIC version, which digit-level, which materiality threshold for the ‘others’ bucket) should be documented and applied consistently year-on-year.

Pattern 4 — Subsidiary BRSR scope is an entity-policy decision

For subsidiary / associate / JV entities, whether each is included in the parent’s BRSR scope, included on a separate-disclosure basis, or excluded with disclosure is an entity governance call. The terminology around boundary basis (“operational control”, “financial control”, “equity-share”) is internal convention drawn from adjacent reporting frameworks (GHG Protocol, Ind AS 110), not SEBI-prescribed for BRSR Section A — the entity should document the boundary convention applied, apply it consistently across years and across BRSR sections, and be prepared for the assurance partner to review the basis. Refer to the latest SEBI BRSR Format and any subsequent SEBI Industry Standards on BRSR Core for any prescribed scoping basis.

Pattern 5 — CSR Sec 135 applicability shifts year-on-year for borderline entities

The Section 135 applicability tests are evaluated under the Companies Act 2013 framework against the entity’s prior-year financial position; entities close to the thresholds can move in and out of Section 135 scope year-on-year, which changes the Section A CSR disclosure from “applicable + activities + spend” to “not applicable” or vice versa. The applicability test working under Section 135 should be retained as part of the BRSR working file. Refer to Section 135 of the Companies Act 2013 and the Companies (CSR Policy) Rules for the specific threshold tests and the spend calculation basis.

Pattern 6 — Complaints registers across NGRBC principles need cross-system aggregation

Section A’s transparency block aggregates complaints / grievances across all 9 NGRBC Principles. The data sits across multiple registers — POSH, consumer complaints, vendor complaints, whistle-blower, environmental complaints, etc. — each typically owned by a different department. The aggregation pattern that emerges in most engagements: a single Section A complaints summary owner runs a quarterly cross-functional pull from each register; the year-end Section A disclosure consumes the consolidated data. Where the entity does not maintain certain registers (e.g., no formal whistle-blower mechanism), the disclosure is “Nil — mechanism not in place” rather than left blank.

Pattern 7 — Year-on-year delta vs full re-derive is a workflow choice

Pure carry-over (start from prior-year, change only the cells with known updates) is faster but can mask drift over time. Full re-derive (rebuild every field from source each year) is slower but catches all drift. This is an internal workflow choice — not a SEBI-prescribed methodology. Most entities adopt a hybrid in practice: full re-derive for fields with known volatility (workforce counts, CSR spend, products turnover, complaints), pure carry-over for static fields (CIN, registered office, year of incorporation), and a documented refresh cycle for slowly-changing fields (typically every 2-3 years for products narrative, holding structure, top management bios). The cadence the entity chooses should be applied consistently and reviewed by the disclosure committee or equivalent governance forum.

The pre-fill workflow — practical sequence

The below describes the commonly observed sequence for a Section A pre-fill workflow. The exact mechanics scale with entity size and the number of subsidiaries in scope.

1. Anchor on the prior-year BRSR — pull the prior-year BRSR Section A as the starting template. Mark each field with its source-system pointer.
2. Refresh static fields against MCA21 — confirm CIN, registered office, paid-up capital still match MCA21 master data. Flag any divergence for record-update before BRSR finalisation.
3. Refresh financial / structural fields against the current Annual Report — products narrative, business segments, holding-subsidiary structure, top management, named directors. The Annual Report sign-off date typically anchors the Section A finalisation timing.
4. Re-derive workforce from the year-end HRIS extract — apply the documented employee-category mapping table, generate the BRSR-taxonomy headcount with the gender / permanent-vs-non-permanent / differently-abled splits.
5. Re-derive products breakdown from the GST sales register — aggregate by HSN / SAC, apply the documented HSN→NIC mapping at the agreed digit-level, generate the principal-products-by-turnover schedule.
6. Pull CSR data from the Section 135 CSR Annual Report — applicability test (against the prior FY thresholds), spend, activities by Schedule VII category. Where Sec 135 doesn’t apply, state non-applicability explicitly.
7. Aggregate complaints across registers — pull from POSH register, consumer complaints, whistle-blower, environmental, etc. Consolidate against the NGRBC Principle taxonomy used in BRSR.
8. Disclosure committee review — the assembled Section A is reviewed by the disclosure committee or equivalent governance forum before being signed off into the BRSR.
9. XBRL tagging — the finalised Section A content is loaded into the NSE / BSE BRSR XBRL utility. The utility validates structure; tagging issues are resolved before the entity proceeds to filing.

---

Where Batchwise fits (service description — separate from the regulatory workflow above)

The sections above describe the regulatory workflow for Section A — the source systems, reconciliation patterns, and assembly sequence that any entity preparing BRSR Section A would follow regardless of tooling.

The section below describes Batchwise’s service in this workflow. The two are deliberately kept separate so readers can distinguish what BRSR Section A is from what Batchwise does.

Batchwise helps structure the extraction, mapping, and reconciliation across source systems for the Section A preparation workflow. The entity remains responsible for the final BRSR submission and sign-off; the partner CA firm remains responsible for the assurance opinion.

In practice, Batchwise’s role in a Section A engagement covers the manual extraction-and-mapping steps that recur across entities:

• Annual Report PDF → Section A narrative fields — AI-assisted extraction of products / services description, segment breakdown, geographic operations
• Section 135 CSR Annual Report → Section A CSR block — extraction of the entity’s own Sec 135 working into the BRSR CSR field structure
• Payroll register → BRSR-format headcount — application of the employee-category mapping table at scale, with audit-trail
• Complaints registers → NGRBC-aggregated complaints schedule — normalising across multiple register schemas into the BRSR Section A complaints summary

These are data-preparation activities. The signed BRSR is the entity’s submission under the entity’s authorised-signatory DSC; the assurance opinion is the partner CA firm’s under their own DSC; Batchwise’s name does not appear on either signed artefact.

What this guide captures and what it doesn’t

Captures:

• The six source systems that pre-fill Section A
• The year-on-year carry-over discipline (static / slowly-changing / always-re-derive)
• The reconciliation patterns that recur (employee taxonomy, HSN→NIC, contract-labour scope, subsidiary scope, CSR applicability, complaints aggregation)
• The pre-fill workflow sequence
• Where AI-structuring helps in the data preparation layer

Doesn’t capture:

• BRSR Section B (NGRBC Principle-wise disclosures) — see the NGRBC pillar pages for each Principle’s coverage
• BRSR Section C (BRSR Core attributes) — see the BRSR Core methodology pages for each KPI
• The XBRL tagging / utility mechanics in detail — see the XBRL Taxonomy for BRSR methodology page
• DSC signing and filing portal mechanics — see DSC Signing for BRSR Reports

Related reading

• DSC Signing for BRSR Reports — the filing event after Section A is finalised
• XBRL Taxonomy for BRSR — the structure that consumes the finalised Section A
• NGRBC to BRSR Metric Mapping — Section B disclosures by Principle
• Tally Ledger to BRSR Mapping — adjacent ledger-level mapping for financial figures referenced in Section A
• Document Evidence Requirements — the underlying evidence the assurance partner reviews
• BRSR Core Assurance Service — how the engagement scope sits relative to Section A preparation