Nodal RTM Settlement Timeline Snapshot Timing for Load and Gen Data (Follow-Up) Mandy Bauld COPS November 10, 2009

Topic Refresher Proposed Nodal settlement schedule will advance the capture of generation and load data for use in settlements by 1 day Zonal Timeline for gen/load data capture for use in settlements: Generation: Operating Day + 8, + 57, + 178 Load: Operating Day + 8, + 57, + 178 Nodal Timeline for gen/load data capture for use in settlements: Generation: Operating Day + 7, + 56, + 177 Load: Operating Day + 7, + 56, + 177 The timelines for running settlement calculations which use Data Agg data and for posting the statements do not change Raised to COPS as a matter of transparency and to ensure that ERCOT considered all impacts

COPS Request for Follow-Up Summarize comments/questions received from COPS members Summarize the pros and cons discussed at COPS 10/13 Recommendation for transparency to the process Summarize other points of interest Comment on early posting of Settlement Statements

COPS Feedback Summarize any comments/questions received from COPS members since 10/13 None received to date

Pros / Cons Pros Cons Allows for Data Agg validation (and backout/rerun if necessary) prior to use of the data in the “next step,” thus minimizing the risk of a back-out / rerun on all other settlement jobs TDSP and ERCOT EPS meter data processing timeline loses 1 day Splitting the RTM settlement into 3 modular jobs: (1) RTM settlement not dependant on Data Agg, (2) Data Agg, and (3) RTM settlement dependent on Data Agg, allows flexibility to run the batch jobs according to the schedule and timing that best accommodates all DAM, RTM, and Zonal batch jobs NOIE data submittal processing timeline loses 1 day Reduction in percentage of NIDR data available for RTM Initial settlement

Recommendation for Transparency Describe this process in the COPS Market Guide Be clear that this process is the “happy path” scenario Caviat that if ERCOT experiences system issues the timeline may vary (e.g., batch running long or issues that result in a rerun of Data Agg later than scheduled) If there is a need to change the methodology for the “regularly scheduled” timing of this process, it would go back to COPS through the COPS Market Guide revisions process

Other Points of Interest TDSPs are planning to have AMS data to ERCOT by Op Day + 6, therefore the proposed schedule (Op Day + 7) would accommodate the expedited AMS submissions. The TDSP planned AMS data submission exceeds Protocol expectations of every 38 days, where data is typically not available at Initial Settlement. The last Zonal Initial Settlement and the first RTM Initial Settlement would use the same load data

Early Posting Current Nodal Protocols use “on” rather than “by” language PR 9.2.2(1) “ERCOT shall make each Settlement Statement for a DAM available on the date specified on the Settlement Calendar for that DAM …” PR 9.5.2(1) “ERCOT shall make each Settlement Statement for the RTM available on the date specified on the Settlement Calendar for that Operating Day…” ERCOT sees value in having a predictable schedule Early posting could have unexpected consequences on billing cycles. It is possible that a statement expected to hit the next billing cycle would end up on the current billing cycle, instead. Stmt scheduled to post 11/7, but posts early on 11/6 Moves from the 11/19 invoice back to the 11/12 invoice 11/12 invoice is “heavy” and the 11/19 invoice is “light”

Appendix Slides from 10/13 COPS

Why the change? Increased number of Operating Days to be processed in the settlement system on a daily basis and to be verified by business on business days Zonal Initial, Final, True-Up*, Resettlement Nodal DAM, DAM Resettlement Nodal Initial, Final, True-Up*, Resettlement *Zonal True-Ups should be complete prior to start of Nodal True-Ups and therefore these jobs should not compete Need to minimize the risk of a back-out / rerun on all other settlement jobs Zonal: Data Aggregation and Settlements run in one batch, no opportunity for modularized verification before proceeding to the “next step” Nodal: Data Aggregation and multiple Settlements jobs run in separate batches, allowing data verification of each job before starting the “next step,” and reducing impact of a back-out/rerun when necessary Need to reduce risk of posting statements and invoices late when verification identifies errors and a back-out/rerun is necessary

Nodal Schedule for Settlement Use of Meter Data "Operating Day + ... "   Zonal Nodal Initial Final True-Up EPS Data Captured 8 57 178 7 56 177 Load Data Captured Settlement batch using Gen & Load Settlement Statement Posting 10 59 180

Assumed Impact to Market Participants TDSP and ERCOT EPS meter data processing timeline loses 1 day QSEs with load should recognize which day was the “cut-off” for purpose of ERCOT’s calculation of Real-Time Adjusted Meter Load (RTAML)