What a UPC does that an ISRC doesn’t

33 · 2026-08-31 · 13 min read · Español

A UPC identifies the release you are selling. An ISRC identifies one recording inside it. That is not a difference of size: the same recording keeps the same ISRC on the single, on the album and on every compilation it is ever licensed to, so no reference to an ISRC can tell you which of those a play or a sale came from. The ISRC standard says exactly that, and names the codes that answer instead — product identifiers, which it places outside its own scope.

• A UPC is a GS1 GTIN. It identifies a trade item — a product sold — and the barcode is only a machine-readable way of carrying the number.
• An ISRC identifies a recording, and that recording keeps the same code across every release it appears on.
• Apple requires an individual UPC for every digital album delivered and an ISRC for every track. Neither can be edited afterwards.
• DDEX does not accept an ISRC as a release identifier: a release is identified by a GRid, an ICPN or a proprietary ID.
• One recording carries one ISRC and as many UPCs as there are releases it sits on. Three of each is normal and none of it is a duplicate.

What does a UPC actually identify?

A UPC identifies a release as a product for sale. It is not a code for music at all — it is a code for the thing the music is being sold as.

The number is a GTIN, and GTINs are not a music invention. GS1, which issues them, defines a GTIN as “a GS1 identification key used to identify a trade item, which can be a product you sell or service you offer.” A trade item is a thing that gets ordered, priced and invoiced. Your album is one. The recording on track four is not.

Two formats matter to you, and they are the same standard with different digit counts. A GTIN-12 is twelve digits, is used predominantly in North America, and is what everybody means by UPC. A GTIN-13 is thirteen digits, is used predominantly everywhere else, and is what everybody means by EAN. They are interchangeable in every delivery system you will meet.

And the barcode is not the code. GS1 puts it in one line — the GTIN is “the number found under a product barcode’s black and white lines.” The lines are packaging for a scanner. A digital release has no lines and still has the number, which is why “I’m not pressing CDs, so I don’t need a barcode” is a sentence that has cost people a delivery.

DDEX, whose message format your distributor’s delivery is written in, gives the whole family one name and stops arguing about it: an ICPN, an International Code Product Number, covering “Universal Product Codes, UPC, European Article Numbers, EAN, Japanese Article Numbers, JAN, and Global Trade Item Numbers, GTIN.” When a store's documentation says ICPN, it is asking for your UPC.

What can a UPC answer that an ISRC cannot?

Which release an exploitation belongs to. The ISRC cannot answer that, and the standard that governs it says so in writing rather than leaving you to work it out from a report that will not reconcile.

Clause A.8.4 of the ISRC Handbook, on what happens when a recording is reused:

The exploitation of a recording on a compilation (or other subsequent issues) cannot be distinguished from exploitations of the same recording on other releases by reference to the ISRC. The ISRC must be the same in each case. Where such distinction is required, reference should be made to product identifiers, which are outside the scope of the ISRC system.

Read the third sentence again. This is not a limitation somebody discovered; it is the registration authority drawing a boundary around its own code and pointing over the fence.

And “a compilation” sounds like a rarity until you notice that it describes your Tuesday. You put out a single. Six weeks later the same recording opens the album. Those are two releases of one recording, the code on the recording is identical in both, and the question you want answered on the next statement — which one did people actually buy — is a question about the product, not the recording.

The UPC is the only key in the delivery that knows the difference.

And what does an ISRC do that a UPC cannot?

It follows one recording everywhere the recording goes, for as long as the recording exists.

The same clause that limits the ISRC is also the clearest statement of its power: the code is the same in each case. Licence the master to a film, sell the catalogue, re-release it under a different label in a different decade — the recording arrives carrying the identifier it was born with. A UPC does none of that. It expires with the product, and the product is a packaging decision.

The standards bodies enforce the split rather than merely describing it. DDEX’s rules for releases say that “any main release intended for consumers shall be identified by either a GRid, ICPN or a ProprietaryId” — and then, for anyone who tries the obvious shortcut: “If a record company or distributor is considering the use of an ISRC as an identifier for a Track Release, it shall be communicated as a ProprietaryId.”

That is a standards body being told the ISRC is right there and answering that it can go in the box for codes it does not recognise. Which is the whole argument, settled by the people who have to make the messages parse.

Everything else about the ISRC belongs to other pages and is not repeated here: where the code comes from and what being the registrant obliges, and whether a remaster, an edit or a remix needs a new one, which has an actual table and thirty-odd rules in it.

