How to Structure a Music Catalog Data Model
By Qlero Team
Separate works, recordings, releases, parties and agreements in a music catalog. Test the relationships with a cover-song example and documented Qlero workflows.
A music catalog data model should distinguish the work, the recording, the release, the people and organizations involved, and the agreements that govern the accounting. Putting all of them in one row called “song” makes it harder to answer a basic question: which rights and terms does this income relate to?
This guide proposes a structure for keeping those relationships explicit. It is a design checklist, not a claim that one database layout guarantees accurate royalties or that every platform implements the same model.
Start with the composition and the recording
The composition and its recorded performance are not interchangeable. The U.S. Copyright Office distinguishes the musical composition from the sound recording and explains that copyright in one does not substitute for copyright in the other. That is a useful foundation for the model, not advice about who owns a particular catalog.
Keep separate records for the work and the recording, then store their relationship. An ISWC identifies a work, not a recording, and does not encode ownership shares. See the ISWC agency's explanation. Store the confirmed code alongside the work; do not manufacture one to satisfy an internal database requirement.
A work can have several recordings. The reverse relationship also matters: DDEX's work-resource link definition allows a recording to refer to more than one musical work. A model restricted to one work per recording cannot represent every case. How those relationships must be submitted to a particular registry is a separate question.
For the identifier rules rather than the database design, see ISWC vs. ISRC.
Six parts of a practical catalog model
The following is a recommended logical structure, not a prescribed set of software tables. DDEX's conceptual approach separately describes works, resources, releases, parties, roles and business relationships. Your internal system should make the distinctions your reporting and agreements require.
1. Works
Store the composition's internal reference, titles, confirmed external identifiers and links to its writers and relevant rights records. Use a separate relationship for each recording associated with the work. An unresolved relationship should remain marked for review rather than silently becoming an accepted match.
2. Recordings
Store the recording identity, ISRC, version description and contributor relationships. A new performance is not merely a new spelling of the original recording's title. Conversely, do not duplicate a recording simply because it appears on another release.
Keep identity separate from ownership history. IFPI's ISRC FAQ says an existing ISRC remains with a recording when ownership changes.
3. Releases and products
Represent the tracklist as links to recordings, including their order, rather than copied recording records. The same recording can then appear on a single, an album and a compilation.
Terminology matters at an exchange boundary. DDEX distinguishes a release—a bundle of resources—from a product through which it is made available. IFPI describes UPC/EAN barcodes as product identifiers, distinct from recording-level ISRCs. Map your internal release and product records to the recipient's requirements; do not use an ISRC as the identifier for an entire album.
4. Parties and roles
Give each resolved person or organization a stable internal reference. Attach a role to the relevant work, recording or agreement instead of assuming that someone is always only a writer, performer or payee.
Store external identifiers with their scheme and source. DDEX's proprietary-identifier guidance uses a namespace to identify the organization controlling a proprietary identifier. As an internal design precaution, do not merge two parties merely because their names—or unqualified numeric IDs—match.
5. Rights, claims and shares
Avoid one generic percentage field for everything. DDEX distinguishes collection shares from other work-share concepts and scopes rights information by matters such as rights type, territory and time. A writer's share, a collection mandate and a recording royalty rate answer different questions.
For each share or claim, record what the percentage measures, its scope, its source and whether it is confirmed or disputed. Keep contributor credits separate from the evidence for an ownership or payment entitlement. A credit alone should not become a royalty instruction.
6. Agreements and accounting terms
Link the relevant repertoire and parties to an agreement. Store the applicable royalty base, rates, costs, advances and other terms in that agreement's accounting configuration, with a reference to the supporting document.
This is a modeling recommendation, not an interpretation of a contract. If the scope of a right, amendment or recoupment provision is unclear, obtain qualified review before configuring it. A party-level default is not enough to explain two different deals with the same person.
Worked example: one composition, two recordings
Consider an explicitly fictional case. Two writers own an unchanged composition in agreed shares of 60% and 40%, within the same defined scope. It has one confirmed work identity. Artist A records it; Label A owns that recording under the assumptions of this example. It appears on an album alongside nine other tracks.
A year later, Artist B records a straightforward new performance of that unchanged composition. Label B owns the second recording, which appears on a separate single. Assume no arrangement, lyric adaptation, ownership transfer or other change to the composition in this scenario.
The model should show:
- One work record, with the two assumed writer shares: 60% + 40% = 100%.
- Two distinct recording records for this work, each with its own ISRC and contributor links.
- Two release records: the first links to the original recording and nine other tracks; the second links to the cover recording.
- Separate recording-rights and agreement records for the two labels.
The album's other nine tracks still need their own catalog relationships; the example focuses only on the shared composition. Do not duplicate its 60/40 ownership records as a second independently owned work just because another recording exists. Equally, do not copy those percentages into either label's recording royalty contracts.
There is no revenue or bank-payment calculation here. The example tests relationships, not licensing clearance, a market-standard split or a prediction of what either writer will receive.
Model versions without inventing new rights
A new remix and a routine remaster are not the same identifier event. IFPI lists remixes and edits among changes requiring a new ISRC, while a remaster generally retains the existing code unless significant new creative input justifies a new one. “Remaster” in a title is not sufficient evidence of a new recording identity.
Changes to the composition need their own assessment. The ISWC agency's eligibility guidance calls for separate work identifiers for arrangements, lyric adaptations and translations, with links to the original in the metadata. Do not infer from “cover” that every underlying work and share must be unchanged.
Keep the original relationship, version description and supporting evidence visible. Whether a new contributor has ownership or royalty rights must be established separately; the version label does not decide it.
Controls to add before relying on the model
Use these six checks as recommended acceptance tests:
- Separate work and recording identity. Can the system represent both several recordings of one work and a recording associated with several works?
- Reuse recording records across releases. Does adding a compilation create a tracklist link rather than an unnecessary new recording?
- Resolve parties deliberately. Can name variants be investigated without silently merging different people?
- Label every percentage. Can a reviewer distinguish ownership, collection scope, participation and royalty rate?
- Preserve version evidence. Can the reviewer see why a new or existing identifier was used?
- Trace the applicable agreement. Can two contracts with one party retain different terms and repertoire assignments?
Failure to represent those distinctions can produce ambiguous records or incorrect configuration. It does not establish that a payment has already been lost. Likewise, a clean structure does not validate source reports, resolve disputed rights or prove a bank transfer.
Do not reject a spreadsheet solely because it contains rows and columns. Evaluate the actual identifiers, linked records, validation, change controls and review process. The control questions apply whether the implementation is a workbook, an internal database or purchased software.
What Qlero documents—and what to demonstrate
Qlero's track and release guide documents separate tracks and releases, with a track able to appear on multiple releases. Creating them requires Repertoire write access. A track needs a name, artist and ISRC; a release needs a name, artist and a barcode or catalog number, or both. Identifier uniqueness is scoped to the record company.
The participation guide documents separate track-level and release-level contract assignments. Attaching a contract to a release does not automatically attach it to its tracks. Sales and Costs participation are separate, changes require saving, and the sections are not forced to total 100%. Editing requires Repertoire write access.
Participation is not itself the final royalty rate. The calculation guide applies the royalty base, participation share and adjusted rate separately. It also limits participation overrides, deductions, escalations and the PPD base to Pro and Enterprise. Calculated royalties are not the closing balance or cash paid.
Qlero's terms guide distinguishes shared terms from contract-only terms. Editing a shared term affects every linked contract; creating and linking terms requires Agreements write access.
These are documented recording-accounting workflows, not proof that Qlero implements every work-recording-party relationship proposed above. Ask for a demonstration of your publishing relationships, scoped rights, version history and contract exceptions. Missing documentation is not proof a feature is absent, and this guide is not a hands-on product test.
Frequently asked questions
Why separate a composition from its recording?
They are different assets. Keep their identities linked without using one record as a substitute for both. Their associated rights and accounting information must also remain distinguishable.
Does every remix need its own recording record?
Represent a distinct remix separately and follow the applicable ISRC rules. Preserve its link to the source material, then confirm the actual contributor and agreement changes rather than assuming a new split.
How do release and recording identifiers differ?
A product code identifies the packaged offering; an ISRC identifies a recording within it. A tracklist links the two levels. Check the recipient's release and product requirements when exchanging data.
Why keep a stable party record?
It lets you link a resolved identity to multiple roles without repeatedly copying it. Keep uncertain matches under review: the same displayed name does not establish the same person or company.
Does a cover need a new work record?
The unchanged-work example can retain the existing work identity. An arrangement, translation or adaptation requires separate assessment under the work-identification rules. The recording still has its own identity.
Should terms belong to a party or an agreement?
For this proposed model, attach them to the relevant agreement and its scope. Reusable terms can be helpful, provided changes to shared terms are intentional and their affected agreements are visible.
Test the relationships, not just the fields
A useful catalog model lets a reviewer trace from a recording or release to the relevant work, parties, rights evidence and agreement. Test those links with the cover example and your own exceptions before relying on the resulting accounting.
Book a Qlero demo to walk through a representative catalog and confirm which relationships and contract workflows your setup supports.