Music Catalog Metadata and DDEX Delivery Software: Why Does Your Money Sit Unmatched While Deliveries Fail Quietly?

Why bad metadata is a revenue problem, not an admin problem

A label group acquires a catalog. Twelve thousand recordings arrive as a folder of audio, a spreadsheet of titles and a list of contracts. Some recordings have an ISRC. Some have two, because they were registered once by the original label and again by a distributor who assumed there was none. Contributor credits exist for about a third of the catalog and are inconsistent for the rest, with the same session drummer appearing under four spellings. Territory rights differ from the parent catalog because of side agreements from the 1990s that were never digitized.

That catalog gets delivered to platforms anyway, because there is a release schedule. What follows is predictable. Some recordings land on a wrong or duplicate artist page, splitting streaming history. Some deliveries report success and never appear. Publishing royalties sit unmatched at collection societies because the underlying work identifiers and writer splits were never registered against the recordings. A takedown notice arrives in one territory where the acquired rights did not actually extend. Each of these is a small operational failure and each one is money that either does not arrive or arrives to someone else.

The tooling around this is usually a distribution platform, a spreadsheet per delivery batch, a Dropbox of contracts, and an operations person who has memorized which platform rejects releases for what. That works at one scale and stops working when catalog volume or acquisition activity outpaces the person.

Problem 1: identifiers are the data model, and yours are not reconciled

Music has a genuinely difficult identity graph. A recording has an ISRC. A composition has an ISWC. A release has a UPC or EAN. Parties have IPI or CAE numbers, sometimes ISNI. Platforms have their own internal identifiers that you only learn after delivery. A single recording can appear on an original album, a deluxe reissue, a compilation and a territory specific edition, each with its own release identifier and sometimes a new ISRC that should never have been created.

Most catalog owners keep this in a spreadsheet where the release is the row, which quietly asserts that a recording belongs to one release. It does not. What a build does is model party, work, recording and release as separate entities with explicit relationships, then run identifier reconciliation across sources: matching, proposing merges with a confidence score, and requiring human confirmation for anything ambiguous. Critically, merges must be reversible with full provenance, because a wrong merge in a music catalog corrupts royalty attribution and you will need to prove what changed and when.

The output that matters day to day is boring: a completeness view. Which recordings lack an ISWC, which have no writer splits, which have contributor credits missing, which have no territory rights record. That view is the queue that converts unmatched royalties into matched ones.

Problem 2: every platform has its own dialect of the same standard

DDEX exists precisely so this is not chaos, and it helps. But an ERN message that one platform accepts can be rejected by another over a field that is optional in the specification and mandatory in their profile. Message versions differ across partners, so you will be generating more than one version of the same standard at the same time for years. Some partners require particular handling for pre orders, instant grat tracks, explicit flags, non Latin script titles, or artist role coding. Sales reporting comes back in its own formats, which you need in order to match income to recordings.

Then there are the error semantics. A rejection might be a hard failure, a warning that silently prevents live availability, or a success followed by nothing appearing. Anyone who has run a supply chain knows the third case is the worst, because your system says delivered and the artist says it is not there.

A build handles this as a validation rule engine per partner profile, run before delivery rather than after rejection. Rules are configuration, not code, so an operations lead can add a partner requirement the week it changes. Delivery orchestration then manages batching, transfer, retries and acknowledgement, and every partner error code maps to a plain language task with an owner. Nobody should have to know what a specific numeric error means, they should get a task that says which field to fix on which release.

Problem 3: FUGA and Revelator are good products with their own model

FUGA and Revelator are real platforms with real delivery pipelines, and for many labels they are the correct answer. We tell people that regularly. FUGA has deep partner coverage and a mature supply chain. Revelator serves labels and distributors who want rights and royalty handling alongside distribution.

The constraint is structural rather than a quality complaint. They are products with an opinion about how a catalog is shaped: how ownership is expressed, how splits work, what a release can be, which identifiers are authoritative. If you are a label group carrying forty years of inherited catalog with conflicting identifiers, chain of title that runs through three acquisitions, and side agreements that carve out territories, you end up reshaping your data to fit the product, and the parts that do not fit go into a spreadsheet next to it. If you are a distributor, there is a second problem: your delivery pipeline is your product, and building your business on someone else's economics puts a ceiling on your margin and your ability to differentiate.

