Attachment_1_-_XBRL_Assessment.pdf

FERC XBRL ASSESSMENT

FINAL

Version 4 - May 17, 2018

1 | FERC XBRL Assessment -DRAFT | April 2018

Table of Contents 1 Executive Summary

1.1 Overview

1.2 Advantages

1.3 Steps Required

1.4 Impact

1.5 Issues Raised

2 Overview

3 Scope

4 Current State

4.1 Systems

4.2 Form collection

4.3 Electric Quarterly Report (EQR)

4.4 eTariff

4.5 FACS

4.6 Use of data

4.7 Refresh project for forms collection

4.8 Data Analysis

4.9 Current State Observations

5 Proposed Solution

5.1 Forms collection process

5.2 Implementation options

5.3 eTariff and EQR

5.4 XBRL Taxonomy

5.5 Use of US GAAP taxonomy for FERC Reporting

5.6 IT considerations for implementation

5.7 Training Requirements

5.8 XML and XBRL

6 Benefit Analysis

6.1 Data is entered once

6.2 Data is decoupled from the form structure

6.3 Filers provide data rather than a Form

6.4 Comparison to SEC data

2 | FERC XBRL Assessment -DRAFT | April 2018

6.5 Leverage existing software base

6.6 Data is managed by business users

6.7 MetaData management is centralized

6.8 Informed filers and data users

6.9 Access to standardized validation rules

6.10 Speed of Form rollout

6.11 Support for re-submissions

7 Cost Analysis

7.1 Process

7.2 Assumptions

7.3 Cost Considerations

7.4 Timing Considerations

7.5 Software/Tool Considerations

8 Appendices

8.1 Task Order Description

8.2 Task Order Questions

8.3 Proposed Training for FERC Staff

8.4 Software for Filing and Processing XBRL

8.5 Cost Analysis

8.6 Public Companies List

8.7 Why Regulators use XBRL

8.8 XBRL Project Strawman

8.9 Issues WIthWith SEC Implementation

8.10 Q & A

8.11 Referenced papers

3 | FERC XBRL Assessment -DRAFT | April 2018

1 Executive Summary

1.1 Overview

We recommend the FERC transition the current eForms Refresh project to support the XBRL standard. Using government accepted data standards, positions the FERC with a flexible data collection system that supports current and future data collection needs, is easily expanded to cover other form reporting requirements like EQR, and is compatible with collection systems being used by the Federal Government. These benefits will be difficult to realize with a proprietary XML based collection system.

We believe the implementation of an XBRL based solution as detailed in the FERC XBRL Assessment document can be completed in approximately 6 months.

1.2 Advantages

The additional advantages of an XBRL solution for forms collection include:

1. A data model that is managed by business users.

2. Minimizes system changes when form changes are required.

3. Validation of data prior to filing.

4. Support from a community of regulators in the U.S. and globally.

5. Consistent time series of data as meta data is not tied to the form structure.

6. Filers can use pre-existing XBRL software and vendors to file with the FERC.

7. Allows filing of amended filings under prior reporting requirements.

In addition to these advantages it eliminates regulatory risks for the FERC

1. Data collection is consistent with other US regulators.

2. Forms can be updated quickly to facilitate regulatory requirements.

1.3 Steps Required

The first and most important step is to create an XBRL taxonomy that defines FERC reporting requirements for Form 1, Form 2, Form 6, Form 60 and Form 7140F

1. The preparation of these taxonomies can be performed by FERC staff with the assistance of an XBRL specialist. The creation of these taxonomies is the key requirement for filers to begin filing in an XBRL format to the FERC.

The following steps need to be completed to implement an XBRL solution:

1. Train existing business users on XBRL Taxonomy design.

2. Train IT staff on the XBRL specification and software that supports XBRL

3. Define existing forms as an XBRL taxonomy

1 All these forms currently use the visual Fox Pro application to collect data.

4 | FERC XBRL Assessment -DRAFT | April 2018

4. Convert existing validation rules into an XBRL format

5. Integrate XBRL data collection mechanisms with existing FERC infrastructure (reusing what is created in the eForms Refresh project)

6. Implement a database for storing XBRL data

7. Implement rendering solutions that render submissions as a form (pdf, html)

8. Convert end-user applications to read XBRL data sets

9. Develop outreach programs to filer community and software community (Webinars &

Workshops)

10. Convert historical Visual Fox Pro data to an XBRL format for backward compatibility and time series analysis

1.4 Impact

● No significant impact to existing infrastructure requirements.

● The additional cost of implementing XBRL is expected to be approximately

● Approximately 95 person days of FERC staff time spent on training and involvement in taxonomy creation.2F

1.5 Issues Raised

Data quality and comparability issues in SEC filings have been raised related to reporting unstructured data. In the proposed FERC implementation these issues are avoided. The FERC data is structured using a form based approach, whereas the SEC allows filers to report data as a free form report. The FERC based collection system mirrors the approach adopted in the very successful FDIC program which also follows a form based approach.

