Two ISRCs on one recording: what breaks, and how to merge
13 · · 12 min read · Español
A recording assigned two ISRCs keeps both. Codes are never withdrawn and never reused, so the remedy written into the standard is bookkeeping rather than repair: name one code the preferred ISRC, retire the other inside your own records, and tell every partner downstream. The ISRC Handbook puts this in a clause almost nobody quotes, and that clause settles which of the two codes wins. What it cannot do is put your streams back together — the plays banked against the retired code stay where they landed, and the merge most people assume exists is owed to you by nobody.
- The ISRC standard assigns one and only one code to each distinct recording, and a recording that has not materially changed must not be assigned another.
- Where a recording already carries more than one code, clause A.13.2 of the ISRC Handbook requires the owner to select one as the preferred ISRC and note the others in their own records.
- Where several parties assigned codes, the owner who made the first assignment makes the selection, and the earliest assignment is normally preferred.
- The standard does not require stock already released to be withdrawn, and no store or society publishes a procedure for reuniting two codes’ histories.
- Every system that identifies recordings by ISRC — stores, YouTube, SoundExchange, The MLC — reads two codes as two recordings.
Can one recording have two ISRCs?
Not validly. The standard assigns one and only one ISRC to each distinct recording, and a recording that has not materially changed must not be assigned another code.
The ISRC Handbook — the standard’s own rulebook, 4th Edition, 2021 — states the principle in a single line at 4.1:
The key principles for ISRC assignment are (a) that each distinct recording shall be assigned one and only one ISRC and (b) that any particular ISRC shall be assigned to one and only one recording.
Two principles, and each has its own way of failing. Give one code to two recordings and you have the mess piece 01 is about. Give one recording two codes and you have this page. The Handbook separates them into two clauses because the repairs are not the same repair, which is the single most useful thing to know before you start fixing anything.
Clause 4.3 closes the door on the honest version of the mistake: “A recording with an ISRC that has not undergone material change since an ISRC was assigned shall not be assigned another ISRC.” The US ISRC Agency, which issues prefixes in the United States, puts the same rule in the language of a help page — once an ISRC has been assigned to a track, it should stay the same for the lifespan of that track, even when ownership changes. And neither of your two codes can be quietly recycled out of the way afterwards: the industry’s ISRC FAQ is absolute that once assigned, an ISRC must not be re-used under any circumstances.
None of which helps you, because you are not deciding. You are looking at two codes that both exist.
How does a recording end up with two codes?
Four routes account for nearly all of them, and three are administrative rather than musical.
You switched distributors and left the ISRC field blank. This is the common one by a distance. Ari Herstand’s guide to switching distributors without losing your stream counts states the default plainly: “every distributor will assign you an ISRC number if you don’t provide it.” The new upload is the same audio, the same performance, the same recording — and a brand-new identity. Nobody set out to duplicate anything. Somebody left a box empty, and the box was not empty for fucking long.
A version took a code it did not need. A remaster given its own ISRC, a fade shortened by four seconds and re-coded, a single re-registered for the album. Which versions genuinely need one is a decision with written rules and a threshold, and it belongs to its own page rather than this one.
You re-delivered. A takedown and a rebuild are the correct repair for a code that is wrong, and the rebuilt product will take a fresh code unless you carry the old one across deliberately. That sequence, and the order it has to happen in, is the fix-it piece.
Your register lives in somebody else’s dashboard. If the only copy of your codes is a distributor’s back end, then every migration is a re-keying exercise performed from memory. That is not a filing habit. That is a coin toss with your catalogue on it.
What actually breaks?
Every system that identifies a recording by its ISRC reads the two codes as two recordings, so plays, royalty matching and registrations split between them.
This is the part worth reading slowly, because the sourcing runs the opposite way from what you would expect. Platforms document the split in detail. Not one of them documents the reunion.
YouTube says it in its own words. Its guidance on managing sound recording metadata warns delivering partners directly: “Keep in mind that entering a new ISRC or new Custom ID may result in the creation of a new sound recording share.” The code is not a label on the record. The code is the record. Its documentation on sound recording shares makes the mechanism explicit — “Custom ID and ISRC delivered together form a unique ‘key’” — and adds that only the latest delivered ISRC counts as official for a given share.
Apple removes the obvious escape route. Its Music Provider documentation on digital packaging is one sentence long on the subject and needs no second: “Once you have submitted your music with an ISRC, it cannot be edited.” You are not going to log in and correct this.
SoundExchange, which collects the US digital performance royalty, restated the rule in December 2023 in terms that leave no room: “A single ISRC should only be used for one recording, and each distinct recording should only have one ISRC.” Its register is built from codes submitted by rights owners, and its matching runs on the codes in licensees’ usage reports.
The publishing side is not immune either, though it fails one step further along. The MLC’s Matching Tool exists to “match sound recordings to compositions/musical works within their catalog,” and it organises what the streaming services report by code — “each column shows all the information from DSPs that is tied to that specific ISRC code.” Two codes means two recording records arriving to be matched, and a match you made once does not cover the code you did not know about.
Add it up and the shape is dull and expensive: two lines on the statement, two entries in the register, half the plays on each, and every downstream match performed twice or not at all. If a statement has already come up short and you have been hunting for the reason, that hunt has its own page and a duplicate code is one of the named causes on it.
Which of the two codes do you keep?
The earliest assignment normally wins: where several parties assigned codes, the owner who assigned first makes the selection, and the earliest code is normally preferred.
The Handbook devotes a clause to this and it is the reason this page exists. A.13.2, “Single recording assigned more than one ISRC”:
Where more than one ISRC has been assigned to a recording, the Registrant shall select one and use it as the preferred ISRC. The other ISRC(s) shall be noted in the Registrant’s internal records and not used for future releases. Business partners shall be informed of the error and steps taken to mitigate the potential for further error. It is noted that it is not always practical to withdraw physical or digital stock. Where repertoire databases exist and can accept registrations, such ISRCs shall be registered as such and linked to the preferred ISRC. Where multiple parties have assigned ISRCs to the same recording, the owner making the first assignment should make the selection, with the earliest assignment normally being preferred.
Read the last sentence twice. It answers the question that stops everyone: two valid codes, neither of them wrong, and a rule for which one survives. The first assignment. Not the one your current distributor prefers, not the one on the newest release, and not the one that happens to be winning.
Which is where the standard and your bank account can part company. The earliest code is frequently not the code carrying the streams — the duplicate usually arrives on the newer delivery, and the newer delivery is often the one collecting the playlist adds. A.13.2 tells you which code is correct. It has nothing to say about which is richer, and the Handbook’s word is “normally,” which is doing real work in a sentence about a rule.
So take the earliest code as your default and depart from it deliberately, in writing, with the reason recorded — because the one outcome with no defence is choosing by whichever dashboard you happened to have open.
How do you actually merge them?
Two different operations get called merging, and the one you control is the register, not the streams.
The register merge is yours, and you can do it this afternoon. A.13.2 lays out the steps and they are all clerical:
- Select one code as the preferred ISRC, by the rule above.
- Note the other code — or codes — in your own records, marked retired, against the preferred one. Do not delete it. You will meet it again on a statement, and an unexplained code is how this becomes a mystery a second time.
- Stop using the retired code for future releases. Permanently.
- Tell your business partners: your distributor, your label if there is one, your PRO and neighbouring-rights agency, and anyone administering the recording.
- Where a repertoire database will accept the registration, register the retired code as retired and link it to the preferred one.
The catalogue merge is nobody’s, on paper. No store and no society publishes a procedure for reuniting two codes’ streaming histories. What exists at the platform level is a distributor asking a service for a data merge and the service deciding — a request, not an entitlement, and covered along with the takedown sequence in the piece on fixing a wrong code. Start that conversation early if you are going to start it, and do not build a plan on it.
If a national agency needs to be involved — a prefix that was never yours, a code assigned by a company you no longer work with — A.13.4 routes you to the ISRC registration agency in your own country, which escalates internationally if it has to.
What does this cost, and what do you not get back?
Plays already banked against the retired code stay there, and nothing in the standard requires anyone to withdraw stock already released.
The Handbook concedes it inside A.13.2, in the flattest sentence in the entire document: “It is noted that it is not always practical to withdraw physical or digital stock.” That is a standards body writing the words this will not be fully fixed in the only register standards bodies have.
So the honest accounting. You keep the catalogue, the copyright and every stream that was ever played — none of that is at risk. What you lose is the arithmetic: one recording’s history stated as two half-histories, in every system, permanently, unless a platform decides on its own to link them. Moonlight got its correction on live television. You get a support ticket.
Which is the argument for finding these before they find you. A duplicate code does not announce itself; it shows up as a statement that is quietly smaller than it should be, months later, in a line item nobody reads. Matching your own register against what the services actually show, code for code, is a scheduled job rather than an instinct — and the checklist for it has the identifiers section written for exactly this.
One recording, one code, held in a register you control and supplied with every delivery. That is the whole of the prevention, it costs nothing, and it is the only part of this page you can act on before the problem exists.
FAQ
Can an ISRC be deleted?
No. Once assigned, an ISRC must not be re-used under any circumstances, and the standard offers no way to withdraw or delete one — a retired code stays retired inside your own records.
Does the second release have to come down?
No. Clause A.13.2 requires the retired code to stop being used for future releases, and it states plainly that withdrawing stock already released is not always practical.
Two companies each assigned a code. Who chooses?
The owner who made the first assignment makes the selection, and the earliest assignment is normally the one preferred.
Does a duplicate ISRC affect the songwriting side?
The musical work carries its own identifier, but The MLC matches sound recordings to musical works by ISRC, so a second recording record has to be matched separately.
Sources
- IFPI, ISRC Handbook, 4th Edition (2021) — the clauses this piece runs on: the one-and-only-one principle (4.1), no second code without material change (4.3), and the recovery annex, A.13.2 for a recording with more than one code and A.13.4 for errors that reach other registrants. Each clause code above links to its page in the PDF.
- IFPI, ISRC FAQ — the industry’s own summary, including the rule that once assigned, an ISRC must not be re-used under any circumstances.
- US ISRC Agency, Guidance and Support — the American agency’s statement that a code stays with a track for its lifespan even when ownership changes, and that correcting or mitigating an error is the job of every affected party.
- Apple, Digital packaging for music — Music Provider documentation: an ISRC cannot be edited once music has been submitted with it.
- YouTube, Manage your sound recording metadata — the warning that a new ISRC may create a new sound recording share.
- YouTube, Sound Recording Shares for music labels — ISRC as part of the unique key, and only the latest delivered code treated as official.
- SoundExchange, All About ISRCs (December 2023) — one code per recording, one recording per code, from the organisation matching US digital performance plays.
- The MLC, What is the Matching Tool? — recordings matched to musical works, organised by ISRC.
- Ari Herstand, How To Switch Distributors Without Losing Stream Counts or Playlists (updated May 2021) — the auto-assignment default that causes most duplicates.
The Handbook, the FAQ and the agency and platform pages above are their publishers’ own documents, quoted verbatim and current as of the date on this page. Platform behaviour is not a standard and changes without notice; confirm anything operational with your own distributor before acting. None of this is legal advice.
Keeping the register
A duplicate is found by searching a code and finding two of something. CatalogTracker holds the ISRC as a field on the track and searches the identifiers directly — type a code and the result tells you which identifier matched — and its history keeps what changed, when, and from what to what. Selecting a preferred code is still your decision to make and record. In development for iPhone.