Content Licensing, Avails and Windowing Software: Why the Rights Database Decides What You Can Sell

Why the rights database is the most expensive spreadsheet in the company

A sales executive is at a market. A buyer wants pay television rights to a package of twelve films for a four year term starting next January, and the executive needs to know in the room whether those rights are free. What happens is that he messages the rights manager, who opens a workbook called AVAILS_MASTER, cross references a second sheet of output commitments, remembers that three titles have a holdback because a subscription service took a first window, checks a folder of contract PDFs, and replies ninety minutes later with a qualified maybe.

That is not a tooling failure at the small end. It is genuinely how a large amount of content distribution runs, including at companies with substantial catalogues. The reason is that rights are not a simple inventory. A right is a slice of a multidimensional space: territory, language, media type, term, exclusivity, and sometimes platform or business model. You do not own a film, you own a set of slices, some acquired, some inherited from a chain of prior agreements, some encumbered by holdbacks that reference other agreements you may not have on hand.

The cost of getting this wrong is asymmetric and that is what makes the category interesting. A missed sale costs you a deal. A conflicting sale costs you a breach, an indemnity claim, a damaged relationship with an output partner, and legal fees. Everyone in distribution has a story about a title that went live in a territory it should not have, and the story is always told quietly.

Problem 1: rights are dimensional and spreadsheets are flat

You can express a right in a spreadsheet row. What you cannot express is overlap. If a licence grants free television in a territory in one language exclusively for three years, and another grants basic cable in the same territory in the same period, whether those conflict depends on your media type definitions and the exact wording, and no cell colour will tell you.

Rightsline, FilmTrack and Whip Media all model rights properly, and they are real products built by people who understand this. Where they are weaker is bending to your specific structures. Media type taxonomies are opinionated and yours may not match. Inherited rights, where a right flows through an acquisition chain and carries its original restrictions forward, are frequently modelled as a note rather than as data. Holdbacks that reference a window in a different agreement are often expressible only as a manual date.

What a custom build does: represent the right as an interval over each dimension and make conflict detection a computation rather than a memory. When someone proposes a sale, the system evaluates the proposed slice against every granted slice and every encumbrance, and either clears it or names the specific conflicting agreement and clause. That single behaviour, asked at the deal memo stage rather than at contract stage, is the whole business case. It turns the rights manager from a lookup service into a person who manages rules.

Problem 2: avails are generated by hand and are stale on arrival

An avails list is what you send a buyer: here is what I can sell you, in your territory, in this period. Producing one means resolving every title's rights position as of a future date, subtracting what is already committed, applying holdbacks, and formatting to the buyer's expectations. Done by hand, an avails list takes days and is out of date the moment another deal closes.

The industry has a standard for this. The Entertainment Merchants Association avails specification exists precisely so that a distributor and a platform can exchange availability data in a machine readable shape, and the Entertainment Identifier Registry gives titles stable identifiers so that both sides are talking about the same asset. Many distributors still do not use either, and produce spreadsheets with title names that the buyer then has to match by hand.

What a custom build does: make avails a query, not a document. Given a territory, period, media type and buyer profile, resolve the catalogue live and output in whatever shape that buyer takes, including the standard avails format. Every list carries its date and assumptions, so when a buyer returns three weeks later you regenerate and show what changed. Adding stable identifiers is dull work with a disproportionate payoff, because it removes a whole class of matching errors from every downstream conversation.

Problem 3: the contract says one thing, the system says another, and the contract wins

Rights data enters the system because someone read a contract and typed. Long form agreements run to dozens of pages with schedules, amendments and side letters. The person typing is not usually the person who negotiated. Nuance gets lost: a most favoured nation clause, a step in the exclusivity, a condition that a right only vests on delivery of certain materials.

Off the shelf systems store an attachment and a set of fields. The link between the field and the clause that produced it is a human's recollection. So when a dispute arrives, the work of proving your position starts from the PDF again.

What a custom build does: keep provenance. Every rights record points at the agreement, the amendment and ideally the clause reference it derives from, so a lawyer can trace a claim to its source in one step. Document extraction pays for itself here: run long form agreements and amendments through a structured extraction pass that proposes rights records with the source text attached, then have an analyst confirm or correct each one. It changes the job from reading and typing to reviewing, which makes the legacy contract backlog tractable. Never let extraction write a record unconfirmed, because the failure mode is a silent breach.

Problem 4: output deals and volume commitments are tracked separately from sales

