Sync Licensing Management Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does the ownership model get underscoped so often?

Briefs for sync systems usually arrive as catalogue and workflow. Store the tracks, store the metadata, move a licence through statuses from enquiry to signed. Every part of that is reasonable and none of it addresses the thing that decides whether you win business.

A composition is a set of percentages across writers and publishers, and the master sits separately with a label or an artist. Clearance therefore is not a status on a licence, it is an independent state per party. A single status field marching through a workflow can tell you that a deal is in clearance. It cannot tell you that three parties are approved, one is outstanding, that party is an administrator who typically takes four working days, and the shoot is in nine.

The underscoping shows up the first time a deal is at risk. Your sync manager knows who she is waiting on because she is holding it in her head, and the system contributes nothing to the only question that matters. So she keeps a spreadsheet, and the software becomes an archive.

Scope it correctly by insisting that each required approval is its own object with a party, a share, a state, a contact and a response history, before any workflow screens are designed. Ask the supplier what happens when one party vetoes after three have approved, and what the dashboard shows. Ask them to define one stop and master versus publishing rights out loud. It takes thirty seconds and it filters heavily, because a developer who has not built in music will model an owner field and discover the problem on your money.

What goes wrong when splits data is migrated?

Splits are assembled over years from statements, society registrations and contracts, and parts of them are stale. Every rights holder knows this and most still expect the migration to be a load.

Three problems recur. First, shares that do not total correctly. This is more common than anyone admits, and the temptation is to normalise quietly so the data looks clean. That quiet correction becomes a payment error later, and it removes the evidence that anything was ever wrong. Second, conflicting sources. Your copy, the co publisher's copy, the society registration and the writer's belief may all differ, and a migration that picks one source silently has made a commercial decision inside a technical task. Third, identity. The same writer appears under three name spellings, two societies and an old publisher, and deduplicating them badly merges shares that belong to different people.

The way through is to stop treating splits as numbers. Store each share with its source, whether a contract, a society registration or a statement, and the date it was last verified. Surface shares that do not total as a data quality exception with provenance attached rather than normalising them. Then run verification as an ongoing programme alongside the build, prioritised by earnings, rather than as a prerequisite. Waiting for perfect splits means never starting, and confidence displayed honestly is more useful to a sync manager than a clean number nobody trusts.

Why do the society, accounting and delivery integrations break after launch?

A sync platform sits between systems that change on their own schedules, and the failures are quiet rather than loud.

Statement and registration ingestion is the most fragile, because formats differ by territory and change without notice, and a parser that silently produces zero rows looks exactly like a period with no activity. Accounting is second: sync fees allocate across writers and publishers by share, and if allocation is recomputed rather than recorded, a later splits correction retroactively changes what you already paid, which is a reconciliation problem that takes months to unpick. Delivery and asset storage is third, where a stems package or an instrumental gets replaced and the licence still points at the previous file.

The failures are all silent because nothing errors. A parser returning nothing, an allocation recomputed from current data, a file replaced in place: each is a successful operation producing a wrong result.

Design against it. Alarm on absence, with an expected arrival interval per source, so a statement that never arrived raises an alert rather than a gap. Validate a schema contract on every ingest so a changed format fails loudly with the specific violation attached. Snapshot allocations at the moment they are calculated and store them, so a later splits correction produces a visible adjustment rather than rewriting history. And version assets rather than replacing them, since the file a licence covers is part of what was licensed.

What happens when restrictions and licence lifecycle are not covered?

These two are the deferrals that cost money, and both look optional at scoping.

Restrictions first. Writers and artists restrict uses: no political advertising, no alcohol, no tobacco, no gambling, no firearms, sometimes approval required for any advertising, sometimes a restriction specific to a territory or to a competitor of an existing endorsement. Systems that model restriction as free text block nothing, so a quote goes out, work proceeds, and the restriction surfaces during approval. That is late enough to be embarrassing with an agency and sometimes late enough to be expensive. Encode restrictions as structured rules against categories, with the source clause attached, and evaluate them at search time rather than at approval time. A supervisor searching for a beverage campaign should never see a track that cannot clear for it. Most favoured nation terms deserve the same treatment, because enforcing them by hand across a multi party clearance produces quiet errors in fees.

Second, the licence tail. A sync licence has a term, a territory, a media scope and often options to extend. Once the fee is in, attention moves to the next deal, and nothing tracks the tail until a writer asks why their song is still running in a market that expired last year. Treat the licence as a live object whose dates generate work: expiring options are commercial conversations worth having in advance, term ends are compliance checks, and cue sheet filing determines performance income and is frequently dropped after delivery. None of this is complex. It simply has to exist before the first licence is issued, because retrofitting it means auditing everything you have already signed.

Should you build custom or configure what you already own?

If you control your catalogue outright, which is the normal case for a production music library, the problem this category exists to solve does not apply to you. Disco or Source Audio for pitching and delivery plus a solid licence template will serve you well, and a clearance system would be an expensive answer to a question you do not have. The same holds if your sync volume is low enough that one manager comfortably holds every live deal in her head, because that person is faster than any system until she is overloaded.

If you already use Disco or Source Audio, be clear about what they are good at. They are strong on discovery, pitching and getting music in front of supervisors quickly, and replacing that is rarely where the value is. Synchtank is a serious rights product and models rights properly. What none of them can do is make your splits accurate, because that data problem is yours and every tool inherits whatever you feed it.

The build case appears when your catalogue is co owned so most deals need third party approvals, when splits live across several sources and nobody fully trusts them, when restrictions exist in contracts but nowhere that can block a quote, or when the chase is a full time job. The signal that usually funds the project is losing deals to speed. If your team can name three in the last year that went elsewhere while you were waiting on clearances, the arithmetic makes itself. Before committing, ask your current tool to produce a list of one stop titles. If it cannot, you have found the gap.

How do hidden costs get into the quote?

Five items sit outside most sync quotes. Splits verification, which is an ongoing programme rather than a task and is routinely priced as data migration. Whether you administer both composition and master, since a combined operation carries two ownership models and roughly doubles the clearance logic.

Third, society registration and statement ingestion, which is valuable and fiddly because formats differ by territory and each is separate work. Ask which territories are in scope by name. Fourth, multi currency and withholding if you licence internationally, which changes the accounting design rather than adding a field. Fifth, a client facing portal, which brings access control, secure streaming and watermarking requirements that have nothing to do with the rest of the build.

Add audio analysis features to the watch list too. Similarity search against an uploaded temp track and automatic tagging are individually affordable and collectively a line item. Attach a written exclusion list to a fixed first release and name what is out.

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

The builds that work start with the top earning catalogue rather than everything. Clearance value concentrates heavily, and a system that resolves ownership and approvals properly for the titles that actually get pitched delivers inside a quarter, while a full catalogue ingest delays the first useful day by months and adds verification work on titles nobody licenses.

The second differentiator is whether clearability reaches search. A beautiful search that returns tracks you cannot clear for this use is worse than no search, because it costs a supervisor time she does not have and teaches her that your catalogue is unreliable. Filter by one stop status, by restriction compatibility with the brand category, by territory availability and by whether the required approvals come from parties with fast response histories. That last filter only becomes possible after a year of recorded response times, which is a reason to record them from day one.

The third is control of the data. You should own the repository, the database and the cloud accounts, with the right to hire another firm, agreed in writing before kickoff. Ownership, restriction and approval history is the operating asset of a rights holder. It should never live somewhere you cannot take it from, and it should never be recomputed in a way that loses what you knew at the time.