A second concern is the need to have Information Technology professionals conversant in both XML and XBRL to support an XBRL implementation, EQR and eTariff reporting. XBRL and XML are not programming languages but are both syntaxes used to define data. XBRL is built on XML and was originally defined to optimize XML for regulatory reporting requirements. The same programming languages can be used to process both. A solid understanding of XML is required to understand XBRL.

The eForms Refresh project will not reuse the business processes used to process EQR or eTariff processing even though all use XML for data collection. Implementing an XBRL solution for forms collection does not create an extra burden over implementing eForms Refresh while maintaining XML collections for EQR and eTariff.

An important requirement for the eForms Refresh project is the urgent need to replace the existing VFP process because VFP is no longer supported. Any solution adopted must be able to be

3 Assumes taxonomy built by external consultants.

5 | FERC XBRL Assessment -DRAFT | April 2018 completed comprehensively in a short period of time. Implementing the XBRL solution prior to filers switching from the VFP process will extend the delivery date, while having filers submit in the custom XML and then later switch to XBRL will have a detrimental impact on the filers and the FERC.

2 Overview XBRL US was tasked with evaluating the appropriateness of an XBRL program versus the XML eForms implementation currently underway, for the collection, processing and analysis of certain FERC forms. The evaluation covers the impact to existing workflow, processing, and reporting of data, as well as the impact to the Commission to support two filing standards during the transition process.

This report contains the findings of a cost/benefit analysis comparing the two approaches; and also includes training that will be necessary for FERC staff to conduct a successful implementation of the recommended option. The impact to the FERC eForms Refresh project currently underway, dependent systems, and to internal reports is also covered. The task order descriptions and task order questions covered by this report are described in the Appendix (section 7).

The analysis conducted during the evaluation has led to a recommendation that XBRL is the more appropriate standard versus XML, for the collection, processing, and analysis of FERC data. The rationale for a switch to XBRL is noted below:

● Provides the ability to leverage existing XBRL tools and software to reduce workload and improve efficiency. A competitive marketplace of software offerings has been established to create and analyze data, and manage taxonomy development; validation rules have been developed for other taxonomies in use. All of these tools can be re-used for FERC data.3F

● A reduction in workload for data consumers and filers can be expected. Data users will have access to computer-readable data to automate data extraction and processing. Filers will only need to enter data in forms once.

● Makes change management easier. Data is decoupled from the form structure and when there is a change in reporting requirements, it will be significantly easier for FERC, and for filers, to transition to revised forms.

● Improves the integrity of the data. Filers provide data, not a form, which can be created directly out of their internal system. Validation rules can be easily implemented on the filer data entry point, and on the user consumption point, to identify and help resolve errors.

● Enables centralized control over metadata management by the business unit. Does not need to be handed off to IT every time a revision is made.

4 For example, XBRL US makes available its XBRL database schema developed for the SEC program that can and is used in other implementations.

6 | FERC XBRL Assessment -DRAFT | April 2018

Two options have been identified for an XBRL implementation, each with pros and cons which are covered in greater detail later in the report. These options can be considered separately, or can be used for a “phased” approach to an XBRL implementation:

● Collect XBRL data from filers, convert to internal formats, and use the existing eForms refresh project to validate, render and disseminates the renderings

● Integrate XBRL throughout the FERC downstream process

3 Scope The XBRL Impact Assessment is limited to providing FERC with an analysis of the impact of transitioning from XML to an XBRL standard for FERC information collection forms, data, systems, and resources, and will also cover the benefit to the Commission of adopting the XBRL standard. eTariff and EQR are addressed, but the primary focus of the analysis is on forms, specifically Forms 1, 1F, 3Q (gas and electric), 2, 2-A, 6, 6Q, 60, and Form 714.

4 Current State This assessment documents the current state of the form collection process as the basis of analyzing the use of the XBRL data standard. The current state includes the current process and the refresh project for forms collections. This description of the current state is not meant to be comprehensive but to provide a general overview.

The FERC collects several types of data through its automated collection processes:

1. Forms

2. EQR - Sales transactions

3. eTariff - Rate data

4. eLibrary Filings

5. Company Filings

6. Other communications - emails, letters, notifications

This current state looks at the first three types of data, with a focus on Forms.

4.1 Systems

Several FERC systems and technologies are included in this assessment. The following is a brief list:

eFiling FERC web-based collection system eLibrary FERC repository of collected data and documents

VFP Visual FoxPro database and application. VFP is used as an application to collect form data. The application includes a user interface for entering data

7 | FERC XBRL Assessment -DRAFT | April 2018 and validations to ensure the correctness and completeness of data. VFP may also refer to just the database of collected data. Collected data is distributed as a VFP database file. This version of the VFP database does not include the user interface or the validations.

EQR Electric Quarterly Report system. The EQR is a system for collection of sales data on a quarterly basis. The data is collected via a web application in XML or csv format.

eTariff The eTariff system collects tariff information. The data is collected in an XML format of mostly text data.

FACS FERC Annual Charge System. FERC annual charges are paid by the regulated entities. FACS determines the portion of the annual charges that a regulated entity is billed.

Access Microsoft Access Database. Access is used to connect to VFP databases to query form data.

ATMS Activity Tracking Management System. ATMS is used to manage FERC workload.

Velocity Suite

