ISRC and UPC/EAN: The Complete Technical Reference for Musicians

What is an ISRC, and do I need one?

An ISRC — International Standard Recording Code — is a 12-character identifier that names one specific recording. Not the song. Not the album. The recording: one performance, one mix, one master. Its structure is fixed: two characters of country code, three of registrant code, two digits of year of reference, five digits of designation code. Hyphens are a reading aid and are not part of the code. There is no check digit. Yes, you need one for every recording you release commercially, and a different one for every materially different version — the radio edit, the remix, the live take, the instrumental. The ISRC is the key that streaming services, collecting societies and neighbouring-rights organisations use to match a play to a payee. If two recordings share an ISRC, or if the ISRC in your metadata does not match the one attached to your audio, the money goes to the wrong place or nowhere. A distributor can issue ISRCs on your behalf, and those codes stay with your recordings when you leave.

Three identifiers, three different things

Three identifiers run the recorded-music supply chain, and confusing them is the commonest cause of unmatched royalties.

ISRC identifies the recording. ISO 3901, administered by IFPI as Registration Authority with national agencies handling allocation. One master, one ISRC. Your studio version of "Bahar" and your live version of "Bahar" are two recordings and therefore two ISRCs, even though they are the same song by the same writer.

ISWC identifies the composition. ISO 15707, administered under CISAC. The format is T-123.456.789-C — a T prefix, nine digits and a check digit — and the digits carry no embedded meaning about region, writer or publisher (ISO 15707). It names the work as written: twenty recordings of one song share one ISWC and have twenty ISRCs. You do not obtain an ISWC yourself; it is assigned through your collecting society or publisher when the work is registered.

UPC/EAN identifies the release. A GS1 Global Trade Item Number — the same class of product code that identifies a bottle of shampoo. It names the album, EP or single as a commercial product. A three-track EP has one UPC and three ISRCs.

The ISRC is the recording, the ISWC is the song, and the UPC is the box you sold them in — and every royalty system you will ever be paid by depends on you knowing which is which.

How the confusion loses money, concretely

The money splits along the same three lines. Recording revenue — streaming master royalties, neighbouring rights for broadcast and public performance — is matched on ISRC. Publishing revenue — mechanicals and performance royalties owed to writers and publishers — is matched on ISWC and on the ISRC-to-ISWC links in society databases. Product-level retail and reporting runs on UPC.

Three failure patterns follow:

1. You give two different recordings the same ISRC. A neighbouring-rights society receives play data for both and cannot tell them apart. Payments merge into one line, distributed against whatever ownership data is registered for that code. If the recordings have different performers or splits, someone is being paid for a recording they did not make.
2. You issue a new ISRC for a re-release of an unchanged master. Stream counts, playlist history and society registrations built up under the old code do not follow you: to the industry, a brand-new recording just appeared with zero history. This is the most common self-inflicted wound in catalogue migration.
3. You register a work under an ISRC instead of an ISWC, or vice versa. The recording-to-composition link is what lets a society route mechanical royalties to the writer. Break it and the recording is "unmatched" — the play is counted, the money is collected, and it sits in a suspense account until someone claims it or the window closes.

An unmatched royalty is not a lost royalty yet, but it becomes one on a schedule and nobody sends a reminder.

ISRC structure, character by character

Twelve alphanumeric characters in four fields. IFPI describes it as a five-character prefix (two letters plus three alphanumerics), then two digits of year of reference, then five digits of designation code (IFPI ISRC structure). Written for a reader: CC-XXX-YY-NNNNN

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

Hyphens are display only

The Handbook is explicit: "The letters 'ISRC' (the space) and the hyphens do not form part of the ISRC" (§5). QZ-ES6-24-00042 and QZES62400042 are the same code. Store it as twelve characters — delivery specs want them unpunctuated, and a hyphenated string in a twelve-character field is an avoidable validation failure.

There is no check digit

This matters because people assume there is. A UPC has a check digit; an ISWC has a check digit; an ISRC does not. Nothing in the specification provides for one, and no validator can tell you a well-formed ISRC is the correct ISRC for your recording. All you can check mechanically is the shape: two letters, three alphanumerics, two digits, five digits, a registered country code, a plausible year.

An ISRC has no check digit, which means a single transposed character produces another perfectly valid-looking ISRC that belongs to somebody else's recording.

That asymmetry is why ISRC data entry deserves paranoia that UPC entry does not: a UPC typo usually fails its own check digit, while an ISRC typo sails through.

What the year of reference actually means

It is not the year the recording was made, and it is not the release year. IFPI defines it as the year the ISRC was assigned: it consists of "the last two digits of that year (e.g. 15 for 2015, 20 for 2020)," and IFPI states plainly that "the year in which the ISRC is assigned may be a different year from the year of recording" (IFPI ISRC structure).

