Building a catalogue spreadsheet: the fields that matter

65 · 2026-10-03 · 19 min read · Español

A catalogue spreadsheet is three tables, not one — songs, recordings and releases — and the fields that matter in each are the ones another system will ask you for or pay you on: the identifier that system issued, the ownership share somebody signed for, and, for every registration, the date it was made and the reference it came back with. Everything else — genre, artwork, stream counts, royalty figures — belongs to a store, a dashboard or a statement, and copying it into the register makes the register wrong. The spreadsheet is an index of where the truth is kept, not the truth. Every cell in it either names the system that issued the value or the document that proves it.

• The ISRC Handbook’s own annex says musical works and recordings are “distinct categories of entity” identified by distinct categories of identifier, that one work may be recorded many times, and that a recording is independent of the product it sits on. That is three tables: songs keyed by ISWC, recordings keyed by ISRC, releases keyed by UPC, with each recording row naming its song and each release row listing its recordings.
• Identifiers are copied from the system that issued them and never typed from memory: the ISRC from whoever assigned it, the ISWC from the society that allocated it, the IPI from the PRO, the UPC from the distributor or GS1. Apple’s specification marks the track ISRC and the album UPC “cannot be updated”, so a wrong one in the register is a wrong one for the life of the release.
• Ownership columns hold a claim; the paper column holds the proof. For every master share and every writer share, the register names the document, where it is filed and the date it was signed. The Handbook’s clause A.14.6: assigning an ISRC “does not affect ownership in any way”.
• Registration columns are one per register that pays — the PRO, The MLC and SoundExchange; SOCAN, CMRRA and Re:Sound in Canada — each holding the date registered and the reference the register handed back, never a tick. SoundExchange requires the ISRC, artist and title to include a recording and also collects the country of fixation and the date of first release; The MLC’s form reads writers by IPI, roles, publisher and a collection share.
• What stays out: anything a store can change after delivery, anything a dashboard regenerates, and any amount of money. Those live in the store, the dashboard and the statement, and a copy in the register is wrong by the next morning.

One row per what?

One row per recording, keyed by ISRC, with songs and releases in tables of their own: a song has many recordings, and a recording sits on many releases. That is not a preference. It is what the standard says the things are.

The ISRC Handbook spends an annex on it: “Musical works (songs) and recordings are distinct categories of entity, and they are therefore identified by distinct categories of identifier.” Then the sentence that decides the shape of your sheet: “A musical work may be recorded once or many times as different recordings, and each distinct recording would have its distinct ISRC.” And the recording itself is “independent of the product in which the recording is included.” The annex draws it as a figure with three boxes and two arrows — a musical work is performed in a recording, a recording is included in a product. Three boxes. Three tables. Not a tab per year, not a tab per album, not one sheet called CATALOGUE FINAL v3.

Here is what the one-table sheet does. One row per song, and the album cut, the radio edit and the remix are three recordings with three ISRCs and one cell, so the cell holds whichever code somebody typed last. One row per release, and a recording that is on the album and the compilation is two rows that disagree the first time one of them is corrected. One row per recording — the only shape the standard supports — and a single is one UPC listing one ISRC, the album is another UPC listing twelve, and the recording that appears on both appears once.

The join is two columns. A recording row carries the ISWC of the song it performs or, until the society has issued one, the song’s title and its writers, which is what the ISWC will be assigned against. A release row lists the ISRCs it contains, in track order. That is the whole of the structure, and it is what lets a stranger answer the three questions a catalogue exists to answer — what is this, whose is it, where does it earn — without asking you. The four codes identify four different kinds of thing; the sheet is three of those kinds, each in its own table, and the fourth — the people — is a column in two of them.

Which identifier columns matter, and where does each value come from?

Six — ISRC, ISWC, UPC, IPI, the society’s work number and the distributor’s reference — each copied from the system that issued it, never typed from memory. One per recording, one per song, one per release, one per person, one per society and one per distributor. The rule is the column. Which system issued it is the thing to write beside every one.