Velocity Suite is utility market data tool provided by ABB. It was acquired by ABB from Ventyx in 2010. Velocity Suite combines and normalizes FERC data with data from other agencies and data providers. Velocity Suite is used by some FERC departments for market analysis.

4.2 Form collection

4.2.1 Scope

This assessment is being conducted as part of the eForms Refresh project. This project is focused on the following forms:

Form Company Type Form 1 Electric utilities Form 2 Gas pipeline companies Form 6 Oil pipeline companies Form 60 Centralized service companies Form 714 Electric utility balancing authority

Related forms 1-F, 2A and 3-Q are also part of the eForms Refresh project but are not included in this assessment. These forms are simpler versions of Forms 1 and/or 2 and although these forms are not being explicitly reviewed for this assessment, the assessment should easily apply to these forms.

8 | FERC XBRL Assessment -DRAFT | April 2018

4.2.2 Process

The FERC has several collection processes for different types of data that is collect. The collection described here focuses on the forms collection process (highlighted in the red dashed lines in the diagram below).

Forms are currently collected using a Visual FoxPro database application. The database application is distributed to filers. The filer uses the VFP application to enter form data. The VFP application has limited validations, mostly to ensure proper data types (i.e. a number field does not allow character data). When complete, the filer submits the form to the FERC via the application. There is a separate VFP application for each form.

As forms are submitted by filers in the VFP application, they are consolidated into a single VFP database for the form and year. In addition to the VFP database, each filed form is rendered into a PDF. The PDF is available via eLibrary as well as from specific viewing applications. At the end of each year, the consolidated VFP database is made available to the public on the FERC website.

The consolidated VFP database contains only the last submitted data. If a filer re-submits a form, the data is overwritten in the database to reflect the latest data.

Once the public version of the VFP database is published, it is not updated. Resubmissions that come after the publications are not reflected in the public version of the database.

9 | FERC XBRL Assessment -DRAFT | April 2018

Many forms are collected quarterly and annually. The data for both (quarterly and annually) are stored in the VFP database.

The FERC provides viewer applications for accessing the VFP database. Each form has a separate viewer application. The viewer is a VFP client application. The user must download the view application and install it locally and also download the publicly available VFP database. The viewer application links to the local copy of the VFP database. The user can select a specific filing and schedules and the viewer will render the selected schedules.

Data users can also access the VFP database via Microsoft Access using a Visual Fox Pro ODBC driver. This allows the user to create SQL queries to access the data.

PDF versions of the filings can be publicly accessed via the eLibrary website.

One of the driving factors for revisiting the data collection process is the age and maintainability of the current collection process. Microsoft no longer supports Visual FoxPro. The last version of Visual FoxPro was released in 2007. Official support ended in 2015. This poses significant security issues for filers and the FERC, as there are no new security updates.

4.2.3 Form structure

Each form is organized as a collection of schedules. There are four types of schedules:

1. Identification

2. Fixed row schedules

3. Dynamic row schedules

4. Text schedules

Identification schedule Every form has an identification schedule. The identification schedule contains basic information about the submitting entity and the contact person. The fields on the identification are fixed and non-repeating. Essentially, each field collects a discrete piece of information.

Fixed and dynamic schedules Fixed row schedules have a row for each specific reporting item that is collected. For example, on the balance sheet there is a row for “cash”. The columns identify a specific aspect of the row.

In the balance sheet, the columns are current year and prior year. The intersection of the row and the column is a discrete piece of data.

Dynamic row schedules generally collect one reporting item that repeats. For example, the Officers Schedule collects information for each officer of the company. The row is “repeated” for each officer. Like fixed row schedules, the columns identify a specific aspect of the row. In the case of the Officers Schedule, the columns are “title”, “name of officer” and “salary”. The intersection of a row and column is a discrete piece of data.

Schedules are identified by the name of the schedule and alternatively by the page number of the schedule on the form. Rows are identified by row number, and columns are identified by

10 | FERC XBRL Assessment -DRAFT | April 2018 alphabetic letters. Often references to specific data on a form are identified by the page, row and column (the “GPS” of the data field). For example, “cash” for the current year on Form 1 may be referenced as ‘Form 1, page 110, row 35, column c’.

The columns of the schedule may span more than one physical page. The continuation page will have a different page number. The row numbers will be the same as on the first page. The columns will be identified by continuing the alphabetic sequence. For example, the statement of income on page 114 of Form 1 has columns ‘a’ through ‘f’. Columns ‘g’ through ‘l’ continue on page 115.

Fixed row schedule specifics Fixed row schedules have a predetermined number of rows. Each row represents a reporting item. The reporting item description is usually shown in column “a” of the schedule. The reporting item may be permanently assigned or left blank and filled in by the filer. For permanently assigned rows, there may be a column for page reference which identifies another schedule that has more detail about the reporting item of the row.

The reporting item may be an account. In this case, the description of the item includes the title of the account number in parenthesis.

Some rows represent totals or subtotals. Often, when there are blank rows, a total row will follow.

Fixed row schedules may have more rows than can fit on a physical page. In this case, the additional rows will continue on the next page. The row numbers will continue incrementing on the next page.

