Decision Proposal 198 - Candidate Billing & Invoicing End Points

[CDR-API-Stream]

This decision proposal contains a recommendation for the candidate URIs and end points for Billing and Invoicing data.

The decision proposal is embedded below:
Decision Proposal 198 - Candidate Billing & Invoicing End Points.pdf

Note that this proposal has incorporated changes arising from initial feedback from AEC members on incorporate C&I customers.

This consultation will be open for feedback until the 22nd October 2021.

[EnergyAustraliaBA]

Attaching a pack (pdf) that was provided by EA to the Data Standards Advisory Committee (DSAC) re C&I customers and CDR. Has relevance for DPs 197 and 198. This pack identifies specific data issues relating to Billing, Tailored tariff and Meter data.
Aligned to the information in this pack, one key callout is that our Mass Market and C&I subject matter experts (SMEs) have identified that it’s not compatible to have both payloads on the same API endpoint.
DSAC - EnergyAustralia presentation 8 Sep 2021.pdf

[jonmilne]

Some observations/suggestions for the Billing Transaction Common Types:

usage:timeOfUseType: I note the previous consultation where the inclusion of 'OFF_PEAK_DC' was requested and subsequently included by the DSB, but there does not appear to be any information about its meaning.

Is this intended to represent a controlled load? If not, should 'CONTROLLED_LOAD' be added as an additional enum to identify controlled load usage, without ambiguity?

onceOff object: I note the previous consultation where the DSB indicated that the 'onceOff' charge object could/should be used for non-usage charges including metering, demand and daily supply charges. However, there is only a free text description field to describe the charge. This presents issues for machine readability and makes it difficult for ADRs to interpret these charges, particularly if the same charges are described in different ways by data holders.

Should an additional enumerator be included for this object, as a mandatory field, to create some consistency and to aid interpretation of the charges in this object? i.e. DAILY_SUPPLY, METERING, OTHER etc.

General comments/questions regarding GST: Presumably, invoice amounts are intended to be returned inclusive of GST given this is how they would appear on a customer bill. However, with respect to charges in billing payloads, are these expected to be returned inclusive or exclusive of GST? I note there is an 'adjustments' object, is this intended to be used for this purpose if the usage charge itself is exclusive of GST? If so, the prior comments regarding machine readability of the description field apply. We recommend consideration be given to the application of GST in these payloads, with inclusion or exclusion made explicit.

[AGL-Sumit]

Please find attached AGL's consolidated feedback for Decision Proposal #197 and #198:

AGL Decision Proposal response for 197 and 198.pdf

[PratibhaOrigin]

As raised with the Commonwealth Treasury and DSB, we remain concerned with the proposed inclusion of large Commercial and Industrial (C&I) energy consumers in the CDR framework. The inclusion of large energy consumers in the framework needs to be considered in the context of size, current regulatory arrangements, the service offerings that are currently available to these consumers, and the cost effectiveness of integrating the complex pricing arrangements into the regime. There should be a clear mandate to ensure that the costs to create complex systems to include C&I consumers does not exceed the benefits to this group of consumers.

The energy sector is still awaiting confirmation from the Commonwealth Treasury as to the size or nature of a consumer who will be considered “eligible” under the CDR framework. We understand that a decision on this issue will be included in the Energy Rules for CDR when they are finalized.

Given the regulatory uncertainty with regards to the size of an energy consumer for CDR, we have reviewed and provided comments on the APIs for Billing and Invoicing Payloads from a C&I consumer perspective. The individual fields within the APIs have been specifically assessed to identify 1) the intent of providing that data to the consumer and 2) how this data field aligns with a data source within our systems. Where these fields are not found to be suitable, recommendations have been made to remove or modify these fields. We have also proposed new fields that we believe will be needed within the APIs to provide the customer with a close representation to how their account has been setup.

Given the substantive number of proposed amendments to this payload to potentially cover C&I consumers, we suggest the DSB that consideration needs to be given to a separate billing & invoicing payload for C&I consumers.

At a high level, the following changes have been proposed for C&I consumers if a decision is made to include these consumers.

