Collective Management Organization Software: Why the Unmatched Pile Keeps Growing Every Quarter

Why matching, not licensing, is the hard part of a collecting society

It is week two of the quarterly distribution run. The usage files landed: broadcaster logs, cue sheets from television production, digital service provider reports in DDEX format, venue setlists typed by promoters, and a background music file where half the entries say the artist and none say the writer. The matching engine has done its pass. Ninety something percent of the money is matched by value, which sounds fine until you look at what is left: a queue of hundreds of thousands of lines, each one a claim someone is owed, and four people working through it in a spreadsheet exported from the system because the system's review screen is unusable at that volume.

Meanwhile the works database is fighting itself. A publisher registered the same song twice under slightly different titles through two sub-publishers. A member's shares sum to 104 percent because a co-writer's estate registered separately after the original filing. A foreign society has sent a claim for a work you already distributed on last quarter, so somebody has to decide whether that is a back-claim, a duplicate, or a conflict.

None of this is a licensing problem. Licensing is comparatively easy: negotiate a tariff, invoice, collect. The hard part is identity resolution at industrial scale, followed by policy arithmetic that your board and your regulator both scrutinise. That is data engineering, and it is why societies keep hitting the ceiling of packaged tooling. The cost of getting it wrong is not a bad report. It is money sitting undistributed while members write angry letters and the culture ministry asks why.

Problem 1: matching is identity resolution, and lookups do not survive real data

A usage line arrives as free text produced by someone with no incentive to be precise. Title variants and transliterations, cover versions credited to the performer rather than the writer, featured artist noise in the title field, remix suffixes, and the fifteen second cue a production assistant logged as background music. A lookup against your works database matches the easy half, and the easy half is mostly the same hundred thousand works every quarter.

Packaged matching engines are real and some are genuinely good at candidate scoring. What they do not do is learn your repertoire's specific failure modes: the way one broadcaster formats classical works, the naming conventions in your territory, the promoter who always types the venue into the title field. That is not configuration, it is a model.

What a custom build does: separate the pipeline into candidate generation, scoring, and decision, and own all three. Candidate generation uses blocking keys built from your data, not a generic engine's. Scoring combines string similarity with structural evidence such as performer to work links, duration, territory, and prior confirmed matches for that source. Decision applies thresholds you set per usage type, because a high value broadcast line deserves a different confidence bar than a background music line worth a few cents. Every human decision in the review queue becomes labelled training data, so the unmatched pile shrinks quarter over quarter instead of being re-worked from scratch. That feedback loop is the entire point and it is what generic tooling cannot give you, because your corrections improve their product for everyone rather than compounding for you.

Problem 2: claims conflict, and money has to wait somewhere defensible

Shares that do not sum to 100 percent are routine. Overclaims arrive because sub-publishers file across territories with overlapping mandates. Estates register after a death without coordinating with co-writers. Two societies both claim collection rights for the same work in the same territory. A member disputes an allocation three years later.

These are not exceptions to handle later. They are a standing share of your repertoire, and how you treat them is a policy decision with legal consequences that should not sit in a vendor's default behaviour.

What a custom build does: treat a claim as a first-class object with a state machine. Claimed, in conflict, held, resolved, distributed, adjusted. Disputed money moves to a defined hold with a clock on it and a policy for what happens when the clock expires, and the hold is reportable because your regulator will ask how much money is sitting in it. Resolution is a workflow with evidence attached, not an email thread. Retroactive adjustment is designed in from day one, because a resolution six quarters later has to reverse and reissue cleanly across everyone affected without breaking the closed periods your auditors already signed. Retrofitting retroactivity into a system that assumed forward-only distribution is the single most expensive rebuild in this category, and we have been called in to do exactly that more than once.

Problem 3: your distribution rules are policy, not arithmetic

Pro-rata by usage sounds simple until you read your own distribution rules. Smaller broadcasters are surveyed by sampling rather than census, so a sampled usage has to be weighted and grossed up. Minimum payment thresholds roll balances forward. Deductions for administration and for cultural or social funds are set by your board and differ by category. Mandate dates matter: a member who joined mid-period gets a prorated entitlement, and a member who resigned to a competing society keeps rights to usages before their exit date. Foreign inflows arrive net of another society's deductions and have to be allocated without double-deducting your own.

No vendor maintains that rule set for you, because it is yours and it changes when your board votes. Societies that buy a packaged distribution module usually end up computing the real allocation in Excel and using the module as a ledger.

