Your distributor issued your ISRCs. What happens when you leave?

An ISRC identifies a recording. It does not identify a business relationship, it is not a licence, and it grants your distributor nothing. When you change distributor, your ISRCs go with your recordings — that part is settled. What surprises people is the part that does not travel: the prefix. You keep every twelve-character code you have already used, forever, and you cannot mint a single new one under that prefix once you have gone.

That distinction is the whole article. Everything else is what follows from it.

What the code is made of, and which part is yours

IFPI describes the ISRC as a five-character prefix — two letters plus three alphanumerics — then two digits of year of reference, then five digits of designation code. Written out for a reader: CC-XXX-YY-NNNNN.

The country code plus the registrant code form the prefix, and the prefix is allocated by a national ISRC agency to a specific entity. The registrant controls the designation codes within each year — up to 100,000 per prefix per year across the full 00000–99999 range, though allocation may be narrower for smaller registrants: the ISRC Handbook states that "the allocation of a new prefix will be accompanied by the range of designation codes for which it is authorised for that registrant" (§3.3.4).

So if your distributor issued you QZ-ES6-25-00013, then QZES6 is the distributor's registrant code. The serial number 00013 was allocated by them, out of their range, in their name. The recording is yours; the code is attached to your recording permanently; the prefix belongs to the entity that registered it.

One housekeeping note while the code is in front of you: the hyphens are not real. The Handbook is explicit that "the letters 'ISRC' (the space) and the hyphens do not form part of the ISRC" (§5). QZ-ES6-25-00013 and QZES62500013 are the same code. Store the twelve characters unpunctuated — delivery specifications want them that way, and a hyphenated string in a twelve-character field is an avoidable validation failure.

What you keep

You keep the codes. All of them.

This follows from two rules that point the same way. Handbook §4.6 covers a recording that is sold or licensed: it keeps its ISRC. And the ban on assigning a second ISRC to an unchanged recording means nobody — not you, not your new distributor — is permitted to issue a fresh code for a recording that already has one and has not materially changed.

Which means the correct behaviour when you re-deliver your catalogue through a new distributor is to supply the existing ISRCs. Not to let the onboarding form generate new ones. The form usually has a field that says something like "I already have an ISRC" — that field is the entire point, and leaving it blank is the most common way artists throw away their own history.

Minting a new ISRC for an unchanged re-release discards the recording's accumulated identity. Playlist history, society registrations, neighbouring-rights claims and chart history are all keyed to the old code. The recording carries on sounding the same and starts again from zero as a matching target. Nothing visible breaks, which is exactly why it goes unnoticed.

What you cannot do

You cannot mint new codes under a prefix you do not hold.

Your back catalogue keeps QZES6 in its codes because those codes are permanent. Your next release cannot use QZES6, because you were never the registrant — your new distributor will assign from their own prefix, or you will assign from yours if you have one.

This is the point where people worry that their catalogue now looks broken. It does not. A catalogue with mixed prefixes is not a defect. A catalogue with duplicated designation codes is. Prefixes reflect who assigned each code and when; duplicates mean two different recordings are claiming the same identity, and that failure is not self-correcting. Every downstream matching system will treat the two recordings as one, permanently.

The Handbook is unambiguous on the related point at §A.3: an ISRC is never re-assigned. Once a code has been used for a recording it belongs to that recording and to nothing else, for good.

Whether your distributor was allowed to issue codes at all

Distributor-issued ISRCs are legitimate — when the distributor is an approved ISRC Manager. The US ISRC Agency states that "a handful of companies are approved to assign ISRCs on behalf of the owner of a recording," and warns that codes from unauthorised companies "are invalid and risk collisions with codes issued by authorized registrants." IFPI maintains the list of approved managers.

The practical version: a code invented by a service with no allocation is not an ISRC. It is a twelve-character string that looks like one and will eventually collide with a real code belonging to somebody else. There is no way to detect this from the shape of the code, because an ISRC has no check digit — a UPC has one, an ISWC has one, an ISRC does not, and nothing in the specification provides for one.

That absence is worth internalising, because it changes how carefully you handle the codes. A UPC typo usually fails its own check digit and gets rejected loudly at ingestion. An ISRC typo sails through. A single transposed character produces another perfectly valid-looking ISRC that belongs to somebody else's recording — and the plays go to them, or to nobody, silently.

If an unfamiliar country code appears in your catalogue, investigate it before release rather than after. It is usually a symptom of something worse: a code typed by hand, or a service issuing codes without an allocated prefix.

When it is worth getting your own registrant code

Apply to your national ISRC agency for your own prefix when any of these is true:

• You run a label with more than a handful of artists, or you assign codes continuously rather than once per release.
• You release through more than one distributor and want a single stable prefix across the catalogue.
• You need ISRCs before delivery — for sync, physical manufacture, broadcast delivery or society registration.
• You want your codes to be independent of any company's continued existence.

