What does this section cover?

What

is Prepaid Billing Run?

Normal Prepaid billing run is a billing mechanism which is used in cases where customers pay in advance and after that start using the services that were subscribed to/or delivered to them, and by the end of their billing frequency period they are charged for those services. Normal billing run deducting the used amount from the paid amount, using the wallets module.

 It is usually performed on a monthly daily basis and is responsible to identify the billable services, rate them, invoice them per subscription or job, assemble each customer’s bill which includes all of those invoices and post them. Normal customers receive a bill which covers all the invoices related with their subscriptions or jobs, which is then sent to them in order to make their due payments.

Normal billing run process is performed in a number of steps (processes) as provided below.

Visit Configuring & Executing Normal Billing Run for more information on how to create and execute a Normal Billing Run

Billing Run Execution System Processes

Billing Run process is used to bill billable entities having :

• Identify the service usage
• Rate the used services
• Debit the related wallets based on that usage

In addition there are optional services to:

• Stop subscription services which are left with no wallet credit
• Start services which were stopped and are now having enough wallet credit
• Estimate the date that the wallet amount will be consumed by the subscription services, based on their existing usage and billing term schemes.

Unlike Normal Billing Run, no bills or financial transactions are generated by the prepaid billing run and it is only applicable on Subscriptions.

Prepaid Billing Run Execution System Processes

This process is used to bill billable entities having a billing term which is classified as normal.

This process pre-bills or post-bills services, based on how those services were classified in each billing term scheme and results to a unified accounts receivable bill, including multiple invoices or credit note, where each invoice or credit note represents the total debits and credits of a specific billable entity owned by that accounts receivable.

Normal prepaid. The execution of this process results to the following:

• Rating subscription services following a prepaid billing term scheme
• Debiting the related wallet for the amount that was rated
• And optionally
  • Starting services that were not effective if the wallet amount which is available to be used by those services is above the threshold specified in the prepaid billing run definitions
  • Stopping services that were effective if the wallet amount which is available to be used by those services is equal or below the threshold specified in the prepaid billing run definitions
  • Estimating the date that the wallet balance will be consumed, based on the billing terms and the usage of the subscription services.
    The date which is calculated is a near proximity estimation of the consumption date, meaning that it can slightly be different to the actual date, if it is more than 6 months ahead.

Prepaid billing run is performed following a series of intermediate processessteps:

• Identification
• Rating
• Invoicing
• Assembling
• Posting
• Formatting

• (Mandatory)
• Rating (Mandatory)
• Start Services (Optional / Configurable)
• Stop Services (Optional / Configurable)
• Wallet Debiting (Optional / Configurable)
• Estimating Wallet Consumption Date (Optional / Configurable)

Prepaid billing runs can be performed up to a specific step and resume their execution starting from the step that they have reached. The progress of each normal prepaid billing run is determined by its life cycle state. The supported life cycle states are the following:

• Draft: The billing run was is not yet executed yetInterpreting Prepaid Billing Run Execution Steps
• Identification & Rating: The billing run was is executed up to the Rating step
• Invoicing: The billing run was executed up to Invoicing step
• Assembling & Posting: The billing run was executed up to Posting step
• Interpreting Prepaid Billing Run Execution Steps: The billing run was executed up to Formatting stepidentification and rating
• Completed: All billing run steps were executed are completed successfully
• Failed: The billing run was not executed and no no bills were  were created
• Completed with  with errors: the billing run was executed, with minor errors and bills were created

Normal Prepaid billing runs can be performed once or on a recurring basis. If a normal prepaid billing run is recurring, then at the end of the execution a new normal prepaid billing run is created and scheduled to be executed on the date that was specified.

Normal Prepaid billing runs are multi-threaded and are performed using the number of threads which were specified considering also the maximum number of threads that can be used by batch processes, as specified in in General Settings. Visit Configuring General Settings for more information on how to configure a global setting for the number of threads, which can never be exceeded.

Mandatory Processes

Anchor

identification

identification

Identification

Process

This step identifies all the unrated billable (chargeable or creditable) information which is ready to be billed and should be considered during the specific billing run. The supported billable entities are the following:

• Subscriptions
• Subscription Usage Detail Records 
• Subscription Services considering Subscription Service Life Cycle State History Periods
• Jobs 
• Job services
• Job physical goods
• Job activities
  • Activity services

The process follows business rules which are defined specifically for each type of unrated billable information. The process is considering the generic billing run attributes and applies the following logic:

• Identify billable entities having Identify billable entities having billing term schemes classified as normal normal filtered  by by the following billing run parameters:
• Billing term schemes included in normal schemes /wiki/spaces/V4Manual/pages/9833520included in prepaid billing run billing term schemes conditionsBilling frequencies included in normal billing run billing frequencies conditions
• Accounts receivable classifications/wiki/spaces/V4Manual/pages/9833391 included in normal prepaid billing run accounts receivable classification conditions
• Accounts receivable active payment preference included in normal prepaid billing run accounts receivable payment preference conditionsfilter list
• Accounts receivable presentment preference included in normal billing run accounts receivable presentment preference conditions
• Accounts receivable included in normal billing run accounts receivable filter list
• Subscriptions included in normal billing run subscriptions filter list
• Jobs included in Normal Billing run job filter list
Accounts receivable in an Active or Suspended state