What a custom build does: express distribution rules as versioned, testable policy rather than code buried in a run script. Each rule set is dated, so re-running a 2024 distribution applies 2024 policy and not today's. Every allocation carries the rule version that produced it. That single design choice is what makes an audit a conversation rather than a forensic exercise, and it is what lets you model a proposed rule change against last quarter's actual data before the board votes on it.

Problem 4: members want to know why, and one number is not an answer

A member opens a statement and sees an amount. The question they ask, always, is why it is lower than last time. If answering requires a staff member to run a query, you have a support cost that scales with membership and a trust problem that scales faster.

Explainability is a property of the pipeline, not a report bolted on at the end: this payment came from these usages, matched at this confidence, allocated under this rule version, net of these deductions. If the pipeline throws away intermediate state to save storage, the answer is unrecoverable and no dashboard can invent it.

What a custom build does: keep the lineage. Every distribution line links back to the usage lines that produced it and forward to the payment that carried it. The member portal exposes that at the level members can act on, with the ability to challenge a line and open a claim without emailing anyone. Publishers and larger members get bulk access through an API and file exports in the formats their own systems consume, because a major publisher will not use your web portal regardless of how good it is.

Problem 5: the run takes eleven days and nobody dares re-run it

The distribution run is a sequence of jobs held together by a runbook and one engineer who knows the order. If something fails at step nine, restarting is frightening because some steps are not safely repeatable, and the member payment deadline is fixed.

What a custom build does: make the run idempotent and re-entrant, so any stage can be re-executed on the same inputs and produce the same outputs. Usage ingestion writes immutable batches. Matching writes decisions, not mutations. Allocation is a pure function of decisions plus rule version. That turns an eleven day ritual into something you can run twice on a Tuesday to compare outcomes, and it makes correcting a mistake routine rather than a crisis.

What this costs and how long it takes

Digital Heroes has delivered more than 2,000 projects, and the honest shape for a collecting society is this. A first release covering usage ingestion for your two or three highest value sources, a matching pipeline with a usable review queue, and a repeatable allocation run costs $90,000 to $200,000 over 14 to 20 weeks. A full platform adding claim conflict and dispute workflow, retroactive adjustment, member and publisher portals, reciprocal exchange, and audit lineage runs $250,000 to $700,000 phased across 9 to 18 months.

What drives the number up: the number of distinct usage sources, because each format is its own ingestion project and broadcasters do not follow the spec they claim to follow. Reciprocal exchange with foreign societies, since standards such as CWR and DDEX are implemented differently by every counterparty. Historic data migration, which is almost always worse than expected. And multi-right operation, if you administer performing and mechanical or neighbouring rights in the same system, because those rules do not merely differ, they conflict.

What holds it down: start with the highest value usage source and the matching loop, and leave the member portal for phase two. Recovered money from a better match rate funds the rest of the programme, and it is the number your board understands.

Build versus buy, and when buying is right

Buy, and we will say so plainly, 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 constraint on custom software here is not money, it is whether you have or can hire the two or three data people who will own it.

Build when two or more of these are true. Your unmatched value has been flat or rising for three consecutive distributions despite effort. Your distribution rules require a spreadsheet outside the system to compute correctly. You handle multiple rights or multiple 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.

The threshold is not organisation size, it is whether the coordination logic between usage, repertoire, claims and policy has become the institution itself. For a society, it usually has, which is why this category builds more often than most.

How to choose a developer for collective management software

Ask them to draw the data model before you sign anything. A team that has done this will draw work, interested party, share with territory and date range, claim, usage, match decision, allocation, and payment, and they will immediately point at share overlap as the hard part. A team that draws songs and royalties has built a marketplace and will discover conflicts in your production data.

Ask how they will handle a retroactive correction to a closed period. The answer must involve reversal and reissue with audit trail, not editing history. If they hesitate, they have not run a real distribution.

Ask what they will do when the match confidence is 0.62. The right answer talks about thresholds per usage type and value, a review queue that is usable at volume, and corrections feeding back into scoring. The wrong answer is that the model will get better.

Ask who owns the code, the models, the training data from your reviewers, and the cloud accounts. All four should be yours in writing before kickoff. At Digital Heroes the client owns everything from the first commit, and for a society that also matters institutionally: your members' data and your repertoire intelligence should not accrue to a supplier.