The Billing process

#Charging and billing process# When trying to generate a bill, it is necessary to fulfill some steps:

• Metering (also knows as charging). Being able to measure and report usage at different levels (i.e. service, hardware, IaaS).
• Mediation. Formatting, aggregating, and preparing data in 1 to be able to be processed (i.e. gathering all sources of information into a single place and adding/deleting redundance). For this process, it is also the opportunity to include information from external systems and mediate it so it can be used in the platform.
• Guiding. Finding the customer that should be billed using the information found in Metering.
• Rating. Applying rates and discounts to generate charges, based on the information measured and the rate tables associated to the user.
• Billing. Generate the bills
• Invoicing. Formatting and preparing a bill (group of charges) to be a legal payment document.
• Payment (yes, that part)
• Collections (you nasty boy)

##Metering:## The first thing you need in any charging process is to have the information available for charging. Thus you need to measure what you want to charge. Sometimes, information for the elemnt is generated at different levels. For instance,

All the information has to be tagged and time-labeled so it can be identified afterwards. You need to be able to repeat the process with the information stored in the database about the element.
Information can come from different sources (i.e. firewall giving charging information at the same time that network switches) Each source of information is independent. In this case, a service platform can be sending information through CF about the charges at the same time that CF generates information about the resources associated to the service (i.e. a game that you pay by match, number of users in the database, number of concurrent session, events processed per minute, etc)
Information is provided in an specific format with a predefined frequency. Each source can use a different format/frequency  (that is why we need mediation)
Not only events but sessions are reported.
Prepaid is implemented as a policy here (that is to say, control is done at specific moments, not continously, and there is no real time protocol in place)
Although standards exist, they don’t cover all the data needed and are extended. Some elements follow its own format, that is not standard
Information can be text or binary

##Mediation## Once information has been received from the different service elements, that information need to be preprocessed and cleansed. As we described in Metering, sometimes different sources of information are using formats and frequencies that differ one from another. In some other situations, user id are different and need to be normalized.

For that reasons, there are some preprocessing that needs to be done on the input data:

Add missing information (i.e. location, internal user, internal id for the tenant, country codes,etc)
Delete redundant information (i.e. if you have received the same data from different elements, you can discard some of the redundant data)
Corelate different sources of information (identifying that a service is being deployed in a hardware element and adding that data to the CDR)

##Guiding## In order to select a rate, you need to identify the customer. In this step the customer is identified, including organizations he belong to, and all other information needed. Key in multi-tenant, multi-input environments where user ids can be different on different data sources. Users can be multiple, because different parts of the system are rated to different users, or basically because you need to generate more than one rate for differnt users depending on their hierarchy. For instance, wholesale and retail charges defined in the same element would need to define two users/rates and calculate charges twice. The complexity of this step will define what associations can you do. One customer can be associated to different organizations / tenant and this will select which one applies There are overlapping business models: wholesale, retail, that needs to be taken into account (i.e. in a public cloud you have internal costs and external costs, two different users and tariffs, i.e. a CCSP provider will need to generate a bill for their customer and another to report to Red Hat) Rate tables are recovered at this step, identifying what rate is associated to each user. That can vary:

Depending on customer / tenant  used
Depending on business model (wholesale, retail ,VAS)
Depending on time, date (to take into account changes of tariffs)

##Rating## So we need to put a rate to the events and sessions to calculate charges accrued. It is necessary to use the information gathered and process it. We have the identification of the user(s) involved in the event, and we have recovered the tariffs for the user, now we are prepared to put them together:

The first step would be to calculate "gross rates", for each tariff table and each party involved. For instance, you can rate for a session, charges and costs are calculated for the end user, the organization, the provider (wholesale), etc. And those charges and discounts are separately added to the users profiles. In a second step, we process discounts. We go again to those rates and calculate discounts based on different parameters. When genereating information for the P/L, having a separation in two steps makes it possible to assign different P/L accounts to rates and discounts).

Now there are two possible northbound systems for this information.

For  any company that wants to use an ERP/billing system to do rating and charging, we generate a Cloud Data Record (CDR) to be processed
For administrators, showback, or any company that does not need integration with ERP/billing, we store that information into the database and process it

Some considerations: Charges can be done in different currencies. In particular, services can be defined in one currency, while the account holds a different one, and they system is based on a third one: a Mexican user from a Spanish company accessing services provided in USA. Exchange rates are time-bounded (you can define tariffs that are regional or exchange rates between currencies)

