Solution for your billing challenges, adapted to all your needs
The collection layer is in charge of retrieving the event, the data, the consumption.
In the Telecom business, we talk about a Call Detail Report when a call between A and B is made.
In this business you have many formats but the most simple is a file with contains multiple events. The collection retrieves the file and deposits it in another folder (or rename it) and at this stage all the events are published on the next level in the initial format.
We have already developped mani ready-to-use connectors : DB; files, Messages Queue, Diameter, events … but we can adapt to any kind of format if required.
This is where all events are translated into one unique format. Re using the example of a typical telco event, it will usually look like :
- Event Type : SMS, Call, VOD….
- Start time
- Magic Number
What is the Magic Number ? It is an event unique identifier calculated as a numerical combination of the previous inputs. Thanks to this method, we can automatically identify and eliminate any duplicate : we all hate to be charged twice for the same thing ! This Magic Number will also be used to track the transaction inside the system, through all the different processing layers. Once everything is done, we trigger the next layer.
The last ‘Event relative layer ‘is the one consisting in assigning the flow of events to the relevant accounts.
In short, as an example, in a B2C Telco business, we take the Normalized Event as generated and identify the right account, usually based on the Caller.
The Rating operation consists in calculating a price for a given transaction as if this transaction was billed as a single event without any associated commercial tarif plan, similar to the Pay-Per-ride in the metro where you pay for each trip you make.oint.
As you can imagine, many Off-The-Shelf models are already available and we can invent and create many others. Our rating functional layer is flexible enough not to limit your creativity.
Thanks to a concept of look up table, we can aggregate the price lists in the way that suits you. For instance, at the rating level we could use the country where the call is made to assign it to a predefined tariff zone and then retrieve the right price to apply.
The billing operation is required to calculate the global amount of your invoice. Usually manually launched on a dedicated batch of subscriptions, this consists in the following actions :
- Bundle all the events, calculating the SUM/AVERAGE/MIN/MAX … of duration, consumption, or any other input the bundle is built upon.
- Apply bundle rules on the subscriptions.
- Mark some or all of the bundle’s transactions as free (zero rate) if and when they are included in a bundle package.
- Create discounts transactions based on bundle indicators : total call duration, total consumption, etc…
- Create commitment fee transactions if the bundle doesn’t meet the customer commitment requirements
- Apply flat fees (if any) of the subscriptions.
- Various periodicity : one-shot, monthly, yearly etc…
- Prorated calculation where applicable.
- Applied upfront or on due date.
- Resiliation fee
All these calculations are done net of tax which will be added by the following layer.
The last layer of this subscription planet relates to the taxation. Tax regimes are generally dependent on the countries and some as in North America have very specific rules applicable to the Telco business. In some instance, taxation is managed within the ERP or any accounting system. When this is the case, this layer is not used but be sure if you want to use it, BillingLabs can deal with any tax mechanisms and regimes.
All the rated and billed transactions have been mapped to a product code. Each product codes has a corresponding tax code that gives the VAT rate to apply. The taxing process sums all the transactions with the same tax code and applies the corresponding rate creating an additional transaction. This operation is performed by batches of transactions with the same tax code.
This optional layer has been designed to offer the capability to split one invoice into multiple invoices to be dispatched to different entities.
As an example, this can be used to answer a customer accounting requirement to have separate invoices for capital and operating expenditures for example. Another scenario is when one customer company want different business entities to be invoiced separately for different items.
The split in multiple invoices can be based on various criteria such as the offer, an accounting code or any other customer references.
Once all the necessary information required per invoice has been generated, we prepare the invoice content itself covering four main sections:
- The destination company : the billing account details in other words : Name, address, account number….
- The invoicing company : we can handle multiple tenants or subsidiaries : Name, address, logo, account number …
- The invoice summary (in line with potential local regulatory and legal requirements) ; Net of tax amount, tax amounts, service split and all regulatory and accounting rules.
- The invoice details.
The content and presentation of the details is fully customizable, every customer have their own specific way of showing that information. In Telco or any business billing many various events, there are different options to aggregate them per day, per conference, per destination at the customer leisure with the focus to keep them easy to read for the end customer.
The output of the invoicing layer is a JSON document which contains both the content of the invoice to generate as well as the related input for the ledger to ensure consistency.
We’re almost at the end of our journey !
The output from the invoicing layer is then organized as per a predefined template and used to generate a pdf with the proper look & feel of the company.
This predefined template will vary depending on the invoicing company or even the type of offer, there is no limitation in the number of templates BillingLabs can manage.
Steady, ready, POST !
The invoice document is now ready to go ! We can post them on a directory, a sharepoint folder, a SFTP server or any other form of secured repository where it can be distributed from.
Inevitably, SQL is a must have as it is designed to manage structured data. Because accounts, contracts and rates are recognisable structured data, storing these types of data in a relational database is the most effective way of retrieving them.
BillingLabs harnesses both SQL and NoSQL technologies and selects that which best suits each data storage within each microservice. Transient data is rapidly computed and shared with NoSQL DB while ACID controlled data is consolidated in Relational DB for durability.
Message Oriented Architecture
Event messaging is a great pattern that enables flexible and cooperative microservices development. Following this pattern, the billing process is split into many small steps that follow one after the other, based on message-based communication. This is what we call a Tiered Architecture.
The whole process is divided up into multiple chained steps. Microservices are the « worker units » in these steps. One can be triggered by a message and it can trigger another one subsequently. This is the “push” method. The other one is the “pull” method where the microservice itself is the initiator of the process. Each microservice can be configured according to the “push” or “pull” method and in so doing, you build your processing workflow.
You can therefore choose where to put validation checkpoints or bypasses. Errors are easy to deal with: retrying is as simple as a message resend.
Operation User Interface
Thanks to the Operational User Interface, the DevOps team can monitor and track the behaviour of a BillingLabs instance at any time, at any stage of the overall billing process.
This user interface can display a rich set of information regarding the status of the platform such as:
- number of instances per microservice
- instances in a failed state
- release number for each instance
Through that interface, a lot of metrics regarding the application activity are also made available:
- system metrics for all cluster nodes (CPU / Mem usage, IOPS etc…)
- business metrics with the amount of processed transactions, generated invoices, etc…
The modern and pragmatic approach of NoSQL databases and their capabilities of handling massive amounts of data in native clusterizable systems offer real opportunities to develop up-to-date solutions that require scalability. Cassandra is used as the main storage for billable events to leverage the row modeling which is well suited to these types of data. We have also opted for mongoDB to store the invoices and reports in order to take full advantage of the flexibility of the document format.
Scalable & stable processing capacity is guaranteed by the implementation of independent asynchronous processing units that communicate with publish-subscribe mechanisms. The advantage of being stateless means that your solution can be scaled up or down on a cluster of mid-range servers whenever you want. Any part of the solution can be hosted on premises or in SaaS, so the more servers you have, the greater the performance. This is real horizontal scaling.
By applying the Single Responsibility Principle, each processing unit is treated as specialized, meaning that you just install and run only the components that you need. You can easily adapt and even code your own units. The integration with your legacy I.S. is made easy through full REST APIs developed in Python for accessibility or through MDM synchronization using Kafka Streams.
Web consoles developed using React for modularity enables the configuration of the subscriptions and contracts, to trigger and monitor processing and to explore the invoices and reports.
Billing User Interface
The billing User Interface is the main entry point for the BillingLabs users, it allows them to:
- visualize and manage / provision every billing resources: customer account, rating plans, fixed rates, invoices etc…
- manage all workflows available in BillingLabs: start new CDR collectors, manually restart full or partial billing cycles on a subset of CDR, generate invoices for a batch of accounts, post a batch of invoices, export invoices to external systems (accounting, BI, etc…)
All activities performed through this User Interface are logged for security and audit reasons. Every action is associated to a specific owner, whose access rights can be adjusted by a duly appointed administrator.
Through our recent implementations, we have been able to measure the following KPI improvements vs legacy traditional systems:
New feature TTM : 2 to 3 weeks vs 6 months
8hrs (vs several days) to execute a full Billing Cycle on 100 000 000 transactions
0 sec unavailability per upgrade and software change
1 or 2 people maintenance team where 4 to 5 were needed previously
Leave your contact details and we will get back to you
Salon - Contact
"*" indicates required fields