• For each subscription/job the following billable entities are identified:
• For pre-bill subscription services: The process retrieves all subscription service life cycle state periods which were not already being fully  in an Active or Suspended state
• Subscriptions included in prepaid billing run subscriptions filter list
  
  

• For each subscription the following billable entities are identified:
• Usage Data Records: The process retrieves all usage detail records which were not already being fully rated, based on the following rules:
• Billing effective date is before or equal to “Bill as of Date”
• Billing directive Directive is equal to “To be billed” or "To be credited"
• For post-bill subscriptions subscription services:  The The process retrieves all subscription subscription service life cycle state periods  which were not already being which were not already being fully rated, based on the following rules:
• Subscription Service “Billing Effective Date” is before or equal to “Bill as of Date”
• Billing directive is equal to “To be billed” or "To be credited"
• Subscription service period started before the “Billing as of date”
• Subscription Usage Detail Records: The process retrieves all UDRs that have: 
  • Billing Directive set to "To be Billed" or "To be Credited"
  • Life Cycle State equals to Posted
  • If a rated item exists then it has Billing Directive equals to "Cancelled" 

Anchor
rating rating

Rating

Process

This step is calculating and applying a rate on each service or physical good to be billed, for a specific period of time, by creating creating rated billing items.  The The process is considering all the unrated billable information and it either rates them or not based on the business rules specified on each billing run. 

Rated Billing items can either be invoicing items or crediting items. The system will deduce what rated billing items need to be created by acquiring information from the Subscription Service Life Cycle States periods.

For each period that can be uniquely identified per:

• Service 
• Billing term instance 
• Price plan rate 
• Auto applied discounts 
• Ad hoc discounts 
• VAT rates

 a rated billing item will be created with the following attributes:

• Sign
  • Invoices: Positive
  • Credits: Negative
• State: Not billed

In the cases where the system identifies a Cancellation in the Life Cycle State history, where a Binding period penalty needs to be charged, then for each period that can be uniquely identified per:

• Service 
• Billing term instance 
• Price plan rate 
• Auto applied discounts 
• Ad hoc discounts 
• VAT rates

a rated billing item will be created with the following attributes:

• Sign: Positive 
• State: Not billed
• Penalty type:Cancellation out of binding period penalty
   

Billing Run Life Cycle State will be updated to Identification & Rating

During Rating, the system will decide how Flexible Product Bundles will be rated and eventually billed. According to how the products are defined in the Price Plans then the billing may differ. The following pricing models are available:

• Based on the rates which are set for the flexible product bundle
• Based on the rates which are set for each product which is composing the flexible product bundle
• Based on both the flexible product bundle and the product components

While rating the flexible product bundles the following logic is applied:

During Invoicing step, an invoice item is created for each rated product. Note that this process is applicable only for flexible product bundles as Fixed product bundles are billed normally as a single service.

Invoicing step is responsible for the generation of invoices or credit notesThe same logic as in normal billing run is applied, although there are some rules which are never applicable on prepaid subscriptions (as specified in billing term definitions).

Prepaid Billing Run Rating process also handles Flexible Product Bundle billing. Go to Rating of Flexible Bundle Products to check out how Flexible Bundle Products are being billed 

Optional Processes

Anchor
start service start service

Starting Subscription Services Process

This step is performed only if it is enabled through the prepaid billing run. 
The process is starting subscription services belonging to a prepaid subscription, that are not effective, if the wallet amount which is available to be used by those services is above the threshold specified in the prepaid billing run definitions.

A start service subscription action is created for each subscription, including the services that should be started, which is executed imminently.

Anchor
stop service stop service

Stopping Subscription Services Process

This step is performed only if it is enabled through the prepaid billing run. 
The process is stopping services belonging to a prepaid subscription, that are effective, if the wallet amount which is available to be used by those services is equal or below the threshold specified in the prepaid billing run definitions.

A stop service subscription action is created for each subscription, including the services that should be stopped, which is executed imminently.

Anchor
wallet debiting wallet debiting

Wallet Debiting Process

This step is performed only if it is enabled through the prepaid billing run and if the prepaid billing is included in the causes debiting wallet rules, specified in the active wallet definitions. The process is responsible for the generation of wallet debit transactions, based on the amount denoted by the rated service periods, which were generated in the previous rating step, or already existed but not processed. 
The system will perform process applies the following steps per accounts receivable.

logic:

• Gets all related rated service periods, which are not billed, having billing effective date before or equal to the billing as of date and life cycle state equal to “Not billed”
• Sum the amount of all services related to each accounts receivable
• If the amount is above zero then
• Create a wallet debit transaction, based on wallet definitions to debit the wallet. Create one wallet debit transaction for each service (i.e. for each rated billed period). The wallet transaction type specified in the active wallet definition's causes debiting wallets is used to create the wallet debit transaction (see Wallets)
• Set the life cycle state of all rated service periods that were invoiced or credited will be updated to “Billed”

Billing Run Life Cycle State will be updated to Invoicing

Assembling step is responsible for the generation and assembling of the actual /wiki/spaces/V4Manual/pages/9830749, considering all the information that was generated in the previous steps. Each bill is related with a customer account and includes all the financial transactions generated for that account.

• The creation of the bill is made up by accumulating  
  • All related invoices
  • All related Credit Notes
    and calculating the Total Bill amount
• Billing will also take into consideration
  • Partially Settled or Unsettled bills
  • Debit transactions which were posted between the current bill and the previous bill (and not included in any bills)
  • Credit transactions which were posted between the current bill and the previous bill (and not included in any bills)
    The Total amount to be paid will be calculated using the following formula
    Total billed amount + Total due amount from previous bills + Total debit amount posted between bills - Total credit amount posted between bills
• The billing classification will be set to “Billed”

The amount of the wallet debit transaction is calculated based on the following logic:

• If

  the bill amount is less than the maximum credit amount specified in normal billing run definitions exceptional bill thresholds then
  Billing classification equals to “Maximum credit amount reached”
• Else if the bill amount is more than the maximum credit limit fixed amount, or the accounts receivable credit limit * credit limit multiplier, as specified in normal billing run definitions exceptional bill thresholds then
  Billing classification equals to “Maximum credit limit amount reached”
• Else
  Billing classification equals to “Normal”
• The bill state will be set to “Draft”

Posting process is responsible for posting all financial transactions included in each bill, by setting their transaction date and due date and changing their state to posted.

• Financial transactions transaction date will be set equal to the specified transaction date
• Financial Transaction due date, on all invoices, will be set equal to the calculated due date (Due Date will be set as defined in the /wiki/spaces/V4Manual/pages/9833521, but if the date is invalid then the due date as set in the account receivable Setting and updating Credit Terms for Account Receivable
• All Financial Transactions will be posted
• Sets Bill life cycle to “Posted”

Billing Run Life Cycle State will be updated to Assembling & Posting

Formatting process is used to format the billing run results, in a standard format, which is both human and machine readable. The process is generating an XML file, which includes all the information that was considered or generated by the billing run process. The following steps are applied:

• All bills generated by bill run are exported in an XML file, which is stored on a specific path.
• The file name includes the billing run number and the date that was performed
• Export file includes all information related with each bill such as the amount to be paid, related financial transactions, related rated periods etc
• Export file includes the following additional information which is not directly included in the bill

• Rated Service Periods: Rated service periods are included based on the rated service periods formatting settings defined on normal billing run definitions

• Subscription service usage detail records: UDRs are included based on the usage detail records formatting settings defined on normal billing run definitions

• Export file includes a summary of the following:
• Bills that were created
• The total amount of accounts receivable that were billed
• The total number of services billed per service
• The total number of invoices
• The total number of credit notes
• The total amount of debited amount
• The total amount of credited amount
• The total amount of debited amount per service
• The total amount of credited amount per service

Billing Run Life Cycle State will be updated to Formatted

• Wallets with balance less than the stop service threshold, are restricted through the active billing term definitions for subscriptions then

  • The amount will be equal to the remaining wallet available amount
• Else
  • The amount will be equal to the sum of the rated amount of all rated subscription services

Anchor
estimations estimations

Estimating Wallet Consumption Date Step

This step is performed only if it is enabled through the prepaid billing run. The process is estimating the date that the wallet balance will be consumed, based on the billing terms and the usage of the subscription services. The date which is calculated is a near proximity estimation of the consumption date, meaning that it can slightly be different to the actual date, if it is more than 6 months ahead. The process is estimating and setting the following information on each related wallet and wallet product consumption:

• Wallets
  • Estimated Consumption Days: An estimation on the number of days left until the whole wallet amount will be consumed
  • Estimated Consumption Date: An estimation of the date on which the whole wallet amount will be consumed
  • Estimated Consumption As of Date: The latest date that the estimation was performed
• Wallet Product Consumption
  • Available Amount: The amount of money which is available for the specified product as of the specified date
  • Daily Consumption Amount: The daily rate for the specified product as of the specified date
  • Estimated Consumption Days:  An estimation on the number of days left until the whole wallet amount allotted for the specified product will be consumed
  • Estimated Consumption Date: An estimation of the date on which the whole wallet amount allotted for the specified product will be consumed
  • Estimated Consumption As of Date: The latest date that the estimation was performed

More information on wallets and related estimations visit Understanding Wallets