Event management

Our billing journey starts on the Planet of Events.
Events you need to bill and invoice. But first, you need to collect these events and assign them to their relevant context…
BillingLabs performs this task in three layers:
  • Collection : we need to retrieve this information from different sources and interfaces.
  • Normalization : you can guess that we will translate all these events into one unique generic format.
  • Consolidation : each event will be assigned to the relevant owner.

Collection is the first task of any billing cycle. This consists in fetching or receiving all new events to process. As an illustration, one traditional technique consists in reading a file containing all events. The collection layer will read the events and push each of them in a repository roughly keeping its initial format.
For security purposes, this data is archived and will remain available.

Let’s take an example:
In the Telco postpaid business, a file containing all events is made available daily with typical events containing the following information:

  • The date and time of the beginning of the call.
  • The date and time when the call ends.
  • The callee.
  • The caller.
  • And all technical information of the bearer, the initial operator, the conference Room ID….. Anything relative to your business which you will need further.

You can imagine easily the wide variety of information you could get in these events : SMS, Data packet size, device location information,  … and you can also foresee what it could be if you manage a Parking Lot, a VOD service or a Swimming Pool access…

We have many existing technical connectors to fetch the information:

  • Files retrieved thru SFTP, HTTPS, NFS….
  • DB connection : from a Base to base connection and mapping.
  • Diameter connection.
  • Radius connection.
  • Message Queue.
  • …. Or any specific development to fit with any existing setup.

Across all these sources and input formats, we constantly monitor the progress of the collection activity, we can cope with any connection issue through a proper recovery mechanism and we notify an operator if an external manual intervention or further investigation is required.

Once the event is stored in our repository, we trigger the next layer.


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
  • Stop time
  • Caller
  • Callee
  • Additional info….
  • 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.

A few other treatments can be executed at this level   :
consolidate all time indications under the same Time Zone if you’re on multiple TZs.
Calculate the duration in a unique way : rounding per minute or per sec … or per ticks….
Aggregate CDRs : complex but mandatory for Conference business or when we receive two messages for one event : one for the beginning, one for the end….

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 process might sometime be slightly more sophisticated depending on the use case:

  • Multi subscriptions : Subscriptions remain valid over a period of time. In case an event is received lately (Roaming case), it is necessary to assign the valid subscription at the time of the event. One account can also correspond to multiple commercial products and the events must be assigned to the right offer/product category : one for VOD, one for voice…
  • Duplication of Events : Events generate billing to the end user but also potentially billing elements to cross charge potential business partners : roaming partners, resellers, wholesalers… These rating elements aimed at billing different parties are generated simultaneously at this stage.
  • Multi guiding key for a subscription : used in case of a fleet management for instance which is billed as a group, not as individual users.

As for all the BillingLabs layer, this consolidation can be replayed at any time in entirety or limited to a subset of inputs. This allows to take into account any late changes in the overall billing ecosystem.

Throughout these entire event management layers, we guarantee every single event is properly processed invoking manual intervention whenever required. We care too much about your business to take the risk of losing any data !

This is the end of our activity on the Planet of Events, let’s now move to the Planet of Subscription.