Dynamic row schedule specifics Generally dynamic row schedules are a series of blank rows. However, there may be some fixed rows. The fixed row may be:

● A heading for a section of the schedule. An example is the Transmission Service and Generation Interconnection Study Costs schedule (Form 1, page 231). This schedule has a heading for “Transmission Studies” on line 1 and “General Studies” on line 21.

● A few lines of the schedule are not dynamic and collect data for a specific reporting item.

An example is Accumulated Deferred Income Taxes - other (Form 1, page 276). This schedule has fixed rows for “Federal Income Tax”, “State Income Tax” and “Local Income Tax”.

● A total line. An example is the Long-Term Debt schedule (Form 1, page 256). This schedule has blank lines for each long-term debt instrument. The last row is a total line.

When dynamic schedules span more than one page, the page numbering will append a ‘.’ followed by the sub-page number for each of the pages. Fixed rows and total rows will be repeated on each of the pages with the same line number and value.

11 | FERC XBRL Assessment -DRAFT | April 2018

Text schedules Text schedules ask for specific information in an open text field. For example, the Notes to Financial Statement schedule (Form1, pages 122-123). These schedules include instructions on the first page and the text field is on the following page. The content of the text may span more than one physical page.

When text schedules span multiple pages, they follow the same page number system as dynamic schedules: the page number is appended with a ‘.’ followed by the sub-page number.

Structured data on unstructured schedules Fixed row forms provide the most structured data. Each data field has a known reporting item and column heading. However, in some cases, structured data is identified in the instructions to be reported, in dynamic row schedules. In these schedules, the data itself is structured, but is not captured on the schedule in a structured manner.

An example of a dynamic row schedule for capturing structured data is the Investments in Subsidiary Company schedule (Form 1, page 224). This schedule asks for specific information on subsidiaries, including:

● a heading for each subsidiary

● a list of investments

● additional information that is not identified by a column (i.e. for bonds, the principal amount)

● a total line for each subsidiary

The schedule has structured components identified by the columns (i.e. (b) Date Acquired, (c) Data of Maturity), however, additional requested information is supplied in an unstructured way in the description column for the row.

Footnotes When a form is filled in, any data field may have a footnote attached to it. The footnote may be either text or a file attachment.

4.2.4 Validations

Form data is validated in the VFP submission software. Validation rules are created by the FERC and pushed to the submission software on client side. Form validation is limited to data type validations (i.e. verifying that a number field is not text). Validation rules are published on the FERC website as excel spreadsheets.

4.2.5 Rendering

Forms are rendered into PDF documents. The PDF documents are available to the public through eLibrary on the FERC website and through a forms viewer. The forms viewer is a VFP application, downloadable from the FERC website.

4.2.6 Data referencing

Data is most often referenced by “GPS” location of the data on the form by identifying the form, page, line number, and column of the data. This method of referencing makes changes to the

12 | FERC XBRL Assessment -DRAFT | April 2018 forms difficult as the numbering system would change. In particular, these references are used in the OATTs (Open Access Transmission Tariff) to support cost based rates.

4.3 Electric Quarterly Report (EQR)

EQR collects contractual terms of interstate sales as well as the sales transactions. Filers report EQR data quarterly. Data is prepared by filers, either through the EQR submission web application or by direct upload via the FERC EQR website. The EQR submission web application allows the filer to manually enter data or import date from a csv file. The direct upload option submits an XML file prepared by the filer for the submission. Regardless of the format for submitting the data, the data is made available in as both XML and csv.

Validation takes place on FERC systems. Validation includes XML structure validation, data type validation (i.e. that a number field does not contain text), cross data checks (i.e. if the filing type is “New” then the contract types must also be “New”) and data checks against other FERC systems (i.e. the company id must match a registered company). Most validation rules are published by the FERC on its website in a PDF for filers to read. Filers or vendors can write their own programs by manually reading these rules and converting them to custom code to check the validity of their data before uploading.

The FERC provides XML schema files (.xsd files) so that filers can validate prepared XML files prior to submission. Schema validation only handles XML structure and data type validation. Filers can submit their EQR filing to a test sandbox to perform all validations prior to final submission.

EQR data is very structured with well defined XML elements.

4.4 eTariff eTariff is used to collect all tariffs, tariff revisions and rate changes. eTariff data is collected as an XML file. The eTariff data is mostly text structured in hierarchical sections. The hierarchical structure represents a table of contents of the data. The data in each section is formatted text in a binary format and a plain text version. The structure of the sections is determined by the filers.

eTariff contains validations for data type validation, code validations and cross data validation.

Many of the cross data validations are focused around statuses. The structure and data type validation is handled by the eTariff XML schema.

eTariff data is available as XML and rtf files via the eTariff viewer.

4.5 FACS

The FACS system is used to create invoices for annual charges to the regulated companies.

FACS collects minimal data from the existing forms to calculate individual company charges. The FACS system is being replaced by the FERC accounts receivable system and is not seen as significant to this assessment.

13 | FERC XBRL Assessment -DRAFT | April 2018

4.6 Use of data

4.6.1 Form data

Form data is made available internally and externally via a variety of methods and formats.

