NY EDI Changes Filed to Accommodate ESCO Credits Required To Be Provided to Low-Income Customers
April 08,2015
A New York EDI working group has filed changes to EDI standards to accommodate credits which ESCOs may be required to issue low-income utility assistance program participants (APP) as a condition of serving such customers, and also filed other EDI revisions, including changes relating to the contest period and sales tax information.
Under the New York PSC's recent retail market order, ESCOs may only serve utility assistance program customers if they guarantee savings versus default service, or provide a value-added service (which may include a value-added fixed rate). In cases where the ESCO is permitted to serve the APP customer by guaranteeing that the customer will pay no more versus default service, the ESCO may comply with this mandate through the issuance of credits at the end of the customer's term.
The EDI changes, among other things, address the issuance of such credits by ESCOs to APP customers to ensure that the customer does not pay more than default service, both under Utility Bill Ready (“UBR”) and Utility Rate Ready (“URR”) billing
The EDI Working Group also revised the EDI Standards Documents to:
• Accommodate the use of EDI for Service Portability
• Facilitate ESCO Contest Period Reinstatement Requests
• Modify language to reflect accelerated switching changes
• Clarify language regarding provision of sales tax rates for URR billing model
APP Credits
Regarding the provisions of credits to APP customers, the working group said that the EDI Standards modifications necessary to accommodate bill credits on utility consolidated bills vary by billing model. Under the Utility Bill Ready model, receipt of the APP Credit is functionally similar to receipt of other ESCO credits or charges. Utility Rate Ready Model implementations differ fundamentally; there is no corresponding means to receive credits of any kind. Further, while UBR amounts are calculated by ESCOs and summed by the utility for presentation, the core of the URR model is multiplication of an ESCO provided rate times the customer’s usage. In addition to receipt of the APP Credit, URR utilities must significantly modify their business systems in a fundamental manner and develop a “UBR-like” functionality to process the APP Credit as a part of the bill calculation. UBR utilities will also have to modify their business systems but not in a fundamental manner.
More specifically, APP customer credits from ESCOs will be implemented as follows:
UBR Approach
The APP Credit will be communicated to the utility via an incoming 810 UBR Invoice transaction in the Segment: SAC Service, Promotion, Allowance, or Charge Information (Charges/Adjustments), using a new code CRE030. If the 810 transaction containing the APP Credit passes the utility’s validation tests, the Utility will apply the credit to the customer’s next bill and send an 824 Application Advice (Positive) transaction to the ESCO confirming acceptance of the APP Credit.
URR Approach
The EDI Working Group investigated the concept of creating an incoming 810 URR Invoice transaction, analogous to that present for the UBR model, but determined that modifications to the 814 Change Request and outgoing 810 URR Invoice transactions were more consistent with the fundamental design of URR billing systems. The preferred URR solution is for the ESCO to send an 814 Change using a new segment AMT*7 (Assistance Program Participation Credit) with Reason for Change AMT7. If the APP Credit passes the utility’s validation tests, the Utility will apply the credit to the customer’s next bill and, based on the same code, include the amount in the outgoing 810 URR Invoice transaction.
APP Credit Presentation/Billing Window Issues
The EDI Working Group developed the EDI modifications under the assumption that the ESCO issuing the APP Credit will most often be the ESCO serving the customer when the credit is issued. Under this assumption, the APP Credit should be presented in the same section of the bill as other ESCO charges. In addition to adjusting the amount due from the customer, the utility will reflect the effect of the ESCO’s APP Credits in the 820 - Remittance Transaction by reducing the Purchase of Receivables payment to the ESCO from what would otherwise be due.
The EDI Working Group noted that there will be some circumstances under which the utility may not be able to process the APP Credit. For example, if the customer has moved outside the utility’s service territory, has switched to an ESCO that issues an ESCO Consolidated Bill (“ECB”), or otherwise closed their utility account, the ESCO should issue the APP Credit directly to the customer.
Another circumstance under which the utility may or may not be able to process the APP Credit is when the customer has switched to another ESCO or to utility full service but the utility is still issuing a bill to the customer. When an 814 Change transaction is received from an ESCO not currently serving the customer (“Former ESCO”), the utility’s usual course of action is to reject the transaction. Similarly, UBR utilities will reject inbound 810 Invoice transactions from Former ESCOs. To accommodate this circumstance, utilities will either need to modify the validation rules for their systems to accept 814 Change transactions (or for UBR utilities, in-bound 810 Invoice transactions) containing APP Credits or provide a non-EDI means, such as a web portal, under which a Former ESCO can provide APP Credits to the utility.
Absent any of the above circumstances for a utility to not accept and process an APP Credit received from a Former ESCO, such APP Credit will be presented on the customer’s bill separate from the current ESCO charges in order to minimize customer confusion. Subject to modifications discussed above and corresponding billing system modifications, utilities should be able to present the APP Credit elsewhere on the bill and reduce the amount due from the customer. The EDI Working Group also noted that even when APP Credits from Former ESCOs can be presented on customer bills, 820 – Remittance transactions are limited to reflecting payments for the current ESCO’s customers. Preliminary EDI Working Group discussions of modifications to the 820 – Remittance transaction were not fruitful but other alternatives, including provision of remittance advice to Former ESCOs in a non-EDI format, may yet be identified.
Finally, for some utilities, the billing window is the time period prior to issuance of the utility consolidated bill during which the utility will accept billing items (for UBR) or rate changes (for URR). If an ESCO misses the billing window but continues to serve the customer, the APP Credit will slip to the next bill. If, however, the utility has a pending switch to another ESCO or will no longer be issuing a bill to the customer for one of the reasons discussed above, the utility may reject the APP Credit. Other utilities reject rate changes during the billing window, and therefore would reject the APP Credit also received, even from the current ESCO, during the billing window.
Supplemental APP Credit-Oriented EDI Changes
While the EDI Working Group has developed EDI Transactions necessary to accommodate bill credits, there are other potential EDI transactions that may help ESCOs to calculate customer APP Credits, the working group said. For example, the EDI Working Group plans to discuss whether a new transaction to provide customer Utility Full Service billing amounts to the ESCO should be provided to improve accuracy and calculation efficiency. Additionally, further EDI Standards development to address the above-mentioned issues associated with APP Credits from Former ESCOs may narrow differences in utility APP Credit implementations.
APP Credit Implementation and Testing Timeline Observations
With respect to EDI changes necessary to accommodate APP Credits, the PSC's order has stated that any required testing by utilities and ESCOs must be completed, and the EDI transactions must be operational, within 120 days from the date of the compliance filing, i.e., in early August 2015. In isolation, this timeline is aggressive, particularly for URR utilities, the working group said. Beginning in September 2015, utilities and ESCOs will be testing other previously filed EDI changes to be implemented by November 2, 2015. Prior to September, ESCOs and utilities will be modifying business systems to support these EDI changes. Rather than diverting resources to test APP Credit EDI changes, the Working Group observed that from a technical perspective it may be more cost effective for and place less stress on both ESCOs and utility technical resources to coordinate APP Credit EDI transaction testing with the November EDI changes.
Other Changes
The EDI Working Group developed modifications to the 814 Drop transaction to accommodate EDI Contest Period Reinstatement Request. Initially proposed in 2009, use of EDI for the Contest Period reinstatement request is voluntary and to date, most utilities have been able to process such requests manually due to the low volume of requests in their territories. The EDI Working Group’s modifications are designed to address technical conflicts present in some utility EDI implementations that may, in part, have prevented a wider implementation of EDI-based processing of Contest Period reinstatement requests. By including the instant EDI modifications, the EDI Working Group is not proposing that use of EDI for contest period reinstatement requests be mandatory; where requests can adequately be processed manually there is no technical reason for a change in current practice
Consistent with Con Edison’s current EDI Implementation, the EDI Working Group is also including modifications to the 814 Enrollment to accommodate Service Portability, i.e. retention of a customer’s ESCO service across accounts when the customer relocates within the same service territory. While the practice of service portability is addressed within the UBPs, most utilities have been able to process such requests manually due to the low volume of requests in their territories. By including these modifications, the EDI Working Group is not proposing that use of EDI for service portability requests be mandatory; where requests can adequately be processed manually there is no technical reason for a change in current practice.
With regard to ESCO provision of sales tax rates provided for URR billing, the EDI Working Group has also modified the 814 Change and 814 Enrollment EDI Standards Documents to clarify use and interaction of various EDI Segments. Support of these segments is voluntary; i.e., at the utility’s discretion. Because the modifications reflect existing URR implementations, they do not require further testing or have an associated implementation date. By including these modifications, the EDI Working Group is not proposing that use of EDI for sales tax rates be mandatory; where requests can adequately be processed manually or other non-EDI means, there is no technical reason for a change in current practice, the working group said