Review of demand charges in energy billing transactions

[CDR-API-Stream]

Description

In the recently published candidate standards for energy demand charges were incorporated into the billing payloads. This was, however, a late addition to the payload so there is concern that the structure may need amendment.

Area Affected

Energy APIs and payloads

Change Proposed

Determine if the structure for demand charges in the energy billing transactions payload needs amendment.

[CDR-API-Stream]

This change request is created to allow the community to review and provide feedback on the demand charges object incorporated into the billing payload. The demand charge can be viewed in the billing endpoints on the standards page - https://consumerdatastandardsaustralia.github.io/standards/#get-billing-for-account

Full feedback for candidate billing & invoice payloads can be found on decision proposal 198 - ConsumerDataStandardsAustralia/standards#198

[priyaH-OriginEnergy]

For C&I customers, we recommend displaying Demand charges within the “otherCharges” section provided that the enumeration for this transaction type is clearly defined for network charges. This is because Demand charges (if applicable for C&I customers) are passed through from the Network and can also include other Fixed or Volume based charges

We request for the attributes within the otherCharges section to also be reviewed as per below

• Demand charges do not have a time of use definition
• Billing unit of measure cannot be assumed as this can vary based on tariffs. for example $/kw, $/kva etc
• Similarly, usage unit of measure also cannot be assumed. It can be kw, kva, kvarh, kvar etc.

[CDR-API-Stream]

Thanks for the feedback @priyaH-OriginEnergy.

we recommend displaying Demand charges within the “otherCharges” section

With regards to the request to have demand charges within "otherCharges", the reasoning is unclear. Can you elaborate more on the reason for this request?

Demand charges do not have a time of use definition

The timeOfUseType is defined along with the ENUM values in the EnergyBillingUsageTransaction schema which can be found here - https://consumerdatastandardsaustralia.github.io/standards/#tocSenergybillingtransaction

We can discuss the above in today's maintenance call

[priyaH-OriginEnergy]

Hi,

With regards to the request to have demand charges within "otherCharges", the reasoning is unclear. Can you elaborate more on the reason for this request?

Demand charges for C&I customers belong to the Network Charges that get passed on to the customer based on their Network Tariff and are not calculated separately by Retailers (unlike mass market). Network charges can also include other fixed or volume based charges too

Given that the recommendation from the DSB was to utilize "otherCharges" to represent Network Charges (assuming an enumeration list will be added to represent various transaction types), we think that Demand Charges should stay within the same block. Further to this, demand charges do not have a "time of use" value associated. Therefore the structure of the demand charges block does not suit C&I customers

Thanks!

[CDR-API-Stream]

Given the late feedback received, the DSB proposes this request be carried over to the next maintenance iteration to enable further assessment of the change request.

[CDR-API-Stream]

The recent maintenance iteration call discussed the feedback from @priyaH-OriginEnergy

The DSB's understanding is that demand charges are not calculated or captured separately for C&I customers. They are incorporated as part of network charges.

Based on the above, the DSB suggests no change should be made as otherCharges already allows capturing network charges, which would include demand charges for C&I customers.

Feedback on this issue would be welcome. If further clarification or justification is provided, inclusion of demand charges within otherCharges will be considered, otherwise no changes are recommended at this time.

[CDR-API-Stream]

Based on consultation in Maintenance Iteration 10 it was agreed with the community that no change is required. Accordingly, this issue will be closed.