Form data is available as PDF documents for individual filings. There are various methods and systems to access the PDF documents. The PDFs are available in eLibrary on the FERC website.

For forms 1, 2 and 6, annual copies of a VFP database are provided by form and year. When using the VFP database, the database cannot be accessed directly without a Visual FoxPro installation, which is no longer available. Instead, the VFP database can be accessed with a Visual FoxPro ODBC driver. Most ODBC client applications can then read the VFP database. Most commonly, Microsoft Access is used to link to the VFP database through the ODBC driver.

In addition, there is a viewer application that can read a downloaded VFP database. There is a separate viewer application for each form. The viewer application can be downloaded from the FERC website. Because the VFP database files are segregated by year and form, it is difficult to access form data from multiple forms or multiple years (even for the same form).

The structure of the VFP database mirrors the format of the forms themselves. Each schedule in a form is represented as a single database table and each record in the table represents a single row of the form. The table fields represent the columns of the form. There are some additional metadata tables, such as reporting item descriptions, list of respondents and filing information.

Although this data model supports the collection of data, it does not easily support querying the data for analysis. This is because the data is spread over many tables and multiple databases.

Querying for data from multiple schedules requires significant joining or query unioning. These types of queries are inherently complicated and often require in-depth technical knowledge.

Form 60 data is only available as a PDF from eLibrary.

Form 714 data is available as a zip download of csv files.

4.6.2 EQR data

EQR data is available as a PDF, a set of csv files or a set of XML files for each submission. Zip files of quarterly data in csv or xml are also available. The quarterly data is a zip file containing a separate zip file for each filing. Access to the EQR data is via a FERC web application (Report Viewer).

4.6.3 eTariff data eTariff data is available as PDFs, HTML and XML. There is an eTariff viewer which is a web based application for searching for eTariff submissions.

14 | FERC XBRL Assessment -DRAFT | April 2018

4.6.4 General notes on use of data

The available data is very siloed in various systems and formats. This makes it difficult to aggregate data for analysis. Some FERC staff use third party vendors (i.e. ABB Velocity Suite, formerly Ventyx) to access data.

4.7 Refresh project for forms collection

The current forms collection process has some significant limitations:

● Use of Visual FoxPro which is no longer updated or supported

● Limited flexibility of the forms to change what is collected

● Lack of data validation beyond data type validations

● Siloed data for analysis

VFP poses a significant problem. Due to its lack of support, it may not run on current operating systems and is not updated for security patches. This poses a significant issue and may involve security risks for filers and the FERC.

Many of the FERC forms have not changed, although data collection needs have changed. This is due in part to the difficulty in changing the systems involved in collecting and disseminating the form data. When additional data is approved for collection, often times an instruction is added to the schedule and the data is put in an existing field or footnote. This data is less structured and more difficult to use systematically.

Forms are validated in the VFP client application and on FERC systems. Currently, these validations are very limited and focused around data type validation. Additional types of validation have been identified, including cross reference validation, data existence checking, summation validations, historical data checks and code lookups.

The siloed nature of the data makes using the data for analysis challenging. Often, staff print PDF versions of data for analytical tasks, even when digital formats (i.e. database) are available.

Due to the limitations of the current forms collection process, the following requirements and supporting functionality have been identified:

Requirement Functionality Facilitate the exchange of business information from disparate internal databases and externally with other regulatory bodies.

● Data shareable internally & externally

● Supports relational databases

● Uses XML standard

● Supported by XML validation tools

15 | FERC XBRL Assessment -DRAFT | April 2018

Enable multiple relationships to be defined, specifically, information that belongs to multiple hierarchies or dimensions.

● Expresses multiple relationships

● Uses other XML-based technologies

● Supports multidimensional databases

Increase data quality by implementing formula and data validations.

● Supports simple and complex formulas

● Supported by XML validation tools

● Supported by data validation tools

Flexible and extendable system that allows changes to data structure and content to accommodate changes to reporting requirements.

● Flexibility (extensibility)

Enable programmed and ad-hoc reports while ensuring high quality presentation of data.

● Provides user-defined presentation

The following is a high level flow of the proposed refresh submission process.

16 | FERC XBRL Assessment -DRAFT | April 2018

1. The filer prepares an XML file for the form.

2. The filer can schema validate with the FERC-provided XML Schema.

3. The filer can render the XML into HTML/PDF with the FERC-provided XML stylesheet.

4. The filer can test a submission via the FERC website. This will run validations (cross check data and summations).

5. The filer submits the XML via the FERC website.

6. The XML file is rendered into PDF/HTML.

7. The rendered filing is sent to eLibrary.

8. The XML is loaded to the forms database.

The eForms Refresh Project will eliminate the use of Visual FoxPro for submission and viewing data and improve several aspects of the current form filing process. Much of the refresh project re-uses the logical data model in the current process but switches the underlying technologies (VFP client application, SQL Server, XML). However, issues in the current process will still exist including:

● The form-centric nature of the database structure. The new database model is similar to the current VFP database in that each schedule is a separate table. This provides a good data model for the collection and validation process of the form data but makes querying data across schedules challenging.

17 | FERC XBRL Assessment -DRAFT | April 2018

● Historical data will not be loaded into the forms database, time series analysis will be limited.

