Third party revenue settlement

Summary

Settlement is used by billers to divide up their revenue streams for products and services provided by outside business partners. Accurate and automated settlement enables billers to actively seek additional product offerings and collect a revenue slice from these additional sales. Automated settlement allows billers to team efficiently with multiple partners and address large product catalogs (e.g. music) that are difficult to handle manually.

Many businesses employ revenue settlement including content providers (Apple's iTunes), advertising (Google's Adsense), third party billing (NTT DoCoMo's i-mode), and payment support (Swisscom Mobile).

Sharing revenue with business partners (providers)

Many billers share their revenue stream with business partners who provide raw products and services that are on-sold to the biller's retail customers. Revenue settlement is the business-to-business (B2B) process that divides / shares a (usually retail) revenue stream between two or more contributing parties.

Examples of businesses sharing their revenue streams include:

Content provider: Apple's iTunes sells song downloads and shares the resulting revenue with record labels (businesses). The songs are not 'owned' by Apple who retails them to end customers.
Advertising: Google's Adsense 'sells' advertisements on the websites of third parties (along with their own websites). The advertisers' revenue (i.e. when an ad is clicked upon) is 'shared' with the third party websites upon which they were shown.
Third party billing: NTT DoCoMo's i-mode system allows mobile phone customers to direct non-call charges for data services (e.g. weather, cartoons, games) to their mobile phone bills. DoCoMo retains a portion of the revenue they receive and remits the remainder to the contributing third party businesses.
Payment support: Swisscom Mobile's customers can use their mobile phones to pay for soft drinks from automated vending machines. The soft drinks' charges are placed on the customers' bills and the settlement process pays the vendors a percentage of the drinks' value.

Billers may also settle transactions for which they receive no retail revenue. For example, billers may offer potential customers product samples to encourage further purchases. These 'loss leader' samples are free to the retail customer, but may require payment to the (say) content provider who 'owns' them.

Retail and provider relationships

Each example listed above is constructed of one relationship between the biller and the end customer (i.e. retail), and a second relationship between the biller's business and a provider (e.g. copyright owning business) with whom a settlement arrangement is negotiated to divide up the retail revenue stream. The billing systems supporting the retail relationship are constructed with a different focus to those supporting settlement reflecting the difference in emphasis.

Retail billing systems are configured to address a retail customer base (possibly numbering in the millions) where individual customers are sold products and services at a retail price, possibly with some price customisation. Retail systems focus on the end customer rather than the content, address ongoing customer changes (i.e. new additions, changes, cancellations), and generate customers' regular billing. The provider relationship is secondary to the retail relationship, and unimportant to the retail customer.

Settlement turns this around by focusing instead on the content provider rather than the end customer. The identity of the end-customer is less important than which products and services were 'purchased' within a given period.

Billers will maintain relationships with a small number of providers relative to the size of their retail customer base. As a consequence, billers can have a very high volume of transactions ('sales') mapped to a small number of providers. The provider relationship is primary over the retail relationship, which, for reasons of customer privacy and retention, may omit identifying details of retail customers from data exchanged with the providers. Settlement will perform its processing based on aggregated totals rather than focus on what individual customers have purchased.

Settlement processing is a form of 'anti-billing' because, rather than asking for payment for incurred debts, settlement calculates the credits to other providers based on the biller's business activity. The biller's accounts payable system is passed the calculated balances (rather than accounts receivable), and a report / 'bill' / statement is dispatched to providers explaining how the settlement totals were reached.

Settlement ('billing') arrangements

Settlement can employ the same calculation mechanisms used in retail billing but focused on the provider rather than the end customer. Settlement can use the same transaction details available to retail billing along with the retail price when calculating settlement totals. The specifics of each settlement arrangement will be negotiated between the biller and each provider, with separate settlement arrangements possible for each segment of a provider's product catalog (e.g. music versus movies).

Billing mechanisms employed can include:

Tiered and threshold pricing: These approaches select how the credit amount will be calculated based on aggregated transaction totals. For example, a tiered method might award an increased percentage of the retail revenue as more songs are sold. The threshold method could calculate a different revenue (split) percentage across all sales as they increase.
Fixed amounts and percentages: A fixed amount may be credited per transaction, or a percentage of the retail revenue might be used instead.
Base credits: Providers may receive a base credit per settlement period that is volume-independent delivering providers a guaranteed income. Billers may negotiate an offset of this advance against the provider's settlement credits to minimise outlays.
Minimum and capped totals: Billers may negotiate minimum and maximum payments per transaction to balance the provider's downside (i.e. minimum payment) and protect the biller's upside (i.e. maximum payment).

In common with retail billing, arrangements may be effective dated and employ standard rates overridden for transactions performed on special days or under specific circumstances.

The timing of revenue settlement

Including the dimension of time in settlement processing allows billers to adjust when payments to providers are made, and pay only when charges have passed specific points in the end-to-end billing process. Naturally, this timing is another aspect that is up for negotiation between the biller and their providers.

Immediate settlement - Under this approach the timing of when billers pay their providers for transactions incurred is independent of how much and when the end-customer pays their retail bill. Transactions are settled with little or no reference to the billing process. This is the simplest settlement approach to support, but billers may settle (pay) for transactions that are never billed or collected.

This approach does not have to wait on customers' billing cycles, and may not use the retail price to perform the settlement. For example, a direct feed of music downloaded from a biller's network may support the calculations of a fixed settlement amount per song with a music provider. To reduce the financial exposure, a revenue assurance reconciliation against what is billed would be advisable to monitor the quantity of songs sold.

Settle only when billed - Billers may delay settling with their providers until after transactions have been billed and sent to customers. Charges that are incomplete or withdrawn (disputed) can then be omitted from settlement calculations. The retail billing process may establish the actual retail price charged to the end customer (e.g. after discounting).

Billers taking this approach must develop feeds from their billing systems that preserve sufficient detail to support the settlement process. For example, the identity of songs downloaded or reports purchased must be maintained to allow different settlement arrangements for 'Top40' songs over 'Jazz', or 'Premium' business reports over 'Summaries'.

This approach adds additional conditions to the settlement process and increases the data storage requirements for customers who bill infrequently (e.g. quarterly).

Settle only when paid - Billers may defer settlement until retail customers have paid their bills (debt). This approach ensures billers only settle revenue that has completed its bill processing and for which the cash has been received. Customers whose bills are unpaid may become delinquent and the biller will have settled for revenue they are unable to collect.

This approach adds still further conditions to the settlement process and requires additional data feeds and storage. The billing system must store and supply details of bills containing transactions eligible for settlement, and indicate to settlement when they have been paid. The biller's accounts receivable system may need updating and new data feeds may be required.

Multiple Feeds to Settlement Processing

A biller's systems may not support all of these settlement practices. Each may require data feeds from different operational systems that are stored until the settlement calculation is performed. The data storage required will increase as the pre-conditions to settlement increase.

Depending on which settlement approaches are used, a biller's settlement system may receive feeds from their network (or other operational systems), from their billing system when a retail customer's bill is generated, and from their financial systems identifying when bills are paid (or written off).

Challenges in settlement processing

Classification - Providers with large product catalogs (e.g. music, movies) present challenges in billing since the biller's own product portfolio may be overwhelmed by those of their provider partners. One approach to reducing this challenge is to classify the providers' offerings into a smaller number of categories. For example, categories such as 'Jazz', 'Blues' and 'The Beatles' can be used in billing to price and display a customer's purchases rather than the individual music tracks.

Using this approach, a customer's purchase of a song can include its classification (category), identity (song 'id'), and title description. These details can be populated before the purchase reaches the biller's billing systems, reducing the detail that must be stored and maintained (in billing). The song's category could be used in pricing and bill presentation, its identity passed to settlement (or other business systems), and its description populated in a standard field varied to address customers' language preferences.

Alternatively, the price of transactions can be assigned before billing (in the providers' systems) and charged to customers unchanged. The provider would be responsible for adjusting prices over time, and the biller would be compensated through the settlement process by retaining a portion of the retail revenue.

Price Changes - A provider's catalog will change, with some items changing rapidly over a short period of time. For example, a song might be classified initially as 'Latest release', be changed to 'Top10' after a few days (or weeks), move to 'Top40' over the next few months, and eventually end up with a long-term category of 'Jazz'.

The settlement process must be able to distinguish between songs purchased under each of these categories to support targeted settlement arrangements. Each item in a provider's product catalog may undergo such transitions, though the most recently added are more likely to under the highest degree of change.

Scale - Billers must address multiple dimensions of scale affecting their settlement and bill processing. Depending on what their provider's sell, billers must address scale in dimensions such as catalog size (e.g. music versus business reports), rate of catalog change (e.g. price, classification), number of separate catalogs (e.g. music companies), customer base (e.g. corporate versus mass market), and number of transactions per customer (e.g. one report per company versus twenty songs per individual).

Examples of products with large catalogs include newspaper articles (many per day), music (artists, record companies, albums, independent producers), movies (by country, language, genre), phone ringtones (similar to music), and stock photographs (used in publications and advertising).

The dimensions important to each biller will vary. Billers with a limited number of providers may develop their systems with just those providers in mind, but this may limit their ability to scale their settlement processing to include other providers and their product offerings in the future.

Bundles and Subscriptions - How billers collect revenue from their retail customers may have no relationship to how they settle with their providers. Billers who collect revenue using bundles / subscriptions ('all you can eat') and perform settlement based on the count of transactions performed must decide how their fixed revenue base (subscriptions) will be divided. This becomes more complicated when the same subscription covers multiple providers.

Maintenance - Billers and their providers must identify how their products and services will be maintained over time. Each existing item in a catalog may be modified by the biller and/or provider. Each provider will want to add new items to their product catalog, and will prefer to perform their updates independent of other providers (and the biller). The biller's systems may also be updated weekly or monthly to reflect new products offered by the biller's own (internal) network.

The maintenance process, timing and interfaces must be developed to ensure all parties can perform as and when required to generate accurate results. If maintenance is not performed in a timely manner, transactions received by billing may fail validation ('what is it?') or be assigned incorrect pricing.

Credit management - The settlement arrangement between the biller and provider must address the issue of bad debt. Customers who purchase or 'consume' products are expected to pay their bills providing the necessary cash for settlement. If part payments are received, billers must determine when providers' settlement conditions have been met so that the appropriate payments can be made.

When customers' bills remain unpaid and their accounts are written off, any amounts subject to settlement must also be addressed. If settlement was conditional on the customer's payment then no settlement payments will have been made and so no reversal will be required (though supporting reports may be needed). Unconditional settlement payments or those conditional only on the billing step will have paid providers already. In these circumstances, a settlement reversal may be calculated and applied against the provider's future settlement payments.

To avoid these complexities, billers and/or providers may prefer to adjust the terms of their settlement arrangement to compensate the biller for assuming the financial risk of bad debt. This is a form of 'insurance' on the part of the provider, and reduces the complexity of settlement processing for the biller.

Inter-system reconciliation - Generating transactions on a biller's network and subsequently performing settlement on them can generate reconciliation discrepancies between time periods and product totals. Billers and their providers must work through 'in detail' the specific timing and basis of their reconciliation process. All parties must agree on the timing cutoffs and ensure that measurements are applied consistently throughout the billing process.

For example, settlement arrangements that vary the settlement percentage based on the number of transaction in a month will need to agree on when the 'month' runs from, which transactions are included, how to address delayed transactions, and which totals should reconcile (e.g. music tracks downloaded from network servers reconciled to the rated tracks processed in billing).

Tags: Billing, Content Settlement, Revenue Sharing, Third Party Billing