Decision Proposal 116 - Billing Data Payloads

[CDR-API-Stream]

The decision proposal for Energy Billing data payloads is attached below:
Decision Proposal 116 - Billing Data Payloads.pdf

Feedback is welcome on this proposal. This thread will remain open for feedback until the 9th of November.

As previously discussed in various forums, the practice of the DSB is to respond to feedback incrementally before the consultation is complete to promote an interactive style of consultation.
Participants are therefore encouraged to provide feedback earlier in the consultation process so that the community can work together to a consensus outcome.

[SArn-erg]

I note the usage lines do not have the facility for metering charges or daily connection charges. These are separate from the usage calculation.

[SArn-erg]

Time of Use type does not have an allowance for season. There are some seasonal TOU tariffs in Regional Queensland.

[SArn-erg]

Tariff 14 – Residential Demand
This is a ‘Demand tariff’, which is new type of tariff only available to customers with smart meters. Essentially, customers receive lower supply and usage charges, however a ‘demand charge’ is incurred in the peak summer months. A demand charge is a daily charge that reflects a customer’s peak time usage in a 30-minute period between 4pm and 8pm. For example, if you’re charged a 20c/kWh demand tariff, and you use a maximum of 3kWh of electricity in a 30 minute period, you will be charged 60c per day. This charge resets every month.

[SelenaLiuEA]

Hi All,

EA’s response below relates to mass market and small business customers. It is not yet clear whether large commercial and industrial customers will be in scope for the CDR and this will be determined by the ACCC in their CDR Rules. We will need to confirm large customer billing data payloads if this is looking likely.

We also note that the overall purpose of the billing data is unclear. Beyond total billed amount, the billing items are very complex and non-standardised (other than what is required by regulation). It will be highly unlikely that the billing items can be combined with usage data and tariff data, to produce reliable bill estimates. We question the utility of requiring the specific billing data. We note that this issue will be determined by the ACCC at a policy level but that the DSB’ work on billing data payloads will need to follow this direction. It's also unclear how the different retailer provided data sets will be used together.

Invoice Common Type

1. How do the invoice common types relate to the billing transaction types? Is the former a high level description of the latter?
2. invoiceNumber – Is this the same as a bill ID number i.e. unique number for a bill? Our bill numbers do not show on the bill, but our system can produce this number. However, other retailers may not be able to produce this and so I suggest this be changed to Optional.
3. issueDate – the National Energy Retail Rules and Energy Retail Code specify regulated contents of a bill and that a bill must contain the “bill issue date”. We suggest that this should be the data that meets this Object Type and that this be clarified in the payload description. This is to cover situations where the bill generation and bill issue date may be different. Links to relevant regulations follow - Rule 25 is the main section for billing contents: https://www.esc.vic.gov.au/electricity-and-gas/codes-guidelines-and-policies/energy-retail-code and https://www.aemc.gov.au/regulation/energy-rules/national-energy-retail-rules/current
4. period – Again, it would make sense that this means billing period as per the regulations. We also assume that the startDate and endDate correspond with this period
5. amountDue for the invoice - This could be taken to mean the account balance as at the date the bill is issued (including that bill) with adjustments applied, or it could mean the amount for that single, current bill.

• EA can produce both data points but this should be clarified.
• Pay on time discounts also present a unique issue – as this affects the amount of the bill depending on whether the customer pays on time (during the short period it’s unknown whether the customer will pay on time). Our system calculates the bill amount that’s payable but then the pay on time discount amount is separately calculated and presented on the bill.
• We would prefer that the current bill amount does not include the deduction for the pay on time discount (remembering that it would be uncertain whether the customer will actually pay on time).
• Payment plans also present another issue, as a separate amount that the customer has to pay, which is likely to be different from the bill amount again. This is not necessarily an issue but I wanted to point this out so the DSB can clarify that payment plan amounts are not what the DSB is alluding to in their billing payload definitions.

6. BalanceAtIssue – we take this to mean the account balance at the time of the bill, including the current bill amount and adjustments on the account. This could overlap with amountDue as discussed above, and can be resolved by changing the definition and making this clear.
7. electricity is defined as charges and credits related to energy usage. We note that Daily Supply Charges are another typical and key category of charge that could be separated out, and to a lesser extent, Demand charges.
8. totalAccountDiscounts – we point out that some discounts will not be whole of bill but only relate to discounts of usage charges. This seems like it can be reflected in this data object, but we just point out the complexities if this data were used to try to recreate or estimate what a bill should have been. Other variations of discounts to be aware of:

