Using Billable Charges for Pass Through / Convergent Billing

The term "pass through" billing is used to describe the practice of receiving charges calculated by third parties and presenting them on the customer's bill along with your own charges. "Pass through" billing is implemented in the system using Billable Charges.

The following points provide information to help you decide the most appropriate way to implement "pass through" billing given your specific requirements:

  • Customers with pass through charges will need a separate service agreement to hold the pass through charges. We refer to this type of service agreement as a "billable charge" service agreement.
Note:

A service agreement's SA type controls whether a service agreement can have billable charges linked to it. Specifically, the SA type must have a "special role" of Billable Charge.

  • A billable charge service agreement holds the billable charges until the customer is next billed. At that time, a separate bill segment will be created for each unbilled billable charge linked to the billable charge service agreement.
  • While it is not required, we recommend creating a separate billable charge service agreement for each type of pass through charge. For example, if you can receive "pass through" charges from the local water company and the local cable company, we'd recommend having two billable charge service agreements for each customer.
  • As described under We Bill For Them, you can setup the system to automatically create billable charge service agreements when you start regular service for your customers. If you take this approach, you can also have the system create the payable transaction to pay the 3rd party. Refer to Pay At Bill Time vs. Pay At Pay Time for more information.
  • You can interface billable charges using the Billable Charge Interface. The interfaced charges can consist of any of the following:
  • Pre-calculated bill lines that will be presented "as is" to the customer.
  • Service quantities that are used by the system to calculate the charges on behalf of the third party. For example, the 3rd party may pass through the number of kilowatt-hours and you calculate the bill lines for them. Refer to Uploading Consumption Rather Than Bill Lines for more information.
  • Meter read details that you want printed on the bill. Note, the base package bill segment creation algorithm (BSBS-BC) simply sweeps billable charge read details onto the related bill segment's read detail. This algorithm does NOT use these reads to derive service quantities. This is intentional as most implementations that import reads also import service quantities and therefore deriving service quantities is unnecessary (and also error prone). If your implementation needs to derive service quantities from these reads, you can develop your own bill segment creation algorithm to do just this.
  • All of the above. You might interface both bill lines and service quantities if the third party calculated the charges but did not calculate the taxes. The dollar amount for which taxes will be calculated would be defined using a service quantity. Refer to Calculating Taxes On Uploaded Charges for more information.
Note:

You cannot interface interval data via the billable charge interface. Rather, you would need to interface the interval data to Oracle Utilities Meter Data Management and then let the system calculate the charges for you.

  • The bill lines on a billable charge can fit into any of the following categories:
  • Memo-only (i.e., don't affect the general ledger). A bill line that is memo-only contain information that is purely informational. For example, the 3rd party might pass the start and end meter reads that they used to calculate the charges. You can use memo-only bill lines to show this information on the customer's bill. If a bill line is not memo-only (i.e., it affect the general ledger), a distribution code must also be specified to define how the lines affects the general ledger.
  • Show on the customer bill. It is possible to create bill lines that affect the general ledger, but are not shown on the customer's bill. This is an unusual practice, but it happens.
  • Summary / detail. Each bill line has an indication of whether it is a summary or detail line. This only impacts bill presentation.
Note:

The above indicators can be defaulted onto a billable charge line by using Billable Charge Line Types when you interface the lines into the system.

  • Characteristics (i.e., user-defined fields) can be associated with billable charge lines. You might populate this information if you are interfaced information that may be useful during bill presentation or for reporting purposes.
  • If service quantities are specified on a billable charge, they are saved on the bill segment created when the billable charge is billed. This means that they system can support creation of a graph of historical usage on the bill, as well as other queries on customer usage. In addition, it might be possible to event estimate consumption based on these service quantities (but such a plug-in is not supplied with the base package).
Note:

The system does not support passing in items (e.g., street lamps). This could be a problem if you need to perform ratable calculations for the 3rd party based on, say, the number of street lights. However, if you require ratable, street light pass through billing, you can calculate a service quantity for each type of street light and save this information on the billable charge. The associated rate would then have a price per service quantity rather than a price per item type.

The system does not support sending in raw meter reads with billable charges. This consumption needs to be passed in as a service quantity. However, you can pass in meter read details to be printed on the bill segment.

  • Cancel / rebill for billable charges is quite different than for normal bill segments. A billable charge bill segment can be cancelled, and this will reverse the financial effects of the billable charge. But without new information from the source, there is no way to rebill the customer. Therefore, if the original charges were incorrect, the source system would send both a reversal of the charges and a newly revised set of information. These could be passed as two separate billable charges or they could combined on a single billable charge.
  • In terms of the customer information setup, while a service agreement that holds billable charges does not need a service point, there are advantages to having this information in the system. For one thing, if jurisdictional taxes are being calculated by the system, the definition of the jurisdiction(s) is held on the service point or premise. Also, the link to the service point defines the service address, facilitates customer lookup, causes information to appear in Control Central's trees, etc.
  • For most other functionality, the billable charge service agreement supports the same functionality as normal service agreements. This includes budget billing, payment distribution, credit & collection tracking and events, current & payoff balances, movement of old debt onto payment arrangements, etc.
    Fastpath:

    For more information about billing billable charges, refer to How To Create A One-Time Invoice. For more information about creating a billable charge, refer to Maintaining Billable Charges. For more information about creating sub service agreements to hold billable charges, refer to We Bill For Them. For more information about interfacing a billable charge from an external system, refer to Uploading Billable Charges.