Adding Publisher Agreement Numbers for Your CWR Deliveries

Certain societies, such as PRS, require you to provide agreement numbers between yourself as an Original Publisher and your Composers. These agreement numbers can be stored on the Composer on Curve.

In the event where you Sub-Publisher or Administrate another Publisher, you would need to provide an agreement number between yourself as a Sub-Publisher/Admin and the other Publisher. These agreement numbers can be stored on the Publisher that you sub-publish/administrate.

1

Add the Agreement Number to the Composer or Publisher that you represent

To get started, go to your Catalogue > Composers (if you wish to add the agreement number to a Composer that you control) or Catalogue > Publishers respectively (if you wish to add the agreement number to a Publisher that you sub-publish or administrate).

Via the Publisher Agreement area of your Composer/Publisher, you can specify the below variables:

  • Publisher - Which Publisher does this Composer/Publisher have an agreement with? This would be one of your own controlled Publisher entities.
  • Agreement Type - Do you represent this Composer/Publisher's entire catalogue (Original General)? Or just specific Works from their catalogue (Original Specific)?
  • Territory - In which territories do you represent this Composer/Publisher?
  • Society - With which society is this agreement number registered?
  • Agreement No - The agreement number in question. This is the number you would have registered with the society.

2

Select this Society in your CWR Delivery

Once your agreement numbers have been set up, these will automatically be included in your CWR file when the Receiving Party in your Delivery matches the Society in the agreement number setup.

How does this look like in CWR?

In the CWR format, an agreement number between a Composer and its Original Publisher will always be stored on the PWR line in the CWR format, which links the Composer to the Original Publisher.

An agreement number between two Publishers is always stored on the SPU line of the Sub-Publisher/Admin highest up in the chain.

What if one Sub-Publisher/Admin has multiple Agreements?

It is possible that you have a Sub-Publisher or Admin at the top of the chain, which controls another Sub-Publisher or Admin. You may thus end up in a situation where a Sub-Publisher controls multiple Publishers within one chain, and thus that Curve could find multiple agreement numbers to apply. In this event, the agreement number which we will store on the SPU line of a Sub-Publisher will be the one that we can find on the Publisher which is lowest down in the chain.

In the example below, if you have only specified an agreement number between "Agreement B Publishing" and "Agreement C Publishing", then this will be stored on the SPU line of the "Agreement C Publishing".

If you have only specified an agreement number between "Agreement A Publishing" and "Agreement C Publishing", then this will be stored on the SPU line of the "Agreement C Publishing".

If however you have specified an agreement number between "Agreement A Publishing" and "Agreement C Publishing" as well as between "Agreement B Publishing" and "Agreement C Publishing", then we will store the agreement number between "A" and "C" on the SPU line of "Agreement C Publishing".

We do so because in practice, the societies would expect to find the Agreement Number between the Sub-Publisher at the top of the chain and the Original Publisher at the bottom of the chain. Thus if one is provided, that's the one we will take. There could be scenarios however where you control a Sub-Publisher which controls lots of different Original Publishers, and that you wish to apply the same Agreement Number for each of these Works. In this event, just storing this Agreement Number on the Publisher that you directly sub-publisher itself will do, rather than you having to store this Agreement Number on every single Original Publisher that this Publisher may work with.

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.