• Ongoing vs one off discounts
• Fixed rate (dollar amount) discounts vs percentage based discounts.

9. All charges and credits should be optional as it is possible that an innovative product may not charge a Usage charges or Daily Supply Charge for instance, and may structure their prices in a completely different way.
10. How will bill reversals be treated i.e. what is the bill for the purposes of billing data under the CDR?

Billing Transaction Common Type

11. transactionUType – is defined as the Indicator of the type of transaction object: (1) usage (2) onceOff (3) payment. Our way of thinking about billing transactions is higher level and different:

• Bill segment (billing item charges) which can include once off charges and regular charges (usage or daily supply charges for instance)
• Adjustments which can be additions or deductions (credits) on an account. They can include charges for services though.
• Payments which we assume are payments by the customer – but which won’t necessarily correspond to a bill. i.e. one Payment made by the customer may be paid over multiple bills or only pay part of a bill.

12. Usage –

• usage – definition reflects the period in kWh. This seems to be accumulated and will not reflect usage during different time of use periods which may be relevant for time of use pricing.

13. timeOfUseType – This category likely needs further work to ensure that all different tariffs are reflected. We will come back on this next week.

14. Tariff information (i.e. $ per kWh) doesn’t appear to have been included in these billing data payloads – which seems logical as it would better fit in tariff payloads, but this means it may not be apparent which tariffs apply to a particular bill. Even if historical tariff data was delivered under tailored tariff payloads, it would be difficult to reconcile which tariffs apply to each bill.

Cheers
Selena

[CDR-API-Stream]

I note the usage lines do not have the facility for metering charges or daily connection charges. These are separate from the usage calculation.

These are expected to be included in the totalOnceOffCharges and totalOnceOffDiscounts fields in the invoice structure and in the onceOff object in the transaction structure.

[CDR-API-Stream]

Time of Use type does not have an allowance for season. There are some seasonal TOU tariffs in Regional Queensland.

The structures in the billing proposal do not seek to contain tariff information, only the resulting charges. As these are time dependent it is assumed that seasonal pricing will be applied at the time of the charge or invoice being generated.

[CDR-API-Stream]

Hi @SArn-erg, in response to this comment:

Tariff 14 – Residential Demand
This is a ‘Demand tariff’, which is new type of tariff only available to customers with smart meters. Essentially, customers receive lower supply and usage charges, however a ‘demand charge’ is incurred in the peak summer months. A demand charge is a daily charge that reflects a customer’s peak time usage in a 30-minute period between 4pm and 8pm. For example, if you’re charged a 20c/kWh demand tariff, and you use a maximum of 3kWh of electricity in a 30 minute period, you will be charged 60c per day. This charge resets every month.

Could you expand on the applicability of this to the payloads in the proposal? It isn't clear as to what part of the proposed standard this is a comment on or what the impact would be.

[CDR-API-Stream]

In respons to @SelenaLiuEA:

Thanks for the comprehensive feedback. Detailed responses are below. The general notes around utility of billing data and the applicability to large corporate customers is more policy related so will be left to the ACCC rules consultation and potentially to Treasury. Any feedback on how you see the introduction of large commercial customers may potentially impact the standards would, however, be beneficial as it would test the future flexibility of the standard.

Invoice Common Type

1. How do the invoice common types relate to the billing transaction types? Is the former a high level description of the latter?

Yes. That is the intent.

2. invoiceNumber – Is this the same as a bill ID number i.e. unique number for a bill? Our bill numbers do not show on the bill, but our system can produce this number. However, other retailers may not be able to produce this and so I suggest this be changed to Optional.

Thank you for this feedback, it was intended that it was the bill ID assigned by the retailer and it was assumed that all invoices would have this. The need for optionality will be considered.

3. issueDate – the National Energy Retail Rules and Energy Retail Code specify regulated contents of a bill and that a bill must contain the “bill issue date”. We suggest that this should be the data that meets this Object Type and that this be clarified in the payload description. This is to cover situations where the bill generation and bill issue date may be different. Links to relevant regulations follow - Rule 25 is the main section for billing contents: https://www.esc.vic.gov.au/electricity-and-gas/codes-guidelines-and-policies/energy-retail-code and https://www.aemc.gov.au/regulation/energy-rules/national-energy-retail-rules/current
4. period – Again, it would make sense that this means billing period as per the regulations. We also assume that the startDate and endDate correspond with this period

