Music Royalty Accounting Software: What It Costs to Match Hundreds of Millions of Streaming Lines to Contracts That Survive an Artist Audit

Why royalty accounting stops working at streaming scale

The royalty run is due Friday. Your head of royalties has downloaded platform reports for the period, and the biggest one is a compressed file that expands to something no spreadsheet will open. She loads what she can into a database somebody set up three years ago, runs the matching query, and gets a number: 4.1 percent of lines did not match to a recording in the catalogue. That is a small percentage and a very large pile. Inside it are territory variants of the same track, a live version distributed by a partner under a different code, forty tracks from a catalogue acquired last year whose codes were never mapped, and a batch where the platform changed a column name. She has three days, and the choice is to hold the run or to accrue the unmatched income to a suspense line and deal with it next quarter, which is what happens, and the pile grows.

The stack around this is typically a distributor dashboard, platform reporting portals, society statements arriving as files and PDFs, an accounting system that knows nothing about tracks, and a set of workbooks holding contract terms. Curve Royalty Systems and Reprtoir are real and good, particularly for independents. Vistex is a serious enterprise engine. What none of them holds by default is your specific combination: an inherited catalogue with three generations of contract wording, distribution partners whose file formats you do not control, and a matching problem where the same recording exists under several identifiers because it was released, re-released and licensed by people who left years ago.

Problem 1: the identifier is supposed to be the easy part

Recording identity is meant to be solved by the ISRC, and works by the ISWC, with the UPC tying a release together. In practice a single recording arrives under multiple ISRCs because a distributor minted a new one for a territory, a compilation used its own, and a remaster got another. Society statements identify works by their own internal numbers and by title and writer strings that are transliterated inconsistently. Publishers deal with the harder version of this, where a work has share splits registered differently at each society and the statements disagree.

The build treats identity as a resolution problem rather than a lookup. Every incoming line gets normalised, then matched in tiers: exact identifier, then a mapping table of known aliases, then a scored match on artist, title, duration and release, then a human queue. Crucially, every automated match is recorded with its rule and score, so a match can be reviewed and reversed without unpicking a payment. This is where machine learning earns a place, not as a chatbot but as a scoring model over your own confirmed matches, which improves as the queue is worked. Target a shrinking unmatched pile, not zero, and report on it every period so it never quietly compounds again.

Problem 2: the contract library is three generations deep

A 2003 artist agreement has a packaging deduction and a reduced rate for what it calls new media. A 2014 deal has a net receipts share on streaming with a defined deduction list. A 2022 deal has a straight split with no deductions and an escalator at a revenue threshold. A distribution deal you inherited has a different fee at different volume tiers. A producer has a points share payable after the artist's account recoups, or from record one, depending on the memo attached to the agreement.

Packaged platforms model a rate against a revenue type, which covers modern deals well and legacy deals poorly. The failure appears where deductions are conditional or where a term changed by amendment on a date. A custom build makes the deal a set of ordered rules with effective dates, so the same artist can carry one calculation before an amendment and another after it without maintaining two artist records. Deductions become explicit named items rather than an aggregate percentage, because when an artist's business manager asks what the eleven percent was, the answer has to be itemised. Build the terms editor for your royalty team, not for engineers. If a new deal requires a developer, the system will be out of date within a year.

Problem 3: recoupment is the part that gets audited

Advances, recording costs, video costs, tour support, marketing contributions recoupable at fifty percent, cross-collateralisation across an album cycle or across a whole deal term. An artist account is a balance with a history, and the sequence in which costs entered it changes what has been recouped and when payment begins. Add a producer whose share is payable from a different point in the waterfall and the order of operations becomes the whole answer.

The system must post costs as dated events against a defined recoupment pool, apply earnings in a defined order, and be able to show the balance at any historical point. Never store a recouped balance as a single mutable field. When a cost is later found to be non-recoupable under the contract, and that happens in most audits, you reverse it as an entry and regenerate downstream statements deterministically. Cross-collateralisation needs to be explicit: which projects share a pool, from when, and what happens on a term ending. Those questions are answered in the contract and they belong in structured data, not in a note field.

Problem 4: statement formats change without warning

