Royalty Software for Music Publishers

If you are looking for Music Royalty Software, try DMP Guru, otherwise enjoy the article.

When one googles music royalty software, most solutions and articles are about royalty tools for labels, not for publishers. While there are other causes, the main one is that publishing is far more complicated than labels. Registrations are far more complex with original publishers, administrators, sub-publishers, share changes for three types of rights. On the other, in most cases, the use of the recording is logged, and composition has to be deduced.

When it comes to the latter, it is the responsibility of the collecting society or whoever is sending the input statement, so it is irrelevant.

If one has the right data in the database, then the former also becomes irrelevant. The processing may take a bit more time, but that is the only difference. If one has the right data in the database…

What does it really do?

Royalty processing for publishers usually means taking incoming royalty statements and using that data to create outgoing ones and data for accounting. Rarely, instead of through incoming statements, the input data is manually entered.

Incoming statements can have different formats, but the basic unit is usually referred to as “row”. A row usually holds data on what recording was played, for how long, where, when, etc. Usually, it also has data on the underlying composition(s), but not always. What it always has is the amount (to be) received. Sometimes it is in a foreign currency, so it has to be converted.

But, in general, one row in the incoming statement has to be converted to multiple rows (zero or more, technically), usually in multiple statements for multiple clients. The resulting row is, in essence, the same as input row, with additional data: what percentage goes to which client, how much is a publisher fee, a few other numbers and, most importantly, the net amount to be paid. The form of this additional data actually does not differ at all, except that it may say “publisher” or “writer” or “performing artist” in one of the columns.

This process has, basically, three steps. The input statement has to be parsed into a format that is native to the royalty software. Then this data has to be processed, resulting in output rows. Finally, this data has to be outputted. Each step can result in data being saved or not. Each step will be described in more detail.

Parsing incoming statements

There are (far too) many royalty statement formats, but they can be divided into two groups: flat and complex. Flat formats are mostly CSV files, although there are also other formats, e.g. Excel spreadsheet. What makes them “flat” is that each row is independent and holds all the data required for processing. Complex formats usually have a more database-like normalized structure. But they can always be flattened (denormalized) into a flat format. While this may not be the optimal process in all cases, it is a pretty universal one. The flat data is then converted into the internal format.


Data processing is a relatively simple task, although it is usually the most time-consuming. For each row, the work and/or recording has to be identified and the data on interested parties and their shares, have to be fetched from the database. The incoming amount has to be split into amounts for all interested parties that partake, the fees have to be calculated and deducted and the resulting data is returned.

For example, if an original publisher controls two of four writers, with 25% relative share each, and publisher fee of 50%, then there will be two output rows for each incoming one, one for every controlled writer. And for each unit of currency (e.g. $) received for the controlled share, .25 will be the net amount to be paid to each of the writers and .50 in total to be kept as the fee.

Please note that much of this processing can and should be delegated to the database, but this, as any other optimization, is beyond the scope of this article.

Output statements and accounting reports

The resulting rows then have to be outputted. In the case above, the two rows will be outputted in two separate statements, one for each of the writers, and an accounting report. This data may also appear in various summaries. It is also possible that the creation of the output statements is delegated to the accounting software, which is the optimal process if accounting software supports this.

All possible formats for these documents are beyond the scope of this article. It can safely be presumed that there will be at least one that is flat, while more complex ones can appear as well. In many cases, they can be, but don’t have to be, the same as input formats.

An alternative approach is to export the data in a single Excel document with predefined pivot tables. This will be covered next.

Using Excel and pivot tables

In my opinion, for small publishers, this is the optimal approach. Excel does impose limitations on the number of rows to just above one million, so if there are more rows in a single output, then this approach can not be used (without splitting).

If this approach is used, then the output of the last step within the royalty processing software is to output the Excel file with at least three sheets. One holds all the data, while another features a pivot table, which enables filtering and summaries. Then further sheets can be used as templates for various statements.

For example, if a single writer is filtered in the pivot table, then this data, in the properly defined statement sheet, results in an output statement for this writer. There are really no limitations to the look of this sheet, it can have a logo and other branding elements.

It is also possible to use macros to automatically create and export statements for all the writers. Although this can be done in the royalty software, the Excel approach is a far more customizable option, though it does require Excel skills beyond basic.

An example will be made in one of the next articles.