# What is CWR? Common Works Registration Explained > CWR (Common Works Registration) is the CISAC standard format for registering musical works with collecting societies worldwide. *Published by [TrackForge](https://trackforge.studio) -- 9 March 2026* --- Common Works Registration is the global standard for exchanging music rights data between publishers and collecting societies. Every royalty payment starts with a registration -- and almost every registration travels as a CWR file. If you work in music publishing, administer rights, or collect royalties across territories, CWR is the format that carries your data from your system to theirs. - CISAC Standard - Fixed-Width ASCII - Used by 200+ Societies --- ## The Format CWR is a flat-file data format maintained by CISAC (the International Confederation of Societies of Authors and Composers). It exists for one purpose: to let publishers register musical works with collecting societies in a standardised, machine-readable way. A CWR file is a **fixed-width ASCII text file** with strict formatting rules. Every line is exactly 80 characters in CWR 2.1 (or variable-length in 2.2), and every character position has a defined meaning. There are no delimiters, no XML tags, no JSON brackets. It is a positional format -- column 1 to column 3 is always the record type, column 4 to column 22 is always the transaction sequence number, and so on. Inside a CWR file you will find everything that defines a musical work from a rights perspective: ### Identifiers (ID) ISWC (International Standard Musical Work Code), society work numbers, publisher-assigned internal identifiers. The keys that link a work across systems worldwide. ### Interested Parties (IP) Every contributor to the work: writers, composers, arrangers, sub-arrangers, translators. Each identified by IPI number (Interested Parties Information) and society affiliation. ### Publishers (PU) Original publishers, sub-publishers, administrators, income participants. The full chain of entities with a commercial interest in the work. ### Ownership Shares (SH) Performance, mechanical, and synchronisation shares for each interested party. Expressed as percentages that must sum correctly within the file. ### Territory (TR) Which territories (countries or regions) each share applies to. A single work can have different ownership structures in different territories -- CWR handles this natively. ### Recordings (RC) Links to specific sound recordings via ISRC codes, connecting the abstract musical work to its physical or digital embodiments. --- ## Why It Matters: The Backbone of Music Rights Data Exchange Before CWR, every collecting society had its own proprietary format for receiving work registrations. A publisher operating across 20 territories needed 20 different data pipelines. Mismatches were inevitable. Royalties were delayed, misallocated, or lost entirely. CWR standardised this. A single format that any publisher can use to register works with any participating society. Today it is used by **publishers, sub-publishers, administrators, and CMOs** (Collective Management Organisations) across more than 200 territories. The practical impact is significant. When a song is played on radio in Germany, streamed in Japan, and performed live in Brazil, the royalties generated in each territory need to flow back to the correct rights holders. That flow depends on accurate registration data -- and that data almost always travels as CWR. > **Key Point:** CWR does not determine who owns a work. It **communicates** ownership information between systems. The legal reality of who wrote, published, and controls a work exists independently. CWR is the transport layer that ensures every society has the same information. If you are a publisher and your CWR registrations are incomplete, late, or contain errors, the consequence is direct: **societies cannot match your works to usage, and royalties accumulate as unidentified or unclaimed income.** Getting CWR right is not administrative overhead -- it is the mechanism by which you get paid. --- ## The Workflow: How CWR Files Move Between Systems CWR is a two-way exchange. Publishers send registrations, societies send acknowledgements. Understanding this round-trip is essential to working with CWR effectively. ### Step 1: Publisher sends NWR The publisher creates a CWR file containing NWR (New Work Registration) transactions for works being registered for the first time, or REV (Revised Registration) for updates to existing works. The file is transmitted to the receiving society, typically via FTP or a web portal. ### Step 2: Society validates The society's system parses the file, checks formatting rules, validates share totals, cross-references IPIs against its own database, and looks for potential duplicate registrations. This can take hours or weeks depending on the society. ### Step 3: Society returns ACK The society sends back an acknowledgement file (ACK) containing accept or reject decisions for each transaction. Accepted works receive official identifiers: the society's internal work number and, if assigned, an ISWC. Rejected works include error codes explaining what went wrong. ### Step 4: Publisher enriches catalog The publisher processes the ACK file, updates their catalog with society-assigned identifiers, and fixes any rejected registrations for resubmission. The catalog grows richer with each round-trip. > **Common Misconception:** CWR is not a one-time submission. Catalogs change constantly -- new works are created, shares are revised, sub-publishing deals change territory allocations, writers switch societies. A healthy publishing operation sends CWR files regularly and processes every ACK that comes back. --- ## Ownership vs. Collection Every CWR file encodes two distinct concepts that are often confused: who *owns* a share of a work, and who has the *mandate to collect* royalties for that share in a given territory. **Ownership shares** reflect the legal reality of who created and controls the work. A songwriter who wrote 50% of the lyrics owns a 50% writer share. Their publisher controls a corresponding publisher share. These percentages are facts about the work itself -- they do not change based on who you are registering with. **Collection shares** reflect administrative arrangements. A UK publisher might collect 100% of mechanical royalties in the UK through MCPS, but only 25% in Germany through a sub-publisher registered with GEMA. The same work, the same ownership -- but different collection mandates in different territories. | Dimension | What It Represents | Changes When | Scope | |---|---|---|---| | **Ownership** | Legal entitlement to a share of the work | Work is re-assigned, share is sold, reversion clause triggers | Global (same everywhere) | | **Collection** | Administrative mandate to collect royalties | Sub-publishing deal signed, administrator changed, territory added/removed | Per-territory | What you include in a CWR file depends on context. When registering with your home society, you typically declare both ownership and collection shares. When sending data to a sub-publisher for registration in their territory, you may only include the shares relevant to their mandate. When exchanging between societies (CRD -- Common Royalty Distribution), the focus shifts to collection entitlements. > **Practical Consequence:** If your CWR file declares ownership shares but omits the collection mandate for the receiving society's territory, the society knows who owns the work but has no instruction to pay anyone. If it declares collection shares that exceed the actual ownership, the society will reject the registration. Getting both dimensions right -- and keeping them in sync -- is where most CWR problems originate. --- ## CWR 2.1 vs. 2.2 Two versions of CWR are in active use. Understanding the differences -- and knowing which to use when -- matters more than you might expect. **CWR 2.1** has been the workhorse of music publishing data exchange for over a decade. It is universally supported, well-understood by every major society, and handles the vast majority of registration scenarios. Its fixed 80-character line length and rigid structure make it predictable and reliable. **CWR 2.2** extends the format with capabilities that address real limitations in 2.1. Variable-length records allow more metadata. Multiple identifier support means a work can carry its ISWC, multiple society work numbers, and publisher internal codes simultaneously. Complex rights chains with multiple levels of sub-publishing are better represented. | Feature | CWR 2.1 | CWR 2.2 | |---|---|---| | Record length | Fixed 80 chars | Variable length | | Work identifiers | One per work | Multiple per work | | Society support | Universal | Partial (growing) | | Rights chain depth | Basic (OP + sub-publisher) | Extended (multi-level chains) | | Additional metadata | Limited | Extended (AVI, additional titles, etc.) | | Character encoding | ASCII only | ASCII (UTF-8 discussed, not standard) | | Backward compatibility | N/A | 2.1 files are valid 2.2 | | Recommended for | Maximum compatibility | Complex catalogs, multi-territory chains | > **Practical Advice:** Always check with the receiving society before choosing a version. If the society accepts 2.2 and you need its features, use 2.2. If you are unsure, or the society has not confirmed 2.2 support, use 2.1. A valid 2.1 file that arrives and is processed correctly is always better than a 2.2 file that is rejected or partially parsed. The industry is gradually moving toward 2.2, but "gradually" in music publishing standards means years, not months. Many societies still run 2.1-only pipelines. Some accept 2.2 files but silently ignore the new fields. The safe default remains 2.1 unless you have a specific reason to use 2.2 and have confirmed support with your receiving society. --- ## Anatomy of a CWR File A CWR file is organised into a strict hierarchy: header, groups, transactions, records, and trailer. Every valid file follows this structure without exception. ### HDR -- Transmission Header One per file. Identifies the sender (publisher), receiver (society), creation date, and CWR version. Always the first record. ### GRH -- Group Header Marks the start of a group of transactions. Groups organise works by transaction type (NWR, REV, etc.). A file can contain multiple groups. ### TXN -- Transactions Each transaction represents one work. Contains the NWR/REV record followed by all its detail records: SPU (publisher), SWR (writer), SPT/SWT (territory shares), REC (recording), and more. ### GRT -- Group Trailer Closes a group. Contains the count of transactions and records in the group, used for validation. ### TRL -- Transmission Trailer One per file, always the last record. Contains total counts for the entire file: groups, transactions, and records. If the counts do not match, the file is invalid. The record counts in GRT and TRL are not optional niceties -- they are validation checksums. If your file claims 150 transactions in the trailer but contains 148, the receiving society will reject the entire file. This rigid structure is deliberate: it catches truncation, corruption, and incomplete generation before bad data enters the society's system. --- > "Every misregistered work is a royalty payment that goes to the wrong place -- or nowhere at all. CWR is not glamorous infrastructure. It is essential infrastructure." --- ## Check Your CWR Files The TrackForge CWR Workbench checks .V21 files against Common Works Registration 2.1 Revision 8. It catches formatting errors, share calculation problems, missing identifiers, and structural issues before you submit to a society. Upload a file. Get results in seconds. No account required. - [Check a CWR file](https://trackforge.studio/cwr-tool) - [CWR Record Types Reference](https://trackforge.studio/certification/cwr/record-types) --- ## Related Documentation - **[CWR Record Types](https://trackforge.studio/certification/cwr/record-types)** -- Complete reference for every record type in CWR 2.1 and 2.2. NWR, REV, SPU, SWR, SPT, SWT, REC, ACK -- what each contains and when to use it. - **[Common CWR Errors](https://trackforge.studio/certification/cwr/common-errors)** -- The most frequent CWR validation failures and how to fix them. Share calculation mismatches, missing IPIs, malformed identifiers, and structural problems. - **[CWR Workbench](https://trackforge.studio/cwr-tool)** -- Create a CWR 2.1 file, check or read an existing .V21 file, and understand society ACK responses. Free, no account required. --- ## Frequently Asked Questions **What is CWR (Common Works Registration)?** CWR is a flat-file data format maintained by CISAC for registering musical works with collecting societies worldwide. It is a fixed-width ASCII text file containing work identifiers (ISWC), interested parties (writers, composers), publishers, ownership shares, territory allocations, and recording links (ISRC). **What is the difference between CWR 2.1 and CWR 2.2?** CWR 2.1 uses fixed 80-character lines and is universally supported. CWR 2.2 adds variable-length records, multiple identifier support, and better multi-level sub-publishing chains. Most societies still run 2.1-only pipelines, so always check with the receiving society before using 2.2. **How does the CWR workflow work?** CWR is a two-way exchange: (1) Publisher sends NWR or REV transactions, (2) Society validates and cross-references, (3) Society returns an ACK file with accept/reject decisions and assigned identifiers, (4) Publisher processes the ACK and updates their catalogue. **What is the difference between ownership and collection shares in CWR?** Ownership shares reflect legal entitlement and are global. Collection shares reflect administrative mandates to collect royalties and vary per territory. Both must be correctly declared in CWR files. **How can I validate a CWR file before submitting to a society?** Use the free [TrackForge CWR Workbench](https://trackforge.studio/cwr-tool/workbench). Upload your .V21 file and check it against Common Works Registration 2.1 Revision 8. No account required. --- *Source: [https://trackforge.studio/certification/cwr/what-is-cwr](https://trackforge.studio/certification/cwr/what-is-cwr)*