How one stream becomes a payment, and where the chain quietly breaks

A stream is not a payment. It is the first row in a chain of database joins, and every join in that chain is made on an identifier you supplied. When one of those identifiers is wrong, nothing rejects it and nobody writes to you. The play is still counted, the money is still collected, and it stops moving at the join that failed.

This is that chain, hop by hop: which identifier each part reads, what a distributor-issued ISRC actually gives you and what you keep when you leave, and why the expensive failures are the ones that let the release go live.

The three identifiers, and who reads which

Three identifiers run the recorded-music supply chain. Confusing them is the commonest cause of unmatched royalties, and each one is read by a different part of the chain.

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 a song and your live version of the same song are two recordings and therefore two ISRCs. Read by: streaming services matching a play, distributors matching a report line to your catalogue, and neighbouring-rights societies matching broadcast and public-performance use.

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. 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. Read by: societies and mechanical licensing bodies routing money to writers and publishers.

UPC/EAN identifies the release. A GS1 Global Trade Item Number — the same class of product code that identifies a bottle of shampoo. UPC-A is 12 digits, EAN-13 is 13. It names the album, EP or single as a commercial product. A three-track EP has one UPC and three ISRCs. Read by: product-level retail and reporting, and by you when you try to reconcile a statement against a release.

The ISRC is the recording, the ISWC is the song, and the UPC is the box you sold them in. The money splits along exactly those three lines: recording revenue on ISRC, publishing revenue on ISWC and on the ISRC-to-ISWC links held in society databases, product-level reporting on UPC.

The six hops, and the identifier each one reads

Here is one play, from a listener's phone to money in an account.

Two things about this table are worth saying out loud.

Hop 2 is where the amount is decided, and it is not a rate. Recording-side money is calculated as a share of pooled revenue. 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. No service publishes a per-country payout rate either.

Hop 4 is a separate pipeline with a separate schedule and separate money. Publishing income does not arrive because the recording matched. It arrives because the ISRC-to-ISWC link exists in a society database. Break that link and the recording pays out perfectly while the writer's side sits unmatched.

What a distributor-issued ISRC actually is

An ISRC identifies a recording, not a business relationship. The code is not a licence and grants your distributor nothing.

Distributor-issued codes 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. A code invented by a service with no allocation is not an ISRC. It is a twelve-character string that will collide with somebody's real code.

The ISRC is 12 characters in four fields: two 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 — the Handbook says so at §5. There is no check digit. The country code plus registrant code form the prefix, and the prefix is allocated by a national ISRC agency to a specific registrant.

That last sentence is the whole issue.

What you keep when you leave, and what you don't

Split it in two, because the answer is different for each half.

The twelve-character codes: you keep them, and you must. When you change distributor your ISRCs go with the recordings. This follows from Handbook §4.6 — an unchanged recording that is sold or licensed keeps its ISRC — and from the standing ban at §4.3 on assigning a second ISRC to a recording that has not materially changed. Those codes stay attached to those masters permanently.

The prefix: you do not keep it. If your distributor issued you QZ-ES6-25-00013, then QZES6 is the distributor's registrant code, not yours. You keep using that exact twelve-character ISRC on that recording forever. 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. A catalogue with duplicated designation codes is.

The registrant controls designation codes within each year — up to 100,000 per prefix per year across 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" (Handbook §3.3.4).

When to apply for 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 from the US ISRC Agency: 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." Assigning codes for other people's recordings needs manager status, not an 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.

The failure modes, and what each one costs

These are the ones that actually happen, with the hop each one breaks.

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. A neighbouring-rights society receives play data for both and cannot tell them apart; payments merge into one line and are 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. Usual cause: a spreadsheet copy-paste, or a template row nobody updated. Breaks hops 1, 3 and 5 at once.

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, and none of it follows. To the industry, a brand-new recording just appeared with zero history. Usual cause: a distributor onboarding form that auto-generates codes with the "I already have an ISRC" field left blank. Always fill that field. This is the most common self-inflicted wound in catalogue migration.

A 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, in which case the 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 outright. 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." Do that in your own spreadsheets too.

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. Break the audio-to-metadata correspondence and every step breaks at once.

Why a broken identifier produces silence, not an error

There are two structural reasons the chain fails quietly, and they compound.

The first is that a join has no opinion. Every hop above is a database join: take an identifier from a report line, look for it in a catalogue, attach money to the match. A join that finds nothing does not raise an error. It returns nothing. A reported ISRC that is not in your distributor's catalogue never reaches your statement — it sits unallocated. Nothing in the mechanism is designed to tell you that a line went missing, because from the system's point of view no line went missing; there simply was no match to make.

The second is that the ISRC cannot self-check. A UPC has a check digit and an ISWC has a check digit. An ISRC does not — nothing in the specification provides for one. So a single transposed character produces another perfectly well-formed ISRC that belongs to somebody else's recording, and it passes every validator. All you can check mechanically is the shape: two letters, three alphanumerics, two digits, five digits, a registered country code, a plausible year. 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.

Put together: the wrong-but-valid identifier is accepted at delivery, the join it breaks fails silently, and the only visible symptom is a number that is smaller than it should have been — which is indistinguishable from a quiet month.

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

What to do before your next delivery

The discipline is unglamorous and takes about an hour per release.

1. Keep one authoritative sheet you control: track title, version, ISRC, ISWC, writer splits, release UPC. Not a distributor dashboard — your own file. Format the identifier columns as text before pasting anything into them.
2. Assign ISRCs before delivery, not during. If you already have a code for a recording, put it in the form. If you are unsure whether a version needs a new one, the rules for remixes, edits, live takes and remasters are set out at /blog/isrc-when-you-need-a-new-one/.
3. Verify every UPC check digit, and confirm the identifiers embedded in your audio match the sheet, character for character, before anything is delivered.
4. Register recordings and works with the relevant societies using the same codes you delivered. That is what builds the ISRC-to-ISWC link at hop 4.

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.

Mazufa's ISRC and UPC/EAN checker is free at /isrc-upc-checker; it validates ISRC structure and UPC/EAN check digits and runs entirely in your own browser. It cannot tell you an ISRC is your ISRC — nothing can — but it will catch a malformed code and a bad check digit before delivery rather than after.

Sources

• IFPI, ISRC Structure (country code, registrant code, year of reference, designation code) — https://isrc.ifpi.org/isrc-standard/isrc-structure
• IFPI, International Standard Recording Code (ISRC) Handbook (§3.3.4 designation-code ranges; §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) — https://www.ifpi.org/wp-content/uploads/2021/02/ISRC_Handbook.pdf
• 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 (approved managers; risk of collision from unauthorised code issuers; prefixes allocated in sequence and not alterable; rights-owner prefixes used only for owned recordings) — https://usisrc.org/how-it-works/
• 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
• International Standard Musical Work Code, Wikipedia (ISWC format T-123.456.789-C) — https://en.wikipedia.org/wiki/International_Standard_Musical_Work_Code