Two constraints come with it. Prefixes are allocated in sequence and, per the US ISRC Agency, "cannot be altered after allocation" — you do not get to pick a memorable one. And a rights-owner prefix should be used only "to assign ISRCs for recordings that you own." If you intend to assign codes for other people's recordings, that is manager status, not an artist prefix, and it is a different application.

For a solo artist putting out two singles a year, distributor-issued codes are genuinely fine, and the migration story above is the whole cost. For anyone building a catalogue they expect to administer for decades, your own prefix removes a dependency for a modest one-time effort.

Why any of this shows up in your bank account

Every royalty you receive is the result of a database join, and the identifier is the only thing holding the join together. The chain runs like this:

1. The play happens. The service logs it against the recording in its catalogue, matched to the ISRC you delivered.
2. The service reports. Usage reports reach the rights holder or distributor itemised by ISRC, with the release identified by UPC. Recording-side money is calculated as a share of pooled revenue, not a fixed rate per play — Spotify states that it does not pay a per-stream rate: revenue is pooled and divided by streamshare, so what a play is worth moves with the pool.
3. The distributor accounts. They match report lines to your catalogue on ISRC and UPC and produce your statement. A reported ISRC that is not in your catalogue never reaches your statement; it sits unallocated.
4. The composition side runs in parallel. Societies and mechanical licensing bodies link the reported ISRC to the registered work (ISWC) and then to writers and publishers. Separate pipeline, separate schedule, separate money.
5. Neighbouring rights. Broadcast and public-performance income for the recording is matched on ISRC against a registration naming the rights holder and featured performers.
6. Payment, subject to tax treatment at source.

A distributor change touches steps 1 through 3 directly. Deliver the old ISRCs and the joins keep working: the reports still name codes your catalogue recognises. Let new codes be generated and the reports arrive naming codes that mean nothing to anyone's history — the money still arrives, but the recording's identity does not travel with it, and steps 4 and 5 are matching against registrations keyed to the codes you abandoned.

The quietest failure in the whole chain is a mismatch between the ISRC embedded in the audio file, the ISRC in the accompanying metadata, and the ISRC in your society registration. When those diverge, everything appears to work — the release goes live, streams accrue, dashboards show numbers — and matching fails somewhere you cannot see, months later.

What to do before you send the termination email

The migration is administrative, not technical, and it is much easier to do while you still have a working login.

• Export the identifier list first. Track title, version, ISRC, ISWC, writer splits, release UPC — one authoritative sheet, before you lose access to the dashboard that holds it.
• Format identifier columns as text before pasting anything. A leading zero destroyed by spreadsheet auto-formatting is a UPC that fails its own check digit later.
• Copy, never retype. There is no check digit to catch a transposition.
• Fill in the "I already have an ISRC" field on every track at the new distributor. Every single one.
• Check that the embedded identifiers in your audio match the sheet before you deliver, not after.
• Expect a new prefix on your next release and do not treat it as an error.

That is roughly an hour per release of unglamorous work, and it is the difference between a statement you can argue from and a statement you can only accept.

What to do with this

Your codes are yours because they are attached to your recordings, not because of who issued them. The prefix stays behind; the identity does not have to. The failure mode is not losing the codes — it is quietly replacing them.

Mazufa's free ISRC and barcode checker is at /isrc-upc-checker. It runs entirely in your browser — nothing is uploaded — and it will tell you whether a code is structurally well-formed and whether a barcode's check digit is correct. It cannot tell you an ISRC is the right code for your recording, because no tool can: there is no check digit, and only your own source list can settle that.

Mazufa distributes music with no upload fee, no subscription and no per-release charge, and takes 0% commission: royalties received for a release are passed through in full. A bank or payment provider's own transfer fee and statutory withholding are third-party costs, not a Mazufa deduction. Every complete application gets a human review.

Sources

• IFPI, ISRC Structure (country code, registrant code, year of reference, designation code). isrc.ifpi.org/isrc-standard/isrc-structure
• IFPI, International Standard Recording Code (ISRC) Handbook (§3.3.4 designation-code ranges; §4.6 a recording sold or licensed keeps its ISRC; §5 hyphens are not part of the code; §A.3 an ISRC is never re-assigned). ifpi.org/wp-content/uploads/2021/02/ISRC_Handbook.pdf
• IFPI, ISRC Managers — the list of entities approved to assign ISRCs on a rights holder's behalf. isrc.ifpi.org/get-isrc/isrc-managers
• US ISRC Agency, How It Works (approved managers; codes from unauthorised issuers are invalid and risk collisions; prefixes allocated in sequence and not alterable; rights-owner prefixes used only for owned recordings). usisrc.org/how-it-works/
• Spotify's published statement that it does not pay a per-stream rate: revenue is pooled and divided by streamshare. support.spotify.com