How many of each does one recording carry?

One ISRC, and one UPC for every release it appears on.

Work it through with one song. It goes out as a single in March, opens the album in May, and turns up again on the deluxe edition in November. That is one ISRC and three UPCs, and every one of the four codes is correct.

Both halves are documented. GS1’s rule for products is that “each variation of each product you sell requires a unique barcode”; Apple’s delivery documentation says “every digital album requires an individual UPC upon delivery” and, one line later, “each song or music video requires an ISRC.” The two rules are counting different things and both are absolute.

This is worth holding onto because it is the difference between a healthy catalogue and a repair job. Three UPCs on one recording is a discography. Two ISRCs on one recording is a defect with its own order of operations, and people who have not separated the two ideas tend to panic at the first and miss the second.

Where does a UPC come from, and what does it cost?

From GS1, either directly or through your distributor. Direct, a single GS1 US GTIN is $30 with no annual renewal; a GS1 Company Prefix, which gives you a block, starts at $250 up front and $50 a year for ten items. Through a distributor it is almost always free.

Spotify’s own glossary describes the normal path without ceremony: “If you’re releasing through a label or distributor, they’ll usually generate and manage UPCs for you. If you need to obtain your own, you can register through the appropriate issuing agency in your country.”

So the $30 is not buying you a better number. Both codes are equally valid at every store. What it buys is the same thing the equivalent decision buys on the other code — independence from the company that issued it — and that argument is made properly, with all three routes and what each one costs, in the piece about getting an ISRC without a distributor. The shape of the decision is identical. The fees are not.

How do you find the UPC of a release that is already out?

Through the same two APIs that carry the ISRC — but on the release object, never on the track.

On Spotify, an album’s UPC sits in external_ids — the album object carries upc and ean in the same field that carries isrc on a track. And the search endpoint draws the line this piece has been arguing for, in one sentence of its own documentation: “The isrc and track filters can be used while searching tracks. The upc, tag:new and tag:hipster filters can only be used while searching albums.” Hand it a UPC and ask for tracks and you get nothing, because you asked a question about a product using the wrong noun.

Apple is symmetrical about it and has a whole endpoint for the job — Get Multiple Catalog Albums by UPC, which takes a filter[upc] parameter and returns albums. Its ISRC counterpart returns songs. Neither one will cross over, because the catalogue does not think they are the same kind of thing.

Everything about hunting down an ISRC already in the wild — the free IFPI database, the developer tokens, what each route costs to set up — is its own piece, and the setup work it describes is the same work here.

What breaks when one code goes in the other’s box?

Nothing visible. The delivery is accepted, the store publishes what you sent, and the first sign is a report months later that will not reconcile against your own register.

Neither system knows anything about the other’s objects. A well-formed code attached to the wrong one passes every check there is, because every check reads the string and never the thing behind it. Two teams, two unit systems, nobody converting — that is how you fly an orbiter into Mars.

Some of it does get caught at the door, and that is the good outcome rather than the bad one. A code that belongs to a different product is already on the rejection list, and a rejection is a Tuesday afternoon. What is not caught is a code that is well-formed, unused and simply attached to the wrong object, and that one goes live.

You meet it again on the statement, where the first step in checking one is matching every line’s identifiers against your own register. A statement is the store’s memory of what you told it. It has no opinion about what you meant.

Can you fix a UPC after it has been delivered?

Not in place. Apple’s documentation is one sentence about it — “UPCs cannot be modified or used again” — and the same page files UPC, EAN and JAN together as “noneditable unique identifiers for retail products.” The correction is a takedown and a fresh delivery under a new code. That is your release week, pissed away on a box somebody filled in at one in the morning.

The reason runs deeper than one store’s policy. GS1’s rule since December 2018 is that “a GTIN allocated to a trade item SHALL NOT be reallocated to another trade item,” full stop, across every sector. The old waiting periods are gone. There is one exception and it will not be yours: a code assigned to something that was never actually produced can be reused twelve months after it is deleted from the catalogue.

And if you are about to do the takedown, do it in the right order. Getting that sequence backwards strips the recording from its playlists and loses the listener history, which is a considerably more expensive mistake than the one you set out to repair.

FAQ

Does every single and EP need its own UPC, or only albums?

