Every label believes it has its catalog somewhere. Then someone asks a simple question, such as who owns the masters for this version in Canada, and three spreadsheets disagree. A single source of truth is the fix, and it is less about software than about deciding, once, where facts live.
The three-spreadsheets problem
Catalog data drifts because it is copied. A release sheet gets a version for the distributor, a version for accounting and a version the label manager keeps on their laptop. Each copy is edited for a different purpose, and within a year nobody knows which one is correct. The cost is invisible until a royalty audit, a catalog sale or a rights dispute forces a reconciliation that takes weeks.
What a system of record means
A system of record is simply the place where a fact is authoritative. If the ISRC in the catalog and the ISRC in the distributor portal disagree, the catalog wins and the portal gets corrected. Other tools may hold copies, but they are downstream. This is a policy decision first and a technical decision second: the label has to agree that one system is canonical and stop editing the others.
The entities you need to model
A usable catalog model is smaller than people expect. Most labels need the following, each linked to the others.
- Recordings: ISRC, title, version, duration, contributors and their roles.
- Releases: UPC, format, release date, tracklist, artwork, territories.
- Artists and groups: identifiers, members, contact and management details.
- Writers and publishers: IPI, PRO affiliation, publisher splits.
- Contracts: parties, term, rights granted, royalty terms, linked releases.
- Deals: what can be sold where, from when, in which formats.
Migrate in stages
Do not try to import ten years of catalog in one weekend. Start with everything releasing in the next quarter, because that data is fresh and the people who know it are available. Then move the active back catalog that still earns meaningfully. Deep catalog with no activity can wait, and some of it may never justify the effort.
Treat migration as cleaning. Every record that moves gets its identifiers checked, its contributors matched to a single profile and its contract linked. Moving dirty data into a new system just gives you a prettier version of the same problem.
- Export current spreadsheets and agree which one wins per field.
- Import upcoming releases first and fix them completely.
- Import active catalog, matching artists and writers to existing profiles.
- Link contracts to releases and confirm splits against the signed terms.
- Switch downstream tools to read from the new system and stop editing the old files.
Keep it clean
The new system will decay exactly like the old spreadsheets unless someone owns data quality. Give one person the authority to merge duplicate artists, reject incomplete releases and set naming rules. Make incompleteness visible with checks that flag missing identifiers or unlinked contracts. Data that is inspected stays clean; data that is merely stored does not.
What becomes easy
With one clean catalog, royalty calculations stop needing manual reconciliation, licensing and sync requests can be answered in minutes, catalog valuations become a report instead of a project, and changing distributor means exporting once rather than rebuilding everything. Most importantly, questions about ownership get one answer.