Move from Manual to Batch Registrations with CWR 3.0

Starting with Manual

Normally, publishers start registering manually, some have been doing it for decades. But, at some point, they choose to move to batch registrations. This process was quite problematic so far, mostly due to missing internal work identifiers.

I have covered identifiers in several other articles, for this one, it is sufficient to say that sender’s (publisher’s) work ID is important. No society that I know allowed their input through the web interface, a good choice since it would just make a mess. They did assign them receiver’s (society) work IDs, visible in the web interface.

Moving to CWR

So, when a publisher chose to move to batch registrations, there was an issue of importing existing registrations. Different societies dealt with this in different ways, some would send CWR Light files (not really CWR), or fake acknowledgment files, or custom CSV files. Each approach had issues but in none of them were both publisher and society work IDs in one file.

So, publishers would import the data with society work IDs. The software would assign internal publisher work IDs, but there was no way to send these to the society in some kind of re-registration.

Or, more usually, they would not, but put the “old” works into the system without society work IDs (most software does not allow that anyway). And without ISWCs, which were problematic. (This is hopefully also solved now with CWR 3.0, as described in this article). Without any of them, there was no good way to match royalty statements and the society still did not know publisher work IDs.


Cross-reference (XRF) records have been introduced. These records can now be used to submit various identifiers, including for work, including third-party IDs. So, even without ISWCs, a publisher can now tell to the society: you already have this work under this work ID. Also, sub-publishers can now add their work IDs, but also say: this original publisher uses this work ID for this work.

This whole process will make moving from manual to batch registration a very simple process. With the introduction of the new, cloud-based software that supports it, at prices that are much lower than even a few years ago, music publishing will finally move into the digital age.

Similarly, societies can send work IDs of other interested parties, so if there is a conflict, a publisher will be able to contact the other one and say: look, there is a conflict between this work, my ID is this, yours is that. It should really streamline the process.

Surely, everything depends on implementing it correctly. But, if I can do it in a free open-source project, then societies and big software vendors should be able to do it as well. Now, for full disclosure, Django Music Publisher had imports of society work IDs even with CWR 2.1, but it now reports them in CWR WRK transactions.

In this way, data delivery to other publishers (most notably sub-publishers) will be complete. Please note that CWR 3.0 no longer has ownership shares, but there is a way to exchange complete data, as well as validate it. I will cover it in one of the next articles.