Thank you. This is helpful feedback.

5. amountDue for the invoice - This could be taken to mean the account balance as at the date the bill is issued (including that bill) with adjustments applied, or it could mean the amount for that single, current bill.

• EA can produce both data points but this should be clarified.

It is intended to be the former. The amount due with current balance incorporated.

• Pay on time discounts also present a unique issue – as this affects the amount of the bill depending on whether the customer pays on time (during the short period it’s unknown whether the customer will pay on time). Our system calculates the bill amount that’s payable but then the pay on time discount amount is separately calculated and presented on the bill.
• We would prefer that the current bill amount does not include the deduction for the pay on time discount (remembering that it would be uncertain whether the customer will actually pay on time).
• Payment plans also present another issue, as a separate amount that the customer has to pay, which is likely to be different from the bill amount again. This is not necessarily an issue but I wanted to point this out so the DSB can clarify that payment plan amounts are not what the DSB is alluding to in their billing payload definitions.

The intention of this payload is that the information included on the bill at issue is presented. If discounts for on time payment are not included in the amount due on the issued bill then it is reasonable to exclude it. This detail would be picked up under the transaction end points so is still shareable.

1. BalanceAtIssue – we take this to mean the account balance at the time of the bill, including the current bill amount and adjustments on the account. This could overlap with amountDue as discussed above, and can be resolved by changing the definition and making this clear.

That is the intent. We can clarify the descriptions.

2. electricity is defined as charges and credits related to energy usage. We note that Daily Supply Charges are another typical and key category of charge that could be separated out, and to a lesser extent, Demand charges.

This could be reasonably accommodated as account level once off charges or usage based once off charges. It would be at the discretion of the retailer as to how they categorise each charge.

3. totalAccountDiscounts – we point out that some discounts will not be whole of bill but only relate to discounts of usage charges. This seems like it can be reflected in this data object, but we just point out the complexities if this data were used to try to recreate or estimate what a bill should have been. Other variations of discounts to be aware of:

• Ongoing vs one off discounts
• Fixed rate (dollar amount) discounts vs percentage based discounts.

Thanks you for this feedback. If there are any that cannot specifically be accommodated in the proposed structure please let us know as this may warrant changes to accommodate the specific variation.

1. All charges and credits should be optional as it is possible that an innovative product may not charge a Usage charges or Daily Supply Charge for instance, and may structure their prices in a completely different way.

It is expected that, under the invoice structure, this would be accommodated by having a zero value against the appropriate field.

2. How will bill reversals be treated i.e. what is the bill for the purposes of billing data under the CDR?

Bill reversals are a new topic so this may require some thought. The intent of the invoice APIs is to show the billing history for a customer (according to the requirements of the designation instrument). In this context a reversed bill could be handled in multiple ways:

• We could include a flag indicating a bill was reversed
• The reversed bill could be simply excluded as it is, presumably, no longer part of the history
• We could accommodate the reversal, and new invoice information, in the same structure which would accommodate partial reversal
• There could be another approach more reflective of the standard approach in the electricity sector

Which option would be most appropriate?

[CDR-API-Stream]

In respons to @SelenaLiuEA:

Billing Transaction Common Type

1. transactionUType – is defined as the Indicator of the type of transaction object: (1) usage (2) onceOff (3) payment. Our way of thinking about billing transactions is higher level and different:

• Bill segment (billing item charges) which can include once off charges and regular charges (usage or daily supply charges for instance)
• Adjustments which can be additions or deductions (credits) on an account. They can include charges for services though.

It is expected that each retailer would conceptualise their billing charges differently depending on their technical implementation and policies. The structure proposed is an attempt to create a generic structure that would accommodate many different variations. The proposed structures would appear to be able to accommodate the model you describe. Are there specific issues in the structure that would prevent your charge history from being represented correctly?

• Payments which we assume are payments by the customer – but which won’t necessarily correspond to a bill. i.e. one Payment made by the customer may be paid over multiple bills or only pay part of a bill.

This is expected. The payment structure does not include a link to a specific invoice.

2. Usage –

• usage – definition reflects the period in kWh. This seems to be accumulated and will not reflect usage during different time of use periods which may be relevant for time of use pricing.

The intention is that different periods, where different TOU pricing would apply, would be separated into other charge records.

1. timeOfUseType – This category likely needs further work to ensure that all different tariffs are reflected. We will come back on this next week.

That would be appreciated.

