Fixing a wrong ISRC after a track is already live

01 · 2026-07-30 · 8 min read · Español

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.

• An assigned ISRC can never be edited or reused.
• The fix is delivering the recording again under a new code, waiting for it to go live, then taking the original down — in that order.
• Streams and playlist history do not move by themselves; your distributor must request a merge, and some services refuse.
• A straight remaster, or the same recording on a new release, does not need a new code.

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 the word mitigate. There is no undo. Everything below works, and all of it is damage control.

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”:

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. The mirror image of it — one recording carrying two codes at once — is a different error with a different repair.

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.

1. 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.
2. 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.
3. Deliver it, and wait for it to go live. Do not skip the waiting.
4. Only then take the original down. The order is the whole fucking 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. Leave the corrected version live for at least 48 hours before you request the takedown — longer costs nothing, and rushing this step is how a fix becomes a second incident.
5. 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 Ship of Theseus docks here about once a week. The standard is specific about when a recording counts as a new recording — and the full decision, clause by clause, has its own piece.

• 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. Close the tab and go finish the record.

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 — 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. Everything else a register has to hold is its own checklist.
• 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.

FAQ

Does a remaster need a new ISRC?

No. A straight remaster keeps the original recording’s ISRC unless significant new creative input is involved. A remix, an edit, or a change in playing time of more than ten seconds needs a new code.

Can two recordings share one ISRC?

No. One recording carries one code for its lifetime, and a shared code collapses the streams, royalties and reporting of both recordings into a single line. Both have to be re-delivered under correct codes.

Does the same recording need a new ISRC on a different release?

No. A recording keeps its ISRC across releases, formats and territories — one recording, one code, everywhere it appears.

Will fixing a wrong ISRC lose my streams and playlists?

Playlist placements are usually lost when the original listing comes down, and stream history moves only if a service agrees to a distributor-requested merge. That risk is why the corrected version goes live before the takedown.

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 CA to CB change 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.