Music Royalty Software - Calculations
In the previous article, it was explained why and how the matching of rows from a royalty statement with works in the database can and should be fully automated. Even when this is not possible, and manual matching is required, it has to be done before the step described here - Calculations.
If you watched the video linked above, then you know that we claim that the identifier column was used for matching. There are one or columns that are important in this step. One is the amount that has to be distributed. The other column, available only in some statements, says which kind of right this is: performance, mechanical or sync.
One column often raises confusion at this point: Currency. It is irrelevant in this step, the math is the same for all currencies. We'll deal with it in the next step: Aggregations.
The example in the video above presumes that the incoming royalty statement was sent to a publisher who is only the original publisher, not administrator or sub-publisher. In this particular article, we'll presume the same. We'll deal with administrators and sub-publishers in other articles.
In the screenshot above (from the video, linked at the top of the page), we can see how calculations are performed. We'll focus on the first two rows. They were a single row in the incoming statement, but this publisher controls two (out of three) writers in this work. So, one row becomes two rows, one for each of the controlled writers.
The first four columns are just copied over from the incoming statement. More columns can be copied over, of course, we are just keeping it simple. The other columns are added by during royalty processing in DMP.
Controlled by Publisher
This columns tells us what share is controlled, so by both controlled writers. This is simply the sum of Manuscript Shares for these writers in this work.
Interested Party, Role and Manuscript Share
The next three columns are simply copied over from the database. Note that DMP uses a single manuscript share model. Another system would output different columns. Regardless, at least one of them would be a share column. Interested Party column will be used in Aggregation.
Share in Amount Received
This column tells us what share Smith has in Amount. This is calculated by dividing Manuscript Share by Controlled By Publisher. So, 50% / 75% = 66.67% for Carr-Toon, and 25% / 75% = 33.33% for Toonsen.
Amount Before Fee
This is the column that shows how much of the received amount is for manuscript share of each writer. In this case, the amount is 12.12, so 66.67% * 12.12 = 8.08 is for Carr-Toon's manuscript share, and 4.04 for Toonsen's.
This is another column copied over from the database. It seems that Carr-Toon has a better deal than Toonsen.
This column is calculated by multiplying the previous two columns.
This is the amount to be paid out to the writer, it is calculated by deducting Fee from the Amount Before Fee. So, 8.08 - 2.02 = 6.06 for Carr-Toon and 4.04 - 1.21 = 2.84 for Toonsen.
We are often asked why most people in the industry make so much fuss about this, and we claim that it can be as simple as shown here? You should really ask those making the fuss.
Does administration and/or sub-publishing make things more complicated? Actually, no. Besides the writers, interested parties would be also publishers. The process is exactly the same.
If you are an administrator, you repeat the same process one more time, with your outgoing statement for a publisher you administer going into the same process as incoming statement. Then the output of that process are statements that go to your client's clients. As stated at the beginning, that will be covered later in the series.