Subsidiary Rights and Permissions Software: Why Publishers Lose Track of What They Still Control

Why the rights grid stops being knowable at a certain backlist size

A rights director is preparing for a book fair. She needs a list of what is available: which titles have free translation rights in which languages, which options have lapsed, which audio rights came back when the licensee let the term run out, which film options expired last spring. The source of truth is a rights grid in a spreadsheet, a folder of contract PDFs going back thirty years, an inherited database from a house acquired in 2011 that nobody can query, and the memory of a colleague who retired.

Publishing subrights is the purest form of a data problem dressed as a commercial one. The income is high margin: a translation licence costs almost nothing to fulfil beyond the file and the paperwork, and permissions income is nearly pure contribution. But you can only sell what you know you control, and the knowledge decays. Every year the backlist grows, every year a few contracts revert or lapse, and every year the gap between what you actually own and what you can prove you own gets wider.

The specific failures repeat across houses. Options expire without anyone noticing, so a title sits blocked for two years after it stopped being blocked. Reversion requests from authors take weeks to answer because someone has to read the contract and calculate whether the sales threshold was met. Translation licences renew or lapse without a chase. And when the head of rights leaves, a meaningful part of the asset register leaves with her.

Problem 1: rights are per title, per type, per language, per territory, per term

The rights grid is conceptually simple and combinatorially awful. For one title you may control world rights in all languages, or English language rights in specified territories with another publisher holding rest of world, and within that you have volume rights, translation rights per language, audio, dramatic, first and second serial, book club, large print, anthology and quotation, digital, and now audio adaptation and machine learning uses that older contracts never contemplated.

Klopotek and Virtusales Biblio both model rights, and for houses whose contracts fit the assumed shape they do it well. Ingenta handles content distribution and the commercial side competently. Where all of them strain is the clause library problem: your contracts changed in 2006, again in 2014, and again when audio became serious, so the same right behaves differently depending on which contract generation a title falls under. Systems built around a fixed rights taxonomy express that as a note in a field.

What a custom build does: separate the right from the clause that governs it. Each title links to a contract, each contract belongs to a template generation, and each right record carries the clause reference that defines its scope, its reversion trigger and its split. Then the grid becomes derived rather than maintained, and the question of which titles have free German translation rights is a query rather than an archaeology project. That single shift is what makes a book fair list take an afternoon instead of a fortnight.

Problem 2: reversion is a calculation nobody performs until an author asks

Modern contracts define reversion by conditions rather than by a date. Common triggers include the work being out of print under a definition the contract specifies, sales falling below a threshold over consecutive royalty periods, or the publisher failing to exploit a right within a defined window. Older contracts define out of print in terms that predate print on demand entirely, which is why the definition matters so much and why the answer differs by contract generation.

Title management systems hold sales data and hold contracts, and connect the two only through a human. So when an author or agent writes asking for reversion, the process is: find the contract, read the clause, pull the sales history, compute, reply. It takes days and it produces inconsistent answers across a list.

What a custom build does: encode the reversion test as an evaluable rule attached to the contract, then run it continuously against sales data. The system flags titles approaching a trigger before the author does, which changes the conversation entirely. Knowing a title will hit its threshold in two royalty periods lets you decide deliberately whether to promote it, reissue it or let it revert cleanly. Rights that have already reverted must be marked unsellable everywhere immediately, because selling a right you no longer hold is the error in this field that costs real money and real reputation.

Problem 3: permissions is a small revenue line with a large administrative tail

Permissions requests arrive constantly. An academic wants to reproduce two pages in a coursepack. A documentary wants to quote four lines. A publisher in another country wants a chapter for an anthology. Each is worth a modest fee, each requires checking whether you control the right being requested, whether the author has approval, whether there is a third party illustration inside the extract that you never controlled, and each generates a licence document.

Most houses run permissions from a shared inbox with a fee schedule in a document, and the economics look poor because the handling cost eats the fee. Some drop permissions entirely, which is a real loss of income and also a service failure to the academic community.

What a custom build does: turn permissions into self service intake with rules. The requester picks the title and describes the use, and the system checks the rights position and extract size against your policy, prices from a schedule, routes anything unusual to a human, and issues the licence with a reference. Cases needing judgement still get it. The routine ones stop costing more than they earn, which turns a nuisance into a line item.

Problem 4: subrights income and author splits are reconciled by hand at royalty time

