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.
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 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.
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.
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 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.
Check a CWR file free — errors and warnings tied to the exact line, nothing stored: cwrcheck.com.