2. Tariff information (i.e. $ per kWh) doesn’t appear to have been included in these billing data payloads – which seems logical as it would better fit in tariff payloads, but this means it may not be apparent which tariffs apply to a particular bill. Even if historical tariff data was delivered under tailored tariff payloads, it would be difficult to reconcile which tariffs apply to each bill.

As the tariffs are presented in a separate data cluster there has been no accommodation included to make the connection between pricing and charging. Should this link be included? If so, what would be the best way to achieve that without including the same data available in the account detail end point?

[Mark-Lee-Momentum-Energy]

Hello,

Feedback from Momentum Energy:

Invoice Common Type

• Doesn't accommodate for dual-fuel products: there is a section for electricity charges but not for gas charges. If the intention is to omit gas charge information, then the total of charges provided in the electricity section may not reconcile with the amountDue field. Suggest adding a section for gas charges, or alternatively an flag that indicates the invoice includes additional charges that are not for electricity supply.

• totalAccountDiscounts: Recommend updating the description to indicate if pay-on-time discounts should be included or excluded here. Note that the discount might be valid when the invoice is generated but - depending on if the customer pays on time - may no longer be valid after the due date.

• Payload does not include a field for 'invoice due date'.

• amountDue: Suggest being careful with using 'due' here as is ambiguous. Perhaps replace with invoiceAmount or invoiceTotalAmount.

• balanceAtIssue: Suggest indicating in the description if this should include or exclude the invoice amount.

• electricity: totalUsageCharges: Assuming this includes energy consumption, demand, and metering/supply charges.

• totalAccountCharges & totalAccountDiscounts: Unsure what charges are expected here - suggest providing clarity on what "account level" means. All our charges and discounts must be invoiced, and would be considered "invoice level", so expectation is that nothing would ever be populated in these two fields, which is clearly the wrong interpretation.

Billing Transaction Type

• transactionUType: Assumption is that 'usage' would include all recurring charges related to the supply of electricity (and possibly gas for dual fuel invoice). e.g., metering charges, demand charges).

• usage: timeOfUseType: This list doesn't account for seasonal times (e.g., Summer/Winter Peak/Off-Peak/Shoulder), and doesn't account for demand (e.g., Summer/Winter Peak/Off-Peak/Shoulder Demand, Contract/Actual Demand, etc).

• usage: usage: Unsure how demand charges should be populated based on this proposed payload, assuming it should be included in the 'usage' section. If so, this field description states the uom is kWh. For demand, the uom is kVa.

• isEstimate: Is there a reason this is Optional and not Mandatory?

[ghost]

Hello,

Feedback from AGL Energy on behalf of AGL Energy CDR technical working group

AGL concours with the feedback provide by Energy Australia above and would like to additional raise the following. At AGL, a bill is issued at an account level that holds one or many arrangements. These arrangements can be electricity and non-electricity products/services that may not always be associated with a NMI (or MIRN in the gas use case).

Subsequently the broader intent of the designation instrument to support item “3(c) information used to calculate a bill” may not be achievable through this technical proposal due to the following:

• An AGL customer can have many accounts that can have many arrangements.
• Data clusters focus on electricity and associates service point ids reflecting only a subset of the billed items.
• Ability to support for account level charges such as payment late fees or other charges that are not related to electricity services.

Invoice Common Type

• We need more clarification or examples on how retailers can represent historical adjustments into an invoice.
• Given we have accounts where both electricity and non-electricity services are items in the same invoice; what's the expected behavior of properties like amountDue, totalAccountCharges, totalAccountDiscounts which sets outside of electricity object? should these represent only electricity ? or energy i.e. electricity and gas or any product regardless of its industry? noting that its quite hard to change these properties to only represent electricity if that's the intention.
• balanceAtIssue: A typo in description The account balance at the time the account was issued, we think its meant to be: The account balance at the time the invoice was issued
• isPaid: With AGL providing budget planning features and payment plans to customers, we are thinking that a basic isPaid = false, might not be enough for ADRs to present relevant value to customers.
• servicePoints: Given this is a mandatory array of strings, we are assuming this can be an empty array. i.e. an invoice issued for an account where all charges are not related to any service point. Please confirm.

Billing Transaction Common Type

• onceOff: We think that servicePointId property should not be mandatory, assuming this should be used to describe something like late payment fees that is at the account level.
• timeOfUseType: We recommend this enum to have "Other" value to support retailer custom types if it exists in future.

[SelenaLiuEA]

Hi again,