● Although form changes are technically easier, they will require coordination between the XML schema, the database and software that creates the XML filings. This will require developer time and coordinated updates and rollouts to the system that will take significant time.

● Validation cannot be performed locally by filers.

An aspect of eliminating Visual FoxPro from the collection process is that the FERC will no longer be providing the software necessary for filers to prepare their filings.

4.7.1 Proposed Logical Model

XML Data Capture As discussed above, the proposed logical model of the refresh redesign mirrors the existing data collection model. This has the advantage of being faster to implement and guarantees the relational integrity between the underlying data and the location of the data on the form. The structure of the XML document used to collect the data reflects that approach.

In the sample XML extract below, the line item node is used as the primary key to capture the form data. In this example of a fixed row for the balance sheet schedule (Form 1, page 110), the XML captures the schedule identifier at the top of each schedule. The XML also captures the underlying periods of 2016 and 2015, even though these values are not captured on the form.

The Line item node is used to capture the row number of the form with the ID attribute and the row name with the ItemName attribute. The values associated with the line item in columns on the form are provided in successive rows that match the column name heading.

<CompBalanceSheetAssetsSchedule ScheduleId="12"> <ForCurrentYear>2016</ForCurrentYear> <ForPriorYear>2015</ForPriorYear> <LineItem ID="1" ItemName="UTILITY PLANT"> <RefPageNo/> <CurrentYear xsi:nil="true"/> <PriorYear xsi:nil="true"/> </LineItem> <LineItem ID="2" ItemName="Utility Plant (101-106, 114)"> <RefPageNo>200-201</RefPageNo> <CurrentYear>76683196010</CurrentYear> <PriorYear>71575321308</PriorYear> </LineItem> <LineItem ID="3" ItemName="Construction Work in Progress (107)"> <RefPageNo>200-201</RefPageNo> <CurrentYear>2183195426</CurrentYear> <PriorYear>2057204814</PriorYear> </LineItem> <LineItem ID="4" ItemName="TOTAL Utility Plant (Enter Total of lines 2 and 3)"> <RefPageNo/> <CurrentYear>78866391436</CurrentYear>

18 | FERC XBRL Assessment -DRAFT | April 2018

<PriorYear>73632526122</PriorYear> </LineItem>

XML Schema The content of the XML submission is controlled by a published XML schema file that places constraints on the content of the XML file. The nature of the constraints defined in the schema include the following:

1. Enumerated values

2. Required values to be reported

3. Maximum rows to be reported

4. Minimum rows to be reported

5. Data types of the values reported

6. The structure of the form indicating which schedules are allowed in the form

7. The structure of each of the schedules

The following is an excerpt for the schema for the XML example above.

<xs:element name="CompBalanceSheetAssetsSchedule" maxOccurs="1" minOccurs="1"> <xs:complexType> <xs:sequence> <xs:element name="ForCurrentYear" type="xs:gYear" /> <xs:element name="ForPriorYear" type="xs:gYear" /> <xs:element name="LineItem" maxOccurs="85" minOccurs="85"> <xs:complexType> <xs:sequence> <xs:element name="RefPageNo" type="xs:string" nillable="false" /> <xs:element name="CurrentYear" type="moneyorempty" nillable="true" <xs:element name="PriorYear" type="moneyorempty" nillable="true" /> </xs:sequence> <xs:attribute name="ID" use="required"> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="1"/> <xs:maxInclusive value="85"/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name="ItemName" type="xs:string" use="required" /> </xs:complexType> </xs:element> <xs:element name="FootNotes" type="FootNotesType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="ScheduleId" type="xs:string" use="required" fixed="12" /> </xs:complexType> </xs:element>

19 | FERC XBRL Assessment -DRAFT | April 2018

The definition of the XML schema and example XML files is still in process and is approximately ⅓ complete.

4.7.2 Database Model

The database model of the eForms Refresh project builds upon the VFP data model. The refresh model allows for greater flexibility by allowing multiple forms in a single database and tracking form changes. The model also captures validation rules and greater metadata about forms and schedules.

Schedule Model The database contains a table for each schedule. The table for a schedule includes fields that match the columns from the form. If the schedule allows fillable reporting items, the table includes fields for the reporting item description (CustomLineItem) and a line number (CustomLineItemID).

Examples The Statement of Income schedule (Form 1, page 117) is represented by the following table. This schedule has fixed rows, all of which are tied to a specific reporting item. The schedule_TOA_fk field links the row to tables that contain the description of the line item.

Table F1_117_Statement_Of_Income

Name Type PK FK

Annual_Statement_Of_Income_ID int Yes

Filing_fk int Yes schedule_TOA_fk int Yes

CurrentYearTotal bigint

PriorYearTotal bigint

RecentlyEndedQuarterBalance bigint

PriorQuarterBalance bigint

The Officers Schedule (Form 1, page 120) is a dynamic schedule. In the table for this schedule there are the CustomLineItem and CustomLineItemID fields to capture the line item description.

Table F1_120_Officers

Officers_ID int Yes

Filing_fk int Yes schedule_TOA_fk int Yes

TitleOfOfficer varchar

