GB2594975A - System and method for multi-channel commission reconciliation for the telecom industry - Google Patents

Abstract

A system and method of reconciling and distributing commissions for the telecom industry in a multi-channel environment. The method comprises steps of converting activation data and commission statement data, provided in proprietary formats, into a universal commission model using a mobile telecom specific file mapping mechanism, including identifying parties owning activations and handling conflicting registration details, resolving commission payment discrepancies and generating commission statements. The method calculates expected commission and assigns reconciliation status based on commission payments received versus expected commission payments and may take multiple commission due dates into account. Thus the system can handle commission statements 105, 107 from a high level party such as an mobile network operator or supplier to a distributor or ‘man in the middle’, and from the distributor to a low level party e.g. retailer, franchiser or dealer, provided in different formats and having different terms, in a single system.

Description

System and method for multi-channel commission reconciliation for the telecom industry DESCRIPTION This invention relates to the processing of mobile network activations through a multidimensional commission system.

BACKGROUND

A mobile network distributor (MND) is a party in the middle of the supply chain who facilitates mobile network activation access from higher level parties (HLP), normally a mobile network operator (MNO) such as Vodafone or EE, to lower level parties (LLP), typically retailers or B2B dealers. A mobile network distributor may supply equipment which is used with the mobile network activation, such as mobile phones, sim cards, tablets and other electronic devices that can communicate over a mobile network.

MNOs and Mobile Virtual Network Operators (MVN05) pay MNDs an array of commissions, subsidies, promotions and other incentives in order to stimulate sales. MNDs pass these incentives minus a margin to the LLP -which may be the retailer who made the activation with the end consumer or another distributor lower down the chain who facilitated it. Thus, an MND can in some cases be the higher level party and in some cases the lower level party.

