Music Royalty Accounting Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the catalogue matching problem get underestimated so often?

Every royalty project starts with a scope line that reads something like ingest platform statements and match to catalogue. It is estimated as a data import. It is not a data import, it is an identity resolution problem, and it is the largest single workstream in the build.

The reason is specific to music. Recording identity is supposed to be settled by the ISRC, and in a catalogue you created yourself last year it broadly is. In a real catalogue it is not, because a distributor minted a new code for a territory release, a compilation carried its own, a remaster got a third, and a licensed live version arrived through a partner under a code you have never seen. Publishing is harder again, because a work carries share splits registered differently at each society and the statements disagree with each other on the writer strings.

Teams that treat this as a lookup ship a system that matches most lines and dumps the rest into a table called unmatched, which grows every period and eventually becomes a suspense balance nobody can clear. Teams that treat it as resolution build tiers: exact identifier, then a maintained alias table, then a scored match on artist, title, duration and release, then a human review queue. The crucial design detail is that every automated match records the rule and the score that produced it, so a match can be reviewed and reversed without unpicking a payment already made. Scope the review queue as a product with a workflow and an owner, not as a screen. Then report the unmatched pile with an ageing view every single period, because the failure mode here is not a spike, it is quiet compounding.

What goes wrong when you migrate a legacy contract library and historic statements?

The contract migration is where royalty projects overrun, and it overruns on business affairs time rather than development time. A 2003 agreement has a packaging deduction and a reduced rate for what the drafter called new media. A 2014 deal shares net receipts with a defined deduction list. A 2022 deal is a straight split with an escalator at a revenue threshold. A producer has points payable either after the artist account recoups or from record one, depending on a memo stapled to the agreement. Nobody has read most of these documents in a decade, and turning them into structured terms is legal reading, not data entry.

The predictable failure is that the project plan allocates a developer to it. What is needed is a business affairs person, or an external royalty consultant, producing a structured term sheet per deal that somebody with authority signs off. Budget it as a parallel workstream starting in week one, because it gates the calculation engine and cannot be compressed by adding engineers.

The second migration trap is historic statements. You need previously issued statements to remain retrievable exactly as issued, and you almost never need them recalculated inside the new system. Import them as immutable documents with their period, artist and totals indexed, and draw a hard line: the new engine computes from a stated cutover period forward. Teams that try to reproduce five years of history in the new model discover that the old system's rounding, currency dates and deduction ordering differ subtly, and they spend three months explaining differences that have no business consequence.

Why do statement feeds from platforms, societies and distributors break after launch?

They break because ingestion was built as a set of import scripts rather than a validated pipeline, and the assumptions that held during development stop holding by the second or third period. A platform adds a column. A territory code changes format. A society sends a corrected file for a period you have already closed. A distributor's export drops a decimal place on one currency. None of these announce themselves.

DDEX has standardised a good deal of digital sales reporting and where a partner sends conforming files life is manageable. Plenty of your income does not arrive that way: society statements, neighbouring rights, sync fees, physical distribution and older partner exports all come in their own shapes.

The design that survives has three properties. Every file is stored raw and immutable on arrival, so you can always reparse rather than re-request. Parsing produces staged rows and the run does not proceed unless the staged totals reconcile to the partner's own control figures, which means a format change stops the run at a gate instead of silently dropping a column into a quietly wrong statement. And restatements are absorbed as adjustments on the next statement rather than as edits to a closed period, because overwriting a closed period is the fastest way to lose the ability to explain a historic payment.

What happens when recoupment and audit traceability are not fully covered?

This is the gap that turns a working system into a liability. Recoupment gets scoped as a balance and a threshold, which handles a simple advance and nothing else. The reality is advances, recording costs, video costs, tour support and marketing contributions recoupable at a stated percentage, sitting in pools that may be cross collateralised across an album cycle or across a whole deal term, with a producer whose share enters at a different point in the waterfall.

When that is modelled thinly, three things follow. You cannot show the balance as it stood at a historic date, so an auditor's first question has no clean answer. You cannot reverse a single disputed cost without recalculating by hand. And you cannot explain the order of operations, which is frequently the whole substance of the dispute.

The correct model is boring and it works. Costs post as dated events against a named recoupment pool. Earnings apply in a contractually defined order. The balance at any date is derived, never stored. Reversals are entries, not edits. Cross collateralisation is explicit structured data saying which projects share a pool, from when, and what happens when a term ends.

Transparency belongs in the same scope. In the European Union the copyright directive introduced a transparency obligation toward authors and performers, which pushes in the same direction as the audit clause already in your agreements: statements have to be explicable, not merely correct. An artist portal showing earnings by track, territory, platform and period, with the recoupment balance visible and deduction items named individually rather than aggregated, is cheaper to build than it is to keep answering the same questions by email.

Should you build custom or configure what you already own?

Buy, and do not call us, if you are an independent label or publisher with a few hundred releases, modern and fairly standard splits, and income arriving through one or two distributors. Curve Royalty Systems and Reprtoir are built for exactly that shape, cost a fraction of a build, and will produce better statements than a first attempt at custom software. If your complaint is that statements are slow rather than that they are unexplainable, configuring one of those properly is the right answer and it is not close.

Vistex is a reasonable answer inside an enterprise that already runs it for other rights, and if it is already in your estate, exhaust its configuration before pricing a replacement.

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 carry conditional deductions, escalators or cross collateralisation that no product's rate configuration expresses honestly. Your royalty run takes longer than the period you are reporting on, which means you are structurally behind and will not catch up. Or an audit has been served and you cannot produce a tie out from platform income to a statement line.

How do hidden costs get into the quote?

Five reliably. Contract conversion, covered above, which is business affairs time and not development time, and which is the item most often left out of a fixed price entirely. Volume, because a system that handles ten million lines a period comfortably can fall over at three hundred million, and the remedy is a different processing model rather than a bigger server. That is an architecture decision that must be made before the first line of code, and retrofitting it is effectively a rebuild.

Publishing, if it is in scope. Share administration across societies is materially harder than recording royalties and belongs in its own phase with its own budget. Quotes that fold works and recordings into one line are quoting the easier half.

And the review queue staffing model. The system will produce a queue of unmatched and low confidence lines every period forever. If nobody is assigned to work it, the build has moved your suspense balance into a nicer interface.

What separates a build that works from one that fails here?

The first separator is whether your royalty team can change a deal without a developer. New agreements arrive constantly and amendments change terms mid relationship. If a new deduction structure needs a code release, the system is out of date within a year and your team quietly returns to spreadsheets for the deals it cannot express. Build the terms editor for the people who negotiate and administer deals.

The second is determinism. Given the same inputs and the same contract versions, a rerun must produce the same statement, byte for byte. That property is what lets you reverse a cost, regenerate the affected periods and hand the result to an auditor without a covering explanation. Systems that cannot be rerun reproducibly are systems whose outputs cannot be defended.

The third is that every statement issued is retained exactly as issued, alongside the contract term versions and the underlying line data that produced it. An audit request then pulls a file instead of starting a reconstruction, which routinely turns a six week engagement into a short one, and that is worth real money independent of the finding.

The fourth is ownership. You should hold the repository, the infrastructure accounts and the unrestricted right to hire another firm, written into the contract before kickoff. At Digital Heroes the code is yours from the first commit. Royalty calculations may be examined by an artist auditor years after they were performed, and a black box you cannot inspect is a liability your legal team inherits at exactly the wrong moment.