20 | FERC XBRL Assessment -DRAFT | April 2018

NameOfOfficer varchar

YearlySalary bigint

CustomLineItem varchar

CustomLineItemID int

The Statement of Retained Earnings table (Form 1, page 118) has some fixed rows and some dynamic rows. The table for this schedule also has the CustomLineItem and the CustomLineItemID fields to capture the line description for the dynamic rows while the schedule_TOA_fk field links the rows to tables that contains the fixed row descriptions.

Table F1_118_Statement_Of_Retained_Earnings

F1_Statement_Of_Retained_Earnings_ID int Yes

Filing_fk int Yes

ContraPrimaryAccountAffected nvarchar

CurrentYTDBalance bigint

PreviousYTDBalance bigint schedule_TOA_fk int Yes

CustomLineItem nvarchar

CustomLineItemID int

For each of the schedule tables, there are two additional tables. One is for column descriptions and the other for capturing footnotes. The following shows the relationships for the three tables that represent the Statement of Income.

21 | FERC XBRL Assessment -DRAFT | April 2018

Form and Schedule Metadata Model Metadata about forms is stored in the lkp_Forms and lkp_Form_Ver tables. This structure allows changes to forms to be tracked in the database. Additionally, metadata about schedules is stored in the lkp_schedules table, lkp_schedule_TOA and lkp_Title_of_Accounts tables.

22 | FERC XBRL Assessment -DRAFT | April 2018

Validation Rules Model The database maintains three types of validation rules:

1. Row validation - This type of validation sums values down a column and checks it against a total row.

2. Column validation - This type of validation sums values across columns on a row and checks it against a total column value.

3. Cross reference checks - This type of validation checks values reported on different schedules.

Row validation rules are stored in the Row_Calculations and Row_Calculations_ParticipatingColumns tables. The Row_Calculations table identifies the total row and contains the calculation rule for which rows to add and subtract. The Row_Calculations_ParticipatingColumns table identifies which columns are calculated for the row calculation.

Column validation rules are stored in the Column_Calculations and Column_Calculations_NonParicipatingRows tables. The Column_Calculations table identifies which columns to add and subtract for the total column. The

23 | FERC XBRL Assessment -DRAFT | April 2018

Column_Calculations_NonParticipatingRows table identifies which rows will NOT be used for a column validation. All other rows will be used for the column calculations.

Cross reference validation rules are stored in the CrossRefCalculation_LeftSide and CrossRefCalculation_RightSide tables. The left side table identifies a single value from a schedule. The right side table identifies one or multiple values from another schedule that are combined to match the left side value.

4.8 Data Analysis

The data captured in the systems described above is analyzed and used by downstream users for compliance and analysis purposes. The data is available in both SQL databases and a central VFP database that is not available to the public.

24 | FERC XBRL Assessment -DRAFT | April 2018

4.8.1 Visual FoxPro Database

The VFP database is made available to the public using discrete databases representing a single year of filings. The staff at the FERC have a consolidated database comprising all years that is used for analysis for each form type. This database resides on the FERC internal network.

FERC users of the Visual FoxPro database connect to it using a FoxPro ODBC driver. This driver is typically used to pull data into an Access database or Excel spreadsheet. All of these applications incorporate user defined queries that pull data from the central VFP database. These queries typically allow the extraction and comparison of data across periods. Any proposed changes to the database structure would have a direct impact on these downstream queries which are custom built based on the VFP table structure. The complexity of the queries differs between users and the number of these queries that have been written are numerous. Any proposed changes to the existing structure needs to facilitate continued support and operation of these queries as they are critical to the day to day activities of the FERC. Any transition to a new structure would also need to consider a transition path to allow continued support for these end user applications with minimal impact on existing processes. At the same time, there are inherent limitations in these applications which any proposed system needs to address. Specifically, many are tied to the existing form structure, therefore, any change to the forms requires these downstream applications to be updated.

Use of VFP data The data in the VFP database is used to analyze the following:

● Status of submissions by regulated entities

● Audit of OATTS submissions

● Year over Year analysis by form

● Building Models

The analysis of this data is done over the following form types

● Form 1

● Form 2

● Form 6

● Form 60

● Form 714

4.9 Current State Observations

The following are observations from the analysis of the current state.

Multiple collection data formats The FERC collects data using different data formats for different collection systems. For forms collection, the refresh project will replace the current VFP format with an XML format. As EQR and eTariff are already using XML for data collection, this will unify the collection format as XML.

However, XML on its own is only a partial data standard. Each of the types of collection have different schemas which define very different structures for the XML data.

25 | FERC XBRL Assessment -DRAFT | April 2018

None of the data collection methods use industry standards. Each collection data format is a proprietary format.

Form centric approach The entire process of data collection is based on the structure of the forms and schedules.

Although this supports the collection process, it creates the following issues:

1. Filers are focused on filling out forms which distracts from thinking about the true nature of the data that they provide.

2. The collected data is difficult to query and analyze.

3. Changes to the forms are harder because the form structure is “baked into” the collection process.

The form approach is based on a legacy means to collect data based on a paper format. Modern collection systems focus on identifying well defined data and not on the presentation of data (in a form).

