Music Rights Management

Part of the worlds-biggest-software-project initiative.

A community-built platform for tracking composition and master recording rights, calculating royalty splits, and paying rights holders. (Source is open to read and to build on; a licence has not been settled yet — see Licence.)

Music Rights Management is a mid-market rights administration platform built for independent labels, music publishers, and artist managers. It unifies catalog metadata, ownership splits, PRO registration, royalty statement ingestion, and payment calculation into a single system -- replacing the patchwork of spreadsheets, disconnected SaaS tools, and manual processes that dominate the independent music sector today.

Why Music Rights Management?

Enterprise tools are priced out of reach. Existing platforms like DISCO and Reprtoir target mid-to-large operations with commercial SaaS pricing, leaving smaller independents and self-publishing songwriters without affordable, full-featured tooling.
No single tool covers the full workflow. DISCO excels at catalog marketing but has basic PRO registration. Reprtoir handles publishing administration well but lacks sync licensing and label workflows. Stem automates revenue splits but cannot manage contracts or multi-territory rights. Users are forced to stitch together multiple paid products.
Statement ingestion is fragile. DSP and distributor royalty statements arrive in highly heterogeneous CSV and Excel formats. Incumbents handle common formats but require manual mapping for proprietary distributor layouts, creating bottlenecks at the most error-prone step in the pipeline.
Split management lacks auditability. When ownership shares change -- due to reversion clauses, option exercises, or dispute resolution -- most tools overwrite historical records or require manual version tracking, making audits and dispute resolution difficult.
AI-generated music is creating new attribution complexity. As AI-generated content grows, rights management must accommodate non-human creators, training data attributions, and fractional ownership at scale -- a need no incumbent currently addresses. Today this build's answer is modest but real: a work carries free-form AI-contribution metadata (tool, extent, human contributors) alongside its splits, so the fact is recorded rather than lost.

Key Features

Dual-Rights Catalog

Separate but linked records for compositions (publishing) and master recordings
Per-record ownership splits with territory and use-type specificity
Linked relationships between compositions and their associated master recordings
Releases group recordings; identifiers (ISWC, ISRC, IPI, UPC/EAN) are validated and canonicalised on entry
Catalog browser with fuzzy search across titles and identifiers, filtered by record type and status

Split Management & Royalty Calculation

Version-controlled split sheets that preserve full history when ownership shares change: revising a share opens a new effective-dated version and closes the old one, and never overwrites it
Concurrent revisions of the same share are rejected rather than silently merged
Deterministic Decimal royalty engine that resolves the share version in force for the statement period, honouring territory overrides and exclusions and per-use-type shares
Currency conversion from daily ECB reference rates, with the exact rate row referenced by every calculation so any figure stays re-derivable years later
Recoupment against recoupable contract advances, with optional cross-collateralisation

Statement Ingestion

Configurable parser pipeline for DSP and distributor CSV/Excel formats, with six presets shipped (Spotify, Apple Music, YouTube Music, DistroKid, TuneCore, CD Baby) and user-defined sources for anything else
Period reconciliation and currency normalisation across heterogeneous statement sources
Identifier matching that auto-applies only on an exact ISRC/ISWC hit; a fuzzy title match is always proposed to a human, never applied automatically
Duplicate statement files are refused on upload, so revenue cannot be double-counted
Anomaly detection flagging a recording whose revenue from a source falls far below its own established average for that source — an early signal of under-reporting

PRO Registration & Contract Management

Structured CWR 2.2 (Common Works Registration) file generation for submission to any society recorded as a PRO party — ASCAP, BMI, SESAC, PRS, SOCAN and the rest
Per-society registration status tracking, updated by importing the society's acknowledgement file
Contract records for recording agreements, co-publishing deals, sub-publishing agreements, administration and distribution deals, and sync licences, with type-validated terms
Option period, reversion and expiry alerts from a daily scan, surfaced in-app and by email

Audit, Reporting & Access Control

Immutable audit trail of all ownership changes, payment runs, and statement adjustments — UPDATE/DELETE on the audit table are rejected by the database itself, not merely by the application
Revenue reporting grouped by territory, use type or currency, and royalty summaries grouped by rights holder, right type or currency, both exportable as CSV
Full derivation behind every royalty figure: statement line, FX rate, share version, contract, deductions and recoupment
Role-based access control across six roles, with rights holders fenced to their own records; two-person approval before any payment run executes
Bank account, routing and tax-ID values encrypted at rest (Fernet), so a database dump never contains them in plaintext

AI-Assisted Reconciliation

Assistive intelligence is pointed at the highest-friction part of rights administration — getting a statement's lines matched to the right catalog records — and deliberately kept out of the parts where a wrong answer costs money.

Reconciliation assistant. For every statement line that did not match on an identifier, the assistant ranks the most plausible catalog records and gives a plain-language rationale and a confidence score, so an operator can bulk-confirm the strong candidates instead of hunting one line at a time. It is advisory only — it never applies a match by itself, and it is only ever sent titles, artist names and identifiers: never amounts, never anyone's personal or banking details. Out of the box the provider is simulated — a deterministic, entirely offline ranker over title and artist similarity. Supply an Anthropic API key and set AI_PROVIDER=claude to use a live model instead; the same guardrails apply either way.

Statement anomaly detection. After a batch is matched, the system compares each recording's revenue in the new batch against that recording's own established average from the same source, and flags any that fall far below it — a signal of under-reporting worth chasing before it becomes a dispute. It needs a couple of prior statements from that source before it can say anything.