Every one of them needs its own. Apple’s delivery documentation requires an individual UPC for every digital album delivered, and GS1’s rule for trade items generally is that each variation of each product requires a unique barcode. A single and the album it later appears on are two products, sold separately, and they are counted separately. If you are about to deliver a release and you are reusing a code from a previous one, stop: that is the defect this whole page is about, and it is not correctable in place.

Is a UPC the same thing as a barcode?

No, and the distinction matters when you are delivering digitally. GS1 describes the GTIN as the number found under a barcode’s black and white lines: the number is the identifier, the barcode is only a machine-readable way of carrying it. A digital release has no printed lines anywhere and still needs the number. If you have ever been told you do not need a barcode because you are not pressing physical copies, you were told something true about the lines and false about the code.

Can you reuse the UPC from a release you took down?

No. GS1’s rule since December 2018 is that a GTIN allocated to a trade item shall not be reallocated to another trade item, and Apple states separately that UPCs cannot be modified or used again. There is one narrow exception, and it is unlikely to be yours: a code assigned to an item that was never actually produced may be reused twelve months after it is deleted from the catalogue. A release that went live and came down is not that case.

Can an ISRC ever be used to identify a release?

Not as a release identifier. DDEX, whose message format your distributor’s delivery is written in, requires that any main release intended for consumers is identified by a GRid, an ICPN or a proprietary ID, and says that a company wanting to use an ISRC for a track release must send it as a proprietary ID instead. That is the standard declining to treat the code as a release identifier while still letting you carry it. If a form is asking you for a release identifier, an ISRC is not the answer to give it.

Sources

• IFPI, International Standard Recording Code (ISRC) Handbook, 4th edition, 2021 — clause A.8.4, on PDF page 17: that reuse on a compilation keeps the same ISRC, that exploitations on different releases cannot be distinguished by reference to the ISRC, and that product identifiers are outside the scope of the ISRC system.
• GS1 US, What is a GTIN? — the definition of a GTIN and of a trade item; that GTIN-12 is twelve digits and predominantly North American, and GTIN-13 thirteen digits and predominantly used elsewhere.
• GS1, What is the difference between a GS1 GTIN, a barcode, an EAN and a UPC? — that the GTIN is the number under the barcode’s lines, and that UPC and EAN are regional names for GTIN-12 and GTIN-13.
• GS1 US, How to get a UPC barcode — that each variation of each product requires a unique barcode; the $30 single GTIN with no renewal fee, and the $250 initial / $50 annual Company Prefix at ten items. Fees read 2026-08-20 and subject to change; GS1’s own GTIN Management Standard pages refuse automated reads, so nothing here is cited to them.
• GS1, Can a GTIN be re-used? — that after December 2018 a GTIN allocated to a trade item shall not be reallocated, and the twelve-month exception for an item never produced.
• DDEX, Bar codes of various lengths — the definition of ICPN and the codes it covers.
• DDEX, ERN Release Profiles, clause 7.3, rules for releases — that a main release intended for consumers is identified by a GRid, ICPN or ProprietaryId, and that an ISRC used to identify a track release must be communicated as a ProprietaryId.
• Apple, Digital packaging (music) — that every digital album requires an individual UPC upon delivery, that UPC, EAN and JAN are noneditable unique identifiers for retail products, that UPCs cannot be modified or used again, and that each song or music video requires an ISRC.
• Apple, Get Multiple Catalog Albums by UPC — the filter[upc] query parameter and that it returns albums.
• Spotify, Web API — Get Album — the album object’s external_ids, carrying upc and ean.
• Spotify, Web API — Search for Item — that the isrc filter applies to track searches and the upc filter only to album searches.
• Spotify for Artists, Glossary of music industry terms — that a label or distributor will usually generate and manage UPCs, and that obtaining your own means registering with the issuing agency in your country.

Every page cited here was read on the date at the top of this piece. Fee schedules, developer interfaces and store documentation change without notice — confirm anything operational, and any price, against the issuing body’s own pages before you act on it. None of this is legal advice.

Keeping the register

The whole problem in this piece is knowing which object a code belongs to, which is a filing question long before it is a delivery question. CatalogTracker holds releases and tracks as separate records — UPC and GRid on the release, ISRC and ISWC on the track — and searches the catalogue by any of ISRC, ISWC, UPC, GRid, ISNI or IPI, showing which identifier matched. That last part is the answer to the question this page is about: you paste in twelve digits and it tells you what kind of thing they belong to. Every change is kept with who made it and what the field said before. In development for iPhone.