Add New Field Claim.SavingsDateField to the 2025 Claim Specification Update

Hi - I’m concerned about the language here. The “SavingsDate” and the ClaimYearQuarter are not in alignment. ClaimYearQuarter is based on when the measure is paid and claimed, but SavingsDate would be based on when the savings were determined (application date or one of the other rules for deemed, post-install review date for custom (after M&V completes)). These can be even years apart in some programs (like new construction) for Deemed. I think the ClaimYearQuarter piece of this needs to be removed, and this should just focus on what data was used to determine measure package eligibility. I also don’t think Savings date should be a required field for Custom, as it would be duplicative and there wouldn’t be any validation needed on the custom side (as any date is valid).

Thanks, Greg. SoCalGas is in alignment with the points made by SDG&E for adding the new field ‘SavingsDate’ to the 2025 Claim Spec update.

This sounds good to me, it would help simplify the date-based rules we have currently.

We may want a second field where the PA can say how they populated the SavingsDate field. If we do, I expect we would want to add an option list for the second field so that all PAs describe it in the same way. Some options might be:

• ApplicationDate minus 60 days

• InstallationDate

• PaidDate

We could also then potentially add a rule that the SavingsDate be within the ClaimYearQuarter for each measure.

This enhancement was requested for inclusion in the 2025 Claim Spec update when IOU's are already required to update their backend systems with several new data points/logic.

SDGE saw this enhancement as more of an opportunity to consolidate the CEDARS validations after an initial check that IOUs have correctly implemented the rules to set the SavingsCalcDate.

If Jen and Sound Data are fine with running the rules on the CEDARS side and outputting which field was used by CEDARS for the validations, SDGE is also fine with that.

Thanks,

Greg.

Let’s make a final call on this at the PCG meeting. We want to go forward with having CEDARS output the date used for the eTRM/DEER validations.

“SavingsDate” seems duplicative if it is a date that we are already submitting in one of the existing DATE fields in the claim spec. However, adding a field to inform the date for the savings claim validation seems reasonable to me.

This field could be a descriptive field that tells what date field to use, or a field where the date to be used is populated, or both. TBD

During the PCG meeting on April 3rd, it was suggested that instead of adding a field and updating the validations, CEDARS could display in the output which date field validation was used for the savings date.

@cedars team @Amy Reardon @jake.richardson@pge.com

PG&E would support the path that CEDARS Dev Team ultimately recommends implementing.

• I will emphasize that the addition of the new field and logic requires an update to PG&E’s back-end systems.

• I believe, regardless of whether SavingsDateField is implemented or not, outcome is the same that CEDARS must still run all the DATE validations in the back end:

  - Option #1: Adding SavingsDateField requires back-end development in CEDARS and in PAs’ systems.

  -Option #2: In absence of SavingsDateField, only CEDARS development is required but the effort is minimal compared to option #1.

  CEDARS would output the DATE used in the deemed savings validation to PA and public record-level outputs in CEDARS dashboard.
  
  Thank you!