--- title: "CWR Record Types -- A Complete Reference" sidebar_label: Record types sidebar_position: 2 description: "A complete reference to CWR record types for music industry professionals. Covers file structure (HDR, GRT, TRL), work registration (NWR, REV), party records (SPU, SPT, SWR, SWT, PWR), share arithmetic, and version type codes." --- # CWR Record Types -- A Complete Reference > A reference guide to every record type in a CWR file, covering file structure, work registration, party records, share arithmetic, and version type codes. *Published by [TrackForge](https://trackforge.studio) -- 9 March 2026* --- CWR -- Common Works Registration -- is the CISAC standard for exchanging musical work data between publishers, sub-publishers, and collection societies worldwide. A CWR file is a flat text file where every line is a record, and every record begins with a three-character type code that determines its structure and purpose. Records are not standalone. They are grouped into **transactions** -- a new work registration, for example, is a single transaction comprising an NWR record followed by SPU, SPT, SWR, SWT, and PWR records that define its rights holders. Transactions are wrapped in **groups** (GRH/GRT), and the entire file is wrapped in a **header/trailer** pair (HDR/TRL). This nesting structure allows receiving societies to validate file integrity before processing any content. This reference covers the record types you will encounter most frequently. It is not a substitute for the full CISAC CWR specification, but it is sufficient to read a CWR file, understand its structure, and diagnose common validation errors. --- ## File Structure: Header, Group, and Trailer Records Every CWR file follows the same envelope structure: one file header, one or more groups, and one file trailer. These records carry no musical work data -- they exist for routing and integrity validation. ### HDR -- Header First record in every CWR file. Identifies the sender (publisher or administrator), the creation date, the character set (typically ASCII), and the CWR version (2.1 or 2.2). The sender is identified by their society-assigned code and IPI number. If the sender ID is wrong, the entire file may be rejected by the receiving society without further processing. ### GRH -- Group Header Marks the start of a transaction group. Contains the transaction type for every transaction in the group (NWR, REV, etc.) and a sequential group ID. A single CWR file may contain multiple groups, each holding a different transaction type. ### GRT -- Group Trailer Closes a group. Contains the record count and transaction count for the group. Receiving societies use these counts for integrity validation -- if the actual counts do not match the declared counts, the group is rejected. ### TRL -- Trailer Last record in the file. Contains the total record count, group count, and transaction count for the entire file. This is the final integrity check: if the TRL totals do not match the sum of all GRT totals plus the HDR and TRL records themselves, the file is invalid. ### File Structure Example ``` HDR Sender identification, date, CWR version GRH Group 1 begins (transaction type: NWR) NWR New work registration (transaction 1) SPU Publisher record SPT Publisher territory SWR Writer record SWT Writer territory PWR Publisher-writer link GRT Group 1 trailer (counts) TRL File trailer (totals) ``` --- ## Work Registration: NWR and REV The two transaction-level record types that register or update a musical work. ### NWR -- New Work Registration Registers a musical work for the first time. The NWR record is the anchor of the transaction -- all subsequent party and territory records belong to this work until the next NWR or REV. **Key fields:** Work title, Language code, Duration, Version type, Music arrangement code, Lyric adaptation code, Submitter work ID. ### REV -- Revised Registration Updates an existing registration. The REV record has the same structure as NWR but replaces the previous data held by the receiving society. Use REV when correcting errors, adding parties, or updating share splits on an already-registered work. **Key fields:** Same structure as NWR. References the original registration. The **submitter work ID** is the publisher's internal identifier for the work. It must be unique within the sender's catalogue and consistent across submissions -- societies use it to match REV transactions to their original NWR. If you change the submitter work ID between NWR and REV, the society will treat the REV as a new registration and reject it. --- ## Party Records: Publishers, Writers, and Their Territories The records that define who owns what, where, and in what proportions. These records follow the NWR or REV record they belong to. ### Publisher Records #### SPU -- Publisher Identifies a publisher in the ownership chain. Contains the publisher name, IPI name number, and publisher type. The publisher type field is critical -- it distinguishes between the original publisher (who signed the songwriter), the sub-publisher (who administers in a specific territory), and the administrator (who handles registration on behalf of another publisher). #### SPT -- Publisher Territory Specifies the territories where a publisher controls rights and the percentage shares for each right type: performance (PR), mechanical (MR), and synchronisation (SR). A single SPU record may be followed by multiple SPT records if the publisher's shares vary by territory. Territory codes follow the CISAC TIS standard: - `2136` = World - `840` = US - `826` = UK ### Writer Records #### SWR -- Writer Identifies a songwriter, composer, or arranger. Contains the writer's last name and first name (separate fields), their IPI name number, and a writer designation code that defines their role on the work. | Code | Designation | |---|---| | `CA` | Composer/Author (wrote both music and lyrics) | | `C` | Composer (music only) | | `A` | Author (lyrics only) | | `AR` | Arranger | | `AD` | Adaptor (lyric adaptation) | | `SA` | Sub-Arranger | | `SE` | Sub-Author | #### SWT -- Writer Territory Territory-specific share information for writers. Follows the same pattern as SPT: specifies the writer's PR, MR, and SR shares for a given territory. Writers who are members of a society typically assign their performance share to the society, so the PR share in SWT often reflects the society's allocation rules rather than a freely negotiated split. ### Publisher-Writer Link #### PWR -- Publisher for Writer Links a specific publisher (SPU) to a specific writer (SWR) within a work. This record answers the question: "Which publisher administers this writer's share?" A work with two co-writers signed to different publishers will have two PWR records, each connecting one writer to their respective publisher. --- ## Share Arithmetic The single most common source of CWR validation errors is incorrect share totals. Understanding the arithmetic is essential. CWR tracks three independent share types. For each type, the shares across all parties must total exactly **100.00%**. Not 99.99%. Not 100.01%. Exactly 100.00%. ### PR -- Performance (100.00%) Who gets paid when the work is performed publicly -- radio, live, streaming, broadcast. ### MR -- Mechanical (100.00%) Who gets paid when the work is reproduced -- physical copies, downloads, interactive streams. ### SR -- Synchronisation (100.00%) Who gets paid when the work is synchronised to visual media -- film, television, advertising, games. ### Common Errors **Shares summing to 200%.** A frequent mistake with co-published works: each publisher enters 100% for their writer, forgetting that all parties must sum to 100% collectively -- not individually. **Missing writer shares.** The writer's SWT shares plus the publisher's SPT shares for the same right type must together total 100%. If a publisher claims 50% MR but the writer's SWT shows 0% MR, the total is only 50% and the file will be rejected. **Rounding errors.** Shares are expressed to two decimal places. Splitting 100% three ways gives 33.33 + 33.33 + 33.34, not 33.33 + 33.33 + 33.33. The last party absorbs the rounding remainder. The share arithmetic applies independently per territory. A work may have different share splits in different territories (for example, when a sub-publisher administers the work outside the original territory), but in every territory, each right type must still total 100%. --- ## Version Type Codes The version type field in NWR and REV records identifies the nature of the work. This affects how societies process and match the registration. | Code | Version Type | Description | |---|---|---| | `ORI` | Original Work | The first version of a musical work. No prior registration exists. | | `MOD` | Modified Version | A derivative of an existing work -- for example, a remix or adaptation that creates new copyright. | | `ARR` | Arrangement | A new arrangement of a public domain or copyrighted work. Requires music arrangement code. | | `ORI/MOD` | Original + Modified | A work that is both original in its composition and a modification of existing material (rare). | | `UNS` | Unspecified | Version type not determined. Some societies will reject registrations with this code. | The version type has downstream consequences. An **ORI** work can stand alone. A **MOD** or **ARR** work should reference its source -- the original work it derives from -- and must include the appropriate music arrangement code (ORI, ARR, UNS) and lyric adaptation code (ORI, MOD, UNS) to describe what was changed. Societies use these fields to ensure the original rights holders are properly credited and compensated when derivative works generate royalties. --- ## All Record Types at a Glance | Code | Record Type | Category | Purpose | |---|---|---|---| | `HDR` | Header | File structure | File identification and routing | | `GRH` | Group Header | File structure | Transaction group start marker | | `GRT` | Group Trailer | File structure | Group integrity counts | | `TRL` | Trailer | File structure | File integrity totals | | `NWR` | New Work Registration | Work | Register a new musical work | | `REV` | Revised Registration | Work | Update an existing registration | | `SPU` | Publisher | Party | Publisher identification and type | | `SPT` | Publisher Territory | Party | Publisher shares by territory | | `SWR` | Writer | Party | Writer identification and designation | | `SWT` | Writer Territory | Party | Writer shares by territory | | `PWR` | Publisher for Writer | Party | Links publisher to writer | --- ## Check Your CWR Files The TrackForge CWR Workbench checks .V21 files against Common Works Registration 2.1 Revision 8 -- share arithmetic, record structure, field formatting, and cross-record consistency. Upload a file and get a detailed report in seconds. - [Open the CWR Workbench](https://trackforge.studio/cwr-tool) --- ## Related Documentation - **[CWR Workbench](https://trackforge.studio/cwr-tool)** -- Create, check and read CWR 2.1 .V21 files and understand society ACK responses. - **[The Unclaimed Economy](https://trackforge.studio/research/unclaimed-economy)** -- 4.25 million works with unclaimed US mechanical royalties at the MLC. - **[The Problem](/docs/certification/overview/the-problem)** -- Why music rights data is broken and what TrackForge does about it. - **[What is CWR?](/docs/cwr)** -- A complete guide to CWR structure, workflow, and versions. - **[Problems and fixes](/docs/cwr/problems-and-fixes)** -- Every problem the CWR Workbench can report, why it matters and how to fix it. --- *Source: [https://trackforge.studio/docs/cwr/record-types](/docs/cwr/record-types)*