The decision is honest and specific. If your catalog fits their model and you are a label rather than a distributor, use them. If your catalog is the awkward shape that comes from acquisitions, or if delivery is the business rather than a cost, build.

Problem 4: chain of title and territory rights that nobody can query

Rights in a catalog are rarely uniform. An artist's first two albums may be owned outright, the next three licensed for a term, one album reverted, and a compilation carries different territory rights per track. Layer on distribution agreements with their own terms and a few tracks with sample clearances that limit certain uses. This is normal, and it is almost never held in queryable form.

What that costs you is specific. You cannot answer whether a given recording can be delivered to a given platform in a given territory today, so someone guesses, and the guess produces either a takedown or unexploited rights. You also cannot value your own catalog properly for a sale or a financing without a rights researcher spending weeks.

A build models rights as time bounded, territory bounded grants attached to recordings and works, with the contract document linked as evidence and a term end date that raises a review before it lands. Delivery then checks rights automatically: a release cannot be sent to a territory where the grant has lapsed. This is the control that turns rights from a legal document into an operational guardrail.

Problem 5: you deliver, and then you stop looking

The last mile of a supply chain is confirmation. Did the release actually appear, on every platform, in every territory, with the right artist, the right credits and the right release date. Most operations check manually for priority releases and never check the long tail, which is where the silent failures accumulate.

A build runs live status reconciliation: after delivery, it verifies availability and key metadata on each platform through their catalog interfaces, compares against what was sent, and raises differences as tasks. Update and takedown messages follow the same path with proof of effect rather than proof of sending. This is the part that pays back on catalog rather than new releases, because a long tail with two percent silent failure across a hundred thousand recordings is a permanent revenue leak nobody has ever quantified internally.

What this costs and how long it takes

A first release covering the canonical party, work, recording and release model with identifier reconciliation, the per partner validation rule engine and ERN generation with delivery orchestration to a first set of platforms runs $80,000 to $180,000 and ships in 14 to 20 weeks in our delivery experience. A full platform adding live status reconciliation, update and takedown handling, sales report ingestion with matching back to recordings, rights and chain of title modeling, and a catalog data quality dashboard runs $200,000 to $500,000 across 9 to 15 months.

What drives price up specifically here: the number of delivery partners, since each profile is real work measured in weeks, not days, and the first three teach you what the abstraction should be. Legacy catalog reconciliation, which is the single most underestimated line and depends entirely on how bad your inherited data is. Sales report ingestion, because formats vary and matching income to recordings at scale is its own engineering problem. Audio processing if you handle masters, transcodes and fingerprinting. And publishing side registration if you administer works as well as recordings, which is effectively a second supply chain.

What keeps it down: two delivery partners, your worst catalog segment and the completeness view. That combination produces measurable recovered income before the full build finishes.

Build versus buy, and when buying is right

Buy if you are a label releasing under a few hundred tracks a year with clean, self created catalog and no acquisitions. FUGA, Revelator or a similar distributor gives you partner coverage you cannot economically replicate, and building your own pipeline would be an expensive way to reach parity. We would say the same to most artist services companies.

Build when two or more of these apply. You have acquired catalog with conflicting identifiers, incomplete credits or unclear chain of title. You are a distributor or aggregator where delivery is the product and partner economics decide your margin. You administer both recordings and works and need one identity graph across both. You need rights checks enforced at delivery time because you operate territory limited grants. Or your operations team spends more than about a day a week on delivery errors and status chasing.

The tipping point is whether your catalog is the shape a product expects. Clean and self generated fits. Inherited and acquired does not, and forcing it produces a second spreadsheet that becomes the real system anyway.

How to choose a developer for music supply chain software

Ask them to draw the identity graph before you sign anything. Someone who has done this separates party, work, recording and release, knows that recordings appear on many releases, and will ask how you want to handle a merge that turns out to be wrong six months later. Someone who draws tracks and albums has built a media library.

Ask specifically how they will handle partner profile differences. If the answer is code per partner, maintenance will overwhelm you by partner number eight. You want profiles expressed as configuration with a validation engine that runs before delivery, so an operations lead can respond to a spec change without a release cycle.

Ask what they will do about deliveries that report success and never appear. If they have not thought about live status reconciliation, they have built a sender rather than a supply chain, and the silent failures will stay invisible exactly as they are now.

Ask who owns the code and settle it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire another firm. At Digital Heroes the client owns the code from the first commit. For a distributor especially, this pipeline is the business, and it should never sit on someone else's infrastructure account.