Fixing a wrong ISRC after a track is already live
An ISRC cannot be corrected in place. The standard forbids changing one or reusing one, so fixing a wrong code means delivering the recording again under a new ISRC and taking the original listing down — in that order, which is the part that saves your streams.
Can an ISRC be changed?
No. Two rules from the standard, and both are absolute.
Once assigned, an ISRC must not be re-used under any circumstances.
Once an ISRC has been assigned to a track the ISRC should remain the same for the lifespan of the track.
That permanence is the point of the code rather than a limitation of it. Royalty matching, neighbouring-rights collection and chart reporting all key on the ISRC, so a code that moved between recordings would take the history attached to it along.
Which leaves a gap. The standard tells you the code cannot change and then stops — there is no official procedure for a recording that is already out. The US ISRC Agency is the one party that says the practical thing plainly:
It is recognized that occasionally errors will occur, and it is the responsibility of all affected parties to work to correct or at least mitigate the error.
Note mitigate. There is no undo here. Everything below works, and it is damage control rather than a repair.
Which of the three mistakes do you have?
Read the code before you touch anything. An ISRC is twelve characters in four parts. Split against a real published example — USUAN1400011, the ISRC for Kevin MacLeod’s “Monkeys Spinning Monkeys”:
| Characters | Part | What it is |
|---|---|---|
US | Country code | The registrant’s territory, ISO 3166-1 alpha-2 |
UAN | Registrant code | The rights holder the agency issued the prefix to |
14 | Year of reference | The year the code was assigned, not the release year |
00011 | Designation code | Your own number for the recording, usually sequential |
The country and registrant codes together are what an agency allocates; IFPI calls those five characters the prefix code. Written down, an ISRC often carries hyphens for readability — US-UAN-14-00011 — but stored and delivered it is twelve characters with no punctuation. A field that rejects your code is sometimes only objecting to the hyphens.
Now the three failure modes, worst first.
One ISRC on two different recordings. The messiest case. It usually starts with a track re-uploaded through a new distributor carrying its old code, or a copied spreadsheet row. Two recordings now share one identity, so streams, royalties and reporting for both collapse into a single line.
A unique ISRC on the wrong recording. Track three got track four’s code. Nothing is duplicated, but everything keyed to those two codes is attached to the wrong audio and stays that way until both are re-delivered.
A code from a prefix that is not yours. Your distributor auto-assigned one from its own registrant code, or the code came from a label you have since left. The recording is identified — just not as yours. You cannot administer a prefix you do not hold, so you cannot issue the next code in that series either.
If you register in Canada, check the country code while you are in there. As of 1 June 2021 new Canadian registrants are issued CB rather than CA, and registrant codes assigned before that date keep CA. Both are current and both are valid. Finding one where you expected the other usually means the code came from a different registrant than you assumed — very often your distributor’s.
How do you actually fix it?
Here is what the other explanations leave out: none of the mechanics are in the standard. The ISRC agency issues codes and never touches releases. Every step below happens at your distributor, and the exact flow differs between them, so confirm yours before you start.
The shape is the same everywhere.
- Get a correct code. If you hold your own registrant prefix, assign the next unused designation code. If you do not, this is the moment to apply for one.
- Build a new release rather than editing the old one. Most platforms will not let you change an ISRC on a product already delivered to stores. FUGA, for one, documents this shape: duplicate the product, remove the asset carrying the wrong code, add the corrected asset, deliver that.
- Deliver it, and wait for it to go live. Do not skip the waiting.
- Only then take the original down. The order is the whole thing. Take the old listing down first and you strip the track from its playlists and lose the listener history you were trying to protect. Common guidance is to leave the corrected version live for at least 48 hours before requesting the takedown.
- Ask your distributor to request a data merge. Streams, saves and playlist adds sitting against the old code do not follow the new one by themselves. Some services will merge history when a distributor asks; some will not. Start that conversation early, because it moves slower than the takedown.
What does it cost you?
Weeks, and sometimes months. Playlist positions are the likeliest casualty: a takedown removes the track from every editorial and algorithmic placement it held, and re-delivery does not restore them. Royalties that accrued against the wrong code are the hardest part to get back, and where two recordings shared one code, apportioning them after the fact may not be possible at all.
Which is why the agency’s word is mitigate.
Do you even need a new ISRC?
A good share of ISRC panic turns out not to be an error. The standard is specific about when a recording counts as a new recording.
- A new ISRC is required for a remix or an edit, for a change in playing time exceeding ten seconds, and for a restoration involving creative changes.
- A new ISRC is not required for a straight remaster. The remaster is fundamentally the same recording as the original, unless significant new creative input is involved.
- A new ISRC is not required because the same recording appears on a different release, a different format, or in a different territory. One recording, one code, everywhere it turns up.
If you are in the second or third case, you do not have a problem to fix.
How do you stop it happening again?
- Hold your own prefix. Apply to the ISRC agency for your territory instead of relying on codes a distributor assigns. In the United States that is the RIAA’s US ISRC Agency. In Canada the application process has moved to Panorama, through SOPROQ — CONNECT Music Licensing, which used to run it, now points applicants there.
- Keep the register yourself. The designation code is yours to allocate and nobody else is tracking which numbers you have spent. Log the code against the recording the moment it is assigned.
- Write it down before delivery, not after. Every duplicate starts as a code somebody believed they remembered.
- Check the code on the delivered product, not the one in your notes. Those are the two places that disagree.
Sources
- IFPI, ISRC FAQ — the reuse and lifespan rules, the prefix structure, and when a modified recording needs a new code.
- US ISRC Agency (RIAA), Guidance & Support — the wording on errors.
- CONNECT Music Licensing, ISRC — the Canadian
CAtoCBchange and the handover of applications. - FUGA, How to Update the ISRC for an Existing Product — one platform’s documented duplicate-and-redeliver flow.
- International Standard Recording Code — ISO 3901, and the worked example above.
Distributor procedures change and this is not legal or financial advice. Confirm the mechanics with your own distributor and your territory’s agency before you take anything down.
Keeping the register
CatalogTracker keeps that register on the phone: the code, the recording it belongs to, and the ownership splits attached to it. In development for iPhone.