This weeks questions, isn’t going to look at a Revenue Loss issue, but instead a common issue for an RA department.

I was working for a Tier 1 fixed line operator and had just completed the development of an E2E CDR reconciliation. As with most of these types of solutions, the front end was also being used by the Finance department to forecast monthly traffic volumes. An issue was raised by Finance, that they felt our count of calls coming off the switches were wrong, as figures from the NOC(Network Operations Centre) which were much higher.  The NOC had implemented an SS7 reporting tool, whereby they had probes attached to the entire transmission network, that recorded every signal sent from each of the switches. These signals were aggregated into dummy CDR’s from which they were able to identify the call volumes on any given day. Even when we removed the SS7 CDRs for which no switch CDR would have been created, the NOC still had figures 20% greater than those being seen by our solution. At this point we could have come to the conclusion that there must be a mass CDR suppression issue or CDR loss issue on the network, however we did something else – that proved our solution to be correct.

What would you do in this scenario?

This weeks issue was identified with on of the simplest RA controls to put in place. It was identified with a CDR sequence number checker. The majority of switches tag each CDR with a unique sequence number(a 6 or 8 digit number). By simply ccomparing the difference between the first and last sequence numbers to the total CDRs within a file, along with the last sequence number in file A to the first sequence number in file B, you have a fool proof way of identifying whether you are receiving all data at the collector.

For this weeks question, I am going to return to a standard RA issue.

At a fixed line operator, it was identified that approximately 50% of CDRs, from a single switch country, were not being received by the mediation systems collector. After a full investigation, the X25 transmission was found to be faulty and hence only half of each CDR file was being transferred to the collector. The issue was identified without gaining access to the original CDR file from the switch or SS7 probe information. The issue had existed since the first day the switch had gone live so call volumes were as expected.

I am sure the majority of people reading this, will have a control in place to identify this issue, but for the benefit of those who don’t, please state your control for identifying the problem.

I don’t believe that this particular issue can be found using any conventional revenue assurance reconciliation. This issue was found by simply talking to a colleague in the Finance department.

At the time I was responsible for the RA compliance of all new product releases. Due to staffing reductions I was also asked to take on the responsibility of ensuring that all of Finance’s requirements were incorporated into new product releases. As a result this meant sitting down with the VAT manager and defining his requirements for a new call feature. During the discussion, he explained the rules for VAT calculation and at this point I drifted off, trying to work out how what he told me was possible. I knew that there was a flag on the postpaid rated CDRs for VATable and Non-VATable charging – as of course the customer needs to see it on the bills. However I didn’t remember seeing the same flag on the prepaid CDRs. I went away and did my investigations and found that the flag didn’t exist, furthermore that in no downstream systems did this categorisation take place. After this the next steps were about proving and quantifying the issue – see Eric’s post on the original question for details on this.

I think this particular issue, highlights an area of Revenue Assurance that is rarely, if ever, looked at. As an RA consultant I spend the majority of my time looking at the processes and systems of both the network and IT functions. I tell them where they are going wrong and what the need to do to, to avoid revenue leakage. Until this point in my career, I had never thought at looking at the department I and most RA resource sit in - Finance. 

For this weeks question, I’m actually going to ask two questions. The usual how would you identify this loss? and a second question – does this fall under the remit of Revenue Assurance?

This weeks scenario:

In the UK, VAT on mobile phone calls is calculated in one of two ways; for calls originating within the EU VAT is charged at 17.5% (the standard UK rate) for calls originating outside the EU VAT is zero rated. The operator I was working for had assumed that IT systems were calculating these figures accurately and were paying the VAT man accordingly. However this was not the case and the operator was in fact paying 17.5% of ALL prepaid call revenues to the VAT man. Needless to say the financial implication of this was massive.

I’ve slightly simplified the above scenario  – as I don’t want to delve into the legislative joys of VAT, but hopefully I have painted the under-lying picture.

Firstly, thankyou to everyone who posted an answer this week. The purpose of this weeks question was to demonstrate that certain scenarios can be picked up by numerous Revenue Assurance controls, all very valid, but varying in degrees of complexity and expense.

The operator I found this revenue loss on was a good old fashioned operator, where CDR’s were created for every scenario – these are less and less common as IT managers attempt to reduce costs by insisting that only billable CDR’s are generated at the switch. 

Switch A was where the fraud was occurring and Switch B represented the other half of the country. I quite simply isolated all of the terminating CDR’s from switch B where the calls had originated from Switch A and reconciled them to originating CDR’s(billable) from Switch A. At first the query was performed at the volume level(a 5minute check) but due to the disproportionate volumes(in both directions) a detailed reconciliation was then performed. This flagged up some numbers on Switch A that didn’t seem to create CDR’s, so the customer accounts where then checked and found not to exist. From here a full investigation was then conducted and the route cause eventually found.

The above reconciliation was not the best way to find the problem(see Matt’s response to the question for the most complete solution), as it’s dependant on the individuals making calls. However all it needed to do, was find one problem and from there good route cause analysis should lead to the full picture.