Billing & Invoicing Payload
• The transaction type or charge type categories across all 3 APIs (ie Billing, Invoicing and Accounts) will need to be expanded to cater to the various unbundled categories represented on an Invoice. The proposed list of categories is “usage”, “generation”, “onceOffCharge”, “onceOffDiscount”, “environmentalCharge”, “regulatedCharge”, “networkCharge”, “meteringCharge”, “retailServiceCharge”, “RCTICharge”, and “otherCharge”;
• Elements within the transaction categories will need to be updated to represent the various units of billing applicable for a category. For example, c/kWh, $/kWh, $/kVA, $/day, $/meter/day etc. These should be represented in separate fields to be able to distinguish between the “units” and the “unit of billing” applicable;
• Some transactions have additional calculation factors involved such as Loss Factors, Environmental Certificate Percentage etc. that are displayed on the customer’s bill but are not in the Billing & Invoicing End Points. These calculation factors contribute to the total amount for a given transaction. An object to represent these calculations should be added;
• GST portion applicable for a transaction should be denoted in a new field, the existing “amount” field will be GST exclusive;
• We propose that the “otherCharge” category be utilized to represent backdated adjustments and additional charges or credits (such as interest, credit card fee, etc.) as opposed to a catch all field for transactions pertaining to a C&I consumer;
• We also propose to remove the “adjustments” array under “usage” as our adjustments tend to be backdated and can take place for many reasons such as environmental rate update, network tariff update, revised consumption, energy rate update etc. which may not necessarily be usage related;
• Account summaries or consolidated statements should be out of scope as the structure of these statements are different to a site-level invoice. We will be able to provide individual site level invoices for all the child accounts and recommend that the ADRs create a summary view as needed for the customer using the raw data;
• For more information, please see our C&I bill explainer for sample transactions that could appear under different categories - https://www.originenergy.com.au/business/commercial-and-industrial/market-events-charges/understanding-your-bill/
• Should the customer’s greenhouse emission for the bill period be included in the payload?
• In terms of the bulk invoice requests, this will lead to huge datasets being retrieved especially for large customers with multiple sites (over 100) – can there be a limit imposed on the number of accounts?
• For a detailed list of fields proposed to be modified, added, and removed, please refer to the APIs on the following page.
• Generic comment on the use of ‘accountID fields in most of these billing and invoicing payloads For example -Get/energy/accounts/balances and Post/energy/accounts/balances , response payload refers – ‘account Id’ where description ‘The ID of the account ‘. Is this same accountId being obtained from account payload - ‘ This is a tokenized ID previously obtained from another account end point.’. If yes, can the description be updated to keep the fields and description uniform and represent the tokenized ID and the accountID term often used by retailers to represent the contract/customer/plan etc.

Further feedback (at a field level) has been provided in the attached document. For a detailed list of fields proposed to be modified, added, and removed, please refer the attachment.

DP-198 Feedback ORIGIN - Oct 2021.docx

[CDR-API-Stream]

This consultation is now closed. Feedback will be reviewed and responded to as soon as possible to allow for a final cut of candidate energy standards by 1st of November

[CDR-API-Stream]

In response to the presentation from @EnergyAustraliaBA. It was difficult to understand exactly how the payloads should be modified to accommodate the issues raised.

One area we have identified is the need to include demand charges in the billing payloads. A structure to accommodate demand will be added (incorporating feedback from the other contributors).

[CDR-API-Stream]

In response to feedback from @jonmilne:

usage:timeOfUseType: I note the previous consultation where the inclusion of 'OFF_PEAK_DC' was requested and subsequently included by the DSB, but there does not appear to be any information about its meaning.

Is this intended to represent a controlled load? If not, should 'CONTROLLED_LOAD' be added as an additional enum to identify controlled load usage, without ambiguity?

We will take these questions forward into maintenance as we don't have enough detail to make a choice at this stage.

onceOff object: I note the previous consultation where the DSB indicated that the 'onceOff' charge object could/should be used for non-usage charges including metering, demand and daily supply charges. However, there is only a free text description field to describe the charge. This presents issues for machine readability and makes it difficult for ADRs to interpret these charges, particularly if the same charges are described in different ways by data holders.

Should an additional enumerator be included for this object, as a mandatory field, to create some consistency and to aid interpretation of the charges in this object? i.e. DAILY_SUPPLY, METERING, OTHER etc.

The intention of the invoice payloads is that they represent amounts but not the details of how those amounts were obtained in a machine readable form. This is the intent of the billing payloads that give more detail. As a result the invoice payloads are deliberately minimal in information.

Under the CDR this supports the data minimisation principle. If additional machine readable information is not required for a particular service then only the invoice data will be retrieved. If more granularity is required then the ADR would ask for the more detailed data.

General comments/questions regarding GST: Presumably, invoice amounts are intended to be returned inclusive of GST given this is how they would appear on a customer bill. However, with respect to charges in billing payloads, are these expected to be returned inclusive or exclusive of GST? I note there is an 'adjustments' object, is this intended to be used for this purpose if the usage charge itself is exclusive of GST? If so, the prior comments regarding machine readability of the description field apply. We recommend consideration be given to the application of GST in these payloads, with inclusion or exclusion made explicit.