Subrights income does not behave like sales income. A translation advance arrives from a foreign publisher, is subject to withholding tax in that country, splits with the author at a rate defined in the contract, may split further with a co agent, and must appear on the author's royalty statement in the correct period against the correct title, possibly recouping against the original advance. Multiply by a few hundred licences a year across several currencies.

Royalty systems handle sales royalties well. Subrights income tends to be entered manually into the royalty run from a spreadsheet the rights department maintains, which is where the errors and the year end scramble come from. Agent splits vary per deal and per territory, and a wrong split is an author relations problem, not just an accounting one.

What a custom build does: attach the money to the deal. The licence record knows its advance, royalty terms, split percentages, co agent, currency and withholding position, so income allocation is computed rather than transcribed. Statements reconcile to deals, and an agent query can be answered from one screen. Royalty accounting stays in your existing system, with the rights platform owning deal truth and feeding it, because replacing it outright is a much larger project than the value it returns.

Problem 5: modern rights categories do not exist in your legacy system

Podcast adaptation, audio abridgement, interactive and app formats, and text and data mining or machine learning use are all live commercial questions now. What a contract signed in 2009 says about them is usually nothing, and whether silence favours the publisher or the author depends on the jurisdiction, the grant language and your appetite for argument. That is a legal question and a publisher should take advice rather than a software opinion.

The software question is narrower and answerable: can your system record a right category that did not exist when the system was designed, distinguish between rights explicitly granted, explicitly reserved and simply unaddressed, and report on the third category across the backlist. Legacy title management systems generally cannot, because their rights taxonomy is fixed and has no state for silent.

What a custom build does: make the rights taxonomy extensible and make unaddressed a first class state alongside granted and reserved. Then when a new licensing opportunity appears, you can produce the list of titles where the position is clear and the list where it needs review, instead of guessing. Publishers who could answer that question quickly when machine learning licensing conversations started had a real commercial advantage over those who could not.

What this costs and how long it takes

In our delivery experience a first release covering the rights grid with an extensible taxonomy, contract and clause capture, option and expiry tracking with alerts, reversion rule evaluation and permissions intake runs $55,000 to $110,000 and ships in 10 to 14 weeks. A full platform adding subrights deal and income management with agent splits and currencies, rights guide and fair list generation, an author or agent facing portal, and integration into royalty and title management systems runs $130,000 to $300,000 phased across 6 to 10 months.

What drives price up in publishing rights specifically: the number of distinct contract generations in your backlist, since each needs its clause behaviour modelled and verified. Imprint and territory structure, if you run several imprints with different practices. Legacy data, which here means an inherited database from an acquisition that must be interpreted before migration. Multi currency and withholding tax if you licence widely. And author portals, which look simple and carry real access control and data protection requirements.

What keeps it down: modelling the last two contract generations properly and the older ones as exceptions, starting with translation and audio rights rather than the whole grid, and leaving royalty integration to a later phase.

Build versus buy for publishing rights systems

Buy if you are a small or mid sized house publishing under roughly fifty titles a year on a consistent contract template. A rights module in Biblio or a well maintained grid is proportionate, and the money is better spent on acquisitions and marketing. Buy also if your primary need is title and product data rather than rights, because Klopotek and Biblio are strong there and the rights layer comes along with it.

Build when two or more of these are true. Your backlist runs to thousands of titles across multiple contract generations and nobody can produce the availability picture without archaeology. You have acquired another house and inherited a rights database you cannot query. Your reversion answers take days and are inconsistent. Or you are being asked new licensing questions, whether podcast adaptation or machine learning use, and cannot report on where your backlist stands. University presses tend to hit the permissions volume argument first, because their extract requests are constant and their staffing is not.

How to choose a developer for publishing rights software

Ask them to model a reversion clause. A developer who has worked in publishing will ask what the contract's out of print definition says and whether print on demand availability counts, because that is the crux. A developer who has not will propose a date field, and you will be back to reading contracts within a year.

Ask how they would handle the fact that your contracts changed three times. The right answer is a clause library keyed to template generations with rights behaviour attached, not a single rights table with a notes column.

Ask what they would do with the inherited database from your acquisition. Good answers involve profiling the data, mapping what is trustworthy, and importing with explicit confidence markers so nobody sells a right on the strength of a record that was never verified. Bad answers promise a clean migration before looking.

Ask who owns the code and the data and get it into the contract before kickoff. At Digital Heroes the client owns the repository from the first commit. Your rights grid is a register of assets accumulated over decades, and it should live somewhere you control absolutely.