Two of those are permanent in the strongest sense there is. Apple’s music specification annotates the track ISRC “required; cannot be updated” and the album UPC “cannot be updated”, and its rules for metadata updates say it a third time: “Updates to the following tags will be ignored,” and the list is the UPC, the ISRC and the GRid. A store will change a title, a genre and an artist name on request. It will not change those two, which is why they are the two the register has to hold correctly before anything is delivered and why a wrong ISRC on a live track is a procedure and not an edit.

The ISRC column has a companion column, and it is the one most sheets are missing: whose registrant code the ISRC was assigned under. The Handbook’s clause 3.1 says an ISRC “is assigned by the rights owner of the recording or an authorised representative,” and the representative is usually a distributor assigning under its own prefix. Whether the code is yours and what happens to the prefix when you leave are two pages of their own; the register’s job is the one column that lets you answer either question in five years. Blank is a legal value in this column and in the ISRC column beside it. An invented code is not. Two codes on one recording and one code on two recordings are both what a filled-in blank turns into.

The ISWC column is the one that teaches the rule, because it arrives rather than being fetched. The ISWC agency is exact: “An ISWC code is only allocated by the local Registration Agency when all of the creators of the work have been uniquely identified,” and the identification it means is “the IPI Name Numbers and Roles of all creators included in the work”, with at least one of them affiliated to the agency. So a song whose co-writer has never joined a society has no ISWC, cannot be given one, and the cell stays empty until the day it is issued. Mendeleev left gaps in his table for elements nobody had found yet. Your ISWC column gets the same courtesy.

The IPI is the people column, and which of a person’s IPI numbers goes in it is the question that page exists to answer; the register holds one per writer and one per publisher, copied from the PRO. The society work number is the column beside the ISWC that nobody keeps and every society reads. SOCAN’s own page on its numbers explains why there are two: a work registered with SOCAN “is first assigned a temporary code, which is replaced by the ISWC code a few weeks later,” and separately its Work Number “is the work registration number SOCAN shares on earnings statements, Member Portal catalogues, and the Public Repertoire site,” which “is a SOCAN-specific number, while the ISWC is shared internationally between PROs.” One column finds the registration; the other identifies the song. And the UPC is the release’s, issued by GS1 as a code for a trade item — “unique to each of your products” in GS1’s words — or by the distributor from a block it holds, and copied from wherever the release was delivered from.

Which ownership columns matter?

Per recording, the master’s owners and shares; per song, each writer’s and publisher’s share; and beside each, the document that proves it, its location and date. The share is the claim. The paper column is the proof, and it is the column a manager reads first.

The standard is blunt about what the codes are not. Clause A.14.6: “Assignment of an ISRC does not affect ownership in any way and the use of a particular Registrant code in an ISRC does not imply that the assigning party owns the recording, or that royalties are to be paid to them.” Every identifier column on this page is a label on the thing. None of them says whose it is, and neither does a percentage you typed. A 50 in a cell is a belief with a font.

So the ownership half of the recordings table is two columns and a pointer: the master’s owners and their shares, and the document that makes those shares true — the signed writing that transferred it, the producer agreement if points were promised, the assignment for every player who was paid a fee. The songs table is the same shape for the other copyright, because a song is two properties and the sheet has to hold both: each writer’s share on the writer-share convention that totals 100, each publisher, and the split sheet that carries the signatures — which is what makes the numbers bind, and the only thing on this page that does.

The paper column is three columns pretending to be one: the document’s type, its location, and its execution date. Type, because a catalogue of any age carries split sheets, producer agreements, assignments, sample clearances, cover licences and a distribution agreement, and a stranger needs to know which kind they are looking for. Location, because a signed PDF that only you can find is a signed PDF that does not exist on the Monday you are not there. And the date, because a grant can be taken back decades later and the window counts from the day it was executed, which is a fact nobody remembers and every register should hold. The ℗ and © years on each release row are the ownership claim as you published it; what goes on those lines is its own page, and the register’s job is to hold what you put there, so that the claim on the store and the claim on the paper can be compared.

Which registration columns matter?

