# Revenue sharing and operations research – part 1

I’ve been putting this one off for too long. First, it was a problem I encountered when I was employed, and I had to be careful about what I wrote. Second, it’s one of those articles where it’s a mix of mathematics and programming, and in this case, business as well. You might not know it, but I get a headache categorising articles like these… that’s why I just dump them into a generic category. Third, fully explaining the problem and the solution makes a long article.

You still here? Good.

I will write this in 3 parts. I’ll explain the business problem first. In the 2nd part, I’ll tell you why mathematics was involved, and how it eventually wasn’t involved because fully implementing the maths model in code wasn’t advisable. Also, I will then be the only one who can understand the code (because of the maths concept). In the 3rd part, I’ll tell you about the solution used (something simpler that other people could understand).

Ok, let’s get to it.

### Revenue sharing

I have to tell you about the business situation first because the term “revenue sharing” means differently depending on the context. In that particular job, I was employed by a telecommunications company. One of my users dealt with content providers, companies who create content such as ring tones, downloadable phone backgrounds (I think?), songs, and eventually included videos-on-demand.

So we (the telecommunications company) charged the end users (people like you and me) based on the content consumed, which was included in the phone bill. The content providers needed us mostly because they don’t have the distribution (number of users) or because of the billing platform (the phone bills).

A parallel would be the Apple App Store. Apple charges the consumers, then gives a cut to the content providers (the app developers).

In the beginning, my users used a simple Excel spreadsheet to do the revenue sharing calculations. Most of the contracts were simple percentage splits, such as 30-70 (as in us 30% and content providers 70%). As the number of content providers and products (from the providers) grew, the simple spreadsheet was proving inadequate. Moreover, the spreadsheet solution was the limiting condition for approaching other content providers to partner with us (and thus growing the business).

There were tax considerations because overseas and local content providers were taxed differently. Withholding tax was a slight headache. The Singapore goods and services tax was a nightmare then, because at the time, we were moving from 3% to 4% then 5% (it’s now 7%). Some content providers wanted minimum sum conditions (“Don’t share revenue with me unless it hits at least \$X per month”). Also, for internal accounting purposes, the Singapore dollar equivalent must be available (there were overseas content providers, remember?), so the currency exchange rate must also be used. Like I mentioned, the spreadsheet wasn’t working too well at that point…

Eventually, my users came to my department for help. Basically, we were to write up a software system to do those revenue sharing calculations for them every month.

“Uh, so what’s the problem?” I’m getting to that.

### Rounding errors

In the report to the content providers, the exact breakdown of each product must be given. This presents the possibility of rounding errors. Let me give you an example.

Let’s say for a content provider, the total revenue is \$100 for that month. Let’s use the 30-70 split. Also, there are 3 products involved. Here’s the total revenue breakdown for the products:

• ProductA: \$63.13
• ProductB: \$20.75
• ProductC: \$16.12

Splitting revenues, we have (rounded to the nearest 2 decimal point because of currency considerations):

• ProductA: \$18.94 (us), \$44.19 (them)
• ProductB: \$6.23 (us), \$14.53 (them)
• ProductC: \$4.84 (us), \$11.28 (them)

Now, let’s get the sum total revenue shared.
We get \$18.94 + \$6.23 + \$4.84 = \$30.01
The content provider gets \$44.19 + \$14.53 + \$11.28 = \$70.00
(note the split for ProductB for the rounding “error”)

But \$30.01 + \$70.00 is not equal to \$100! Therein lies the problem.

I did research on rounding. There’s “normal rounding” (1.14 becomes 1.1, 1.15 becomes 1.2). There’s rounding half up (1.15 becomes 1.2, but -1.15 becomes -1.1), and rounding half down (1.15 becomes 1.1, but -1.15 becomes -1.2). There’s even banker’s rounding.

The department I worked in supported users by providing programming assistance to financial problems. Let’s just say an extra \$0.01 or a missing \$0.02 causes great panic throughout the team…

So I was consulted on how to solve this problem. This is basically an assignment problem. Which are problems addressed by operations research, which I took a full semester’s course on.

Let’s just say my colleague was not pleased that we might have to implement a full-blown mathematical model just to do revenue sharing. In the next part, I’ll tell you how a maths model might be used, if it was implemented.