Today’s guest blog is by Justin White, Head of Information Technology at BEE Mobile in South Africa. Justin has extensive experience as a developer, consultant and product manager, particularly with CSG International and Intec. During that time, Justin formed his own opinions on how to improve the reconciliation of interconnect bills. He encourages the industry to rethink how we bill each other, and what we do to ensure the accuracy of those bills.
Any process that is performed regularly with consistent outputs should be automated. In cases where the process is resource intensive, the expected results are in the same format and interim data is similar there is no reason why technology cannot be leveraged to better solve the problem in an automated fashion. Reconciliation, in support of the settlement of interconnect invoices, is one of these processes.
As part of the reconciliation process, operators load, translate, map, aggregate and compare data. The end to end reconciliation process consists of multiple smaller tasks, each needing to be completed prior to the next, and the flow is based on sometimes complex rules decided on by the operator, or the environment in which the franchise is operating (e.g.: Codifi). After reconciliation, decisions can be made on the financial settlement applied between the wholesale interconnect partners.
This piece discusses some of the challenges of reconciliation in the wholesale billing sector and how a small change could improve efficiencies in the settlement of these large interconnect invoices.
Each billing cycle, network operators issue invoices, or declarations in the case of certain agreement types, to partners. This exchange of commercial documents is completed in order to settle the interconnect charges relating to calls terminating in their network, or that have been terminated by the partner network. In the case of bilateral agreements, where the operators both terminate traffic for their partner as well as route their own traffic to the partner network, they may elect to exchange invoices and offset any charges for the traffic that was exchanged by them (a form of netting).
These invoices amount to the largest operating cost of an operator, and for this reason the payment of these invoices needs to be based on an understanding that firstly the partner did in fact terminate, or route the traffic that the invoice relates to, is basing the invoice on valid up to date rating information and is operating out of the correct billing cycle. These are just some of the factors that could lead to a discrepancy between what an operator has calculated for an invoice and what a partner feels is actually owed.
One of the biggest disruptors over the last two decades in this market has been the upward drive of traffic from over the top players such as the App Stores as well as the ubiquity of firstly feature phones and then smart phones. This not only drives up the volume of traffic, but also the number of partnerships that are required to be in place for an operator to be fully vested in the market and to take advantage of this growth in traffic, and therefore potential revenue.
Invoice level reconciliation
Invoice level reconciliation is the comparison of invoice level data exchanged by partners during the regular billing intervals they share. This process involves the parsing of invoices received from partners, mapping the data to a common key of sorts, aggregating the data if necessary to a higher level and then comparing the data in order to achieve a result.
The format of the invoices that are exchanged between operators often differs across partners and the loading, transforming and mapping of this data and then comparing to Franchise data of the same form is time consuming and error prone. This time consuming process of reconciliation can lead to disputes being raised by either parties in the agreement.
Dissimilar file processing
As part of this reconciliation process Network Operators may exchange data in order to justify the invoice they submit to a partner, or perhaps to justify the dispute of an invoice received. The format of this data varies considerably and outside the context of a standard such as Codifi in Spain, PISA in Mexico or DETRAF in Brazil, partners are left with the time, and resource consuming task of processing large volumes of data in different formats, covering multiple periods and often not the exact data set required for the reconciliation purposes. Any system that is required to process this data is required to parse, transform and load the data, and only once that has occurred can it execute the necessary aggregation and comparison processes used to support this vital revenue assurance procedure. These dissimilar file formats are a hindrance to any attempt at automating the full process and inevitably leads to interim stages where data needs to be ‘cleansed’ prior to loading.
While there are many tools available that can support the loading of complex file types, the complexity of the configuration of these tools is an inhibiting factor in the maintenance and support of these systems. While powerful, these tools often require technical expertise to configure and maintain them, not necessarily a skill-set that is found in the team responsible for revenue assurance in a network operator. Reconciliation tools also often require that partner data be provided to it in a specific format, or aggregated to a certain level prior to processing. This places further strain on the revenue assurance team who then need to create the required data set out of whatever is provided by the partner.
While the results of this process are often required soon after the invoices are exchanged, factors not always in the control of the Franchise can obstruct speedy conciliation and this can lead to lengthy delays in settlements.
Increasing data volumes
Most conventional reconciliation tools were originally designed and built against manageable volumes and were able to quickly process low to medium volumes. As call and data volumes have grown over the last decade, at times exponentially, these tools have either not been able to keep up, or have been required to be modified to such an extent that the cost of maintenance of these tools outweighs the benefits gained by them, for vendor and operator alike.
A large operator in South America, or the Middle East can process over a billion transactions per day. These volumes are not easily processed in a revenue assurance system where those billion records need to be compared to a partners record set of the same magnitude. During reconciliation, not only does the franchise need to process their own data in order to transform it into a state that it can be reconciled, but also the partner data. The partner, on the other hand also needs to provide this data to the franchise and therefore also is required to extract and process this volume of data. This is required to be completed for each interconnect agreement where detailed reconciliation is required.
The solution to the issue around disparate, constantly changing file formats is to remove the files altogether. Removing the files and providing access to the data directly, or indirectly would not only simplify the extraction of data, but would assist in providing partners with the most up to date data as well as in a format that is defined by the partner, for the partner. It is then very feasible for partners to be provided with secure access to billing data related to agreements with the billing data holder.
There are a host of different options available to operators in order to offer up information to partners including direct database access. A database has an array of options in this regard and it is merely a matter of configuring this for each partner agreement. Direct database access is however but one manner in which data can be exchanged, and other options include the implementation of a type of Enterprise Service Bus (ESB) where a variety of protocols can be implemented to provide an interface into a partners billing area such as RESTful web services. This provides an easily accessible mechanism for partners to exchange data in a manner that is not only based on industry standard principles, but also provides a layer of abstraction that is easily managed and controlled by the franchise owner.
The billing operations running within a network operator, regardless of the size of the operator, are typically supported by a database of some sort. This database, or database set form the backbone of the storage of rated events, or CDRs as well as the aggregation of these CDRs into summaries of some form or another to be used as part of invoicing. A high performance billing engine, with scalable capabilities should allow for periods of inactivity where data can be fed into a staging area of sorts, making it available for extraction by partners.
The issue around processing windows becomes far more prudent given the fact that partners will now need to spend quite some time to extract the necessary data. Discussions around when this can occur, and on what data will be paramount for the success of the process.
Billing updates, rerating and late traffic
A staging area is necessary in cases where a billing cut-off is decided on and rated data at a particular point in time is to be made available to partners. In cases where more up to date, or near real-time data is required, direct access to the data can be provided through more complex database mechanisms that will then take into account updates to rated traffic based on rate changes, or corrections, the rerating, or re-pricing of traffic due to some other network change or even the inclusion of traffic that has been excluded previously for some reason (late traffic).
Resistance to change
While the concept discussed in this text is simple, the implications are far reaching and the processes currently employed within operators would undoubtedly need to change. From the perspective of the debtor, or the operator owing the money, the onus would be on them to extract the necessary data to validate the invoice that is owed by them. For the creditor, or the operator being owed the money, they would need only to make the information available by way of the relevant interface.
Operators may be wary of this methodology as they may feel partners could hold back, or hide information from them in the interface or only provide limited data for processing. Since partners may already be holding this information back as they decide what is to be included in the support file, this is not really a valid concern.
Security may be of concern to operators as opening up channels for extraction could expose them to online attacks and the like. While this is possible, employing the necessary controls in the interface could minimise this risk.
This change could possibly lead to new business models where vendors in the industry could provide exchange type services, and act as a proxy to not only provide the services around the exchange of this data but also to limit the number of required connections for partners and even perform the data validation required. For large operators this may not be necessary but smaller operators could possibly benefit from outsourcing this function.
As the market for operators continues to change and margins are put under further pressure, the focus will continue to be on reducing turnaround times for settlement of interconnect invoices. Greater number of wholesale partners and agreements will result in more complex processes around settlement and providing better methods of assuring revenue will be required. The current methods will need to evolve, just as the market has evolved and a more pragmatic and progressive approach will need to be considered and the foundations laid for a more streamlined approach.