One column per register that pays — PRO, The MLC, SoundExchange; SOCAN, CMRRA, Re:Sound in Canada — holding the date registered and the reference it handed back. Never a tick. A tick is what somebody believed once; a date says when, and a reference lets the next person find it.

The two American registers publish exactly which columns they read, which settles what the register has to hold. The MLC’s registration guide walks its form step by step: “Only the Work Title field is required”; writers are searched “by the writer’s name or their IPI number,” and “At least one Composer/Author or Composer writer role is required”; a publisher and a Collection Share that “must be between 0.01% and 100%”; and an optional recordings step — title and artist — because “Recording information entered here helps with the automated matching process.” That is the songs table read aloud: title, writers with IPI and role, publisher, share, and the recordings the song was performed in. The MLC does not require any identifier to register a work and says including them is “strongly recommended,” which is the polite version of the copy rule above.

SoundExchange reads the recordings table, and it names its columns too: “To include a recording in our database we require certain basic points of metadata, including the recording’s ISRC, the artist and track title, but we also collect information that can help with international royalty collection such as the ‘country of fixation’ and ‘date of first release’.” Two columns most sheets do not carry — where the recording was made, and when it first came out — are therefore recordings-table columns, because a register that pays asks for them. It also restates the one-row rule from its side: “A single ISRC should only be used for one recording, and each distinct recording should only have one ISRC.”

What each register pays and how to get into it are not this page’s. The map of which register holds which stream is one page; the PRO, SoundExchange, The MLC and the Canadian trio are each their own. The register’s job is narrower: for every song, the date and the reference at every register that pays on songs; for every recording, the same at every register that pays on recordings. On the Canadian side that is one more column than it looks, because a self-released artist is both the performer and the maker of the recording and registers as each. Where a column is empty, the empty cell is the to-do list, which is what the audit turns it into once a year.

What does not belong in the spreadsheet?

Anything a store can change after delivery, anything a dashboard regenerates, and any amount of money. Genre, artwork, lyrics, stream counts and royalty figures live in the store, the dashboard and the statement, and a copy of any of them in the register is wrong by the next morning.

The test for the first group is already printed. Apple grades every delivery field by whether it can be updated, and the fields it marks changeable — label name, territory, dates, language, title, version, genres, artists and roles — are the store’s fields: the store displays them, the store can be asked to change them, and the version in the store is the version that is true. A register that copies them holds a second version that will be wrong the first time a redelivery moves the first. The two fields Apple marks permanent are the two the register already holds, and three of the changeable ones stay in the register for reasons of their own — the ISWC because a society issued it, the ℗ and © lines because you published them as a claim. Everything else in that form is the store’s to keep. A stream count is the purest case: it is a number the dashboard regenerates every day and the register cannot. Copy it in and the register is wrong by breakfast.

The second group is money, and the reason is the key. A catalogue register is keyed by recording; a royalty statement is keyed by period and payer, and reading one is a job with its own order. Put an earnings column on a recording row and you have two documents wearing one key, and the day the next statement lands, the row is stale and the statement is the only thing that is right. A dashboard rebuilds that number on its own and charges nothing for it. Copy it into the register and you have taken the job off the dashboard and given it to yourself, and you will spend the rest of your career pissing around with a figure the dashboard already has.

The opposite failure is worth one sentence, because it is the common one. A distributor’s dashboard is not a register: it holds your identifiers and nothing you signed, and it holds them for as long as you are a customer. The register holds what is permanent or what you signed. The store holds what is displayed. The statement holds what was paid. Three documents, three keys, and the only one that is yours to keep is the first.

How do you keep it true?

A last-verified date on every row, one file with one owner, an export outside one person’s inbox, and a check against the registers every year. And before anyone else has to read it. The register does not check itself; the date column is what tells you how long it has been since anyone did.

The check is the audit, and this page is the thing it audits: every box on that list is a column here compared against what a store or a register actually holds. For the identifiers that means reading the code back off the store and matching it to the cell; for the registrations it means opening the portal and matching the reference; for the paper it means opening the folder and finding the file. A row that passed a year ago passed a year ago. Write the date, not the tick — the same rule as the registration columns, for the same reason.