Re Tariff information, our feedback is the data object structure seems suitable for most customers today. But it would need to evolve for new tariff types as they are introduced e.g. the direction the AER and others are going with the introduction of Demand charging for Residential customers. Nor does it appear to support multiple dedicated circuits appropriately (unless that’s why there are three shoulder figures – but it’s hard to see how they’d be used consistently).

Cheers
Selena

[CDR-API-Stream]

A request for an extension to this consultation has been received so the consultation will be extended to close of business, Monday 9th November

[PratibhaOrigin]

Feedback from Origin Energy on DP-116

Invoice Common Type

1. Service Order charges - Where will the service order charges like metering works , connection, disconnection fees etc. need to be incorporated ? Are these part of ‘totalOnceOffCharges’ ?
2. Supply Charges - Where will the supply charges need to be incorporated ? Are these part of ‘totalOnceOffCharges’ too ?
3. isPaid - Origin concurs with AGL's feedback on this field. With the scenarios like payment plan and hardship payment arrangements , a true or false value here might not give the correct value to ADRs and customers. ‘ispaid’ is more of a payment related parameter than billing payload related.
4. Bill Reversals - How do we want to treat bill reversals/amended invoice scenarios ? The amended bills often refer the previous reversed invoice for amended charges etc. A guidance from DSB on the treatment of these scenarios would be appreciated.
5. servicePoints - We do issue non-energy invoice at times which may be not specific to a site/NMI and are applicable at account/customer level. Considering this is defined as mandatory array of strings , is it supposed to be left blank for the above mentioned scenario or can it be updated as optional ?
6. Issuedate - Origin concurs with EA’s feedback on this field to consider the National Energy Retail Rules and Energy Retail Code in defining this field.
7. Multiple service invoice - If an invoice is related to multiple services like dual fuel scenarios, is there a DSB suggested way to handle the charges related to each service in the payload ? The payload mentions only electricity charges which may not reconcile with overall invoice amount in such cases if the charges related to other services are not taken into account.

Billing Transaction Common Type

1. Timeofuse - With this field, there are other possible values of demand, solar etc. Is it possible to include to ‘Other’ as a one of the values to handle any other value which is not in the defined list of values ?
2. Multi meter scenarios - A guidance on the following fields in multi-meter scenarios from DSB is requested -

• For a site with multiple meters, there is a possibility of different values for each meter corresponding to the ‘Timeofuse’ field. How do we intend to use it for multi meter scenarios corresponding to one NMI/servicepointID?
• Similarly, its possible in multi-meter scenario to have Actual read for one meter and estimated for other meter. How do we intend to incorporate that in this field being at NMI level ?

3. ServicepointID - A billing transaction can be for once off charges/settlement/credit. Request DSB to consider the same along with below pointers -

• A transaction can be applied across multiple NMIs . Do we need to consider an array rather than a single string servicepointID here ?
• Also, a billing transaction may not be applied to any specific site/NMI/servicepointID and rather at account/customer level, for example few once off charges. So, considering those scenarios this field should not be mandatory.

Generic Comment

Overall the payload seems more tailored to mass market bundled charges. Has the unbundled charging model of the large commercial and industrial customers been considered for these payloads or will it be submitted for consultation at a later stage after the confirmation of ACCC rule regarding inclusion of the large customers ?

Cheers!
Prats

[SelenaLiuEA]

Hi All, please see further feedback from EA below:

EA’s responses:

5.	amountDue for the invoice - This could be taken to mean the account balance as at the date the bill is issued (including that bill) with adjustments applied, or it could mean the amount for that single, current bill.
•	EA can produce both data points but this should be clarified.
It is intended to be the former. The amount due with current balance incorporated.
•	Pay on time discounts also present a unique issue – as this affects the amount of the bill depending on whether the customer pays on time (during the short period it’s unknown whether the customer will pay on time). Our system calculates the bill amount that’s payable but then the pay on time discount amount is separately calculated and presented on the bill.
•	We would prefer that the current bill amount does not include the deduction for the pay on time discount (remembering that it would be uncertain whether the customer will actually pay on time).
•	Payment plans also present another issue, as a separate amount that the customer has to pay, which is likely to be different from the bill amount again. This is not necessarily an issue but I wanted to point this out so the DSB can clarify that payment plan amounts are not what the DSB is alluding to in their billing payload definitions.
The intention of this payload is that the information included on the bill at issue is presented. If discounts for on time payment are not included in the amount due on the issued bill then it is reasonable to exclude it. This detail would be picked up under the transaction end points so is still shareable.