DDEX has standardised a good deal of digital sales reporting, and where a partner sends conforming DSR files life is manageable. Plenty of income does not arrive that way. Society statements, neighbouring rights income, sync fees, physical distribution reports and older partner exports all come in their own shapes, and even conforming feeds add columns and change territory codes between periods.

Build ingestion as a pipeline with a validation gate rather than a set of import scripts. Every file is stored raw and immutable on arrival. Parsing produces staged rows with a checksum on totals against the partner's own control figures, and a run does not proceed if the totals disagree. Currency conversion applies a stated rate source and rate date recorded on the line, because six months later somebody will ask which rate you used and a general answer is not sufficient. Restatements from partners are common, so the model must accept a corrected period without overwriting history, then flow the difference through as an adjustment on the next statement rather than a silent edit to a closed one.

Problem 5: artists audit, and transparency is now an obligation

The audit clause in a recording or publishing agreement is not decoration. Artist business managers exercise it, and the first thing they ask for is the tie out from platform income to the statement line. In the European Union the copyright directive introduced a transparency obligation toward authors and performers, which pushes in the same direction: statements have to be explicable, not merely correct.

The practical answer is an artist portal that shows earnings by track, territory, platform and period, with the recoupment balance visible and the deduction items named. Labels resist this and the resistance is misplaced, because the alternative is the same questions arriving by email to a royalties team that has to answer them by hand. Every statement issued should be retained exactly as issued, with the version of the contract terms and the underlying line data that produced it, so an audit request pulls a file rather than starting a reconstruction. Systems that can do that turn a six week audit engagement into a short one, which is worth real money independent of the finding.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape for music royalty accounting. A focused first release covering ingestion at line level, catalogue matching with a review queue, contract split calculation and artist statement production runs $80,000 to $180,000 and ships in 14 to 20 weeks. A full platform adding recoupment with cross-collateralisation, society and neighbouring rights income, publishing share administration, an artist portal and payment execution runs $250,000 to $600,000 phased over 9 to 15 months.

What drives the price up specifically in music: catalogue age, because a legacy contract library takes weeks of business affairs time to convert into structured terms and there is no shortcut. Volume, since a run that processes hundreds of millions of lines needs real data engineering rather than an application database, and that decision changes the architecture and the hosting bill. Publishing, because share administration across societies is materially harder than recording royalties and should be scoped as its own phase. And payment execution, if you want to pay thousands of small balances across borders, which brings compliance and reconciliation work that has nothing to do with royalties.

Build versus buy, and when buying is right

Buy, and do not call us, if you are an independent label or publisher with a few hundred releases, standard modern splits, and income arriving from one distributor. Curve Royalty Systems and Reprtoir are designed for exactly that shape, cost a small fraction of a build, and will produce better statements than a first attempt at custom software. Vistex is a reasonable answer inside an enterprise that already runs it for other rights.

Build when two or more of these are true. Your catalogue includes acquired assets whose contracts and identifiers you inherited rather than created. Your unmatched income has become a standing suspense balance nobody can clear. Your deals include conditional deductions, escalators or cross-collateralisation that no product's rate configuration expresses. Your royalty run takes longer than the period you are reporting on, which means you are structurally behind. Or an audit has been served and you cannot produce a tie out from platform income to a statement line. The tipping point is not volume alone. It is that the relationship between identifiers, contracts and balances has become the business, and that relationship is currently held by two people and a query.

How to choose a developer for royalty accounting

Ask them how they would handle a line that does not match any recording in your catalogue. If the answer is that it gets logged, they have not run a royalty period. The answer you want describes tiered matching, a scored review queue, an alias table that grows, and the ability to reverse an automated match without unpicking a payment already made.

Ask them to model recoupment on a whiteboard. Costs as dated events against a named pool, earnings applied in a defined order, balance reconstructible at any historical date, reversals as entries rather than edits. If they draw a recouped balance field, walk.

Ask about scale honestly and specifically. A system that handles ten million lines a period comfortably may fall over at three hundred million, and the fix is not a bigger server, it is a different processing model. Ask what the largest period they have processed was and how long the run took.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire another firm. At Digital Heroes the code is yours from the first commit. Your royalty engine calculates payments that artists may examine years later, and a black box you cannot inspect is a liability your legal team will eventually inherit.