Royalty Management Software Cost: Seven Modules, and the One That Decides the Rest
A royalty platform costs $59,200 to $148,000 for phase one. That is 1,480 hours at a $40 to $100 rate band, or about $96,200 at a $65 blend. Across the scopes we actually see, the realistic band is 1,200 to 2,100 hours, which is $48,000 to $210,000.
The seven modules: the rights and party model at 200 hours, catalogue and identifiers at 180, deals and rate cards at 240, usage ingest at 220, the royalty calculation engine at 260, statements and payouts at 200, and reporting and admin at 180.
The milestone that matters is not a screen that renders. It is a royalty run somebody is willing to send. Those are months apart, and almost every overrun in this category comes from a plan that treated them as the same thing.
Here is the ordinary failure. A publisher runs the quarter, sends 4,000 statements, and one writer replies that their share of one song is wrong. The share is wrong because a contract amended in 2019 changed a split that the system holds as a single current value. There is no way to answer what the split was in Q2 2021 without reading the paper. The run was not wrong once; it has been wrong since 2019, and now every statement sent since then is in question.
The party model is the foundation and it is the cheapest thing to get wrong. A party is a writer, an artist, a label, a publisher, an estate, a collecting society or a company that acquired another company's catalogue in 2017. The same human being can be three of those at once, with different payment details for each.
Parties also change. An artist signs to a new label, a writer's estate passes to heirs, a catalogue is sold mid-quarter. Every one of those is a change with a date, and the date is the whole point. Usage from before the sale pays the old owner. Usage after pays the new one. A model that stores "who owns this" rather than "who owned this, and when" cannot run a correct statement for any period before the most recent change.
That is why the rights and party model runs 180 to 380 hours. The data structure is not complicated. The versioning is, and it reaches every other module.
Shares are the second half of the same problem. A composition with four writers has four percentages that must total 100, and they are agreed per work rather than per writer — the same two writers may split 60/40 on one song and 50/50 on the next. Controlled shares complicate it further: a publisher may control 50% of a writer's share in one territory and none of it in another, which means a single line of usage can pay three parties at three different rates under three different agreements.
The rule that saves projects is to make every share a row with a date range rather than a column on a work. It looks over-engineered for the first hundred songs and it is the only shape that answers a question about 2021.
A recording has an ISRC. A composition has an ISWC. A release has a UPC. In theory these are the keys that let usage from a platform match a work in your catalogue.
In practice the same recording arrives under three ISRCs because three distributors registered it, a composition has no ISWC because nobody filed one, and a live version shares a title with a studio version and nothing else. The catalogue and identifier registry at 160 to 340 hours is mostly the machinery for resolving these disagreements and recording which resolution was applied, so that a later correction can be replayed rather than guessed at.
The alternative is matching on title and artist name, which works until you have two artists with the same name, a remix, or a title with a comma in it.
Unmatched usage is the operational consequence and it needs a home. Every royalty business has a suspense pile: income received for works the system could not identify. It has to be visible, workable by a human, and — once matched — payable retrospectively to the period it belonged to rather than the period someone fixed it. A platform that silently discards unmatched lines is losing its clients' money, and they will eventually find out.
Deals, rate cards and territory windows at 200 to 440 hours is the module that surprises people, because a deal looks like a percentage and behaves like a program.
A real contract might say: 15% of net receipts, escalating to 18% after 500,000 units, net of a 10% distribution fee but before marketing recoupment, with a different rate in territories where the label licenses rather than owns, a reduced rate on sales through a particular channel, and a minimum per-unit payment that applies when the percentage produces less. The next contract, signed by the same company two years later, uses different words for some of those and means something slightly different by others.
Contracts written years apart rarely agree with each other, and the system has to hold all of them simultaneously, each valid for its own period. That is the real reason this work is expensive: you are not implementing a rate, you are implementing a rules engine whose rules arrive as prose.
Territory windows deserve naming because they are where the rules engine meets the calendar. A release may be licensed in one market from January, in another from March, and withdrawn from a third entirely after a dispute. Usage arriving from a territory outside a window is not an error to reject; it is income that still has to be accounted for, usually under a fallback term buried in the same contract.
Write the deal model to be inspectable by a non-engineer. The people who will find the errors are the royalty analysts, not the developers, and they will only find them if they can read the rule the system thinks it is applying.
Platforms send usage files. Each one has its own format, its own idea of what a stream is, its own currency and exchange rate treatment, and its own schedule. One sends monthly, one sends quarterly, one sends a correction file two months later that restates a period you have already paid.
Usage ingest and normalisation at 200 to 420 hours is almost entirely about that last sentence. Loading a file is a week. Handling a restatement of a period you have already paid out on is the module.
The design that survives is the one that treats every usage line as versioned, the same way the party model treats ownership. You keep what you were told, when you were told it, and what you did about it. Anything that overwrites cannot explain itself later, and explaining itself later is the entire job.
Currency is the quiet cost inside this module. A platform reports in the currency it collected, you pay in the currency the contract specifies, and the exchange rate applied depends on the contract — rate at the date of usage, rate at the date of receipt, or a rate the licensor publishes. Three contracts can require three different answers for the same month, so the rate cannot be a single system setting.
Volume is worth a sentence. Interval-level usage for a mid-size catalogue runs to tens of millions of rows a period, which makes a full re-run an engineering decision rather than a button. Systems that cannot re-run a period affordably end up not re-running it, which is how errors persist.
At 240 to 520 hours this is the largest module, and the arithmetic is the small part.
The engine takes usage, finds the applicable deal for that work, that territory and that date, applies the rate, allocates across the parties on their splits as they stood at the time, and writes down every step. The output that matters is not the number. It is the ability to take any single line on any statement and show the chain: this stream, matched to this recording, under this contract clause, at this rate, split this way because of this agreement effective this date.
Without that chain you cannot answer a query, and queries are not exceptional. They are the normal operating condition of a royalty business.
Audit is the same requirement wearing a formal hat. Labels are audited by artists, publishers by societies, distributors by labels, and an audit asks the system to defend a period that closed years ago using the rules that applied then rather than the rules in force now. A platform that cannot reproduce a historic run is not merely inconvenient at that point; it is a commercial liability, because the usual settlement for an indefensible period is to pay the claim.
The practical test to apply before accepting any royalty build: pick a statement line from two years ago and ask the system to explain it. If the answer requires a developer, it is not finished.
Re-runs are the other half. A correction arrives, a split is fixed retroactively, a contract is re-read. The engine has to recompute a closed period and produce an adjustment rather than a replacement, because the original statement has already been sent and may already have been paid.
Minimum guarantees and floors interact badly with re-runs and are worth designing for early. If a contract guarantees a per-unit minimum, a recalculation that lowers the percentage-based figure may leave the payable unchanged while every component beneath it has moved. The statement has to show that, or the recipient will conclude the correction was ignored.
Statements, recoupment and payouts sits at 180 to 400 hours, and recoupment is the part that generates correspondence.
An advance is a balance that earnings pay down, and what counts against it is contractual rather than obvious. Some costs recoup against the advance, some are deducted before the royalty is calculated, and some are shared at a different percentage than the royalty itself. Cross-collateralisation — where one project's unrecouped balance is paid down by another project's earnings — is common and is frequently the thing an artist did not realise they signed.
Whatever the terms, the statement has to show the balance moving. An artist who cannot see why they are still unrecouped will ask, and the answer has to come from the system.
Payout mechanics are the last mile and they are more work than they look. Minimum payment thresholds hold small balances until they are worth sending. Withholding tax differs by the recipient's country and by whether they have filed the right form, and getting it wrong creates a liability rather than an underpayment. Payments to an estate, a company that has since been dissolved, or a party whose bank details have gone stale all need a held state that is visible rather than a failed transfer nobody notices.
Phase one of a royalty platform is 1,480 hours, which is $59,200 to $148,000 at a $40 to $100 rate band and about $96,200 at a $65 blend. Seven modules: the rights and party model, catalogue and identifiers, deals and rate cards, usage ingest, the calculation engine, statements and payouts, reporting.
Every competitor publishes a total with no hours behind it. Here are the hours.
Module | Hours |
|---|---|
Rights, party and share model | 180 to 380 |
Catalogue and identifier registry | 160 to 340 |
Deals, rate cards and territory windows | 200 to 440 |
Usage ingest and normalisation | 200 to 420 |
Royalty calculation engine | 240 to 520 |
Statements, recoupment and payouts | 180 to 400 |
Reporting, admin and integrations | 160 to 360 |
The worked example takes a mid-point from each: 200 plus 180 plus 240 plus 220 plus 260 plus 200 plus 180, which is 1,480 hours. At $40 per hour that is $59,200. At $100 it is $148,000. At a $65 blend, about $96,200. The realistic phase-one band across the scopes we see is 1,200 to 2,100 hours, or $48,000 to $210,000.
Deliberately not in that number, each its own decision: encoding, packaging and delivery; a consumer-facing app; and any migration of more than two years of historic usage.
Recurring rather than build: hosting, CDN egress, DRM licence fees and the payment provider's charges. Those scale with catalogue and audience rather than with headcount, which makes them an operating line rather than part of the estimate.
If your question is which licences you need and who can grant them rather than how to account for them afterwards, that is a different problem and we wrote it up in music licensing for streaming apps.
Contract variety moves it more than catalogue size does. A catalogue of 200,000 recordings under four deal templates is a smaller build than 2,000 recordings under 180 bespoke contracts, because the engine's complexity tracks the number of distinct rule shapes rather than the number of rows it processes.
Second is how many currencies and territories you settle in. Each adds an exchange-rate policy — which rate, on which date, applied at which step — and the answer is usually specified in the contracts rather than chosen by you.
Third is history. Migrating more than two years of historic usage sits outside the number above for a reason: old usage arrives without the identifiers the new system needs, and reconstructing which deal applied in a period whose contracts have since been amended is forensic work.
There is a cheaper path that most businesses should take. Migrate balances and current agreements, keep the old system readable for historic queries, and run both for a year. It costs a licence you were hoping to cancel and it removes the single largest risk in the project, which is discovering mid-migration that the old data cannot answer a question the new system is now expected to answer.
What barely moves it: the user interface, the number of reports, and whether statements are PDFs or a portal.
Three failures, none technical.
The first is modelling ownership as current state. It is the error in the opening, it is invisible until the first query about a past period, and fixing it afterwards means rebuilding the module everything else reads.
The second is treating the first successful calculation as the finish line. A number on a screen is not a statement anybody will send. The distance between them is identifier resolution, recoupment, adjustments and the explanation chain, and it is most of the build.
The third is scoping from the standard contract. Every rights business has a standard contract and a drawer of exceptions, and the exceptions are the build. Teams that read ten real contracts before estimating produce numbers that hold. Teams that read the template produce numbers that do not.
The cost question has a short answer and it is the arithmetic above. The longer answer is that a royalty system is a historical record that performs arithmetic on request, and every expensive mistake in this category comes from building the arithmetic and forgetting the record.
A royalty platform phase one costs $59,200 to $148,000, which is 1,480 hours at a $40 to $100 hourly band, or about $96,200 at a $65 blended rate. The realistic band across the scopes we see is 1,200 to 2,100 hours, or $48,000 to $210,000. The spread is set by contract variety rather than catalogue size: a large catalogue under a few deal templates is cheaper than a small one under many bespoke contracts.
Seven. The rights, party and share model at 180 to 380 hours. Catalogue and identifier registry at 160 to 340. Deals, rate cards and territory windows at 200 to 440. Usage ingest and normalisation at 200 to 420. The royalty calculation engine at 240 to 520, the largest. Statements, recoupment and payouts at 180 to 400. Reporting, admin and integrations at 160 to 360.
Because the arithmetic is the small part. The engine has to find the applicable deal for a given work, territory and date, apply the rate, split across parties as their shares stood at that time, and record every step so that any line on any statement can be traced back to the contract clause that produced it. It also has to re-run closed periods when corrections arrive and produce an adjustment rather than a replacement, since the original statement has already gone out.
Because usage is dated and ownership changes. An artist moves label, an estate passes to heirs, a catalogue is sold mid-quarter. Usage from before a change pays the previous owner and usage after pays the new one. A system that stores who owns a work, rather than who owned it and when, cannot produce a correct statement for any period before the most recent change — and will not be able to answer a query about one either.
Restatements. Loading a platform's usage file is about a week of work. Handling a correction file that restates a period you have already calculated and paid out on is the module. The design that survives treats every usage line as versioned: what you were told, when you were told it, and what you did about it. Anything that overwrites cannot explain itself later, and explanation is the job.
Three things sit outside the build number, each its own decision: encoding, packaging and delivery; a consumer-facing app; and migration of more than two years of historic usage. Separately, hosting, CDN egress, DRM licence fees and payment provider charges are recurring operating costs rather than build costs, and they scale with catalogue and audience rather than with team size.
A 1,480-hour phase one runs about 5 to 6 months with a team of 4 to 5 people delivering 600 to 700 useful hours a month. The schedule risk is rarely engineering. It is contract reading: every term discovered mid-build is a change to the rules engine, and contracts written years apart rarely agree with each other. Reading ten real contracts before the estimate is the single highest-value thing a rights business can do.
Vikas has around fifteen years of experience building software and now builds generative AI systems at Zyneto. His work covers retrieval augmented generation, agentic AI, knowledge graphs, AI memory, and the evaluation and guardrails that decide whether any of it is safe to put in front of customers. He has shipped enterprise copilots, document AI, chatbots and predictive analytics for e-commerce, fintech and marketing teams, and works day to day in Python, JavaScript and SQL. He follows multimodal models, business process automation and enterprise AI security closely, and mentors engineers moving into AI. He writes about architecture, inference cost and the failure modes that only show up at production scale.
Share your details and we will talk soon.
Be the first to access expert strategies, actionable tips, and the trends actually shaping the digital world. No fluff - just practical insights delivered straight to your inbox.
Dive into our blog and stay ahead of the curve with expert perspectives, future-ready trends, and tech tips written for decision-makers and doers alike.