If you have an output agreement, you owe a partner a certain flow of product on defined terms. That obligation constrains everything else you sell, and it is usually tracked in its own spreadsheet by a different person than the one tracking sales. So the two views drift, and you discover at the end of a period either that you have under delivered against a commitment or that you sold something you owed elsewhere.

Rights systems tend to model grants outward well and commitments inward less well, because the commitment is not a right, it is a promise about future rights. That asymmetry is where the gap sits.

What a custom build does: model the commitment as a first class object with its qualifying criteria, its volume or value target, and its period, then evaluate every candidate sale against open commitments before it is agreed. The system tells the sales team not just whether the rights are free but whether this title is already spoken for by an output partner. It also produces the commitment status report a chief executive actually asks for: what do we owe, to whom, by when, and are we on track.

Problem 5: sales, delivery and finance are three systems that never agree

A deal closes. Materials have to be delivered, often to a specification. Invoices have to be raised on a schedule tied to milestones rather than to the calendar. Participations and residuals may flow to producers and talent based on the revenue that deal generates. In most distributors those three things live in a sales tracker, an operations spreadsheet and an accounting package, joined by a person.

The join is where money goes missing. A licence period starts, the invoice is not raised because nobody told finance, and it surfaces at year end. Or delivery materials were never sent, so the licensee never exploited the window, and the shortfall appears in a reconciliation two years later.

What a custom build does: make the deal the spine. Contract terms generate the billing schedule, delivery obligations become tracked tasks with due dates derived from window start, and revenue posts against the deal so participation calculations run off real numbers. Accounting stays in your finance system. The rights platform owns the truth about what was sold and what is owed.

What this costs and how long it takes

In our delivery experience a first release covering the dimensional rights model, contract to rights ingestion with human confirmation, conflict detection and avails generation runs $85,000 to $170,000 and ships in 14 to 18 weeks. That is enough to answer the question a sales executive asks from a market floor, which is the point of the exercise. A full platform adding deal memo through contract workflow, output commitment tracking, delivery management, billing schedules, participations and partner reporting runs $220,000 to $500,000 phased across 8 to 15 months.

What drives price up in rights specifically: the age and messiness of your back catalogue, since populating rights for a library assembled through decades of acquisitions is the largest and most underestimated line. The complexity of your media type taxonomy, because every extra dimension multiplies the conflict logic. Multi currency and multi entity structures. Participations, which can be a project on their own. And finance system integration, straightforward with a modern platform and painful with a legacy one.

What keeps it down: modelling only the dimensions you actually trade on, starting with your top revenue titles rather than the full library, and accepting that legacy contract capture continues in parallel for months after launch.

Build versus buy for rights and avails management

Buy if your catalogue is modest, your terms are conventional, and you trade in a manageable number of territories. Rightsline and FilmTrack are mature and will do the job, and Whip Media brings useful data alongside the workflow. Configuration is cheaper than construction when the shape fits.

Build when two or more of these are true. Your rights structures include inherited chains, conditional vesting or holdbacks referencing other agreements, and your system stores those as notes. You have output deals or volume commitments that constrain what you can sell and are tracked separately. Your media type taxonomy does not match what vendors offer and you maintain the translation in your head. Or the answer to what can I sell in this territory next year takes more than an hour, which for a distributor of any size is a live commercial handicap.

One honest caution. This is a category where a bad build is worse than a spreadsheet, because a spreadsheet does not give false confidence. If you build, the conflict logic has to be right and the provenance has to be traceable, or people will keep checking the contracts anyway and you will have paid for a second opinion nobody trusts.

How to choose a developer for rights and licensing software

Ask them to whiteboard a right. You want territory, language, media, term and exclusivity as dimensions, and you want them to reach for interval logic when you ask how conflicts are detected. If they describe a table of licences with a status field, they will discover overlap detection the hard way on your budget.

Ask how they would model a holdback that depends on a window in a different agreement. This is the question that separates people who have built rights systems from people who have built catalogues. The answer should involve references between agreements, not a manually entered date.

Ask what they would do with two thousand legacy contracts. A good answer combines structured extraction with mandatory analyst confirmation and a prioritisation by revenue. An answer that promises full automation is either naive or dishonest, and in this category the cost of a silent error is a breach.

Ask who owns the code, the data and the infrastructure accounts, and put it in the contract before kickoff. At Digital Heroes the client owns the repository from the first commit. Your rights data is the underlying asset of the entire distribution business, and it should never sit anywhere you cannot walk away with it.