Structured data in unstructured fields There is data that is structured by nature but not captured in a structured way. Because of this, this data becomes effectively unstructured and is difficult to query and analyze.

Siloed data Data is heavily siloed. This significantly hampers use and analysis of the data across data sets.

Entity identification Entities have different methods of identification. On the forms, identification is done by respondent

id. The respondent id is made by the entity that files the form. A filing may represent many entities, which may or may not have respondent ids.

In EQR, identification is done by company id (cid). These are separate from the respondent id.

A unified system of entity identification would have significant advantages for data validation and analysis.

26 | FERC XBRL Assessment -DRAFT | April 2018

5 Proposed Solution The recommendation of this assessment is to integrate XBRL with the forms collection process.

The forms collection process covers the flow from filer preparation to rendered forms and data loaded into databases for internal and public analysis. This proposal identifies how XBRL is implemented for each step of the collection process.

5.1 Forms collection process

The main steps of the form collection process are:

1. Filer prepares data

a. Filer can validate the data

b. Filer can render data

2. Filer submits via FERC website

3. FERC submission processing

a. FERC validates

b. FERC renders to PDF

c. FERC loads database

d. Rendered forms are made available to public via eLibrary

e. Data is made available to public

4. Form/schedule management

The table below provides a comparison of the collection flow for eForms Refresh and XBRL.

eForms Refresh XBRL

1. The filer prepares data:

This step replaces the current VFP application that is disseminated to filers to create and submit a form.

The FERC provides an XML schema. The filer uses the schema to create an XML document for submission. Filers can use standard XML tools to create the XML document or integrate the creation of the XML document into existing systems.

The FERC provides an XBRL taxonomy. The filer uses the taxonomy to create an XBRL instance document. Filers can use standard XBRL tools to create the XBRL document or integrate the creation of the XBRL document into existing systems.

a. Filer can validate the data

With the XML schema, basic validations (data type validation and XML structure) can be performed with standard XML tools by the filer.

Like an XML schema, an XBRL taxonomy provides basic validation (data type), however the taxonomy can contain all other

27 | FERC XBRL Assessment -DRAFT | April 2018

Beyond the basic validations that can be done with the XML Schema, the filer can perform a test submission to run data consistency validations on the FERC systems.

validations, allowing the filer to validate locally.

Additionally, the filer has the option to perform a test submission to run validations on the FERC systems.

b. Filer can render data

Via the test submission, the FERC can provide a PDF rendered version of the submissions. In addition, the FERC could provide the XML stylesheet (XSLT) to allow the filer to perform rendering locally.

Via the test submission, the FERC can provide a rendered version of the submissions in HTML or PDF. In addition, the FERC could provide rendering code or an XML stylesheet (XSLT) to allow the filer to perform rendering locally.

2. Filer submits via FERC website

For both XML and XBRL the submission process is the same. The filer can submit via the FERC website or possibly submit via an API.

The website option allows the user to login, select the file (XML for eForms Refresh, XBRL instance document for XBRL solution) and submit. Feedback from the website will be acceptance or rejection of the file, validation results and rendering results. The filer will also have the option to send a test submission which will provide the validation results and rendering results without accepting the file as submitted.

The API provides the same features as the website option but is invoked programmatically.

This allows filers and vendors to integrate the submission process into their own software.

3. FERC submission processing

a. FERC validates

FERC validates the XML document with the schema and runs validations rules. The rules are stored in the SQL Server database and processed with custom code.

FERC validates the XBRL document using the FERC XBRL taxonomy.

b. FERC renders to PDF

28 | FERC XBRL Assessment -DRAFT | April 2018

An XML stylesheet is used to render the XML document into a PDF document.

A rendering program is used to render the XBRL document into HTML. This is then converted to a PDF document.

c. FERC loads database

The XML document is loaded into a SQL Server forms database.

The XBRL document is loaded into a SQL Server forms database. In addition, the data can be loaded into an XBRL database.

d. Data is made available to public

The SQL Server data is made available on the FERC website on a periodic basis. This data contains multiple submissions over a period of time (quarterly/yearly).

The rendered PDFs are made available on eLibrary.

The XBRL database (SQL Server) is made available on the FERC website.

The rendered HTML and PDFs are made available on eLibrary.

4. Form/schedule management

Form/schedules are modeled in XML schema, SQL Server and the XML stylesheet (XSLT). The XML schema is used to validate XML submissions. SQL Server is used to collect the data for analysis and to maintain validation rules. The XML stylesheet is used to render the XML submission into PDF.

Changes need to be made by IT.

Form/schedules are modeled in an XBRL taxonomy and SQL Server. Rendering information and validation rules are included as part of the taxonomy. Modeling changes in the taxonomy can be made by business users.

5.2 Implementation options

The primary change required to implement XBRL is to replace the eForms Refresh XML document that the filer submits, with an XBRL document. From the filer perspective, it is a matter of producing an XBRL document instead of the eForms Refresh XML document.

Two options are presented on how to handle the downstream processing. The collection process for each option start with the filer submitting an XBRL document. The two options are shown in the diagram below:

29 | FERC XBRL Assessment -DRAFT | April 2018

Opti…