Back to Prepaid Billing Main Page

Prepaid Billing Run

Normal billing run is a billing mechanism which is used in cases where customers 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 is usually performed on a monthly 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 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 billing run is performed following a series of intermediate processes:

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

Normal 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 billing run is determined by its life cycle state. The supported life cycle states are the following:

• Draft: The billing run was not executed yet
• Interpreting Prepaid Billing Run Execution Steps & Rating: The billing run was 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 step
• Completed: All billing run steps were executed successfully
• Failed: The billing run was not executed and no bills were created
• Completed with errors: the billing run was executed, with minor errors and bills were created

Execution System Processes

The Prepaid Billing process is used to bill Subscriptions whose Billing Term is classified as Prepaid. There are 2 models of Prepaid Services:

• Pre-rated Services: The System will bill a Service for an upcoming defined period (enough funds need to be available in the Wallet before the Service is activated).
• Post-rated Services: The System will bill a Service for a passed period.

The execution of this process results in the following:

• The rating of Subscription Services following a Prepaid Billing Term Scheme.
• The debiting of the related Wallet for the amount that was rated.
• Optionally,

  • The estimation of the date that the Wallet Balance will be consumed based on the Billing Terms and the usage of the Subscription Services.

Prepaid Billing Run is performed following a series of steps:

• Identification 
• Rating
• Wallet Debiting  (Optional / Configurable)
• Estimating Wallet Consumption Date (Optional / Configurable)

The supported LifeCycle States for Prepaid Billing Runs are the following:

• 'Draft': Not executed yet
• 'Identification and Rating': Executed up to this step
• 'Completed': Executed successfully
• 'Failed': Executed and no Bills were created
• 'Completed with Errors': Executed with minor errors and Bills were created

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

Normal billing runs Prepaid Billing Runs are multi-threaded and are performed using the number of threads which were specified considering also are specified, with consideration to 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

Anchor

identification

identification

Identification

Process

This step identifies all the unrated billable (chargeable or creditableor creditable) information which is ready to be billed and should be considered during the specific billing runBilling 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 considers the generic billing run Billing Run attributes and applies the following logic:

• Identify billable entities having billing term schemes classified as normal filtered by the following billing run Identify billable entities with Billing Term Schemes classified as Prepaid, filtered by the following Billing Run parameters:
• Billing term schemes included in normal billing run billing term schemes conditions
• Billing frequencies included in normal billing run billing frequencies conditions
• Accounts receivable classifications included in normal billing run accounts receivable classification conditions
• Accounts receivable active payment preference included in normal billing run accounts receivable payment preference conditions
• 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 Term Schemes included in Prepaid Billing Run Billing Term Schemes Conditions
• Accounts Receivable classifications included in Prepaid Billing Run Accounts Receivable Classification Conditions
• Accounts Receivable included in Prepaid Billing Run Accounts Receivable filter list that are 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 fully rated, based on the following rules:
• Billing effective date is before or equal to “Bill as of Date”As Of Date.”
• Billing directive Directive is equal to “To be billed” Be Billed” or "To be creditedBe Credited."
• For post-bill subscriptions services: The Post-rated Subscription Services: The process retrieves all subscription service life cycle state periods which were not already being Subscription Service Life Cycle State periods which were not already fully rated, based on the following rules:
• Subscription Service “Billing Effective Date” is before or equal to “Bill as of Date”As Of Date.”
• Billing directive Directive is equal to “To be billed” to “To Be Billed” or "To be creditedBe Credited."
• Subscription service 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" 
• the “Bill As Of Date.”
• Pre-rated Subscription Services: The  process retrieves 
  • Subscription Service's which have not been rated before 
    or
  • The latest "Rated Up To Date" is equal to or before the Prepaid Billing Run's performed date.

Anchor
rating rating

Rating

Process

This The Rating step is calculating calculates and applying applies a rate on each service Service or physical good Physical Good to be billed, for a specific period of time, by creating rated billing items. The process is considering , by creating Rated Billing Item/wiki/spaces/WIP/pages/10008754 The process considers all the unrated billable information and it either rates them or not, based on the business rules specified on each billing runBilling 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.

• If a Service is post-rated, then create a Rated Billing Item from the last "Rated Up To Date" until the Prepaid Billing Run's performed date
• If the Service is pre-rated, then create a Rated Billing Item from the last "Rated Up To Date" plus the period for which the service will be billed in advance as this is defined in the Billing Term Scheme.

Anchor
wallet debiting wallet debiting

Wallet Debiting Process

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.

• All the rated billing items that have not yet been billed will be summed up. 
• If the total amount of the items is below the minimum debit amount, as specified in the Normal Billing Run Definitions then the debit will not be created.
• If the total amount of the items is above the minimum debit amount and above or equal to zero then an invoice will be created with the related invoice lines and the rated service period will be updated with the invoice number
• If the total amount of the items is less than 0 then a Credit Financial Transaction will be created with the related lines and the rated service period will be updated with the credit note number
• At this stage the system will check if adjustment transactions should be created based on the rounding options specified on the Normal Billing Run Definitions
  • If the amount should be rounded up then create an invoice adjustment financial transaction
  • If the amount should be rounded down then create an credit adjustment financial transaction
• Finally 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 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

:  

• Gather all related Rated Service Periods which are yet to be billed, have a billing Effective Date before or equal to the Billing As Of Date, and a Life Cycle State equal to 'Not Billed'
• Sum the amount of all Services related to each Accounts Receivable
• If the resulting amount is positive 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 as a cause for debiting Wallets is used to create the Wallet Debit Transaction (see Wallets).
• Set the Life Cycle State of all rated Service Periods to “Billed”.

The amount of the Wallet Debit Transaction is calculated using following logic:

• If Wallets with a 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.

• If the Wallet Balance that is available for the rated Service minus the amount that the service was rated for, is less than the "Minimum Wallet Balance Threshold"  (as specified in the active Wallet Definition) then
  • The Subscription Service Prepayment State is set to invalid
  • The Subscription Service Last Date of Prepayment State Calculation is set equal to the date and time of execution
  • The Subscription Service is not rated as there was not enough amount in the wallet (for both post-rate and pre-rate)
• Else
  • The Wallet is debited, and the rest of the existing functionality is applied (i.e. rated billing items are created etc.)
  • The Subscription Service Prepayment State is set to Valid
  • The Subscription Service Last Date of Prepayment State Calculation is set equal to the date and time of execution.

Anchor
estimations estimations

Estimating Wallet Consumption Date Step

This step is performed only if it is enabled through the Prepaid Billing Run. The process estimates the date on which the Wallet Balance will be consumed, based on the Billing Terms and the usage of the Subscription Services.

The process estimates and sets the following information on each related Wallet and Wallet Product Consumption:

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

There are three options for estimating consumption when executing Billing Runs:

• Skip Estimations: No estimations takes place
• Re-estimate All: Estimation for all Wallets takes place
• Re-estimate Wallets with changes: The System decides which Wallets were modified and makes estimations, only for those Wallets. 
  The decision on whether a Wallet has been modified is based on the following logic:
  
  • A consumption date is estimated only if the date falls within the maximum estimation period as specified on the active Prepaid Billing Run Definition.
  • The date threshold will be calculated relative to the daily price that is calculated during billing.
   

For more information on Wallets and related estimations refer to Understanding Wallets.