Assign ISRC and UPC Codes Before Release Day

Assign your ISRC and UPC codes before you submit to your distributor, not on release day. An ISRC identifies a single recording. A UPC identifies a release (a single, EP, or album). Every stream, sale, and radio play gets counted against these codes, which means they are how you get paid and how you know what is working. Assign them late or reuse them wrong and your data fractures: the same song shows up as two recordings, or a re-release overwrites the history of the original. The codes are cheap and boring. Getting them wrong is neither.

What is the difference between an ISRC and a UPC?

An ISRC (International Standard Recording Code) is stamped on one specific recording. The original mix, the radio edit, and the acoustic version are three different recordings, so they get three different ISRCs. Reuse the same ISRC across different masters and you have merged the analytics of two songs into one meaningless pile.

A UPC (Universal Product Code, the barcode) identifies the product you are releasing. Put the same track on a single and later on an album, and the track keeps its ISRC but the single and the album each get their own UPC. This is the same recording-versus-release distinction that runs through everything in music rights, and it trips people up the same way the master versus composition split does. Keep the layers straight and your reporting stays clean.

Where do the codes come from?

Two paths. Most distributors will auto-assign ISRCs and a UPC when you upload, which is fine for a lot of independent artists. Or you get your own ISRC registrant code and assign them yourself, which gives you control and consistency across every distributor you ever use.

I lean toward owning your own codes if you plan to release regularly, for the same reason I lean toward owning infrastructure generally: you do not want your identifiers tied to a vendor you might leave. If you switch distributors and let them auto-assign, you can end up with a mess of codes across platforms. Owning the registrant code keeps your catalog coherent. This is the music version of the argument I make about why owning your own stack matters, applied to identifiers instead of servers.

Why does assigning them late break things?

Because late assignment happens under pressure, and pressure produces mistakes. On release week you are chasing artwork approval, final masters, and a dozen other threads. Bolting on the codes at the end is how you reuse an ISRC by accident, or submit a UPC that clashes with a prior release. Distributors have lead times, and a code error caught at submission can push your release date. This is one of the quiet mistakes coordinating a music release, treating identifiers as a formality instead of the backbone of your reporting.

Assign the codes when you assign everything else: at the point the track is finalized, alongside the metadata. Bad metadata and mismatched codes are the same disease, and I have already made the case that metadata is the money. The codes are just the most machine-readable part of that metadata.

How do you keep codes organized across a catalog?

Keep a registry. Every recording maps to one ISRC, forever. Every release maps to one UPC. When you make a new version, it gets a new ISRC and you log it. When you bundle tracks into a new release, it gets a new UPC and you log that. The registry lives with the tracks, not in a spreadsheet you lose.

The failure mode is scale. One single is easy to keep straight in your head. A catalog of forty recordings across singles, EPs, remixes, and reissues is not, and that is exactly when the code collisions start. Independent artists especially need this discipline because there is no label back office doing it for them, which is the whole premise behind running label operations without a label. Keep every code attached to its recording in one place. Set your catalog up in Track Pitch so the codes travel with the audio, and your streaming reports actually mean something.