> For the complete documentation index, see [llms.txt](https://india-energy-stack.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://india-energy-stack.gitbook.io/docs/use-case-implementation-guides/discom-regulatory-filing.md). # DISCOM Regulatory Filing (WIP) **In a hurry?** Jump to the [Checklist](#checklist). For the standards basis and full field schedule, see the [**Overview**](/docs/use-case-overviews/discom-regulatory-filing.md). **A DISCOM submits its Aggregate Revenue Requirement (ARR), tariff petition, true-up, or other compliance filing to a State Electricity Regulatory Commission (SERC) as a structured, signed, machine-verifiable** [**ArrFiling v0.5**](/docs/schemas/arrfiling/v0.5.md) **object.** {% hint style="warning" %} ๐Ÿšง **Work in progress.** This guide is still being finalised and may change before sign-off. {% endhint %} *** ## Scenario Every year, every DISCOM in India submits an ARR filing to its state regulator โ€” a detailed projection of power-purchase, transmission, O\&M, depreciation, and return-on-equity costs that justifies the tariff it wants the SERC to approve. The same DISCOMs file true-up petitions, FPPCA reconciliations, multi-year tariff petitions, and various compliance returns through the year. Today these arrive as **PDFs and Excel sheets**. SERC staff manually re-key the numbers into their analysis spreadsheets. There is no canonical machine-readable form, so no cross-DISCOM comparison, no automated trend analysis, no straight-through validation. This use case replaces the PDF round-trip with a structured `ArrFiling` payload delivered over IES Data Exchange โ€” signed by the DISCOM, ingested directly by the SERC, archived with a non-repudiable audit trail. *** ## Actors and Roles | Role | Organisation (example) | What they do | | -------------------------------- | -------------------------------------------------------- | ------------------------------------------------------------------------------------ | | **BPP** โ€” data provider | DISCOM | Generates and submits the filing | | **BAP** โ€” data consumer | SERC | Receives, validates, and archives the filing | | **Optional secondary consumers** | Consumer-rep parties, research orgs, Forum of Regulators | Receive the published filing via the same protocol, gated by public-disclosure norms | Unlike Smart Meter Data Exchange, here the **DISCOM is the BPP** (data provider) and the **regulator is the BAP**. The Beckn protocol is symmetric โ€” the same ONIX adapter runs both directions. *** ## Building Blocks Used | Block | Role in this use case | | -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Identifiers](/docs/what-ies-provides/register.md) | The DISCOM and SERC each have a `did:web` identity. The filing carries identifiers for the filing (`filingId`), each fiscal year, and each cost line item. | | [Registries](/docs/what-ies-provides/register.md#the-directory-dedi) | For Beckn message-signature verification: DISCOM and SERC subscriber records resolved via DeDi. The [IES DISCOMs](/docs/what-ies-provides/register.md#the-directory-dedi) and [Regulators reference registries](/docs/what-ies-provides/register.md#the-directory-dedi) provide the Beckn network trust boundary. | | [Data Exchange](/docs/what-ies-provides/discover.md) | Carries the `ArrFiling` payload from BPP (DISCOM) to BAP (SERC), with the same `confirm` / `on_confirm` / `status` / `on_status` lifecycle as the meter-data flow. | *** ## The Dataset โ€” `ArrFiling v0.5` The [`ArrFiling`](/docs/schemas/arrfiling/v0.5.md) schema carries structured cost data for one or more fiscal years. Root fields: `filingId`, `filingType` (`MYT` / `ANNUAL` / `TRUE_UP` / `REVISED`), `licensee`, `regulatoryCommission`, `controlPeriodStart` / `controlPeriodEnd`, `currency`, `unitScale` (`CRORE` / `LAKH` / `ABSOLUTE`), `status`, and `fiscalYears[]`. Each fiscal year (`ArrFiscalYear`) carries `yearType` (`BASE_YEAR` / `CONTROL_PERIOD` / `HISTORICAL`), `amountBasis` (`AUDITED` / `APPROVED` / `PROPOSED` / `TRUED_UP` / `NOT_FILED`), and `lineItems[]`. Each line item (`ArrLineItem`) carries `lineItemId`, `category` (`VARIABLE` / `FIXED` / `INCOME` / `SUB_TOTAL` / `ARR` / `ADJUSTMENT`), `subCategory` (e.g. `POWER_PURCHASE`, `NETWORK_COST`, `O_AND_M`, `DEPRECIATION`), `head`, `amount`, and a `formReference` back to the source regulatory form. ```json { "objectType": "ARR_FILING", "filingId": "ABRC/ARR/XXDCL/MYT/2024-29", "filingType": "MYT", "licensee": "Alpha State Distribution Company Limited", "regulatoryCommission": "ABERC", "controlPeriodStart": "FY 2024-25", "controlPeriodEnd": "FY 2028-29", "currency": "INR", "unitScale": "CRORE", "status": "SUBMITTED", "fiscalYears": [{ "fiscalYear": "FY 2023-24", "yearType": "BASE_YEAR", "amountBasis": "AUDITED", "lineItems": [ { "lineItemId": "transmission-cost", "category": "FIXED", "subCategory": "NETWORK_COST", "head": "Transmission Cost", "amount": 873.52, "formReference": "Form 1.1" } ] }] } ``` The `category` / `subCategory` enums follow the standard ARR cost categories most SERCs use, converging on a superset with per-state mapping notes. > **Status โ€” `ArrFiling` schema is a draft for technical review.** The category enumeration is the open item: SERCs use slightly different cost taxonomies and the schema is converging on a superset. Integrate against the schema's own example (`arr_filings.json`); expect small enum additions, not breaking renames. *** ## Setup: Register โ†’ Discover โ†’ Exchange ### 1. Register โ€” both parties * DISCOM in the [IES DISCOMs reference registry](/docs/what-ies-provides/register.md#the-directory-dedi); SERC in the [Regulators reference registry](/docs/what-ies-provides/register.md#the-directory-dedi) โ†’ [**Setup Register**](/docs/how-you-implement-ies/setup-register.md). * Mint a single canonical `filingId` per submission (typical pattern: `/ARR///`). The same `filingId` should appear on any resubmissions โ€” versioning lives on the data-exchange envelope, not the ID. * If the filing responds to a specific tariff order, reference the `policyID` of that order (see [Policy as Code](/docs/use-case-implementation-guides/tariff-intelligence.md)). ### 2. Discover โ€” stand up the data-exchange adapters The DISCOM runs a BPP adapter; the SERC runs a BAP adapter โ†’ [**Setup Exchange**](/docs/how-you-implement-ies/setup-exchange.md). ```bash git clone https://github.com/beckn/DEG.git cd DEG/devkits/data-exchange/install docker compose up -d ``` ### 3. Exchange โ€” catalogue and submit The DISCOM publishes the filing through its BPP catalogue with `descriptor.name`, `category` (`ARR` / `TRUE_UP` / `FPPCA` / `COMPLIANCE`), `accessMethod` (`INLINE` for filings; `SIGNED_URL` if supporting workbooks accompany it), and `policyContext` (the SERC orders the filing responds to). The regulator (BAP) initiates `confirm` against the catalogue entry; both messages are signed, and the SERC's archive stores the original signed envelope as the non-repudiable record of submission. ### 4. (Optional) Open the filing for public consumption If the SERC mandates public disclosure, the same dataset is republished from the SERC's BPP under a public-disclosure catalogue, settlement value `0` โ€” see [Policy as Code](/docs/use-case-implementation-guides/tariff-intelligence.md) for the pattern. *** ## Why This Matters ARR filings arrive today as PDFs/Excel sheets that regulators manually re-key. Delivering them as structured `ArrFiling` JSON โ€” signed, timestamped, schema-validated โ€” replaces re-keying with direct ingest, gives a non-repudiable audit trail, and lets every DISCOM submit in the same canonical shape. *** ## Open Items * **`ArrFiling` cost-category enumeration** is converging across SERCs โ€” expect additions, not breaking renames. * **Workbook attachments.** The convention for supporting Excel models (separate dataset per workbook vs. embedded) is being agreed. * **Cross-filing references.** A standard shape for *"this filing responds to SERC Order X"* is being aligned with the [Policy as Code](/docs/use-case-implementation-guides/tariff-intelligence.md) `policyID` pattern. *** ## Checklist For the DISCOM (filing) and the SERC (receiving). Role: โ˜ DISCOM โ˜ SERC โ˜ Both. **1. Decide which filings to start with.** * [ ] Filing types selected (`ARR` / `TRUE_UP` / `FPPCA` / `COMPLIANCE`); source system identified for each **2. Register both parties on the IES network.** * [ ] DISCOM in the DISCOMs reference registry; SERC in the Regulators reference registry **3. Agree the cost-category mapping.** * [ ] Categories mapped to `ArrFiling` enums and signed off by regulatory affairs + finance * [ ] Tariff-order references (`policyID`) tracked so each filing cites the order it answers **4. Generate a sample filing as structured data.** * [ ] One prior-year filing converted to `ArrFiling` and schema-validated against [`schema.json`](https://github.com/India-Energy-Stack/ies-accelerator/tree/main/schemas/ArrFiling/v0.5/schema.json) * [ ] Line-item parity confirmed against the source PDF **5. Stand up the data-exchange adapters** โ€” prove on the devkit first. * [ ] Test `confirm` โ†’ `on_status` with the sample filing succeeds; both sides verify signatures **6. Catalogue the filing and submit.** * [ ] Catalogue entry published; SERC archives the signed envelope as the non-repudiation record * [ ] Re-submission policy agreed (same `filingId`, new version on the envelope) **7. (Optional) Open the filing for public consumption.** * [ ] Public-disclosure catalogue entry published (settlement `0`), if mandated **8. Production deployment and go-live.** * [ ] One real production submission completed and verified **9. Team.** \[ ] Regulatory / finance SPOC ยท \[ ] IT SPOC ยท \[ ] Authorised Signatory *** ## References * [`ArrFiling v0.5` schema](/docs/schemas/arrfiling/v0.5.md) * [Example payload](https://github.com/India-Energy-Stack/ies-accelerator/tree/main/schemas/ArrFiling/v0.5/examples/arr_filings.json) * [Overview โ€” DISCOM Regulatory Filing](/docs/use-case-overviews/discom-regulatory-filing.md) โ€” standards basis, definitions, full field schedule * [Data Exchange chapter](/docs/what-ies-provides/discover.md) * [Registries and Directories](/docs/what-ies-provides/register.md#the-directory-dedi) * [Identifiers and Addressing](/docs/what-ies-provides/register.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://india-energy-stack.gitbook.io/docs/use-case-implementation-guides/discom-regulatory-filing.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.