Guides
CWR errors, explained
Every problem the validator can raise, in plain language: what it actually means and what to do about it. The same texts appear in validation reports and in the API's explain field, generated from one catalog — this page cannot drift from the tool's behavior. Writer advisories are marked: they are questions about the songwriters in a file, never errors, and they do not change a file's verdict.
The society accepted this song, but changed it
The registration went through, but the society did not record it exactly as you sent it — they altered something, such as a share, a name, or an identifier. What you hold and what they hold now differ.
Fix: Compare their version with your own and decide which is right. If yours is, send a corrected registration; if theirs is, update your own records to match.
The society's answer needs following up
The society neither registered this song as you sent it nor turned it down. Their answer is one of three: somebody else has claimed the same song, they already hold a registration for it, or they are not collecting for a party you said they would. Each of those is somebody's job to sort out, and none of them resolves itself.
Fix: Read the society's own wording beside the song — it says which of the three this is. A conflict is settled with the other claimant, a duplicate against your earlier registration, and a no-participation by checking the party's affiliation.
The society rejected this song
This file is a society's reply, and for this song the answer is no — the registration was not accepted, so the song is not registered with them. Whatever the society said about it is shown beside the song.
Fix: Read the society's message, correct what it names in your own catalog, and register the song again. Nothing in this reply file needs editing — it is theirs, not yours.
An agreement covers nowhere
An agreement must say where in the world it applies; this one names no territory at all.
Fix: Add at least one territory line (TER) — 'the world' is TIS code 2136.
An agreement is missing one of its two sides
An agreement needs both sides on paper: at least one party giving rights (assignor) and one receiving them (acquirer). One side is missing here.
Fix: Add the missing party line (IPA) with role AS (assignor) or AC (acquirer).
A back-payment date is promised but not given
This agreement says royalties start from a specific prior date ('D') but then never gives the date.
Fix: Add the prior royalty start date, or change the status if no back-payment is intended.
The agreement's shares don't add up to 100%
The shares assigned across the agreement's parties should total 100% per right type, and they don't.
Fix: Adjust the parties' shares for each right until they sum to exactly 100%.
A controlled writer has no IPI name number
A writer you control (an SWR record) has no IPI name number. Societies then have only the name to match on, and a name alone is easily matched to the wrong writer, or to nobody.
Fix: Add the writer's IPI name number if they have one. Their society, or your publishing administrator, can tell you what it is.
A line that doesn't belong in this registration
This line type doesn't belong inside this kind of transaction — the spec defines exactly which detail lines each transaction may carry.
Fix: Check the line landed under the right registration; it may have been misplaced when the file was built.
Lines within a registration are misnumbered
Lines within a registration are numbered 1, 2, 3… and this one is out of step, which usually means a line was inserted or deleted by hand.
Fix: Regenerate the file so every line is renumbered.
A line claims to belong to a different registration
This detail line claims to belong to a different registration than the one it sits under — its registration number doesn't match its header's.
Fix: Lines were likely reordered or spliced. Regenerate the file.
Two agreements share one agreement number
Your own agreement number is how the society tells your agreements apart. Two in this file carry the same number, so it cannot know which set of terms to apply to the works that reference it.
Fix: Give each agreement a number of its own.
Duplicate checking stopped part-way
This file is large enough that comparing every work and agreement number against every other one would have taken more memory than the checker is allowed. The first few hundred thousand were compared; the rest were not.
Fix: Nothing to fix — this is a note about the reach of the check, not about the file. Split very large files if you want it to be exhaustive.
Two registrations share one work number
Your own work number is how the society tells your works apart, and how it matches your later updates back to the right one. Two works in this file carry the same number, so the second will overwrite the first or be rejected.
Fix: Give each work a number of its own. If this is a revision of a work you already sent, send it in its own file rather than twice in one.
An EIDR check character doesn't match
The last character of an EIDR is calculated from the twenty before it. It doesn't match, so a character is wrong and the identifier resolves to nothing.
Fix: Check it against the EIDR registry. The 10.5240/ prefix doesn't belong in the field — just the twenty characters and the check character.
A value isn't in the required form
A value on this line isn't in the form CWR requires — for example letters where a number or date belongs. Every position in a CWR line has a fixed meaning, so one stray character shifts everything after it.
Fix: Compare this line against a known-good one from the same software; look for missing or extra characters earlier in the line.
The file ends mid-batch
A batch of registrations was opened (GRH) but never closed (GRT) before the file ended — like an opening bracket with no closing one.
Fix: The file is most likely truncated. Re-export it and compare file sizes before sending.
The filename doesn't follow the naming rule
CWR filenames encode the year, a sequence number, and who is sending to whom (like CW260001ABC_XYZ.V21). Some societies' inboxes route files by this name and will quarantine one that doesn't match.
Fix: Rename the file to the convention before delivering; the content itself is unaffected.
Two batches of the same type
Two batches in this file declare the same transaction type; the spec allows each type only once per file.
Fix: Merge the batches into one, or split the file in two.
Batches are numbered out of order
Batches must be numbered 1, 2, 3… in order; this one is out of sequence.
Fix: Regenerate the file; batch numbering is automatic.
A batch declares a type that doesn't exist
Each batch declares what kind of transactions it holds; this batch declares a kind CWR doesn't define.
Fix: Use one of AGR, NWR, REV, ISW, EXC, or ACK — for new registrations that's NWR.
A batch starts before the last one closed
A new batch starts before the previous batch was closed. Receivers can't tell where one batch ends and the next begins.
Fix: Each GRH needs a matching GRT before the next GRH. Regenerate the file rather than splicing files together.
A batch declares an unknown CWR version
Each batch declares which CWR version its lines follow, and this value isn't a CWR 2.x version.
Fix: Set it to 02.10 (CWR 2.1) or 02.20 (CWR 2.2) to match the file extension.
A batch's opening and closing lines disagree
A batch's closing line names a different batch number than its opening line — the bookkeeping disagrees with itself.
Fix: Regenerate the file; matching ids are written automatically.
A batch miscounts its lines
The batch's closing line miscounts its lines. Same effect as a wrong registration count: the batch bounces.
Fix: Regenerate the file rather than hand-editing counts.
A batch miscounts its registrations
The batch's closing line says it contains a different number of registrations than are actually there. Societies reject the whole batch on this.
Fix: A registration was added or removed after the file was built. Regenerate the file to recount.
Wrong handshake version in the header
The header must declare EDI version 01.10 — a fixed handshake value every receiver checks first.
Fix: Set the EDI standard version field to exactly 01.10.
The header doesn't say what kind of sender you are
The header's sender type says what kind of party you are (PB publisher, SO society, AA agency, WR writer). A value outside that list makes receivers distrust the whole file.
Fix: Use the two-letter code for your role — for most publisher-side senders that's PB.
A registration's first line is misnumbered
The first line of each registration must carry line number 0 within that registration; this one doesn't.
Fix: Regenerate the file; this numbering is automatic in any CWR writer.
An IPI base number's own check digit says it is wrong
An IPI base number ends in a digit calculated from the nine before it, and it doesn't agree. The base number identifies the person or company itself, and is not the same number as the name number.
Fix: Check the nine digits after the 'I' and the final digit against the IPI entry. If you aren't sure of it, leave the field blank. Songlinks (https://songlinks.io/ipi-name-number-lookup) shows which of a writer's registrations carry an IPI name number.
An IPI name number's own check digits say it is wrong
An IPI name number ends in two digits calculated from the nine before them, and they don't agree. The writer or publisher named here won't be matched to the right party, so their share goes unallocated.
Fix: Look the party up in the IPI system and copy the eleven digits exactly, leading zeros included. Songlinks (https://songlinks.io/ipi-name-number-lookup) shows which of a writer's registrations carry an IPI name number.
An ISRC is not in the standard shape
An ISRC is twelve characters: two country letters, a three-character registrant code, then seven digits. This one isn't, so the recording it points at can't be looked up.
Fix: Copy the ISRC from the recording's metadata without hyphens — CWR wants the twelve characters only.
An ISWC's own check digit says it is wrong
An ISWC ends in a digit calculated from the nine before it. This one doesn't add up, so a character was mistyped or two were swapped. The code will match no work at all — or, worse, somebody else's.
Fix: Check the ISWC against what the society or the ISWC database holds for this work. If there isn't one yet, leave the field blank rather than guess.
Extra text before the file starts
There is text before the first real CWR line — often an email header, BOM, or export banner that got saved into the file.
Fix: Delete everything above the line starting with HDR.
A line is longer than the spec allows
This line is longer than the spec says this record can be. The extra characters are ignored here, but strict systems may refuse the line outright.
Fix: Usually caused by hand-editing. Regenerate the file or trim the line to the documented width.
A required field is blank
A field the spec marks as mandatory is empty on this line. Societies reject the whole registration rather than guess the value.
Fix: Fill in the highlighted field — the message names exactly which one it is.
The file has no header
Every CWR file must begin with an HDR line saying who sent it. This file doesn't have one, so a society's system won't even start reading it.
Fix: Regenerate the file from your software rather than editing by hand; the header is written automatically.
The file has no closing line
Every CWR file must end with a TRL line that states how much the file contains. Without it, receivers assume the file was cut off mid-transfer.
Fix: Regenerate or re-transfer the file; if you edited it by hand, the final line was probably lost.
A line has nothing to belong to
This line sits somewhere it can't belong — for example a detail line with no registration above it to attach to. Societies skip or reject stray lines.
Fix: Check the lines just above: the record this one should follow is missing or out of order.
The song's shares don't add up to 100%
All the ownership slices of a song must add up to 100% for each right type. Here they don't — either someone is counted twice, a share is too big, or a co-writer's slice is missing. Societies won't know who to pay what.
Fix: List every writer's and publisher's share for this song and make each right type total exactly 100%.
A publisher claims more than half the song
For performing rights, a publisher may own at most 50% of a song — the other half always belongs to the writers. This publisher claims more, which societies reject automatically.
Fix: Set the publisher's performing-rights share to 50% or less. The publisher's larger cut, if agreed, is expressed through the collection share instead.
A publisher collects more than half in a territory
Same 50% rule, applied to what the publisher *collects* for performing rights in a territory: the writer's half can't be collected by the publisher.
Fix: Cap the publisher's PR collection share at 50% in each territory line.
Territory lines are misnumbered
The territory lines under a writer or publisher are numbered 1, 2, 3… and this run breaks the pattern — harmless to some receivers, rejected by strict ones.
Fix: Regenerate the file; territory numbering is automatic.
Registration numbering has a gap
Registrations in a batch are numbered 0, 1, 2… and this one breaks the run. Receivers use the numbering to detect missing registrations, so a gap reads as lost data.
Fix: Regenerate the file; if it persists, a registration was deleted without renumbering the rest.
A batch was never closed
The file's closing line arrived while a batch was still open — a closing line (GRT) is missing just before it.
Fix: Regenerate the file; if you assembled it manually, add the missing GRT before the TRL.
The file's own bookkeeping doesn't add up
The file's last line states how many batches, registrations, and lines the file contains, and the actual contents don't match. Receivers treat this as a corrupted or truncated file.
Fix: Almost always means the file was edited after export. Regenerate it so the totals are recounted.
A line no system will understand
The three-letter code starting this line isn't one CWR defines, so no one can process it. Often a sign the line was shifted or the file isn't really CWR.
Fix: If you edited the file, check nothing pushed this line's content sideways; otherwise re-export it.
A V-ISAN check character doesn't match
A V-ISAN carries two check characters: one covers the ISAN itself, the other reaches through the version segment. The arithmetic doesn't come out, so a character in the audio-visual identifier is wrong.
Fix: Check it against the ISAN agency's record. If there is no V-ISAN, leave all of those fields blank.
One IPI name number appears under more than one writer name
The same IPI name number appears in this file under different writer names. An IPI name number belongs to one name of one party, so either these are spellings of one writer, or the number was copied onto the wrong writer.
Fix: Check whether these are the same person. If they are, spell the name the same way everywhere. If they are not, correct the IPI name number on the writer it does not belong to.
One writer name appears with more than one IPI name number
The same name, ignoring case, spacing and punctuation, appears in this file with different IPI name numbers. That can be two people who share a name, one person with a second IPI name number, or a mistyped number. If it is one person on two numbers, their works may be split between two registrations.
Fix: Check whether these are the same person. If they are, use the IPI name number they are registered under for these works. If they are different people, nothing needs to change.
A registration is in the wrong batch
A registration of one type is sitting inside a batch declared for another type — like a revision filed in the new-works batch.
Fix: Move the transaction into a batch of its own type.
Two free checks for your CWR file. Is the file correct? Every record, share and control total against the spec, each problem on its exact line. Do its writers match their registrations? Every writer cross-checked against public registration data, including works registered under another spelling or IPI. Nothing stored: check a file at cwrcheck.com.