Rating can be complex:

Tiered rating: a price for 1-10 VM, another for 11-100, a final one for 101-infinite
Tiered rating using discounts (the same but with a discount being applied)
Based on account information.( i.e. you need to be able to change tariffs or discounts based on group/account tags)
Based on database queries  (i.e. a discount because the product has a limited offer this month)
Based on history (i.e. First 90 days for free)
Based on request (i.e. It is cheaper if you ask for 3 months than for 1 month)
Cancellation and Installation charges should be considered
Specific to the account or group (as you are you, I offer you a specific price)
It is time-bounded: rating done this year is different that rating done last year and next year)
Different accounts can be rated different parts of the service

##Billing## A bill is produced every billing cycle. A bill cycle is flexible, normally a month, but can be defined as a week, bi-monthly, quaterly, etc. The start day of each bill can be fixed or different, allowing one or several billing cycles to be present in the system: When a bill is produced, several things happen:

Charges related to the bill are identified for each account being processed
Charges after the billing period remain in the system. Charges before the billing period are also identified (because it can be an error)
Billing period charges are applied (i.e. a monthly fee)
All charges in rating are added to the bill
Bill time discounts are also added (i.e. 10% discount on bill, 5% discount in amount is over 100.000$)
Taxes are calculated and added (not in this project, I am afraid this is a complex matter in itself)
Everything is got together into the final bill
P/L reporting is done

In some countries, this kind of system needs to have pre and post processing because of legal requirements. Out of scope... ##Invoicing## The bill has to presented in a format that is legally bounding. So you get all the information on the bill and add customer information, customer premises, invoice number, etc You can generate different types of invoice:

Proforma invoice. Used to generate a purchase order
Invoice. Stating what has been accrued

At the end of this process, the customer will have an invoice, with an amount to pay, and a last day to pay that invoice.

For complex systems, there must be a way to dispute charges, when the user is not happy with some of the charges, or the amounts. Whenever a dispute is accepted, you need to record the original amount, the reason for dispute, the status while is being investigated, and the result of it (accepted or denied, and the new charge). Sometimes a dispute will trigger a re-rating (the problem was in the rating table so let's rate for everything again with the updated one) In some countries all the process is legally supervised (in Portugal, invoices has to be digitally signed so no change can be done after issuing them, and the process has to be certified by the government) ##Payment## The process of paying the bill. It has to be integrated with a payment system (Credit Card, PO, Debit Card, Wire Transfer, Invoice Payment, etc) There are some concepts to take into account: prepaid/postpaid: A postpaid system is charged after the fact, so the CMP records usage and at the end of the period calculates the bill. A prepaid system only allows services to continue if there is resources in the account: the customer pays an amount and he's served until services are more than the reserved amount. That implies some way of calculating and storing that amount. Installments. Some customer do not pay or can't pay the bill in one time, and they split it in several items. In this case, financially you need to treat it differently

Payments are out of scope for this project ##Collections## Sometimes the customers don’t pay, and you have to collect the payment in a separate process. Again, can be heavily restricted by government, and is quite complex, a workflow on its own, and out of scope for this project. Batch / Pre-paid / Thresholds In a post-paid model, the customer is entitled to pay an amount at the end of the term - day, week, month), no limits are enforced on the services provided. In a pre-paid environment, the customer has an amount of money (resources) in the account and consumes part of it, no service can be done without money, and current services are stopped when money is depleted. Batch: CDR are processed with a frequency of daily, weekly, monthly, in preparation for the bill. There is no limit in the costs associated with this model. Real-time: some policy element is aware of the costs of the services and the money in the account and stop services when money goes under a limit. Implies a real-time chain and interfaces. Soft and hard thresholds can be defined. Some mechanism to stop services has to be in place if you want to do prepaid Near-real-time: the processing is done in batch mode, but frequency is very high (each 1 minutes).

Real-time can be done in two ways: with a real-time protocol like Diameter CCA, or just processing CDR in near-real time. In the second case, there is a chance of providing services for some time until the CDR is processed and the system understands that the user can't continue using the services. ##Advice of Charge## AoC: a service stating the real price to be paid by the customer taking into account its specific rating and discounts (i.e. how much would cost this service if I ask 5 of them today)