Its function is administrative: it "refresh[es] the space of codes which may be assigned each calendar year, to ensure that codes assigned in prior years cannot be inadvertently re-assigned" (same source) — a namespace partition, not a date field.

So if you assign codes in December 2025 for an album recorded in 2023 and released in March 2026, the year of reference is 25. That is correct; do not "fix" it. Never infer a date from an ISRC — recording year belongs in metadata, not in a parsed identifier.

The year of reference tells you when the code was minted, not when the music was made, and treating it as a release date is how catalogues get silently misdated.

When you need a new ISRC — and when you must not mint one

The governing principle sits in the Handbook: "A recording with an ISRC that has not undergone material change since an ISRC was assigned shall not be assigned another ISRC" (§4.3), and "An ISRC that has been assigned to a recording shall never be re-assigned to another different recording" (§A.3).

Those two sentences point in opposite directions and together define the whole rule: one recording, one code, forever — and one code, one recording, forever.

New ISRC required

• Remix. "A remixed version of a recording will differ from the original and hence it shall be assigned a new ISRC" (§A.9.8).
• Edit. "A version that is edited, for example to mute or replace profanities, shall be assigned a new ISRC" (§A.9.4) — radio edits, clean versions, shortened single edits.
• Live version. "The live recording is completely different from the studio version and a new ISRC is required" (§A.9.1).
• Instrumental, a cappella, stem-suppressed versions. "A version of a track where the vocal (or other element) has been suppressed shall also be assigned a new ISRC if it is intended for release" (§A.9.14).
• Substantive change in playing time. The Handbook treats length alterations as material where they affect creative content, and flags non-creative duration changes exceeding 10 seconds (§A.10.2); IFPI's FAQ restates the threshold as "changes in playing time which exceed 10 seconds" (IFPI FAQ).
• Remaster involving creative input. Narrower than commonly stated. The Handbook conditions a new code on whether "the processes applied to a recording during re-mastering involve the application of creative input" (§A.10.1); purely technical level or EQ adjustment without creative variation does not by itself require one. In practice most commercial remasters are sold as distinct products with distinct ISRCs — and if your remaster sits alongside the original as a separate track, it needs its own code regardless of how you classify the engineering.

No new ISRC

• Re-release of the same master. New artwork, distributor, territory or release date is not a change to the recording. The ISRC stays.
• Change of ownership of an unchanged recording. "If the original Registrant sells or licenses the recording in unchanged form after it has been given an ISRC, no new ISRC shall be assigned and the ISRC for the recording shall remain the same" (§4.6).
• New UPC. A compilation gets its own UPC; the recordings on it keep their ISRCs.

One asymmetric case: IFPI's FAQ states that "if a recording did not have an ISRC originally, has changed ownership, and is being released unchanged by the current rights holder, a new ISRC should be assigned" (IFPI FAQ). The rule preserves a code that exists; it does not invent a lineage for archive material that never had one.

The decision rule

Ask one question: would a listener hear a different audio file?

If yes — different performance, mix, length or content — it is a different recording and needs a new ISRC. If no — the bits are identical and only packaging, artwork, price, territory or distributor changed — reuse the existing ISRC.

Then the safety check: never point one ISRC at two different audio files. If you are unsure whether a change is material, minting a new code for a genuinely new version is recoverable. Reusing a code across two recordings is not — it corrupts every downstream database that ingests it, and you cannot recall it.

If the audio file changed, the ISRC changes; if only the packaging changed, it does not.

Distributor-issued ISRCs, your own registrant code, and what happens when you leave

An ISRC identifies a recording, not a business relationship. The code is not a licence and grants your distributor nothing. When you change distributor your ISRCs go with the recordings — this follows from §4.6 and the ban on assigning a second ISRC to an unchanged recording.

The nuance that trips people up: the prefix belongs to whoever registered it. If your distributor issued you QZ-ES6-25-00013, QZES6 is the distributor's registrant code. You keep using that twelve-character ISRC on that recording forever — that is required — but you cannot mint new codes under QZES6 once you leave, so your next release carries a different prefix. A catalogue with mixed prefixes is not a defect; one with duplicated designation codes is.

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" (US ISRC Agency); IFPI maintains the list (ISRC Managers). A code invented by a service with no allocation is not an ISRC — it is a twelve-character string that will collide.

When to get your own registrant code

Apply to your national ISRC agency for your own prefix when:

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

Two constraints: prefixes are allocated in sequence and "cannot be altered after allocation," and a rights-owner prefix should only be used "to assign ISRCs for recordings that you own" (US ISRC Agency). If you assign codes for other people's recordings you need manager status, not your own artist prefix.

For a solo artist releasing two singles a year, distributor-issued codes are fine. For anyone building a catalogue to administer for decades, your own prefix removes a dependency for a modest one-time effort.

