Works, recordings, releases, and who owns what share of each — in one repertoire view that your royalty calculations actually run on. Not a metadata archive beside the money; the foundation under it.
Last updated: August 25, 2026
A catalog lives in layers — works, recordings, releases, and the ownership structures that connect them to people who get paid. Qlero tracks all of it centrally, so "who owns what share of which recording on which release" is a lookup, not an investigation across tabs. That single view is what teams describe wanting when they ask for a clean overview they can actually work.
Every royalty calculation starts by matching a sales line to a track and its contracts. When catalog metadata is inconsistent — duplicate recordings, conflicting dates, identifiers that drifted across years of different staff entering data — those mismatches surface as unmatched income and disputed statements. Managing the catalog and calculating the royalties in the same system means a fix in one place propagates to every statement that depends on it.
Catalogs at scale arrive from delivery systems, not from manual entry. Qlero supports DDEX catalog ingestion on every tier, so repertoire data flows in from external systems in the industry's standard format — and the import builder handles CSV and Excel for everything that doesn't.
Catalog entries in Qlero link to tree-structured deal models: the splits, advances, and recoupment terms that govern each release and recording. Add a release, and the applicable deal terms follow from the structure — instead of being re-declared in a spreadsheet and drifting out of sync with the contract.
Teams with years of accumulated catalog data consistently want to migrate at the cleanest possible point — not drag historical inconsistencies into a new system. A catalog migration into Qlero is a natural forcing function: repertoire is reviewed as it's structured, and the workflow of linking recordings, releases, and deals surfaces gaps that spreadsheets kept hidden.
The catalog is step one of the full royalty chain — see how Qlero takes it from repertoire to published statements, or start with the 2026 buyer's guide if you're evaluating platforms. Terms along the way are defined in the glossary.
Software that maintains a structured record of a rights holder's repertoire — works, recordings, and releases — together with the ownership shares and deal terms that determine who gets paid for each. In royalty-focused platforms like Qlero, the catalog is the foundation the royalty calculation runs on: sales lines are matched to catalog entries, and catalog entries are linked to contracts.
Because royalty errors are usually catalog errors in disguise: a sales line that can't match a track, a recording with conflicting ownership data, an identifier that changed between systems. When catalog and calculation live together, a metadata fix propagates to every affected statement — instead of being patched separately in a royalty spreadsheet each period.
Yes — DDEX catalog ingestion is included on every Qlero tier, from Lite up. Repertoire can also be imported from CSV or Excel through the same import builder used for sales data, with column mappings saved as reusable templates.
Inconsistent historical data is one of the most common situations labels bring to a migration — years of entries from different staff in different formats. The structured migration into Qlero reviews repertoire as it is imported and linked to deals, which surfaces duplicates and gaps. To walk through your specific catalog, book a demo at qlero.io/book.
See how Qlero can support your royalty workflow, from catalog and contracts to income ingestion and reporting.
