Royalty Distribution Software Problems: The 7 That Hold Member Money, and How to Fix Them

Why does the scope stop at the matching engine?

Because matching is the visible pain. The unmatched queue is a number somebody reports to the board, so the project gets framed as fixing the matcher, and the matcher is only one of three stages that decide whether money reaches the right person.

What gets left out is the decision layer and the money layer. Candidate generation, scoring and decision are three different problems, and packaged tools bundle them so tightly that you cannot change the threshold for one usage type without changing it for all. Then downstream, allocation, holds, adjustment and payment are treated as reporting rather than as the system of record, which is how a society ends up computing the real distribution in a spreadsheet and using the platform as a ledger.

The other consistent omission is the feedback loop. If reviewer decisions do not become labelled training data that improves scoring, your staff re-work the same failures every quarter for years. That is not a nice extra, it is the entire economic case for building rather than licensing, because corrections that compound for you are worth something and corrections that improve someone else's product are not.

Scope by pipeline stage. Name the inputs, outputs and owner of candidate generation, scoring, decision, allocation, hold, adjustment and payment separately, and require an answer for each on what happens when it is wrong. If a proposal has one box labelled matching, half the system is missing.

What goes wrong when you migrate decades of works and shares data?

Assume this is the longest pole in the project, because it usually is. A legacy repertoire database carries decades of accumulated exceptions, and most of them were correct decisions at the time that nobody wrote down.

The recurring findings: the same work registered twice under slightly different titles through two sub-publishers, shares that sum to more or less than one hundred per cent, mandates with unclear start or end dates, interested parties who exist twice because an estate registered separately after a death, and free text notes that encode a real agreement in prose. A naive import loads all of it and the new system inherits every ambiguity while looking authoritative.

The other trap is transliteration and character handling. Titles in a second script, accented characters mangled by an export decades ago, and a matcher that now treats two spellings of the same work as two works. That silently inflates your unmatched pile in the new system while the migration report says everything loaded.

What works: migrate in waves by value, highest value repertoire first, so the works that carry most of the money get the most human attention. Run both systems against the same quarter and compare allocations line by line rather than in totals. Treat every share overlap as a decision that needs an owner rather than as a data error to be cleaned automatically, because behind most of them is a person with a legal interest.

Why do reciprocal exchange and digital reporting integrations break after launch?

Because the standards are real but the implementations are not identical. Common industry formats for work registration and usage reporting help enormously, and every counterparty still implements them differently. That means each reciprocal partner and each digital service is realistically its own integration measured in weeks, not a single generic importer with a dropdown.

Broadcaster logs fail differently again. They do not follow the specification they claim to follow, and they change when the broadcaster changes its own playout system, which they do not tell you about. The failure is silent: a column shifts, your parser reads a duration as an identifier, and the affected usages go unmatched rather than erroring.

Live and venue data is the worst of all, because it is typed by promoters. Setlists arrive with venue names in the title field, support acts missing entirely, and cover versions credited to the performer rather than the writer.

Three defences. Validate every inbound file against an expected shape on arrival and quarantine what fails rather than ingesting it partially. Keep a per partner mapping owned by a named person, so a change is a configuration edit rather than an archaeology project. And write immutable ingestion batches, so when a partner resends a corrected file you can reprocess from the original inputs rather than trying to unpick a partially applied load.

What happens when claim holds and rule versioning are not covered?

These are the two gaps that turn a data problem into a governance problem.

Claim conflicts are not exceptions to be handled later. Overclaims, estates registering after a death, two societies claiming the same work in the same territory and members disputing an allocation years afterwards are a standing share of your repertoire. If disputed money simply stays in the undistributed pool with no state attached, nobody can tell you how much is held, why, or how long it has been there. Your regulator will ask, and so will your board.

Rule versioning is the mirror. Your distribution rules are policy, not arithmetic: sampling weights for surveyed broadcasters, minimum payment thresholds that roll balances forward, administration and cultural fund deductions set by your board, mandate dates that prorate a member who joined mid period, and foreign inflows arriving net of another society's deductions. Those rules change when your board votes. If they live as code inside a run script, re-running a past distribution applies today's policy to a period governed by different policy, and the result is defensible to nobody.

Build both explicitly. A claim becomes a first class object with states of claimed, in conflict, held, resolved, distributed and adjusted, with a clock on the hold and a documented policy for what happens when the clock expires. Rules become versioned and dated, every allocation records the rule version that produced it, and re-running a past period applies that period's policy. That one design choice turns an audit into a conversation and lets you model a proposed rule change against last quarter's real data before anyone votes.

Should you build custom or license what already exists?

License if you are a smaller society with a few thousand members, one or two usage types and no unusual distribution policy. A specialist matching engine such as the one from Spanish Point Technologies plus disciplined repertoire data will serve you better than a bespoke pipeline you cannot staff. The real constraint on building here is not money, it is whether you have or can hire the two or three data people who will own the pipeline afterwards. A society that builds and then loses its only data engineer is worse off than one that never built.

Improve the data before blaming the engine. In a meaningful number of reviews, a flat match rate turns out to be a repertoire quality problem rather than a matcher problem, and cleaning identifiers and duplicate registrations moves the number more than any change of tooling.

Build when two or more of these are true. Your unmatched value has been flat or rising across three consecutive distributions despite effort. Your distribution rules require a spreadsheet outside the system to compute correctly. You administer multiple rights or territories with genuinely different policy. Your members or your regulator have asked for line level explanation you cannot produce. Or your distribution run has become a ritual only one person can perform.

How do hidden costs get into the quote?

Usage source count is the first and by far the largest. Each format is its own ingestion project, and a proposal that prices ingestion as one line has not looked at your sources.

Reciprocal exchange is the second, for the reasons above. Price each counterparty separately or you are being quoted an average.

Historic migration is the third, and it is almost always worse than expected. Budget it as a named phase measured in months rather than as a data task.

Multi right operation is the fourth. Administering performing and mechanical or neighbouring rights in one system is not a matter of adding a field, because those rule sets do not merely differ, they conflict, and the resolution is a policy decision your board has to make before anyone codes it.

Fifth is the review queue itself. A screen that is pleasant with a hundred rows is unusable at several hundred thousand, and building a review interface that a team can actually work at volume, with keyboard driven decisions, bulk actions and confidence banding, is a real piece of product design rather than a table with buttons.

Sixth is the parallel quarter, where both systems run against the same period and outputs are compared line by line. It is the only test that proves the build, and it belongs in the budget.

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

First, the run is idempotent. Any stage can be re-executed on the same inputs and produce the same outputs, because ingestion writes immutable batches, matching writes decisions rather than mutations, and allocation is a pure function of decisions plus rule version. That turns a run nobody dares repeat into something you can execute twice on a Tuesday to compare outcomes.

Second, lineage is kept. Every distribution line links back to the usages that produced it and forward to the payment that carried it. Explainability is a property of the pipeline, not a report added at the end, and a pipeline that discards intermediate state to save storage cannot answer a member's question at any price.

Third, reviewer decisions compound. Every human decision becomes labelled data that improves scoring, so the unmatched pile shrinks quarter over quarter instead of being re-worked from scratch.

Fourth, you own the code, the trained model, the labelled data your reviewers generated and the cloud accounts, agreed in writing before kickoff. This matters institutionally as well as commercially: your repertoire intelligence is the asset your members pay you to build, and it should not accrue to a supplier. At Digital Heroes the client owns all of it from the first commit.