Royalty forecasting. Quarterly projections for a work, recording, rights holder or the whole catalog, fitted from actual collection history, with a scenario slider for growth assumptions and a range that widens with the horizon. It refuses to project from fewer than four quarters of real history, and every output is labelled an estimate — never money owed.

Everything else in the pipeline is deliberately deterministic: the royalty engine is exact Decimal arithmetic with a stored derivation for every figure, because "the model said so" is not an answer you can give a songwriter.

Tech Stack & Deployment

Stack: Python 3.12 · FastAPI · SQLAlchemy (async) · PostgreSQL 16 · Celery + Redis · Next.js (React + TypeScript).
Data model: Relational PostgreSQL with JSONB where the shape genuinely varies (contract terms, territory configuration, parser mappings). The many-to-many relationships between works, recordings, rights holders and territories are modelled as explicit link tables with effective-dated, append-only version chains — the audit story matters more here than schema flexibility.
Statement ingestion: A configurable transformation pipeline handles heterogeneous file formats without hard-coded importers — a new source is a column mapping, not new code. CSV and Excel only; there is no DDEX support.
Standards: CWR 2.2 (the CISAC standard) for PRO registration, generated for submission through the society's own channel — no society exposes an API a system like this could submit to. Acknowledgement files are imported back to close the loop.
Payment rails: A provider-agnostic adapter with two implementations — a sandbox stand-in (records an instant success, moves no money, and is the default so the whole workflow can be rehearsed safely) and Stripe Connect for real disbursement. Payout details are encrypted at rest.
Deployment: One container supervising the web tier, API and Celery worker+beat. Self-host with docker compose, run the data services alone and the app from your IDE, deploy managed on the WBSP platform via wbsp.yaml, or hand an evaluator the single-image build in preview/ that carries its own Postgres, Redis and demo catalog. Role-based access control is a first-class concern given the multi-stakeholder nature of rights data.

Market Context

The global music publishing market was valued at approximately USD 6 billion in 2024, with streaming revenue projected to reach roughly USD 10 billion by 2030. Independent labels and publishers are underserved by enterprise platforms sized for major-label volumes and budgets. A mid-market platform that automates statement ingestion, split calculations, and PRO registration -- without six-figure implementation costs -- addresses a credible gap, further expanded by sync licensing growth and the rise of AI-generated music with complex attribution requirements.

Project Status

Built and running. The application is implemented, covered by an automated suite that runs against real PostgreSQL and Redis plus a Playwright suite driving the production web build, deployed to a sandbox demo on the WBSP platform, and packaged as a standalone evaluation image. Contributions, feedback, and domain expertise are welcome.

Known limitations, stated plainly — the product is honest about its edges rather than hiding them:

Catalog records can be created from the screens but not edited or deleted there; ownership splits are the deliberate exception (revise → new version).
Contract terms are entered as structured text, not a friendly form, and the Contracts screen shows a document count but has no upload control (the API accepts uploads).
Administration fee and withholding tax come from the contract's terms and default to zero, so a contract that declares neither still deducts nothing.
Recalculating a batch replaces the previous run rather than adding to it: the earlier calculations are marked superseded (kept and still viewable, never deleted) and their recoupment is handed back to the advance first. Two edges remain. A payee held below their minimum payout keeps their calculations unpaid, so their batch can still be recalculated — the held run item's breakdown then points at superseded rows, though it disbursed nothing and the next payment run uses the live figures. And if a line goes held on recalculation (a missing FX rate, say), its earlier rows are superseded with nothing to replace them, so the line is not payable until the rate is added and the batch is recalculated again.
A batch whose calculations have already been paid cannot be recalculated at all — the request is refused and the correction has to be an adjustment (a compensating entry), which is a deliberate accounting decision rather than a gap.
CWR export carries a work's territorial restrictions as exclusion records, which requires the territory's CISAC/TIS code in the territories reference table. Those codes now ship populated for all 249 individual countries, so ordinary territorial restrictions export correctly out of the box; the "Worldwide" aggregate row has no country code by design. A territory that still cannot be mapped leaves the work out of the file with a stated reason rather than registering it worldwide against a limited deal.
There is no notifications centre: contract deadlines surface as a banner on the Contracts screen and by email, and everything else confirms itself where you did it.
Programmatic API access is future scope — every request today is made on behalf of a signed-in browser user.

Where to start

If you are…	Read
New to this and want the plain-language orientation	`user-docs/READ-ME-FIRST.md`
Trying it in ten minutes	`user-docs/getting-started.md`
Evaluating without setting anything up	`preview/README.md`
Standing up a real system	`user-docs/production-initialization.md`
Building against it	`user-docs/api-reference.md` · `user-docs/openapi.yaml`
Assessing whether the numbers can be trusted	`user-docs/testing.md`

Contributing

We welcome contributions from developers, domain experts, and potential users. Contribution guidelines have not been published yet — open an issue to discuss a change before starting work on it.

Important: All contributions must be your own original work or clearly attributed open-source material with a compatible licence. Copyright infringement and licence violations will not be tolerated and will result in immediate removal of the offending contribution. If you are unsure whether a piece of code, text, or other material is safe to contribute, open an issue and ask before submitting.

Licence

Licence to be determined — no licence file has been published for this repository yet. Ask before reusing the code in your own product.