UPC and EAN: the product identifier

UPC-A is 12 digits, EAN-13 is 13. Both are GS1 Global Trade Item Numbers — GTIN-12 and GTIN-13 — structured the same way: a GS1 company prefix, an item reference assigned by the brand owner, and a single check digit in the last position.

The UPC identifies the product: this album, this configuration. A digital album, a CD and a vinyl LP of one record are three products and normally carry three UPCs. A single gets its own UPC; when that recording later appears on the album it keeps its ISRC while the album carries a different UPC.

GS1 recommends storing GTINs uniformly: "GS1 recommends that GTIN is always stored as a 14-digit number in the data bases. Shorter formats should be filled in with leading zeroes up to 14 characters" (GS1 EDI technical user guide). Do this in your own spreadsheets too: it makes cross-system matching trivial and prevents the classic disaster where a leading zero is silently stripped.

Why a UPC-A becomes an EAN-13 by prefixing a zero, with the check digit unchanged

This is the part everyone repeats and nobody explains. The weighting in the GS1 algorithm is anchored at the right-hand end of the number, not the left.

The check digit occupies the rightmost position. Working leftwards from the digit immediately before it, the weights alternate ×3, ×1, ×3, ×1, indefinitely. Because that pattern is defined relative to the check digit's position, every digit in a GTIN-12 keeps exactly the same weight when the number is padded on the left to 13 or 14 digits. Nothing shifts.

Prefixing a zero therefore adds one term to the weighted sum, and that term is 0 × 3 or 0 × 1 — either way, zero. The sum is unchanged, so the value that brings it to the next multiple of ten is unchanged, so the check digit is unchanged.

A UPC-A padded to an EAN-13 keeps its check digit because the weights are counted from the right, and adding a zero on the left adds exactly zero to the sum.

Operationally: 602451264538 and 0602451264538 are the same GTIN. If one system rejects one form, that is a formatting rule, not two products — do not mint a second UPC to satisfy it.

The check-digit algorithm, worked by hand

GS1 states the calculation in three steps: multiply each position by its alternating factor, "add results together to create sum," then "subtract the sum from nearest equal or higher multiple of ten" (GS1). GS1 publishes it as a left-anchored table per GTIN length; the right-anchored form below is equivalent, works for every length, and is the one worth memorising.

The procedure.

1. Take the digits before the check digit.
2. From the rightmost of those and moving left, multiply alternately by 3, 1, 3, 1, …
3. Add the products.
4. Round the sum up to the next multiple of ten; the check digit is the difference. If the sum is already a multiple of ten, the check digit is 0.

Worked example. Take the UPC-A 602451264538: the first eleven digits are 60245126453 and the final 8 is the check digit we will derive. Reading the eleven digits from the right:

Sum: 9 + 5 + 12 + 6 + 6 + 1 + 15 + 4 + 6 + 0 + 18 = 82.

Next multiple of ten at or above 82 is 90. 90 − 82 = 8.

The check digit is 8, so the complete UPC-A is 602451264538. ✓

Now the EAN-13. Prefix a zero: 0602451264538. The twelve digits before the check digit are 060245126453. Read from the right, the eleven original digits keep identical weights; the new leading 0 takes the twelfth weight, ×1, contributing 0. Sum: 82. Next multiple of ten: 90. Check digit: 8 — unchanged, exactly as predicted.

To verify rather than generate, run the same procedure including the check digit at weight ×1 and confirm the total is a multiple of ten. For 602451264538: 82 + 8 = 90. Consistent.

A check digit proves a number was typed correctly; it proves nothing about whether it is your number.

The algorithm catches every single-digit error and most adjacent transpositions — but not all. Transposing adjacent digits that differ by 5 (0/5, 1/6, 2/7, 3/8, 4/9) changes the weighted sum by exactly ±10, leaving the check digit valid. That class of typo passes silently, which is why you cross-check a UPC against the source you received it from rather than trusting a checker alone.

You can validate ISRC structure and UPC/EAN check digits with the free browser-based checker at mazufa.com, which runs entirely on your own device.

Common failure modes

Reusing one ISRC across different recordings. The worst error available to you, because it is not self-correcting: every downstream matching system treats the two recordings as one, permanently. The cause is usually a spreadsheet copy-paste or a template row nobody updated.

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 keyed to the old code. Cause: a distributor onboarding form that auto-generates codes with the "I already have an ISRC" field blank. Always fill that field.

Wrong country code. Usually a symptom of something worse: someone hand-typed the code, or a service invented codes without an allocated prefix. Investigate an unfamiliar country code before release, not after.

Transposed characters in an ISRC. No check digit, no detection. The recording is delivered under an identifier belonging either to nobody (plays go unmatched) or to somebody else (plays are attributed to them). Mitigate by copy-pasting rather than retyping, and by validating every ISRC in a release against one source list.