EA can provide both amountDue including pay on time discount and without it (the first would take more data work to provide it though). Our bill presents both. It is important to note that different retailers may take different approaches re including and not including pay on time discounts in their amount due, and so we recommend that this be clarified in the standards.

2.	electricity is defined as charges and credits related to energy usage. We note that Daily Supply Charges are another typical and key category of charge that could be separated out, and to a lesser extent, Demand charges.
This could be reasonably accommodated as account level once off charges or usage based once off charges. It would be at the discretion of the retailer as to how they categorise each charge.

Just a general question - why are the billing charges and tariffs in Tailored Data payloads so different? The latter specifies the different fees and charges in a lot more detail. It may matter if ADRs try to use tailored tariff data (if historical tailored tariffs are in scope) to analyse bills.

3.	totalAccountDiscounts – we point out that some discounts will not be whole of bill but only relate to discounts of usage charges. This seems like it can be reflected in this data object, but we just point out the complexities if this data were used to try to recreate or estimate what a bill should have been. Other variations of discounts to be aware of:
•	Ongoing vs one off discounts
•	Fixed rate (dollar amount) discounts vs percentage based discounts.
Thanks you for this feedback. If there are any that cannot specifically be accommodated in the proposed structure please let us know as this may warrant changes to accommodate the specific variation. 

Fine if this is just a dollar amount.

1.	All charges and credits should be optional as it is possible that an innovative product may not charge a Usage charges or Daily Supply Charge for instance, and may structure their prices in a completely different way.
It is expected that, under the invoice structure, this would be accommodated by having a zero value against the appropriate field.

It is fine for a zero value to be returned for the data fields that the data will not “fit”, but the data will still have to be returned and it may not be clear which field applies. For example, a subscription type plan – may involve just one aggregated charge for a month. This may not technically fall under a usage charge, as it might cover both usage, supply, and other charges, for example. The standards should clarify what should happen in this scenario and for other non-conventional tariff structures. This is also an issue for tailored tariff data.

2.	How will bill reversals be treated i.e. what is the bill for the purposes of billing data under the CDR?
Bill reversals are a new topic so this may require some thought. The intent of the invoice APIs is to show the billing history for a customer (according to the requirements of the designation instrument). In this context a reversed bill could be handled in multiple ways:
•	We could include a flag indicating a bill was reversed
•	The reversed bill could be simply excluded as it is, presumably, no longer part of the history
•	We could accommodate the reversal, and new invoice information, in the same structure which would accommodate partial reversal
•	There could be another approach more reflective of the standard approach in the electricity sector
Which option would be most appropriate? 

We would suggest exclude showing them; having a flag could be even more confusing.

In respons to @SelenaLiuEA:
Billing Transaction Common Type
1.	transactionUType – is defined as the Indicator of the type of transaction object: (1) usage (2) onceOff (3) payment. Our way of thinking about billing transactions is higher level and different:
•	Bill segment (billing item charges) which can include once off charges and regular charges (usage or daily supply charges for instance)
•	Adjustments which can be additions or deductions (credits) on an account. They can include charges for services though.
It is expected that each retailer would conceptualise their billing charges differently depending on their technical implementation and policies. The structure proposed is an attempt to create a generic structure that would accommodate many different variations. The proposed structures would appear to be able to accommodate the model you describe. Are there specific issues in the structure that would prevent your charge history from being represented correctly?

The proposed categories might have gaps (1) usage (2) onceOff (3) payment – e.g. what about non-usage charges that are not once off charges?

2.	Tariff information (i.e. $ per kWh) doesn’t appear to have been included in these billing data payloads – which seems logical as it would better fit in tariff payloads, but this means it may not be apparent which tariffs apply to a particular bill. Even if historical tariff data was delivered under tailored tariff payloads, it would be difficult to reconcile which tariffs apply to each bill.
As the tariffs are presented in a separate data cluster there has been no accommodation included to make the connection between pricing and charging. Should this link be included? If so, what would be the best way to achieve that without including the same data available in the account detail end point?

This only matters if ADRs wish to use tailored tariff data to analyse bills for example. One theoretical use case is a bill check for an issued bill – which we don’t think is likely anyway. It could also possibly be used for a bill estimate – if previous bills and the tariffs that applied to that bill are used to formulate a bill estimate. I think this is a policy issue which needs to be tested further.

Cheers
Selena