Then export it and put the export where a second person can reach it, because a register that has to survive your next four laptops has to survive you being busy, and a copy in one inbox is not a copy. This is the document a manager asks for on the first day, and the columns above are the questions they will ask, in the order they will ask them — what is this, whose is it, where does it earn, and where is the paper. What else that first day needs is a page of its own. This one stops at the shape of the thing they are handed: three tables, one rule, and every cell naming where the truth is kept.

FAQ

What goes in the ISRC column for a recording that has no ISRC yet?

Nothing; leave the cell empty and record, in the column beside it, who will assign the code — your distributor under its registrant code, or you under your own. An ISRC is assigned once, by the rights owner or their representative, and a code invented to fill a cell is a wrong code on a released track.

Does the spreadsheet prove I own anything?

No; a row that says you own 50 per cent of a song is a claim, and the signed split sheet it points at is the proof. The ISRC standard says in its own text that assigning a code does not affect ownership in any way, and the same is true of every cell in a register.

Should the spreadsheet hold royalty amounts?

No; a royalty figure belongs to a statement, which is a different table with a different key — period and payer rather than recording — and copying figures from statements into the catalogue register produces a document that is wrong the day the next statement arrives.

What is the difference between a SOCAN work number and an ISWC?

A SOCAN work number is SOCAN’s own reference for a registration, shown on its statements and in its portal; an ISWC is the international code for the musical work, assigned once every writer has an IPI and shared between societies. Keep both: the first finds the registration, the second identifies the song.

Sources

• IFPI, ISRC Handbook, 4th edition (2021, PDF) — Annex B and B.1, page 25: works and recordings as distinct categories of entity, one work recorded many times, a recording independent of its product, and the figure that draws work, recording and product; clause 3.1, page 5: assigned by the rights owner or an authorised representative; clause A.14.6, page 24: assignment does not affect ownership.
• Apple, Apple Music Specification — the track ISRC “required; cannot be updated”, the album UPC “cannot be updated”, and the metadata-updates section listing the tags whose updates are ignored.
• ISWC International Agency, How to get an ISWC — allocated only when all creators have been uniquely identified; assigned only by the registration agency.
• ISWC International Agency, ISWC for Creators and Publishers — the two conditions: complete metadata including the IPI Name Numbers and Roles of all creators, and at least one creator affiliated to the agency.
• The MLC Help Center, How to register works with The MLC — the form step by step: title required, writers by name or IPI with a role, publisher and collection share, optional recordings for matching.
• The MLC, Know Your Identifiers — no identifier required to register, all of them strongly recommended.
• SoundExchange, All About ISRCs (2023-12-21) — the metadata required to include a recording, the country of fixation and date of first release, and one ISRC per recording.
• SOCAN Magazine, Important Codes & Numbers (2025-11-20) — the temporary code replaced by an ISWC, the SOCAN-specific Work Number, and the IPI assigned by the PRO.
• GS1 US, What is a GTIN? — a key that identifies a trade item, unique to each product.

Every page cited here was read on the date at the top of this piece. The ISRC Handbook is a PDF and was read through a local decoder, because this machine has none of the usual PDF tools; every passage quoted from it was checked against the page’s own footer and the clause numbers this site has cited from the same document before. The columns are written against US and Canadian practice — the registers named are those two countries’ — and nothing here is legal advice: the sheet holds the claims, the documents it points at are what a lawyer reads.

Keeping the register

The three tables above are what CatalogTracker is built around: releases with their UPC, dates, territories and ℗ and © lines; tracks with ISRC, ISWC and version; the people as parties with an IPI, an ISNI and a PRO beside each name; per-track master and publishing splits that must total 100; the agreement uploaded against the recordings it covers, with a content hash and a warning when the splits or the parties changed after it was signed; and a history of who changed what. It holds no registration date and no reference from any collector — those columns stay yours to keep — and it exports the catalogue as JSON in full and as a thirteen-column CSV that the app itself describes as lossy, which is the honest word for what a flat sheet does to three tables. In development for iPhone.