Statements with Artists and Products

[richardbirkin]

Background

Record labels receive their income from selling the work of their artists in diverse ways. The Income Statements from these sources contains data on which products have been sold (albums, tunes) or generated income (from streams or sync) for each artist. It is the responsibility of the label to process these statements and work out how much each artist is owed, and to take the label's own contractual/agreed % share of this income.

It is their responsibility to notify the artist of the final amount so that invoicing/payment can occur.

In some contracts/agreements, a payment will only be made if a certain amount of income has been generated to cover the costs of releasing the artist's work. A label should supply the artist with timely and accurate reporting of any balance +/- that occurs.

What Value Are We Adding ?

It's a struggle running a record label. Releasing music costs money. Selling records costs money as, to do that, you need to make people aware that it exists (marketing). Wrestling with the data flow and working out how much is going out to artists (and then communicating that with the artist/agent) is a struggle and, ultimately, an overhead.

TrackShift can reduce this overhead by:

• processing the data more efficiently and accurately
• communicating directly with the artist via the artist profile
• storing contractually agreed % shares of each product
• providing statistics on the sales of each product
• sharing all data with the artist via the artist profile (transparency)

(...all from drag and drop.)

Initially, this feature should at least achieve the first bullet point above.

Requirements

Feature: Statement Upload and Processing In order to combine and reformat music royalties data into something i can quickly understand As a label user I need to be able to upload a file and have it processed so that I can see how much each Artist has earned And how much each Product has earned

[richardbirkin]

@g105b I don't think the first version of this feature needs to do anything more than this.

I'm breaking down my label statement from Believe that contains multiple artists with multiple releases here

[richardbirkin]

I have sent out a small survey to some contacts. Not really to aid in the product design, but to get an idea of how people are operating currently.

https://tye03q65s4n.typeform.com/to/t8KBzryO

We have had 8 responses in 12 hours all from a couple of emails.

The plan is to contact some of the respondants to be the alpha testers for Milestone 4.

[richardbirkin]

The results of the survey so far suggest that Bandcamp is the most common vendor among small indies. This makes sense as regardless of a label's distributor (Believe, PIAS, Tunecore) they would have to deal with Bandcamp direct as Bandcamp is not a DSP or Distributor in the standard industry definition.

A label would upload their catalogue to Bandcamp and receive payment direct from Bandcamp upon any sale. With physical items (CD, vinyl, merch), Bandcamp will sell them but the label (or their fulfilment partner) is responsible for mailing. Again, they receive payment direct from Bandcamp.

One downside is that metadata is not compulsory on Bandcamp like it is with distributors and DSPs. If a label hasn't put ISRCs etc. in their uploads to Bandcamp then they will not appear in Sales Reports.

We can still do a lot even if a label does not use metadata, since the Bandcamp payment system (with taxes, payment charges, paypal share and Bandcamp share) is still quite hard to understand.

The core scenario of Milestone 4 still applies:

A Label has a Sales Report containing income from multiple artists. TrackShift can process the Sales Reports to show how much each artists has sold/earned Gross/Net for each product.

We have lots of Bandcamp sales report CSVs already.

I have started to breakdown the Sales Report format in the Wiki

[richardbirkin]

I sold a single track from an album last night. Here's the calculations in the email from Bandcamp:

[richardbirkin]

The revenue share balance is a really complicated relationship. Bandcamp was set up that way more than a decade ago and hasn't improved its comms or replaced it with something better. I need to delve more deeply into this. Will do so in the wiki.

[g105b]

One downside is that metadata is not compulsory on Bandcamp like it is with distributors and DSPs. If a label hasn't put ISRCs etc. in their uploads to Bandcamp then they will not appear in Sales Reports.

Something we can automate is making the connections between supplied data from different sources. For example, if a user has populated TS with Bandcamp data, but it's missing the key points like ISRC, we can alert the user of this missing data with suggestions about what data can be used to link up. If they then upload something from their distributor, we can match on the fields we do have (even simply linking on track name), and get the user to confirm the link has been made correctly.

I have started to breakdown the Sales Report format in the Wiki

Super useful, thanks. I'll let it percolate.

The revenue share balance is a really complicated relationship.

Complicated or not, if IS gets to the important numbers as quickly as possible for the user, it might be a tool orgs like Bandcamp can use to simplify things in the future.

All good stuff, I'll read over things over the next few days and give it all some thought.

[richardbirkin]

Bandcamp's own explanation of the Sales Report: https://get.bandcamp.help/hc/en-us/articles/360007802454-Reading-your-sales-report

From my calculations the net amount is the one we should be pivoting to for each artist and upc or (if no UPC value then) item name

The way that all the fees are worked out and collected is different depending on item type but for SLC purposes we don't need to worry about that. As Bandcamp says:

Use this column if you need to determine how to split out payments to multiple artists.

[g105b]

I've just been mulling this over so I have a definite task list when I come to implement it. Some notes to future Greg:

• Need to add a new property to Usage for the Artist the usage refers to
• An Artist should have one or more ArtistIdentifier objects, so the artist can be linked from different sources automatically
• Identifiers will be a different column for each source - for PRS I will use "CAE Number", for Bandcamp I will use "paid to"
• Is it possible to retain a link from Usage to the specific line in the Upload object?

Some questions for you @richardbirkin:

1. On Bandcamp, there are albums and tracks listed. Should we just treat these as a Product even though some tracks will appear on the albums they are alongside, and even though an album sale is a lot more value than a track sale?
2. For Bandcamp, the Artist column varies slightly to not just be "Richard J. Birkin" - should this information be used in the calculation of Artist earnings, or is it OK to group by the "paid to" column? Is there anything we should do in the future with the "artist" column?
3. Do we care about the PRS IP1, IP2, IP3, IP4 column for this iteration of functionality?

[richardbirkin]

1. Yes. track is a type of product
2. We should use the artist not paid to - as if it's a label then all the monet will go to the same paypal address. we want to show how much each artist has earned. In my CSV you should see 'Emphemetry' and 'Richard J. Birkin'
3. No.

[g105b]

The reason I was avoiding the artist field was because it sometimes contains things like "Emphemetry", "Richard J. Birkin", "Emphemetry | Richard J. Birkin" and then things like "Christmas Robin & Emphemetry" - there are a few distinct records in there and I thought it would be confusing to see them listed separately.

Should we just treat them as separate artists?

[richardbirkin]

for now, yes