Typically, LLPs submit connection activation data, in a variety of methods, to the MND on a periodic basis and expect to be paid the commissions, subsidies, promotions and other incentives which the MND has agreed to. The HLPs usually submit electronic commission statements in advance of actually making the payments, detailing out exactly what they are going to pay. The MDN needs to match up the electronic commission statements from the [[Ps with the claimed connections and pay its [[Ps accordingly; in turn submitting electronic or printed commission statements to them.

In some scenarios, there is significant delay between an activation registered and the HLP submitting a commission statement confirming the payment of said activation. This is a problem lower down the supply chain as many retailers suffer from constrained cash flow having to pay distributors up front for physical equipment while charging the end customer little or nothing as a large portion of the physical equipment cost is subsidised by the MNOs and MVN05. As this problem in turn has an impact on MNDs, they often allow LLPs to trade on credit generated by their activations. For example, if a retailer has activated 100 mobile devices to an expected total commission of £20,000, the MND may allow said retailer to purchase additional £20,000 worth of equipment on credit, thus allowing trading to resume.

HLPs, on their end, assist in making this arrangement more credible by issuing activation data with little or no delay. In such scenarios, the MND will favour activation data issued by the HLP and either ignore LLPs' activation data or use it only for reconciliation purposes.

Another challenge for the MND is that there is a lack of standard when processing commission and activation data. Since an MND may partner with a many HLPs they have to support many commission file formats, file structures and terminology. As HLPs, in particular the MN05, need to constantly evolve in order to stay competitive, they keep changing the rules for incentives. Thus, said electronic commission statements keep changing in format, structure and terminology.

Once an MND has overcome the obstacles of interpreting the commission data, the next step is to match each activation with the [[Ps claimed activation. This process is carried out through matching up various activation identifiers, for example SIM card serial numbers, phone numbers, agreement numbers, retailer identifiers or IMEI (International Mobile Equipment Identity) of the mobile device. The majority of activations are usually matched and the LLP identified correctly, but the unmatched, or conflicting, activations typically consume cumbersome manual effort to investigate. For example, the HLP commission statement may include details of IMEI, phone number and rate plan. The MND may have in its records that an activated IMEI has been sold to retailer A, but retailer B has submitted an activation list declaring that they have activated said IMEI on a different phone number and different rate plan, conflicting with the details in the HLP commission statement.

Having overcome the conflicting activations, the next step will be to validate that the agreed incentives are going to be paid for each activation. There is a usually a number of components within an activation, e.g. sim card, mobile device, tariff and various add-ons, each which may have one or more incentives, e.g. the tariff may be eligible for tariff bonus, revenue share commission and activation bonus, which all are payable on different points in time. For example, the activation bonus might be paid 15 days after the activation date when the consumer can no longer cancel the subscription while the tariff bonus might be paid 30 days after the activation date when the consumer can no longer change rate plan. The revenue share commission will usually be split up in monthly payments through the lifecycle of the activated subscription.

The challenge here is to assess whether the expected incentives are declared in the commission statement, at the right time and correct value. As there will inevitably be a large number of conflicts as it is, which usually require manual investigation work, it is imperative to not flood the discrepancy report with false positives.

In order to stay on top of all these evolving challenges, all parties in the telecom network supply chain need to either employ substantial manual effort or constantly keep changing their, usually bespoke, software systems.

This invention seeks to alleviate the problem of continuous re-development of bespoke software when business partners and business rules change in the telecom network supply chain.

STATEMENT OF INVENTION

The first aspect of the invention is a method of generalising the plurality of activation structures and the plurality of incentive offerings for each component within the activation structure into a universal commission model. This model further comprises an activation definition model and an activation registration model, where the former is used to configure rules and terms for different types of activations and the latter is used to contain instances of activation and commission details.

In a further aspect of the invention, there is provided a method of processing incoming activation data from LLPs and HLPs, which may be received in a variety of methods, formats and structures, transforming and translating said structures into the universal commission model. The method preferably comprises a mobile telecom specific file mapping apparatus capable of supporting all known types of activation data structures and commission statement structures.

According to a further aspect of the invention, there is provided a method of processing incoming commission statement data from HLPs, communicated in various methods and in various levels of structures and formats, transforming and translating said structures into the universal commission model using the above mentioned file mapping apparatus.

In a further aspect of the invention, there is provided a method to identify each activation processed through the commission statements with the activations claimed by the [[PS. This method comprises of an algorithm to assign weights on different types of activation and LLP identifiers, which can be used to determine the victor of conflicting activation data based on the highest grade.

According to a further aspect of the invention, there is provided a method to reconcile confirmed paid commission by the HLP against expected commission and determine which activations have been correctly paid, taking both expected amounts and payment dates into account. According to a further aspect of the reconciliation process, there is a method of assessing different types of discrepancies, e.g. underpaid, overpaid, not paid and unrecognised payments. There is also provided a method of clearing discrepancies, both through manual intervention as well as automatically upon receipt of new commission statement data.

In a further aspect of the invention, there is provided a method to calculate outgoing commission to LLPs either before or after commission has been confirmed, based on configured terms. In a further aspect, there is provided a method to produce commission statements and send to the LLPs.

DRAWINGS

The invention will now be described solely by way of example and with reference to the accompanying drawings in which: Figure 1 shows the commission reconciliation and distribution system's role from a MND's point of view in the mobile network supply chain. This includes commission statements and activation data flows.

Figure 2 shows an embodiment of commission reconciliation and distribution system processors at high level.

Figure 3 shows a method for processing incoming activation data records and converting those into the universal commission model for activation registrations.

Figure 4 shows a method for converting activation data and commission statements received from third party sources in proprietary format into a universal commission model.

Figure 5 shows a method for processing incoming commission statements, converting those into the universal commission model for activation registrations and assigning reconciliation status based on commission payments received versus expected commission.

Figure 6 shows a method for resolving commission payment discrepancies.

Figure 7 shows a method for generating commission statements to be sent to LLPs.

Figure 8 is a representation of the universal commission model for activation definitions, comprising an activation, activation component, commission element and commission payment structure.

Figure 9 is a representation of the universal commission model for activation registrations, comprising an activation, activation component, commission element and commission payment detail structure.

Figure 10 shows an example of an activation registration using the universal commission model after successful initial registration.

Figure 11 shows an example of an activation registration using the universal commission model after successful import of a commission statement from a HLP.

DETAILED DESCRIPTION

In the following description, for the purpose of explanation, many specific details are stated in order to provide a comprehensive understanding of the invention. It will be apparent, however, to one skilled in the art that various scenarios may be implemented without some of these specific details. In some instances, structures and processes are shown in block diagram form.

The following description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the following description of the exemplary embodiments will provide those skilled in the art with sufficient understanding for implementing an exemplary embodiment. It should be understood that various changes may be made in the sequence of methods and arrangement of structural elements without departing from the spirit and scope of the disclosed systems and methods as set forth in the appended claims.

Figure 1 is a block diagram of an embodiment of a system 100 for reconciling and distributing commission payments in an exemplary mobile network supply chain. System 100 may include a plurality of higher level parties (HLP) 120 who transmit commission statements 105 through the public internet 108 to a mobile network distributor (MND) 121. System 100 may further include a plurality of lower level parties (LLP) 122 who transmit activation data through the public internet 108 to a MND 121. Activation data 106 may also, in some embodiments of system 100 (although not depicted in Figure 1) be transmitted by HLPs 120.

HLPs 120 may comprise of one or more mobile network operators (MNO) 101. HLPs may also comprise of one or more mobile virtual network operators (MVNO) 102 who purchase airtime from an MNO 101 and trade said airtime in a similar way as an MNO 101, thus also transmitting commission statements 105 to the MND 121 through the public internet 108.

LLPs 122 may comprise of one or more franchisors 103A, master dealer agents 103E3 and retailers 104A-104C. Franchisors 103A, master dealer agents 10313 and retailers 104C may transmit activation data 106 do the MND 121 through the public internet 108. Activation data from franchisee retailers 104A and small retailers 104B, who have no direct relationship with the MND 121, will be transmitted by the respective franchisor 103A or master dealer agent 10313.

System 100 may further include a server 110 processing the incoming commission statements 105 and activation data 106, which after having reconciled the data, producing commission statements 107 to LLPs 122. A central database 111 may be used to store activation and commission data. A plurality of workstations 112 may be used to configure and monitor the system.

In system 100, server 110 may be any suitable server, processor, computer, or data processing device, or combination of the same. Workstations 112 may be personal computers, laptop computers, internet browsers, wireless terminals, portable telephones, etc., or any combination of the same. The central database may be a relational database, hierarchical database, NoSQL database or object-oriented database, or any combination of the same. Commission statements and activation data 105-107 may be transmitted over the public internet 108 using any suitable protocol, for example simple mail transfer protocol (SMTP), hypertext transfer protocol (HTTP), hypertext transfer protocol over secure socket layer (HTTPS), file transfer protocol (FTP) etc, or any combination of the same. Formats for commission statements and activation data 105-107 may be any suitable data format such as comma separated values (C5V) file, spreadsheet, extensible markup language (XML), JavaScript object notation (JSON) etc, or any combination of the same.

The system 100 is merely exemplary and those skilled in the art will readily recognise structural changes to the block diagram of system 100 to accomplish the same function of the present invention. For example, in a different embodiment of the invention, a franchisor 103 may own the system 100 where the current MND 121 would become an HLP 120 and the franchisee retailers 104A would participate in the same process of transmitting activation data 106 and receiving commission statements 107 as the retailers 104C in Figure 1.

The server, depicted by 110 in Figure 1, may contain multiple processors, as depicted in Figure 2. Referring to Figure 2, a preferred embodiment server 110 implements the processing logic mentioned above. Server 110 may contain an activation data processor 201, commission statement processor 202, identification processor 203, identification configurator 204, commission reconciliation processor 205, commission statement generator 206, commission terms configurator 207, file mapping configurator 207 and a shared data conversion processor 210.

Activation data processor 201 may have the role of converting incoming activation data 106 into a universal commission structure, through the assistance of the data conversion processor 210, and registering the generalised activations into the central database 111. Activation data processor 201 may also have the role of calculating expected commission based on the configured terms through the commission terms configurator 207.

Commission statement processor 202 may have the role of converting, through the assistance of the data conversion processor 210, and registering incoming commission statements 105 into the central database 111. The identification processor 203 may have the role of matching up activation data with commission statement data using weights configured through the identification configurator 204 when there are conflicting data records.

The commission reconciliation processor 205 may have the role of detecting commission payment discrepancies and registering those in the central database 111. The commission statement generator 206 has the role of generating commission statements 107 to be transmitted to the LLPs 122.

The commission statement generator 206 may in some scenarios, according to terms configured through the commission terms configurator, be activated before any commission statements 105 have been received. Typically, in such scenarios, any discrepancies detected later through the commission reconciliation processor 205 may be adjusted by the commission statement generator 206 in subsequent commission statements 107.

The processors mentioned above in server 110 need not be linked together as described above or include all of the stated processors. For example, in another embodiment at MNO 101 or MVNO 102 level, server 110 may consist of a single commission statement generator 206 or, in another embodiment at retailer 104C level, server 110 may consist of a commission statement processor 202 and a commission reconciliation processor 205.

Referring now to Figure 3, process 300 is an example of the logic that may be implemented by the activation data processor 201 shown in Figure 2. The activation data processor may start the process by initiating sub process 350, which is the process of converting the incoming activation data into a universal commission model and is depicted in detail in Figure 5 and described further below.

After conversion has taken place, according to step 301 the processor initiates a repetitive process of steps 302 -311 through all activation records in the data set. In step logic 302 may assess whether a LLP identifier has been detected. An LLP identifier can be any reference code uniquely identifying a retailer or other lower level party. An LLP identifier is expected if the activation data has been received from an LLP, but may be excluded if sent by an HLP. If no LLP identifier has been found, step 304 may be executed, which determines LLP by looking up, preferably in the central database, which LLP the physical equipment may have been sold to. If an LLP identifier is found, step 303 may be executed to verify that the physical equipment involved in the activation has been sold to the same LLP.

Typically, an activation includes two pieces of physical equipment: a mobile communications device, which is typically identified by its IMEI number, and a sim card, which is typically identified either by its mobile phone number or by serial number. After identifying LLP through the physical equipment involved in an activation, in step 306 logic may verify that all components have been sold to the same LLP if there are multiple pieces of physical equipment involved. Likewise, if the LLP identifier was attached to the activation, logic in step 305 may verify that all components have been sold to the same LLP and that is the same LLP as recognised by the given LLP identifier. If step 305 or 306 detects conflicting [[Ps, step 307 may then be executed to assess the most likely LLP based on weights given to each piece of identifier.

Once the LLP has been determined, in step 308 the activation may be registered in the central database along with other identified activation components and their details. Figure 10 provides a schematic view of an exemplary activation at this state in time.

In step 309 expected commission from the HLP may now be calculated in accordance with configured HLP commission terms 520, further described below.

If the LLP and the associated activation structure for a given activation are configured to pay on expected, in step 310 expected commission for the LLP may now be calculated in accordance with configured LLP commission terms 530, further described below. Figure 10 provides a schematic view of an exemplary activation along with its calculated expected commissions from the HLP and to the LLP at this state in time.

If no LLP has been determined, logic may in step 311 register the activation in the central database, with LLP set as unknown. No commission will be calculated in this instance and in step 312 logic may assign reconciliation status as "Unknown".

In step 313 logic may complete processing for an activation record by assigning reconciliation status "Not Reconciled" to indicate that no commission reconciliation activity has yet occurred for the activation.

Referring now to Figure 4, process 350 is an example of the logic that may be implemented by the data conversion processor 210 shown in Figure 2. Logic will commence after receiving a structured activation data file or commission statement file from processes 300 or 400. In step 351 logic may identify the sender of the file, the exact method of which may vary according to implementation of the system, but typically may be carried out by interpreting the file name or through manual operator input. In step 352 logic may determine file format by inspecting its file extension and file contents. If the format is not XML logic may convert the file to XML in step 353. In step 354 logic may identify file type, which may vary according to implementation, but typically includes activation data file, commission statement file and payment adjustment file. According to given implementation, the exact logic for determining file type may vary, but typically will either be based on converting given file to XSD and inspecting its schema or accept manual operator input.

In step 355 logic may retrieve relevant XSLT (Extensible Stylesheet Language Transformations) file for given file type and sender as configured by the file mapping configurator. The XSLT file may contain instructions for transforming the given file type to a new XML file in universal activation detail structure 550. In step 356 logic may apply the given XSLT file on the source XML file using any known XSLT processor, such as NET MSXML, to produce the new XML file in universal activation detail structure 550.

Referring now to Figure 5, process 400 is an example of the logic that may be implemented by the commission statement processor 202 shown in Figure 2. Similar to process 300, the activation data processor logic may start the process by initiating sub process 350, which is the process of converting the incoming activation data into a universal commission model and is depicted in detail in Figure 5. Also similar to process 300, after conversion has taken place, according to step 401 logic may initiate a repetitive set of steps 402 -408 processing through all activation records in the data set.

In step 402 logic may locate an activation to which a commission payment belongs using preferred identifier types as per sequence configured per the identification configurator 204. According to different implementations, some activation types may have different preferred identifiers. For example, an upgrade activation type registered with a particular MNO may be identified by its mobile phone number at its first preference while a second preference of activation reference number in combination with IMEI number would also be acceptable. In another scenario, a prepaid activation type registered with a particular MNO may preferably only be identified by its sim serial number.

lithe activation is found then in step 403 logic may verify that the various other activation component details are matching with what is registered in the central database. If any discrepancies are detected which don't have an impact on determining LLP then logic in step 405 may update said details in the central database with the assumption that the connection statement has the most up to date details. If any discrepancies are detected which have an impact on determining LLP then in step 404 logic may use the identification configurator's weights to determine LLP. Typically, bias will be on the commission statement details, especially if said statement includes a direct LLP identifier, as that is assumed to be most up to date.

If the activation is not found, then logic will use the activation data processor logic 300 to register the activation details.

In step 406 logic may allocate each commission payment associated with the identified activation according to its correct position in the universal commission model 500. The correct position may be identified by the file mapping configuration in combination with the commission terms configuration. For example, a source commission statement field name "Revenue Share" could be mapped to a destination field name "Recurring Commission" according to the file mapping configuration for a given implementation, while the commission terms configuration for the same implementation states that the "Recurring Commission" commission element is expected to be paid every month. Assume also, that the commission statement is for the month of July 2017 and accordingly the logic may assign the commission payment to the "Recurring Commission" element scheduled for the month of July 2017.

In step 407 logic may assess whether expected commission at the given point in time has been received and assign commission reconciliation status accordingly. As an example, if a commission element "Handset Subsidy" for activation component type "Mobile Device" is expected at 1 July 2017 for the amount of £45 and the commission statement received from the HLP on 15 July 2017 has no payment for said commission element, logic may assign a commission reconciliation status "Not paid". As per another example, if a commission element "Handset Subsidy" for activation component type "Rate Plan" is expected at 16 June 2017 for the amount of £25 and the commission statement received from the HLP on 15 July 2017 has a payment of £20 for said commission element, logic may assign a commission reconciliation status "Underpaid". In another scenario, if a commission element "Add-On Bonus" for activation component type "Add-On" is expected at 16 July 2017 for the amount of £15 and the commission statement received from the HLP on 15 July 2017 has no payment for said commission element, logic may assign a commission reconciliation status "Not Reconciled" -as the commission payment is not yet expected.

lithe LLP and activation structure are configured as pay on confirmed and reconciliation status is set as "Fully paid", then in step 408, logic may now calculate the commission for the LLP in accordance with configured LLP commission terms 530, further described below.

Figure 11 provides a schematic view of an exemplary activation along with its calculated expected commission, paid commissions and reconciliation status at this state in time.

Referring now to Figure 6, process 600 is an example of the logic that may be implemented by the commission reconciliation processor 205 shown in Figure 2. In step 601, the process may start by an operator reviewing outstanding discrepancies through a screen display, which may also allow the operator to filter the list of discrepancies by dispute type, HLP, period etc. The list may include details such as HLP, issuer, customer, LLP, rate plan, activation date, type of discrepancy and value of discrepancy etc. A drill-down method may be provided in some implementations, showing the operator a view similar to Figure 11. In step 602 the operator may select one or more discrepancies and in step 603 select a suitable action to resolve selected discrepancies. Actions may include clearing the discrepancy without any other adjustment in step 604, which may be typically carried out where the value of the discrepancy is insignificant, perhaps due to rounding. Another action may include in step 605 to clear the discrepancy temporarily, which may be useful when it is expected the HLP will correct the discrepancy in the next commission statement. Another action may include in step 606 to adjust an incorrect commission rate, which may automatically re-calculate all relevant activations and their reconciliation status. Another action may include in step 607 to adjust confirmed payments manually, for example, if the HLP has confirmed payment through an ad-hoc method. Another action may include in step 608 to enquire the discrepancy with the HLP in which case the discrepancy will be cleared temporarily for a pre-defined time period waiting for the HLP to respond. In step 610 logic may produce a dispute report for given discrepancy to be sent to the HLP.

In step 609, logic may update the commission to be paid to the LLP if the commission rate was changed or the payment was adjusted according to whether commission terms are configured to pay on expected or confirmed respectively. In step 611, the resolving of selected discrepancies is complete and the operator may return to step 602 to select further discrepancies until all discrepancies have been attended to.

Referring now to Figure 7, process 700 is an example of the logic that may be implemented by the commission statement generator 206 shown in Figure 2. In step 701, the process may start by logic displaying a list of LLPs with pending commission statements to be generated for the current period, as defined by the commission terms configurator for each LLP. The operator may select some or all of the LLPs in the list for processing. According to step 702, logic may initiate a repetitive set of steps 703 -709 processing through all selected LLPs.

In step 703 logic may add to the statement all commission due to the LLP for the statement period as per calculated in processes 300 and 400, according to whether the LLP and given activation structure is configured to pay on expected or confirmed respectively. This may include negative commission for any cancelled activations within the statement period. In step 704 logic may add any adjustments which may have occurred to previous statement periods, either through commission payment adjustments from the HLP or adjusted commission rates.

In step 705 logic the operator may add any ad hoc commission payments such as one off promotional payments or incentives which have not been configured in the commission terms. In step 706 logic may assign status to paid, so that the LLP will no longer appear in the outstanding list. In step 707 logic may assign tax if the LLP is tax registered. In step 708 logic may generate statement summary in PDF format and statement breakdown in CSV format. In step 709 logic may either print or electronically send the statement outputs to the LLP, according to configured preference.

Referring now to Figure 8, which shows a representation of the universal commission model for activation definitions 500, at the base is an activation structure entity 501, which may be used to define key attributes 505 of an activation type. Key attributes may include Issuer, which is the MNO or MVNO who has the billing relationship with the end customer for an activation; Activation Type, which can be any of a set of predetermined types such as monthly post-pay, upgrade, pre-pay etc; Customer Type, which can be any of a set of predetermined types such as consumer, small business or corporate etc; Duration, which may determine the length in months of a post-pay or upgrade activation type; Pay on Expected, which is a flag that may be set to determine whether to pay commissions to LLPs before the HLP has confirmed those; Preferred Identifier List, which is a one or more of identifier types or combinations thereof, in sequence order for the purpose of identifying commission statement data with registered activations, for example in process 400; LLP Identification Weight List, which is a set of predetermined weights given to activation identifiers in order to determine victor in conflicting LLP ownership scenarios, for example used in processes 300 and 400.

Entity 502 is an activation component, which may be used to define one or more types of components comprising a particular activation type. Key attributes 506 may include Component Type, which is used to define whether a given activation component is a rate plan, mobile device, sim card, add-on etc; Mandatory?, which may indicate whether given activation component is mandatory or not for instantiation of the given activation type; Identifier Type List, which may be used to define the various types of identifiers used to uniquely identify a component in a given activation and is a key factor in assessing conflicts between activation data and commission statements, as demonstrated in process 400.

Entity 503 is a commission element, which may be used to define one or more types of expected commission payments for a given activation component within a given activation type. Key attributes 507 may include Commission Type, which may be used to assign a predetermined type such as standard commission, volume bonus, subsidy, revenue share etc, all of which may encompass certain specific behaviour for commission calculation purposes. Another key attribute may be Element Name, which may be used to identify commission payments in commission statement file mappings.

Entity 504 is a commission payment schedule, which may be used to define terms for expected incoming commission payments 510 and agreed outgoing commission payments 511.

Incoming commission payments are defined by HLP commission terms 520, which may include a plurality of aspects. Product aspects 521 may comprise of Component Type, which may be used to define commission terms at high level, e.g. any rate plan component type might be eligible for £30 commission regardless of which rate plan has been selected; Component, which may be used to define commission terms at specific rate plan, mobile device, sim card or add-on level; Matrix, which may be used to define commission terms at a combination of components, typically tariff plan plus mobile device, for example a certain tariff plan might be eligible for £30 commission while a certain mobile device might be eligible for £20 commission which in total would be £50, however, in combination, the given tariff plan and mobile device might be eligible for £60. In scenarios where commission rates have been defined at more than one product aspect, for example both at component and matrix level, commission calculation may follow the principle of selecting the most particularised level, that is matrix level in said example, but in other implementations it may also aggregate the commission.

Time aspects 522, may be used to define commission terms based on time, for example Effective Date, which may be used to define commission terms in advance, say for example that from 1 June 2017, commission for rate plans may be £30, while from 1 July 2017 commission for the rate plans may be set to £35, where effective date is defined as per date of activation; Activation Date, which may be used to determine which commission terms are in use based on effective date and also when the commission payment may be due; Device Despatch Date, which may be used in some implementations to determine subsidy commission terms for mobile devices; Payable At, which may be used to determine at which point in time the commission is paid relative to, typically, either activation date or device despatch date.

Volume aspects 523, may be used to define commission terms based on volume, typically based on Number of Net Activations, which is activations minus cancelled activations within a given period, but can also be based on Number of Activations, not taking cancellations into account. Volume aspects are typically used in combination of other aspects, for example component types.

Other aspects 524, may be used to define commission terms based on miscellaneous factors such as Bespoke Agreements, which may be used to provide any type of additional commission, often in combination with other aspects, to certain MNDs. Promotional Activities may be used to provide additional commission payments on a temporary, promotional period basis. Customer Spend, or revenue share, may be used to share the revenue from end customers on a percentage basis over the time of an activation subscription duration with the MND.

Outgoing commission payments are defined by LLP commission terms 530, which may include a plurality of aspects. Element aspects 531 may comprise of Pass On, which may be used to determine whether the commission payment from a HLP attributed for a particular commission element may be passed on to the LLP or not; Fixed Commission, which may be used to provide a fixed commission amount to the LLP for the given commission element taking into no account what the HLP commission value is; Fixed Margin, which may be used to pass on the HLP commission amount to the LLP minus a fixed margin, e.g. E5 margin; Percentage Margin, which may be used to pass on the HLP commission amount to the LLP minus a percentage margin, e.g. 10%.

Time aspects 532, work exactly the same for LLP commission calculation purposes as for HLP commission calculation purposes.

Volume aspects 533, work in principle the same for LLP commission as for HLP commission terms, although typically an MND would not pass on the HLP volume commission as it is since that is based on all LLP activation volume. Instead, the MND would define separate volume levels achievable by a single LLP, with the aim of the aggregation of all LLP activations achieving a particular HLP volume based commission.

Other aspects 534, also work in principle the same for LLP commission as for HLP commission terms, although they are not necessarily the same. Typically, MNDs use bespoke agreement aspects to pay key or large LLPs additional guaranteed commission as a competitive measure.

Referring now to Figure 9, which shows a representation of the universal commission model for activation registrations 550, at the base is an activation detail structure entity 551, which may be used to define key attributes 555 of an activation registration. Key attributes may include Activation Structure, which is a reference to the activation structure being used for the given activation registration; LLP, which may be used to determine the owner of the activation from the viewpoint of an MND, i.e. the party which should receive any passed on commission from the HLP; Reference, which may be used to store an activation reference number assigned typically by the HLP; Date, which may be used to indicate the activation date, which is useful information for determining agreed commission payments; Mobile Phone Number, which may be used to store the mobile phone number of a new or upgraded activation for identification purposes; Commission Status, which may be used to track overall commission reconciliation status for a given activation, as per 590, e.g. how much commission are we supposed to receive and how much have we received so far and are there any discrepancies.

Entity 552 is an activation component detail, which may be used to list one or more activation components for a given activation. Key attributes 556 may include Component Type, which may be used to identify the corresponding component type to which the given component may be associated with; Name, which may be used to identify the name of the actual product used whether it is a make and model of a mobile device, a rate plan, an add-on or something else; Identifier List, which may comprise of one or more references uniquely identifying given component, e.g. a sim serial number or mobile device IMEI number; Commission Status, which may be used to track overall commission reconciliation status for a given activation component.

Entity 553 is a commission element detail, which may be used to list one or more types of expected commission payments for a given activation component within a given activation. Key attributes 557 may include Element Type, which may be used to identify the corresponding element type to which the given commission element may be associated with; Commission Status, which may be used to track overall commission reconciliation status for a given commission element.

Expected incoming commission payments 560 may be stored in element structure 565, comprising of Due Date and Amount. Typically, commission elements are paid only once at a given period after the activation date, but some commission elements, notably revenue share type commission types, are paid throughout the life cycle of an activation.

Confirmed incoming commission payments 561 may be stored in element structure 570, comprising of Paid Date, which may store the date of the statement which confirmed the commission payment; Amount, which may store the commission amount paid; Statement Ref, which may store the reference of the commission statement which the commission was paid; Discrepancy, which may be used to record any difference between expected and paid commission amount.

Agreed outgoing commission payments 562 may be stored in element structure 575, comprising of Due Date and Amount. As per expected incoming payments, typically, agreed commission elements are paid only once at a given period after the activation date, but some commission elements, notably revenue share type commission types, are paid throughout the life cycle of an activation.

Confirmed outgoing commission payments 563 may be stored in element structure 580, comprising of Paid Date, which may store the date of the statement which confirmed the outgoing commission payment; Amount, which may store the commission amount paid to the LLP; Statement Ref, which may store the reference of the commission statement which the commission was paid to the LLP; Discrepancy, which may be used to record any difference between agreed and paid commission amount.

Claims (36)

1. CLAIMS1. A method for processing and distributing commission payments from a higher level party (HLP) to a lower level party (LLP) in the telecom industry, comprising: configuring agreed commission terms and rates relating to specific mobile network products supplied by an HLP to a mobile network distributor (MND), into a universal commission model (UCM); configuring agreed commission terms and rates relating to said products supplied by the MND to an LLP, into the UCM; registering activation data containing said products, received by an MND from an HLP or an LLP, formatted in a proprietary standard; calculating expected commission payments from the HLP for said activation data; calculating expected commission payments to the LLP for said activation data; registering confirmed commission payments for said products listed in a commission statement, received by an MND from an HLP, formatted in a proprietary standard; reconciling said confirmed commission payments against said expected commission payments from HLP for said activation data and assigning predetermined statuses for encountered discrepancies; resolving said discrepancies; transmitting a commission statement containing commission payment information by the MND to an LLP, formatted based on the UCM.
2. 2. A method according to claim 1, wherein configuring agreed commission terms and rates relating to specific mobile network products supplied by an HLP includes conforming said terms and rates into an HLP commission terms structure.
3. 3. A method according to claim 2, wherein said commission terms structure includes product aspects.
4. 4. A method according to claim 3, wherein said product aspects includes component type terms.
5. 5. A method according to claim 3, wherein said product aspects includes component terms.
6. 6. A method according to claim 3, wherein said product aspects includes component matrix terms.
7. 7. A method according to claims 4-6, wherein commission, when defined at more than one product aspect, according to configuration, is calculated based on the principle of the most particularised level or aggregated.
8. 8. A method according to claim 2, wherein said commission terms structure includes time aspects to define from what date certain terms are effective from and when commission is due to be paid.
9. 9. A method according to claim 2, wherein said commission terms structure includes volume aspects to define commission based on MND achieving certain gross or net volume thresholds.
10. 10. A method according to claim 2, wherein said commission terms structure includes other aspects to define commission terms based on bespoke agreements, promotional activities or customer spend.
11. 11. A method according to claim 1, wherein configuring agreed commission terms and rates relating to specific mobile network products supplied by an MND includes conforming said terms and rates into an LLP commission terms structure.
12. 12. A method according to claim 11, wherein said commission terms structure includes element aspects to either pass on said element's HLP commission to LLP as is, pass on with a fixed commission amount, fixed margin or percentage margin.
13. 13. A method according to claim 11, wherein said commission terms structure includes time aspects to define from what date certain terms are effective from and when commission is due to be paid.
14. 14. A method according to claim 11, wherein said commission terms structure includes volume aspects to define commission based on LLP achieving certain gross or net volume thresholds.
15. 15. A method according to claim 11, wherein said commission terms structure includes other aspects to define commission terms based on bespoke agreements, promotional activities or customer spend.
16. 16. A method according to claims 2 and 11, wherein said HLP and LLP commission terms structures are defined for one or more commission payment schedules
17. 17. A method according to claim 16, wherein said commission payment schedules are defined for one or more commission elements.
18. 18. A method according to claim 16, wherein said commission elements are defined for one or more activation components.
19. 19. A method according to claim 16, wherein said activation components are defined for one activation structure.
20. 20. A method according to claim 1, wherein registering activation data containing said products comprises converting said activation data into a universal activation detail structure.
21. 21. A method according to claim 1, wherein registering activation data containing said products comprises storing said activation data into a central database.
22. 22. A method according to claim 1, wherein calculating expected commission payments from the HLP comprises determining pre-defined commission rate for one or more commission elements based on said HLP commission terms structure.
23. 23. A method according to claim 1, wherein calculating expected commission payments to the LLP comprises determining pre-defined margin for one or more commission elements based on said LLP commission terms structure.
24. 24. A method according to claim 1, wherein registering confirmed commission payments for said products listed in a commission statement comprises converting said commission statement into a universal activation detail structure.
25. 25. A method according to claim 1, wherein registering confirmed commission payments for said products listed in a commission statement comprises finding an existing activation in the central database by preferred identifier.
26. 26. A method according to claim 25, wherein preferred identifier is defined in an activation structure associated with the activation instance into which a commission statement is converted.
27. 27. A method according to claim 1, wherein registering confirmed commission payments for said products listed in a commission statement comprises updating any conflicting details of an existing activation in the central database.
28. 28. A method according to claim 1, wherein registering confirmed commission payments for said products listed in a commission statement comprises storing said commission payments against identified expected payment in a commission payment schedule associated with said identified activation in the central database.
29. 29. A method according to claim 21 or 28, wherein registering or updating activation data containing said products comprises detecting conflicting LLP information.
30. 30. A method according to claim 29, wherein detecting conflicting LLP information is based on assessing whether LLP looked up by LLP identifier and who each of the physical activation components were despatched to, are all the same.
31. 31. A method according to claim 30, wherein looking up who the physical activation component was despatched to comprises using a unique identifier defined for said activation component.
32. 32. A method according to claim 29, wherein determining LLP by calculating highest grade when conflicting LLP information has been detected.
33. 33. A method according to claim 32, wherein calculating highest grade is based on aggregating predefined weights for each identifier included in said activation, defined at said activation's associated activation structure.
34. 34. A method according to claim 1, wherein reconciling said confirmed commission payments against said expected commission payments comprises assigning of predefined reconciliation statuses based on whether confirmed commission payment makes a registered activation fully paid, underpaid, overpaid, not paid, not yet expected paid or paid to an unknown activation, at the given point in time.
35. 35. A method according to claim 1, wherein resolving said discrepancies comprises selecting an action to either clear the discrepancy, make adjustments or enquire with the HLP.
36. 36. A method according to claim 1, wherein transmitting a commission statement containing commission payment information comprises generating said commission statement based on expected commission calculation or confirmed commission calculation, according to configuration.