A UPC that fails its own check digit. Almost always a typo, a truncation, or a leading zero destroyed by spreadsheet auto-formatting. Format the column as text before pasting. This failure is at least loud — most ingestion systems reject it.

Identifiers that do not match between audio delivery and metadata. The quietest and most expensive failure. The ISRC embedded in the audio file, the ISRC in the accompanying DDEX or spreadsheet metadata, and the ISRC in your society registration must be the same twelve characters. When they diverge everything appears to work — the release goes live, streams accrue, dashboards show numbers — but matching fails somewhere you cannot see, months later. Check that embedded and declared identifiers agree before delivery.

The identifier failures that cost the most are the ones that let the release go live and break the matching afterwards.

How identifiers turn a stream into a payment

Understanding the chain tells you exactly where a broken identifier severs it.

1. The play happens. The service logs a play event against the recording it has in its catalogue, identified internally and 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 here 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 varies with the pool.
3. The distributor accounts. Your distributor matches report lines to your catalogue on ISRC and UPC and produces 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. Mechanical and performance royalties for the song are collected by societies and mechanical licensing bodies, which 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 collected by neighbouring-rights societies, matched on ISRC against a registration naming the rights holder and featured performers.
6. Payment. The money is paid across, subject to tax treatment at source.

Every step is a join on an identifier, and a join fails silently. Break the ISRC at step 1 or 2 and the recording-side money is unmatched. Break the ISRC-to-ISWC link at step 4 and the writer's money is unmatched. Break the UPC and product-level reconciliation falls apart, leaving a statement you cannot tie to a release. Break the audio-to-metadata correspondence and every step breaks at once.

Every royalty you receive is the result of a database join, and an identifier is the only thing holding the join together.

The discipline is unglamorous and takes about an hour per release. Keep one authoritative sheet: track title, version, ISRC, ISWC, writer splits, release UPC. Format identifier columns as text. Assign ISRCs before delivery, not during. Verify every UPC check digit. Confirm the identifiers embedded in your audio match the sheet. Register recordings and works with the relevant societies using the same codes. Then, when a statement is missing a line, you have a source of truth to argue from — without one you cannot establish what should have been paid.

Quick reference

Mazufa's distribution is free — no upload fee, no subscription, no per-release charge — and the only deduction is 5% of royalties received.

Sources

• IFPI, ISRC Structure (country code, registrant code, year of reference, designation code; definition and purpose of the year of reference) — https://isrc.ifpi.org/isrc-standard/isrc-structure
• IFPI, International Standard Recording Code (ISRC) Handbook (§4.3 no second ISRC without material change; §4.6 unchanged recording sold or licensed keeps its ISRC; §5 hyphens are not part of the code; §3.3.4 designation-code ranges; §A.3 never re-assign an ISRC; §A.9.1 live versions; §A.9.4 edits; §A.9.8 remixes; §A.9.14 suppressed-element versions; §A.10.1 re-mastering and creative input; §A.10.2 playing-time changes) — https://www.ifpi.org/wp-content/uploads/2021/02/ISRC_Handbook.pdf
• IFPI, ISRC FAQs (remixes and edits; the 10-second playing-time threshold; re-release of a recording that never had an ISRC) — https://isrc.ifpi.org/faqs
• IFPI, ISRC Managers (list of entities approved to assign ISRCs on a rights holder's behalf) — https://isrc.ifpi.org/get-isrc/isrc-managers
• US ISRC Agency, How It Works (prefix allocation in sequence and not alterable; rights-owner prefixes used only for owned recordings; approved managers; risk of collision from unauthorised code issuers) — https://usisrc.org/how-it-works/
• GS1, Check Digit Calculator and manual calculation guidance (weighting, summation, and subtraction from the nearest equal or higher multiple of ten) — https://www.gs1.org/services/check-digit-calculator
• GS1, Communicating GS1 trade item numbers (GTINs stored as 14 digits, shorter formats filled with leading zeroes) — https://www.gs1.org/edi-xml/technical-user-guide/Item_Numbers
• ISO 15707:2001, International Standard Musical Work Code (ISWC) — https://www.iso.org/standard/28780.html
• CISAC, International Identifiers (ISWC administration) — https://www.cisac.org/services/information-services/international-identifiers
• ISWC International Agency — https://www.iswc.org/
• International Standard Musical Work Code, Wikipedia (ISWC format T-123.456.789-C: T prefix, nine digits, check digit; digits carry no embedded meaning) — https://en.wikipedia.org/wiki/International_Standard_Musical_Work_Code

Note on the worked example: 602451264538 is used as a structurally valid UPC-A to demonstrate the check-digit calculation. It is not presented as the identifier of any particular release.