GST will be added specifically as per feedback from other respondents.

[CDR-API-Stream]

There is substantial field level feedback provided. This is very helpful and will be incorporated as far as possible along the lines of following principles:

• The CDR has an existing set of approaches for optional sub-objects (ie. union types) and these will be used if necessary where different object types are suggested
• Optionality will be incorporated where suggested but these may be made "conditional" and depending on other aspects (such as customer type) rather than simply being made optional
• As these changes are occurring fairly close to the candidate date we don't have much time to iterate on these changes. As a result we will create some specific change requests in standards maintenance to act as a vehicle for ongoing discussion

[CDR-API-Stream]

In response to the requests for clarification in the AGL's submission:

We understand an overarching principle for the Billing and Invoicing data is provide this as it is displayed on the customers bill.

• Billing data – is intended to be all individual line items that appear on the customers invoice, including adjustments and payments.
• Invoicing data – is a summary view, summing up all lines from billing, with one total per category. Plus account balance and payment status.

For invoicing data this is broadly true. For billing data, however, the goal is not to reflect the content of invoices. For this data the goal is produce good data sets that are useful and machine readable.

AGL require further clarification on this field. Clarification was requested on github under DP-116 and the response given indicated the opposite expectation of the field description, creating a contradiction between the standards and advice on github.
Field description in standards: “The net amount due for this invoice regardless of previous balance”.
Github Question: 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. DSB Response: “It is intended to be the former. The amount due with current balance incorporated.”
Please confirm the expectation and update the field description if applicable?

Apologies. The error lies in the previous response on GitHub. The InvoiceAmount field should be the amount for this invoice. The balanceAtIssue field should be the balance for the account when the invoice was issued. The current balance after the invoice would be balanceAtIssue minus InvoiceAmount.

AGL notes the total invoice amount can include concession credits and government rebate amounts. These are not currently list ed under any field in the invoicing data set. Can DSB please provide clarification.
Should these amounts should be included in the following, “TotalOnceOffDiscounts” and “TotalAccountDiscounts” under invoicing, and in “OnceOff” as a credit under billing. Or excluded completely from the data, only considered in the overall invoice total and account balance?

Concessions and rebates should be included in the total fields as suggested. Separate fields have not been created due to the sensitivity of this data set. By aggregating this data a customer is able to share their invoice data without the need to disclose a hardship related concession. Concessions have been separated into a specific data scope for this reason.

“TotalAmount” - This has appeared in the latest documentation but was not mentioned in the changes. The description says “The aggregate total of charges other than usage and once off charges”
It is not clear what information is expected in this field. Can DSB please clarify this? Is this intended to be a combination of all remaining charges not listed elsewhere that contribute to the total invoice amount payable, i.e. balance brought forward, adjustments?

It was referred to in the list of changes under the heading amount which was due to an error as the field name changed name a few times in draft. It is a field in each record in the totalOtherCharges field. This field was added in response to feedback indicating the C&I customers would benefit from more granularity in their invoices to accommodate additional charge types.

[CDR-API-Stream]

After reviewing the detailed field level feedback some additional comments are provided on the feedback.

• The suggested inclusion of additional charge types in the invoice payload have not been included as the intent of this payload is that only aggregate values are included. More granular data is available in the billing data. This allows for a customer to share lower granularity data to data recipients that do not require the lower level detail
• It is expected that credits and backdated adjustments would be included in the totalOnceOffDiscounts field rather than the totalOtherCharges object array. The adjustments arrays in the billing data are for immediate adjustments related to discounts or fees that are intrinsically tied to the usage or demand transaction
• In the billing data the demand and usage structures have been designed to cover usage and generation use cases with the difference flagged by a positive or negative value in the appropriate fields (usage, rate, amount, etc)
• Units have not been included as a definitive list of possible values has not been provided in feedback. If a definitive enum list can be identified then a unit field would be reasonable to add to the structures. For the time being kWh and kVA are assumed
• Some of the feedback suggested that the object structures in the billing data should indicate the type of the transaction. As most of the suggested objects were virtually the same in structure it would appear that a type field with an enumeration would be more appropriate. Before this is included a definitive list should be consulted on as this is likely to be different across different retailers

[CDR-API-Stream]

Please find attached the final decision of the Chair:
Decision 198 - Candidate Billing & Invoicing End Points.pdf